← All posts Fulfilment

Shopify fulfilment workflow: who owns each step

Most fulfilment problems are ownership problems wearing a logistics costume. A step-by-step map of who decides what between a paid order and a delivered parcel.

MK Maya Kessler6 September 2026 · 11 min read
FULFILMENT1Ship it at allfraud, address, terms2Fill it from wherewhich location holds it3Split or holdone of two in stock

The problem is rarely the picking

Ask a small store team where fulfilment goes wrong and you will usually hear about a courier, a supplier or a bad week. Ask them to walk you through a specific order that went wrong and you get a different answer: three people each assumed one of the others was handling it, and nobody was.

This is the pattern. The physical work of fulfilment is not hard. Picking an item off a shelf and putting it in a box is a solved problem, and even a fairly chaotic team gets it right most of the time. What breaks is the handful of moments where somebody has to decide something, and it is not written down who that somebody is.

So the useful exercise is not documenting how to pack a box. It is listing the decision points in your own order lifecycle and putting a name against each one.

The eight moments where a decision is required

Between a customer paying and a parcel arriving, most stores have roughly eight points at which a human has to choose. Everything between them is mechanical.

  • Should this order ship at all? Fraud signals, an address that looks wrong, a wholesale customer over their credit terms.
  • Can it be filled from where the stock is? One warehouse, two, a shop floor, a supplier holding it.
  • Should it be split? One item is in stock and one is not.
  • Which service does it go on? Standard, express, the expensive option that saves a complaint.
  • What happens when it is picked and something is missing? Substitute, short-ship, hold the whole thing.
  • Is this one moving? The parcel has been scanned once in four days.
  • Do we tell the customer, and when? Before they ask, or after.
  • Who pays when it goes wrong? Reship, refund, claim against the carrier.

Write those eight down for your own store, then put one name next to each. Not a team, a name. If two names appear next to one decision, you have found a real problem before it cost you anything.

Why "the ops team decides" is not an answer

Teams often push back here. Surely a small team does not need this level of formality? Everyone talks to everyone.

The trouble is that "everyone talks to everyone" is exactly the condition under which a decision falls through. When two people can both see a problem, each has a reasonable basis for assuming the other has it. This is not carelessness. It is what happens when responsibility is diffuse and nobody is wrong for having assumed.

A single name attached to a decision removes the assumption entirely. It costs nothing, it does not stop anyone else from helping, and it makes the question "who is on this?" answerable in one second instead of one thread.

We wrote about the general version of this in who owns what: a RACI for small Shopify teams. Fulfilment is where it pays back fastest, because the cost of a dropped decision arrives with a tracking number attached.

Mapping your own lifecycle

Take a single recent order that went badly. Not a representative one, a bad one. Write out what actually happened in the order it happened, with a timestamp against each event and a name against each action.

You are looking for three things.

Gaps. Periods where nothing happened and nobody knew nothing was happening. These are almost always where the cost sits.

Duplicate work. Two people who both looked into the same thing without knowing about each other. Cheap in isolation, expensive as a habit.

Silent handoffs. Moments where the work moved from one person to another without either of them saying so out loud. These are where the assumption problem lives.

One order will usually give you two or three real findings. Three orders will give you the map.

Where the information has to live

Once you know who decides what, the second question is where they find out that a decision is needed. This is the part most teams get wrong, because the answer defaults to whichever inbox happens to receive the trigger.

A useful rule: information should arrive where the decision gets made, not where it happened to originate. A carrier exception email that lands in a shared inbox nobody owns is not information, it is a lottery ticket. The same exception raised in the room where the person who can act is already working is information.

This is one of the reasons store teams end up with fulfilment scattered across a mail client, a spreadsheet and a group chat, and why operations in the wrong app is such a common shape. The tools are fine individually. The problem is that the decision and the trigger for it live in different places.

A worked example: the split shipment

Take one of the eight decisions and look at how it actually plays out.

A customer orders two items. One is on the shelf, one is not and will be in four days. Somebody has to decide whether to ship one now and one later, hold both, or contact the customer. Each option costs something: two parcels cost more, holding both risks a complaint, contacting the customer costs time and sometimes triggers a cancellation.

Most stores have no rule for this, so it gets decided per order by whoever notices, which means the same situation is handled three different ways in a week. Customers who receive different treatment for the same problem notice, and support absorbs the difference.

