Case study

One operator. Five storefronts. One reusable fulfilment workflow.

Five separate storefronts in one market, run by one person, fulfilled through a single RyanFulfil account structure. When he asked to add a completely different product category in a new market, it went live on the setup that was already there instead of starting again.

This account is anonymised on purpose. No client name, no store names, no products, no order counts. Everything below comes from our own account records, including the two things we got wrong.

  • 5 storefronts, one account structure
  • One contact, one invoicing rhythm
  • New category live without re-onboarding
  • Largest batch settled and picking the same day

Published 24 August 2026. The figures on this page describe one client relationship and are not a benchmark for any other account. RyanFulfil has operated since 2018, with 500+ active client accounts and 4,000+ orders fulfilled daily. Those two are RyanFulfil's own current operating figures.

Client context

One operator, five sub-brands, one market

The client is one person. He runs five separate storefronts as distinct sub-brands, all selling into the same market, all fulfilled by us. To his customers they are five brands. Behind them there is one operator making every decision.

Volume is uneven by design. Invoice batches on this account swing between roughly $1,200 and $9,700 depending on the week, because five storefronts do not move at the same time. Some weeks one line is busy and the rest are quiet. Other weeks several run together.

Then came the request this page is really about. He wanted to add a completely different product category, in a new market, without rebuilding the setup or re-onboarding from scratch.

The problem

Why five separate workflows cost more than one

Running each storefront as its own relationship is the default. It is also expensive in ways that never appear as a line item on an invoice.

Five conversations instead of one

Every order problem starts by establishing which store, which batch, which shipment. For a single operator that is the same person supplying the same context five times over.

Five billing threads, one cash position

Separate invoicing rhythms all land on the same operator. Reconciliation becomes a weekly clerical job for the seller, and payment timing becomes five decisions instead of one.

The next line starts from zero

A new product category on a separate account means a new integration, a new contact and onboarding repeated end to end for a business we already know how to serve.

Exceptions live in a chat thread

Failed deliveries and redelivery notices tracked in messages go missing once volume rises. We learned that on this account the hard way, and it is written up further down this page.

None of that is dramatic. It is friction that scales with the number of storefronts, which is exactly the wrong thing to have when adding storefronts is the plan.

Account architecture

The structure we actually used

Six decisions, none of them clever. The value is that they compose: each one makes the next storefront cheaper to add than the last.

  1. One account structure The five sub-brands were consolidated into a single account rather than five parallel relationships. Each storefront keeps its own orders. The account carries all of them. RyanFulfil
  2. One point of contact One person on our side owns the account. No per-store handoff, and no re-explaining which brand a problem belongs to before anyone can act on it. RyanFulfil
  3. One invoicing rhythm Work is invoiced in batches on a single schedule across all five storefronts, instead of five billing threads settling on five different clocks. Shared
  4. One integration, reused The existing ERP link already pulling orders from the storefronts became the connection point for anything added later, including a category nobody had planned for at setup. Shared
  5. Address correction before dispatch Incomplete destination addresses are corrected before an order reaches the dispatch queue, not after a delivery fails. On a busy day that is dozens of corrections. RyanFulfil
  6. A shared tracking sheet for exceptions Failed-delivery and redelivery cases sit in a sheet both sides can see, replacing the chat thread they used to live in. This one came late. It should have come first. Shared

Integration and billing

One connection, one settlement rhythm

The integration was already there

Orders reach us through an ERP link connected to the storefronts. That link was built once, for the original sub-brands, and it is the reason the later request was cheap to say yes to.

How a store connects generally: Shopify and WooCommerce are fully two-way automatic, so orders pull in and tracking uploads back, which triggers the store's own notification to the customer. On TikTok Shop, eBay and Etsy we send tracking numbers to the seller to update manually.

Billing runs in batches, not per order

A batch is issued, settled, and then released to picking. On this account batches ranged from roughly $1,200 to roughly $9,700 depending on the week. The largest, about $9,700, was settled and released to picking on the same day it was issued, with the next batch queued immediately behind it.

