Fulfilling Subscription Orders: Batching, Timing and Exceptions

Subscription fulfilment has one enormous advantage over ordinary ecommerce — you know what is shipping before the order exists — and one dangerous property: a mistake in the process repeats every cycle until someone notices.

Fixed date or anniversary?

Fixed ship date. Everyone ships on the 1st. Simple to plan, easy to buy for, efficient to pick. But your entire month’s fulfilment happens in two or three days, and every problem arrives at once — including the support tickets.

Anniversary billing. Each subscriber ships on their own signup date. Load spreads evenly and so does support. Forecasting is harder and picking is less efficient, because you never batch a full cohort.

Cohort batching is usually the best compromise: four weekly cohorts, each shipping on a different week. You keep most of the batching efficiency and lose most of the peak.

Choose deliberately and early — changing later means moving customers’ billing dates, which generates exactly the confusion you want to avoid.

Lock the order before you pick

Set a cut-off — typically 2–4 days before ship — after which changes are not accepted for that cycle. Address changes, skips, swaps and build-a-box selections all lock.

Without a cut-off, someone updates their address while their box is on the packing bench, and you have shipped to the wrong place with the right intention.

Tell the subscriber the cut-off exists and when it is. “Changes by 27 October for your 1 November delivery” is easy to respect; a silent cut-off feels arbitrary.

Skips have to flow through

The single most common subscription fulfilment bug: a subscriber skips, and a box ships anyway.

This happens when the pick list is generated before the skip deadline, or when skips are recorded in the subscription app but the fulfilment export was taken earlier.

Two defences:

1. Generate the pick list after the cut-off, never before
2. Reconcile counts — boxes packed should equal active-minus-skipped for that cohort

Shipping to someone who skipped is worse than an ordinary error: you charged them, or you did not and shipped for free, and either way you have told them their choices do not matter.

Tag everything

Subscription orders should be tagged with the subscription id, the cycle number, and the plan. Everything downstream — shipping rules, 3PL routing, reporting, support — keys off these.

Tag at creation, not in a nightly job, or you will have a window where orders exist untagged and whatever consumes those tags will silently skip them. Order tags.

Plan for the exceptions

Recurring orders generate recurring exceptions. Decide the policy before the first one:

• Item out of stock at pick time — substitute, part-ship, or delay? Whichever you choose, tell the customer before the box arrives.
• Delivery failed — who pays for the redelivery, and does the next cycle proceed?
• Address invalid — pause the subscription rather than repeatedly failing. A subscription shipping to a dead address four times is four losses.
• Customer unreachable — after how many failures do you pause?

Writing these down once saves improvising them monthly.

Watch the right numbers

• Ship accuracy by cohort — a process error shows as a cluster, not a scatter
• Skip rate per cohort — rising skips means cadence is wrong
• Failed deliveries by pincode — recurring geography problems justify serviceability rules
• Time from cut-off to dispatch — your operational headroom

Frequently asked questions

Should I ship all subscription orders on the same day?

A single ship date is operationally simpler and cheaper per order, but concentrates your warehouse load into a few intense days and creates a support spike when anything goes wrong. Staggered cohorts smooth both at the cost of some efficiency.