The fix is one sentence in writing. Something like: split when the delayed item is more than three days out and the order is over a value floor, hold when it is under. You will not get the rule right first time. Getting it written is what matters, because a written rule can be corrected and an implicit one cannot.

The three roles most small stores actually need

You do not need a fulfilment department. In practice most stores under ten people need three roles filled, and one person can hold more than one.

Someone who owns the queue. They know what is in the pipeline, what is stuck, and what is about to become a problem. This is a daily attention job, not a decision-making one.

Someone who can spend money. Upgrading a service, reshipping, refunding a delivery charge. If this sits only with the owner, every small decision waits for the owner, and small decisions in fulfilment are time-sensitive.

Someone who owns supplier and carrier relationships. The person who chases, escalates and knows who to call. Often the owner in a small store, and often the first thing worth handing over.

Naming these three and saying what each can decide without asking removes most of the daily coordination overhead, which is the actual cost of an unclear workflow.

Decision limits, written down

The single highest-return document here is not a process map. It is a short list of what each person can decide alone.

Something like: reship without asking under a value floor; refund the delivery charge without asking; upgrade a service without asking when the order is already late. Above the floor, ask, and here is who to ask.

Two things happen when you write this. Decisions get faster, because most of them are below the floor. And the ones above the floor arrive as actual escalations rather than as a nervous question, which is a different and much better conversation. There is more on what an escalation should contain in what a good escalation actually contains.

Reviewing the map when something breaks

A workflow document that is written once and never touched is a decoration. The useful habit is to open it whenever an order goes badly and ask a single question: which of the eight decisions was unclear, unowned or made too late?

Usually it is one of them, and usually the fix is a sentence. Over a few months this converts the document from a description of what you intended into a description of what you do, which is the only version anybody consults.

This fits naturally into a weekly review. Five minutes, one order, one amendment.

What this looks like in Store Huddle

The structural version of all this is a room per decision area rather than one channel for everything. A fulfilment room where the queue lives, with the people who own it in it and nobody else. Orders and products attached to the conversation, so the item under discussion is identified rather than described. Tasks with a single owner and a due date, so a decision that needs making is visible as an open item rather than as a message somebody may have read.

The Fulfillment role exists for exactly this: someone who needs the packing rooms and the order context, and does not need everything else. Roles decide which rooms a person sees, so the person owning the queue is not reading marketing conversations to find the one message that concerns them.

None of that replaces the thinking. The eight decisions and the names against them are the work. The tool just stops the answer from being spread across four apps.

Common questions

What is a fulfilment workflow?

The sequence of steps between a customer paying and a parcel arriving, together with who decides what at each point where a choice is required. The decision points matter more than the physical steps, because that is where small teams lose orders.

How many people does a small store need for fulfilment?

Three roles rather than three people: someone who owns the queue day to day, someone who can spend money on a fix without asking, and someone who owns supplier and carrier relationships. One person can hold two of them.

Should we document the whole process or just the decisions?

Start with the decisions. A long procedure document for packing a box gets read once. A one-page list of who decides what, and what each person can decide without asking, gets used every week.

How do we stop two people working on the same problem?

Put a single name against each decision, and make in-progress work visible as an owned task rather than as a message in a thread. Duplicate effort is nearly always a visibility problem rather than a communication one.

When is it worth formalising this?

As soon as more than one person touches fulfilment, or as soon as the owner is not always available. Below that the workflow lives in one head and works fine. Above it, the undocumented version starts costing orders.

Keep reading

Fulfilment

Working with a 3PL: the communication that matters

A third-party warehouse is an operations team you cannot see. What has to flow each way, at what cadence, and what to do when the portal disagrees with reality.

5 September 2026·11 min read
Fulfilment

In-house fulfilment or a 3PL: how to decide

The question is not which is cheaper per order. It is which failure mode you would rather manage, and what each choice does to your team's day.

3 September 2026·11 min read
Fulfilment

Stuck shipments: spotting a delay early

A parcel stops moving and nobody notices for four days. A simple detection rule, a routing decision, and what to do before the customer emails you first.

1 September 2026·10 min read

Run your store team in one room.

Free for teams up to five, and about two minutes to connect your store.