The email arrives on Wednesday. “From Monday, please add the autumn leaflet to everything except wholesale.” The account manager reads it, forwards it to the floor supervisor, pastes a line into the client’s SOP document and adds a note to the client record. Thursday’s cycle run for that client will release several hundred orders. Order 847 of that run will be packed by whoever is at station four at about half past two. Nothing in what has just happened connects the email to that packer at that moment. That connection is the job to judge 3PL fulfilment software by.

This is the question a UK 3PL running fulfilment for ten to sixty e-commerce clients has to put to any fulfilment software, including the system it already runs: when a client tells us how their orders must be packed, how does the software make sure every packer does it on every order it applies to, and how do we show the client it was done? The answer this article defends is that a client instruction is enforced only when it becomes a step on the packing task for exactly the orders it applies to, and it is provable only when completing that task records which version of the instruction was followed. Software that stores the instruction as text on the client record leaves the packer to work out scope on every order and leaves the 3PL with no record. Software that resolves scope and effective date into task steps when the order is released, and keeps the completion record, turns the client’s rule into work the operation can run at speed and defend afterwards.

What a client instruction is made of

3PL fulfilment software is the system that receives orders from many clients, directs picking and packing in one warehouse and confirms dispatch. Each client also has its own order platform, a web shop, a subscription billing tool or a wholesale portal, and that is where orders originate. The 3PL’s system receives them. Whether a vendor spells it 3PL fulfilment software or 3PL fulfillment software, the category covers everything from a packaged WMS with a client layer to a platform implementation, and the question here is the same for all of them.

Two kinds of instruction reach the packing bench, and they behave differently. An order-level instruction arrives with the order: a gift message, an insert flag the client’s platform set at checkout, a request for plain packaging on one order. The order already carries it, so the packing screen can show it without anyone deciding anything. A standing instruction is agreed once, usually at onboarding or by email, and applies to many future orders. “Every order ships in our coral mailer.” “First boxes get a welcome card.” “Leaflet in everything except wholesale this October.” This article is about standing instructions, because scope and change live there.

A standing instruction has four parts, whether or not anyone writes them down. The first is scope: the set of orders it applies to. Clients express scope along the dimensions they think in: their own account, a sales channel, a SKU or product group, an order type such as first subscription cycle, recurring cycle or one-off, a date window, a destination country. The second is the effective date, and with it a version, because instructions change and the operation must know which version applied to an order packed on a given day. The third is the physical step: which mailer, which insert, which box, what to photograph. The fourth is the proof the client will later ask for.

Two more terms carry the rest of the argument. A task step is the unit of work the packer sees for one order: a line that says put this in, choose this box, scan this. A completion record is what is written when the packer confirms it. Subscription fulfilment adds nothing new to this list. It is the case where the same customer receives repeat orders on a cadence, the orders are released together in a cycle run, and the rules depend on the cycle number. Scope gains an extra dimension and the cost of a misread multiplies, so subscription fulfilment is the same software with one more dimension to get right and a higher price per mistake.

Why a note on the client record is not a rule

When a standing instruction arrives, someone has to decide which orders it applies to, from when, and which step it adds or changes. Where that decision is made determines everything downstream.

If the instruction is stored as free text in the SOP or a notes field, the scope decision is deferred. The account manager forwards the email and hopes. The packer makes the decision, per order, at packing speed. The packer’s screen shows the order: a client name, some lines, a delivery address, and a paragraph of notes about what might apply. It does not show the instruction’s scope logic. They have to hold “coral mailer for everyone, welcome card for first boxes, leaflet this month except wholesale” in their head and test each order against it while keeping up the rate.

People do one dimension reliably. Everyone on the floor knows this client gets the coral mailer. What fails is the combination: this client, first cycle, not wholesale, October only. Our view is that combination scope is where human application breaks, and that many of the failures a 3PL puts down to packer attention are failures of asking a person to resolve a multi-dimensional rule from memory several hundred times a day.

Subscription fulfilment multiplies the cost. A cycle run releases hundreds of near-identical orders at once, all for one client, all with the same attributes. A misread scope produces a batch of wrong parcels, and nobody notices until a subscriber posts a photo or the client asks a question.

Inserts and packaging are stock. An instruction that adds a leaflet to every non-wholesale order consumes one leaflet per order in scope. If scope is resolved only at the bench, one order at a time, the number of leaflets the run needs is never computed, so the shortfall is discovered when the box is empty in the afternoon. Had it been computed in the morning, the client could still have decided what to do.

