FAQs

They come from attitudinal segmentation. Rather than sorting agencies by size, revenue, discipline, or region, Agency Core groups leaders are grouped by shared patterns in what they believe and feel, drawn from dozens of attitude questions. 

The groups aren’t assigned in advance; they’re revealed by the pattern across responses. Two agencies of the same size in the same city can land in different segments because they think about their work differently.

The segments describe a mindset that shows up across the data, not a fixed box. You might not self-identify with the segment your answers place you in, since each cluster reflects a pattern across many responses rather than a single question. 

As Brian Gerstner notes, most agency owners recognize themselves in all three at different points in their own history.

Most well-scoped automation projects begin showing measurable time savings within 30 to 60 days of full deployment. 

However, the more meaningful ROI—error reduction, capacity reallocation, and downstream efficiency gains—usually takes 90 to 180 days to quantify accurately. 

Projects that skip the scoping and documentation phases tend to take significantly longer, if they deliver ROI at all.

Traditional automation (like RPA) follows rigid, predefined rules—if X happens, do Y. AI-powered automation can handle more variability, learning from patterns in data to make decisions within defined parameters. 

The practical distinction matters most in workflows with semi-structured inputs, like categorizing incoming emails or extracting data from inconsistent document formats, where strict rules break down.

Small businesses often see proportionally larger gains because their teams are leaner, which means repetitive tasks consume a bigger share of everyone’s day. 

The key is starting with low-cost, focused automations—appointment scheduling, lead follow-up sequences, invoice reminders—rather than enterprise-scale implementations. A single well-chosen automation can reclaim five to ten hours per week for a small team.

This is one of the most overlooked aspects of automation. When the underlying business process changes—new approval requirements, updated compliance rules, additional steps—the automation must be updated accordingly. 

Businesses that treat automation as a set-it-and-forget-it investment inevitably end up with workflows that no longer match reality. Quarterly reviews and clear ownership of each automated workflow help prevent drift.

Not when it’s planned in from the start. Most accessibility requirements—semantic structure, keyboard support, sufficient contrast—are cheap to build in early and expensive to retrofit later. 

The constraint tends to sharpen design decisions rather than restrict them, because it forces clarity in navigation and hierarchy that benefits every user.

They’re related but not identical. WCAG is a technical standard maintained by the W3C, while the ADA is US civil rights law that doesn’t name a specific version of WCAG in its text. 

In practice, conforming to WCAG Level AA is the widely accepted way to demonstrate a good-faith accessibility effort, which is why it’s treated as the working benchmark even where the law doesn’t spell it out.

Accessibility isn’t a one-time audit. Every new feature, template, or third-party widget can introduce barriers, so testing belongs in the regular development cycle rather than as a single pre-launch check. 

A practical rhythm is automated scanning on every build, with periodic manual testing by an assistive-technology user whenever something significant changes.

Overlays are widely criticised by accessibility experts and assistive-technology users, and they don’t reliably deliver compliance. 

They sit on top of the underlying code rather than fixing it, which means the structural problems a screen reader actually trips over usually remain. Real accessibility comes from the markup and the build, not a script layered over the top.

Few agencies do, and building that capability from scratch is slow and expensive. This is one of the clearest cases for a white-label partnership: the agency keeps the client relationship while a specialist team handles accessible builds and remediation behind the scenes.

It’s how a small shop can deliver genuinely accessible work without hiring a full accessibility practice to do it.

There’s no fixed limit, but stores commonly start seeing measurable slowdowns between 3,000 and 10,000 SKUs—especially when products have many variations and custom attributes. 

The tipping point depends more on how the data is structured and retrieved than on raw product count. Stores with well-optimised databases, modern order storage enabled, and proper caching layers can scale well beyond 50,000 SKUs without issues.

Managed hosting addresses infrastructure-level problems like server memory limits, processing capacity, and built-in caching, but it won’t fix application-level issues like bloated plugin stacks or inefficient database lookups. 

Think of it as raising the floor—your store won’t dip below a certain baseline—but the ceiling still depends on how the site itself is built.

A speed test measures page load time for a single user at a single moment. 

A performance audit evaluates how the store behaves under concurrent load, tests caching behaviour across dynamic and static pages, profiles database performance at projected catalogue scale, and stress-tests the checkout flow with realistic traffic. 

Speed tests are snapshots; performance audits are simulations.

Yes, and these are among the hardest issues to diagnose because they don’t appear consistently. 

When multiple plugins hook into the checkout process and compete for server resources under concurrent sessions, the result is often sporadic timeouts, failed payment requests, or gateway errors that work perfectly in single-user testing. 

Load testing the checkout flow with all plugins active is the only reliable way to catch this.

A pre-launch performance audit typically adds two to three days, not weeks. The key is building it into the project scope from the start rather than tacking it on as an afterthought. 

For agencies that handle high-volume WooCommerce builds frequently, partnering with a white-label development team that includes performance auditing as part of their delivery process can absorb this work entirely without extending the agency’s own timeline.

No. Reflexive credits can train clients to dispute every invoice. Assess where the documentation gap actually sits—if the SOW was unclear, a credit is fair, and you should own it. 

If the client signed off on the work and is renegotiating after the fact, a credit teaches the wrong lesson. Position concessions as one-time refinements tied to a specific scoping issue, not as a default response to pressure.

Rarely, and only when the SOW is genuinely unambiguous, and the work was approved in writing. Even then, a flat refusal almost always damages more than it protects. 

The better approach is to walk the client through the relevant clause calmly, ask what triggered the concern, and treat the conversation as information about the relationship, even when you hold the line on the number.

Frame it as a working document rather than a contract addendum. A short, plain-language email with the change, the cost, and the timeline impact—sent and acknowledged—works better than a formal PDF for most engagements. 

When change orders feel like operational hygiene instead of legal escalation, clients stop dreading them, and your team stops avoiding them.