The export, the template and the reformat
You moved packing to a fulfilment house to get your weekends back. Each month, on the agreed day, you export orders from the subscription app, paste them into the fulfilment house's template, map each box type and variant to their SKU codes, add the add-ons from a second export, remove the cancellations since the export, and upload the file.
The following week, their team emails: some rows have an unknown SKU, some addresses are missing a postcode, and the gift messages did not come through. Three weeks later a subscriber says she received the large box, though she pays for the standard.
The handover is the weak link
Fulfilment houses are good at packing what they are told. The problem is the telling. Your data describes subscriptions; theirs describes pick instructions.
- Box types and variants need mapping to the fulfilment house's own codes, by hand.
- Add-ons, swaps and gift messages sit in separate exports or notes.
- Late changes after the export, such as cancellations or recovered payments, are applied by email.
- Address problems are found by them, not by you, after upload.
- Dispatch and tracking come back as another spreadsheet that nobody loads into your systems.
The whole month's packing depends on one file being right, and it is built by hand under time pressure.
What a bad handover costs
Wrong boxes cost replacements and postage, usually charged by the fulfilment house too. Rejected rows delay part of the dispatch. Missing gift messages disappoint the people you most want to impress. And the back-and-forth by email uses the time you outsourced packing to save.
Stock disagreements are the slower problem. If the fulfilment house's stock figures and yours drift apart, you find out when an item runs short mid-run.
The checked handover we build
- Each paid subscriber's box recipe for the month is assembled from your subscription app, preference profiles, add-ons, swaps and gift messages.
- Recipes are mapped to the fulfilment house's codes through a mapping table you maintain once, with new variants flagged before the file is made.
- The file is checked before it goes: known codes only, complete addresses, message lengths within their limit, and no duplicate or cancelled orders.
- It is sent in the format and method the fulfilment house accepts, whether that is an API, SFTP or an upload.
- Changes after the handover go as amendment files in their format, not emails.
- Dispatch confirmations, tracking numbers and stock levels come back and are loaded into your subscription app and records, with differences listed.
| Check before sending | What it catches | Fixed by |
|---|---|---|
| Unknown code | Variant or add-on not mapped | You, in the mapping table |
| Incomplete address | Missing postcode or house number | Subscriber, via a quick request |
| Message too long | Gift note beyond their limit | Trimmed with your approval |
| Cancelled after export | Order no longer due | Removed automatically |
| Stock shortfall | Recipe needs more than they hold | You, before the run starts |
We work to the fulfilment house's specification and test with them before the first live month.
The month with a clean handover
On handover day, the file is built and checked in minutes. The few problems are listed for you to fix: a new variant needs a code, two addresses need a postcode. Late cancellations go as amendments. When dispatch finishes, tracking numbers arrive back in your subscription app and subscribers get their shipping emails without anyone uploading a spreadsheet.
The stock comparison shows both sides agree, or shows exactly where they do not.
Signs your fulfilment handover is fragile
- You reformat an export into their template every month.
- Rows are rejected for unknown codes or bad addresses.
- Late changes are sent to the fulfilment house by email.
- Tracking numbers come back as a spreadsheet you upload by hand.
- Your stock figures and theirs rarely match.