A 23-shop agency rollout, modeled end to end.
How a Shopify Plus partner agency would stand Sumeru up once, white-label it per client, and standardise attribution and automation across a 23-shop book - the sequence, the checks that come first, the failure modes, and the consolidation arithmetic with every input published so you can substitute your own.
The portfolio shape this describes.
If your book differs materially from this, the sequence still holds - the arithmetic in section 05 is where you substitute your own numbers.
What breaks at 23 clients.
These are structural properties of multi-shop agency operations, not one firm's discovered pain.
Per-client tooling sprawl
A 23-client book running four growth tools each is 92 vendor relationships: 92 renewal dates, 92 invoices, 92 permission models, and 92 places a departing account manager still has access. The administrative load scales with the book, not with revenue.
Attribution that doesn't reconcile
When the attribution tool, the email platform, and the Shopify admin each compute revenue on their own window and their own identity graph, they disagree. The weekly client call then opens with reconciliation instead of decisions — and the agency absorbs the credibility cost of numbers it did not compute.
No portfolio-level view
Per-client dashboards cannot answer the principal's questions: which accounts are quietly slipping, where servicing hours produce the most marginal revenue, and which growth motions generalise across the book. Staffing and prioritisation decisions get made on instinct.
One runtime, twenty-three tenants.
Product capability, not a claimed outcome - every item here is demonstrable in the 60-minute architecture review.
One install, white-labelled per client
Agency tier is deployed once. Each client gets an isolated tenant, branded with their own colours and domain, while the engines underneath — attribution, automation, orchestration — share a single upgrade path. New client onboarding is a provisioning step, not a procurement cycle.
Shared event bus, per-tenant isolation
Every client's Shopify orders, ad-platform events and engagement data flow through the same event bus, partitioned by tenant at the storage layer. Tenant scoping is enforced on every query and checked by a CI lint rule; audit logging, PII redaction and rate limits all apply per tenant.
Portfolio rollup above the tenants
A second-layer view sits above the client tenants and rolls up what matters at firm level: which accounts are trending, which are at risk, where account-management hours are landing, and which motions are working across the book.
Four weeks, riskiest first.
Tenant isolation and attribution reconciliation are proven on three clients before the portfolio depends on them. A rollout that leaves those to the end is a rollout that discovers them in week four.
- Week 01
Provision, then prove isolation
- Agency tier provisioned; first three client tenants stood up end-to-end.
- Cross-tenant checks run before anything else: tenant A's operator confirmed unable to reach tenant B's data, orders, or audit rows.
- Attribution reconciled against each client's Shopify admin on a known window, and the variance documented before it becomes a surprise.
- Week 02
White-label and widen
- Per-client theming applied: logo, accent, custom domain.
- Next tranche of tenants provisioned once the first three reconcile.
- Approval queues configured per client, with spend-affecting actions routed to a named reviewer.
- Week 03
Automation in dry-run
- Trigger rules enabled in dry-run across the portfolio. Paid-spend actions serve a mandatory seven-day dry-run before they can go live — this window is enforced, not advisory.
- Dry-run output reviewed with the account team: what would have fired, on which client, and whether the reviewer agrees.
- Portfolio rollup switched on once there is enough data in it to be worth reading.
- Week 04
Cut over and decommission
- Automations promoted from dry-run where the reviewer signed off; the rest stay in dry-run rather than being forced live to hit a date.
- Legacy tooling wound down per client as its replacement demonstrates parity — deliberately per client, not in one portfolio-wide switch.
- Final reconciliation pass across the book, with residual variance documented per client rather than averaged away.
Show the arithmetic, not the answer.
The previous version of this page asserted a 62% tooling reduction as a measured customer outcome. It was a model. Here it is, with every input on the table - swap in your own and the output changes accordingly.
- Client shops
- 23
- Growth tools per shop
- ~4
- Vendor relationships replaced
- 92
- Assumed incumbent cost per shop
- $400–$2,000/mo
- Sumeru Agency base
- $799/mo
- Sumeru per additional shop
- $149/mo
Model input — substitute your book size
Attribution, SEO, email/SMS, analytics rollup
23 shops x 4 tools
Published range for a 4-tool growth stack
Includes 10 client shops — see /pricing
13 additional shops in this model
- Modeled Sumeru cost
- $2,736/mo
- Modeled incumbent cost
- $9,200–$46,000/mo
- Modeled reduction
- 70%–94%
$799 + (13 x $149)
23 shops x $400–$2,000
At the published input range
Excludes migration effort, any tooling a client mandates you keep (finance reporting is the usual one), and the operator time the rollout consumes. Run it against your own numbers →
What goes wrong in this shape.
Published because a blueprint that only describes the happy path is a brochure. These are design risks in a portfolio rollout, and they are the questions to put to us on a call.
Sequencing email migration last
Deferring email and SMS flow migration until after attribution is stable is defensible, but it leaves operators working in two tools for weeks. Plan the messaging migration concurrent with provisioning, or accept the double-entry period explicitly instead of discovering it.
Theming assets requested too late
Per-client white-labelling needs logo, accent and domain from each client before week two, and chasing 23 clients for assets mid-rollout is the single most common source of slippage in this shape. Collect them during the provisioning step.
Showing the portfolio rollup too early
A rollup with three clients' data in it looks sparse and undermines confidence in a view that will be valuable a fortnight later. Hold it until it has signal.
Promoting automations to hit a date
The seven-day dry-run exists so a reviewer can disagree with the machine before money moves. A rollout plan that treats week four as a hard cutover creates pressure to promote rules that have not earned it. Let the tail stay in dry-run.
What replaces this page.
This blueprint gets replaced by a real case study when an agency runs the rollout and agrees to be named. That means a signed release, the firm's actual name, figures they have reviewed and stand behind, and their own account of what did not go to plan. Not an anonymised composite, and not numbers we computed on their behalf.
If you are running a portfolio and would consider being the first, that is a commercial conversation and we will treat it as one - reference customers get commercial terms, not a thank-you note.