Two things in that sentence matter, and neither is the dollar figure. First, one rhythm covers five storefronts, so the operator settles once rather than five times. Second, the gate on picking is settlement, not paperwork. When the batch cleared, picking started.

Across the book, invoices settle by Wise or bank transfer, and USD, EUR, GBP, CAD, AUD, NZD and SGD carry no currency surcharge. Full detail is on the pricing page.

New-line onboarding

Adding a different category, in a different market

Not a variant of what was already selling. A different product category, sold to different customers, in a market that was new to the account.

  • No second account The new line joined the structure that already existed.
  • No second point of contact Same person, same thread, one more line to run.
  • No second invoicing thread The new category settles on the same batch rhythm as the rest.
  • No fresh integration Connected through the existing ERP link, so it inherited the workflow instead of starting one.
  • No onboarding repeated end to end The setup work had been done once. It did not need doing again.
  • Material variants sourced as the range matured The catalogue could develop without changing supplier.

The new category went live in the second market. The account structure did not change to accommodate it.

Results

What the record actually supports

Three recorded numbers, then the honest split between what our account notes show and what we never measured.

5 storefronts running on one account structure, one contact and one invoicing rhythm
$9,700 largest invoice batch on the account, at the top of a range starting around $1,200
Same day that batch settled and released to picking, with the next batch queued behind it

What our account notes show

Taken from internal reviews of this one client relationship.

  • Five storefronts fulfilled through one account structure, one point of contact and one invoicing rhythm.
  • A completely different product category, in a new market, live on the existing ERP link without repeating onboarding.
  • Invoice batches from roughly $1,200 to roughly $9,700 by week, settled on that single rhythm.
  • The largest batch, about $9,700, settled and released to picking the same day it was issued.
  • Material variants sourced as the range matured, without changing supplier.
  • Delivery exceptions moved out of chat and into a shared tracking sheet, which visibly reduced what sat unresolved.

What we did not measure

No control account, no before-and-after instrumentation. These are gaps, not modesty.

  • No revenue, margin or order-count figures. We do not publish client trading data, so nothing here is scaled against sales.
  • No measured delivery-time series before and after the change. Delivery windows on any route are estimates, not guarantees, and we did not track them as a series on this account.
  • No cost comparison against running five separate accounts. We never ran the control, so the saving is an argument, not a measurement.
  • No count of exceptions the shared sheet cleared. "Visibly reduced" is an operating impression from the people doing the work, not a metric.
  • No elapsed time for the new-line onboarding. The record shows it reused the setup. It does not timestamp how long that took.

What went wrong

Two failures on this account, both ours

The account structure worked. These did not, and they ran for a long time before we treated them properly.

Quality slipped on two of the sub-brand lines

It slipped far enough that the client described it as a liability for his business. That description was fair. A quality problem on a sub-brand does not stay with the supplier: it lands on his brand, his reviews and his customers.

We left the address workload as a manual grind

Destination addresses in that market arrive incomplete often enough that we were making dozens of corrections on a busy day. We absorbed that as effort instead of fixing the process behind it, and we did that for far longer than we should have.

Absorbing a daily manual workload feels like service. Past a certain point it is a process nobody has designed yet.

What changed afterwards

Exceptions moved into a shared sheet

Chasing individual failed-delivery and redelivery notices through a chat thread stopped. Both sides now see the same open list, and what sat unresolved visibly reduced. The address corrections themselves are still daily work. What changed is that the failures downstream of them cannot quietly age.

Quality went back as a pattern

The complaints went to the supplier as a pattern rather than as separate cases. Handled one at a time they were replacements. Taken together they were a supplier problem, and that is how they were finally raised.

What was learned

Four things we took off this account

1

A reusable account structure makes the next storefront cheap

The expensive part of a new line is rarely the line. It is the setup around it: the integration, the contact, the billing thread. Build that once and adding the next storefront is a decision rather than a project.