And when the client asks in November whether a particular subscriber’s first box had the welcome sample, a notes-based operation can say what should have happened. It cannot say what did. Our view is that those are the client conversations that go badly: the 3PL is confident about its process and has nothing to show for this order.

The rule that resolves it

The alternative is to treat the instruction as a record with fields. It has a scope expressed in the dimensions the client uses, an effective date and a version. When an order is released to pack, the system compares each of the client’s current instructions against that order’s attributes, its channel, its cycle number, its date, its destination, and renders the ones that match as steps on that order’s task. The packer sees the steps and nothing else.

Steps the client cares about can require a confirmation before the order moves to dispatch: scan the insert’s barcode, choose the box type from a list, take a photo. Routine steps can be a tap. Completing the task writes a record: the order, the steps done, the instruction versions that produced them, the station and the time. Because scope is resolved for the whole release at once, the count of each insert the release will consume is known before the first order is picked.

Task steps are also where a separate question lives: what happens to the step list when an order cannot ship whole and lines are split or short. Order fulfilment software when an order cannot ship whole covers that, and this article assumes orders that ship complete.

This is the thing to look for in any fulfilment system: scope resolved once, at release, by the system, into steps and a record. The packer applies the result instead of the rule.

One cycle run, three instructions

Take an illustrative scenario, which runs through the rest of this article: the figures are chosen to be easy and consistent with each other, and no customer is described. A 3PL runs fulfilment for a subscription skincare brand alongside its other clients. The brand has three standing instructions.

Instruction 1: every order ships in the client’s branded coral mailer. Scope: this client, all channels, all dates. Instruction 2: a subscriber’s first-cycle order includes a welcome card and a sample sachet. Scope: this client, subscription channel, cycle number one. Instruction 3: from 1 October to 31 October, include the autumn leaflet in every order except wholesale. Scope: this client, all channels except wholesale, 1 to 31 October.

On 3 October the release for this client puts 1,200 orders on the floor: 200 first-cycle subscription orders, 950 recurring subscription orders and 50 wholesale orders released the same morning. Resolving the three instructions against those orders gives the following.

The client delivered 1,000 leaflets. At release the system has the demand: 1,150 needed, 1,000 on hand, 150 short. The operations manager sees this before the run starts and asks the client whether to hold 150 orders, ship them without the leaflet or give first-cycle orders priority for the leaflets there are. That is a client decision made in the morning with the whole run ahead of it.

At the bench, a recurring subscription order’s task shows two steps: branded mailer, autumn leaflet. A first-cycle order shows four: branded mailer, welcome card, sample sachet, autumn leaflet. A wholesale order shows one: branded mailer. Nobody reads a paragraph and nobody tests an exclusion clause in their head. The operation chose to require a scan of the sachet barcode on the sample step, because that is the step the client cares most about and the one most often asked about later. The mailer and leaflet steps are a tap to confirm. The order cannot move to dispatch until the scan is recorded.

The completion record for one first-cycle order reads: mailer confirmed, welcome card confirmed, sample scanned, leaflet confirmed, packed at station four at 14:32, instruction versions 1.0, 2.0 and 3.0. When the client asks in November whether a particular subscriber’s first box had the sample, the account manager opens the order and reads the answer.

Now run the same release with the three instructions as a paragraph in the client SOP and a Monday briefing. Two things go wrong in this version. The leaflet goes into the wholesale orders too, because “except wholesale” is one clause in a paragraph and a wholesale order looks like any other order on the packing screen. Consumption runs at 1,200 against 1,000 supplied, and the shortfall, now 200, appears when the leaflet box is empty with orders still to pack. And when the client asks about the subscriber’s sample, the answer is whatever the packer who was on station four that day remembers.

The mid-month change shows the versioning. On 10 October the client emails again: stop the leaflet for the UK subscription channel, keep it for EU subscribers. Under the rule-based approach this is instruction 3, version 3.1, effective 10 October, with narrower scope. Orders released from 10 October resolve against 3.1. Orders packed from 3 to 9 October keep version 3.0 on their record, so the operation can say exactly which orders got the leaflet and under which instruction. Under notes it is another email and another briefing, and nobody can say which of the orders packed on 10 October got the leaflet and which did not.

What the scenario shows is one relationship: an instruction with scope, effective date and version, applied to an order’s attributes, produces the task steps and the completion record. The packer works from a short list, the insert count is known before the run, and the answer to the client is on the record. That record is also what a per-order invoice can be built from, since a client that pays per insert or per first-box kit is paying for exactly the steps that were confirmed. 3PL billing: when each client means something different by a pick covers how the record of work becomes an invoice the client can follow.

Five questions to ask of any 3PL fulfilment software

You can now look at any fulfilment software, including the one you already run, and put five questions to it.

Where does the instruction live? If the answer is a notes field, a document or a packing-note text box on the client record, it is stored and someone else resolves it. If it is a record with fields for scope and effective date, ask the next question.

How is scope expressed? List the dimensions your own clients use. For most 3PLs with subscription clients that is channel, product group, cycle number, date window and destination country, on top of the client itself. Ask whether the system can hold an instruction that combines three of them, because a single-dimension field, per client or per SKU, forces the combination back into a note.

When is scope resolved? The answer should be at release, for the whole batch, so that the insert demand is known before picking starts. If it is resolved when the packer opens the order, the stock consequence is still a bench discovery.

What does the packer see? Ask to watch an order with two applicable instructions and one that does not apply. The screen should show the two steps and omit the third. If it shows the full client note, the packer is still doing the resolving.

What is recorded? Complete an order and ask to see the record. It should carry the steps confirmed and the instruction versions in force, and it should survive a later change to the instruction.

These are questions to ask in a demo with your own clients’ rules in hand, and a 3PL WMS demo checklist for testing your client workflows sets out how to run that session.

When your current system is enough

Much of this is unnecessary for some operations. If you have a handful of clients whose instructions have one dimension of scope, a mailer per client or an insert per SKU, and they rarely change, a WMS with per-client packing notes and per-SKU instructions plus a printed checklist at the bench does the job. In our view many WMS and fulfilment products carry those fields. If your clients’ instructions arrive order-level from their own platform, an insert flag or a gift note on each order, the order feed already carries the scope and the existing pack screen is enough. And if no client asks for proof per order, the completion record is a nice-to-have.

The approach described here earns its cost when scope is multi-dimensional and changes monthly, when inserts are stock with a pre-run consequence and when clients ask what went in the box. If you already have a WMS that picks and packs well and the gap is only client-specific packing, the choice between extending it and replacing it is its own question, and should you configure, extend or replace your 3PL’s WMS? works through it.

How Keel runs it

Keel is an operations platform shaped around how your business works. For this 3PL, that means the way its clients specify work becomes the shape of the system. Onboarding a client means the account manager captures each instruction as a rule with scope and an effective date, and sees on the same screen which upcoming orders it touches and how much insert stock it will consume. At the packing station each packer sees the steps this order needs and nothing else, with a scan, a box choice or a photo required on the steps the client cares about, and the order does not move to dispatch until those are done. The account manager has a per-order record to show the client, or a client-facing view of it, and reporting across clients on what was done and what it consumed. They can say yes to a new client’s instruction without wondering who will remember it on Thursday. We infer, without customer evidence, that the peace of mind matters as much as the leaflet count.

Instruction changes stop being retraining sessions. The 10 October email becomes version 3.1 with an effective date, and the packing screens change with it because they are drawn from the same rules.

Underneath, Keel supplies tailored operator screens, workflows that combine human steps such as confirming a sachet scan with processing steps such as resolving a release against the current instructions, and business rules expressed in code. The resolution rule, instruction scope against order attributes producing steps, is written in code in the implementation, which is what lets the scope dimensions match how this 3PL’s clients specify work beyond a predefined set of packing-note fields. Keel supplies the workflow state so an order cannot move to dispatch until its required steps are confirmed, the permissions so that the client can view its instructions and records without editing them, the operator screens and the reporting. The implementation builds the instruction model with its scope dimensions and versions, the resolution logic, the packing screen, the pre-run stock check and the client view. That code needs implementation, testing and maintenance. Keel leads the implementation and agrees the handover with your team; what does Keel supply, and what do you still build? sets out the division. As clients change, AI can help the implementation team evolve the rules and screens, with the same review before anything goes live.

The trade-off is that the 3PL owns the design of its instruction model, which is more upfront thinking than choosing a vendor’s packing-note field. The return is a model that matches the way its clients specify work, and one the 3PL can change without waiting for a vendor roadmap.

What you can now decide

Take your three most demanding clients’ SOPs and write each standing instruction out as scope, effective date, step and proof. Count the dimensions in each scope. Then find where each instruction lives in your current system, when it reaches the packer and what record exists that it was followed. Where an instruction has one dimension and lives in a field the packer sees, you are fine. Where it has three dimensions and lives in a paragraph, you have found the orders that will go wrong in the next cycle run, and the insert count you cannot compute.

If your clients’ instructions have more than one dimension of scope and change monthly, bring those SOPs to a conversation with Keel and we will work through how your packing rules would be modelled.