2

Address quality is fulfilment design, not customer service

A correction made before dispatch is cheap. A failed delivery is a redelivery, a refund conversation and a customer who now distrusts the brand. Same defect, two very different costs.

3

A complaint that repeats is a supplier pattern

Treating repeats as individual replacements hides the cause and costs more than fixing it. The trigger for escalation should be repetition, not severity.

4

A workaround that survives is a process

Daily manual effort that has outlasted the situation it was invented for is not a stopgap any more. It is how the account works, and it should be designed on purpose rather than carried by whoever is on shift.

Read across

What this means for an agency running client stores

An agency running fulfilment for several client stores has the same shape as this account, with one difference that changes everything commercial: the storefronts belong to different people.

What transfers directly

The operating architecture is identical whether the storefronts share an owner or not.

  • One account structure covering many storefronts, rather than one relationship per store.
  • One point of contact, so nobody re-establishes context before an issue can be worked.
  • One invoicing rhythm, batched, instead of a separate settlement clock per store.
  • One integration reused for each store added, which is why adding one is cheap.
  • Delivery exceptions in a shared list from day one, not after chat stops coping.
  • Address quality treated as a store-level fix. We correct before dispatch, but the checkout created the defect and the checkout is where an agency can actually solve it.

What does not transfer

These were one operator's own brands. The commercial relationship in an agency setup is a different thing.

  • On the referral path RyanFulfil contracts with the seller, invoices the seller and supports the seller. The partner does not own that client.
  • The partner names its own commission on top of our net fulfilment cost, with guidance of around 2% to keep the client's landed cost competitive.
  • The quote the seller receives from RyanFulfil discloses that a partner fee is included. There is no hidden margin on a client we contract with.
  • On white label the agency contracts with, invoices, supports and prices its client under its own brand. RyanFulfil invoices the agency and works behind it, subject to a passed visibility audit. The claims the agency makes to its client are the agency's responsibility.
  • White label is a tested operating configuration, not a logo switch. Branded quotes and reports, partner-owned client communication, neutral or partner-branded packing slips, a confidential partner operations channel and consolidated agency billing can be configured. Store app or collaborator access, bank beneficiary and legal entity, carrier tracking and shipment origin, customs and export documents, return addresses and legally required disclosures may still be visible. Both lists are set out in full on the Agency Desk page.
  • RyanFulfil does not build stores, run ads, or act as the client's end-customer service department. On this account the operator handled his own customers. An agency taking that on takes it on as the agency.

Where to read the rest

What this case does not prove

The limits, stated plainly

One operator's five storefronts is not evidence of universal onboarding speed. It is one account, one market, and an integration that happened to already be in place. Another client's platform, category or destination market can make the same request slower, more expensive, or not worth doing on an existing setup at all.

Nothing here is a guaranteed result. The same-day settlement to picking happened on that batch, on this account, in that week. It is a record of what happened, not a service level, and delivery windows on any route remain route-specific estimates rather than guarantees.

These were one operator's own brands, not an agency's third-party clients. The account structure transfers: one account, one contact, one invoicing rhythm, one reused integration. The commercial relationship does not. When the storefronts belong to different people, client ownership, pricing, fee disclosure and who answers the end customer all have to be settled explicitly before the first order, which is what the Agency Desk paths exist to do.

And two of the five lines had a quality problem serious enough for the client to call it a liability. That happened inside this same structure. A clean account architecture does not make a supplier's output good, and we would rather you read this page knowing that.

Running stores for clients? This is the part that transfers.

The Agency Desk applies the same architecture to an agency's client stores: one account structure, one contact, one invoicing rhythm, one integration reused for each store added. Read the paths, then tell us what you actually run and we will tell you whether it fits.

See the Agency Desk Apply for a fit assessment Ask on WhatsApp

There is no joining fee and no monthly programme fee at launch. Founding-pilot terms are confirmed after a fit assessment. This account sits alongside five others, each with its own failures, in the six-case index.