Kanban for Delivery Operations: Build a Board That Moves Orders

A Kanban board for delivery operations is a visual map of every order between “received” and “delivered”, with a hard cap on how many can sit in each stage at once. That cap is the part that does the work. Without it, you have a wall chart.

Most delivery operations already track orders somewhere: a spreadsheet, a clipboard, a shared inbox, someone’s memory. What they don’t have is a way to see, at a glance, that fourteen orders are stuck in packing while the van sits empty. Kanban makes that visible, and then makes it uncomfortable enough to fix.

This guide covers the columns a delivery board needs, how to set work-in-progress limits without guessing, and how to read cycle time and bottlenecks off the board. Kanban is one of several methods in the agile approach to managing deliveries; it’s the one to start with, because it changes what everyone can see without changing who reports to whom.

The Bottom Line

• A Kanban board has two non-negotiable parts: columns that match your real workflow, and a numeric limit on how many cards can sit in each one.
• Little’s Law says average cycle time equals work in progress divided by throughput, so cutting the number of orders in flight cuts how long each one takes, without anyone working faster (Businessmap, Little’s Law).
• Kanban started on a Toyota factory floor as a system for moving physical parts, not as project-management software.
• Where a card stops moving is your bottleneck. That’s the whole diagnostic.

What a Kanban board for delivery operations looks like

Kanban has two primary practices: visualise the work, and limit work in progress. Everything else is commentary.

Applied to deliveries, “the work” is an order. Each order is a card. Each card moves left to right across columns that represent the real stages an order passes through in your business. A workable starting set for a food, floral or wholesale operation:

• Received — the order exists but nobody has touched it.
• Confirmed — stock checked, delivery window agreed, customer told.
• Picking — someone is assembling it.
• Packed — it’s complete and waiting for a vehicle.
• On route — it’s with a driver.
• Delivered — proof captured, done.

Don’t copy that list. Watch an order go through your own business for one day and write down what actually happens to it. If your orders wait for a morning bake, add a column. If picking and packing are one motion done by one person, merge them. A board that doesn’t match reality gets ignored within a week, and an ignored board is worse than no board, because it looks like you have a system.

The other thing on every card: when it entered the board. That timestamp is what makes the metrics possible later, and it costs nothing to write down.

Physical board or software?

Start physical if you can. A whiteboard and sticky notes in the room where the work happens beats a tool nobody opens. Physical boards have one advantage: the pile-up is visible to everyone who walks past, including you.

Move to software when the board stops fitting on the wall, when people need to see it from a van, or when you want the cycle-time numbers calculated rather than counted by hand. That threshold usually arrives somewhere past a few dozen orders a day.

How work-in-progress limits fix a delivery backlog

A work-in-progress limit is a number written at the top of a column saying how many cards may sit there at once. When the column is full, nothing new enters until something leaves.

This feels wrong the first time. It looks like deliberately refusing to start work. That’s exactly what it is, and it’s the reason it works.

Little’s Law states that average cycle time equals average work in progress divided by average throughput (Businessmap). Your throughput, meaning how many orders you can complete in a day, is set by your people and your vehicles, and starting more orders doesn’t raise it. So every extra order you start while capacity is fixed lengthens the time every order takes. Halve what’s in flight and you roughly halve how long each one sits there. Nobody worked faster. Less was in the way.

The practical effect on a delivery floor: when packing is capped at six, and it’s full, the picker doesn’t start order seven. They go help pack. The bottleneck gets resources instead of getting a queue.

Setting your first limits without guessing

Don’t compute anything on day one.

1. Run the board with no limits for a week and just count. Note the largest number of cards that sat in each column at once.
2. Set each limit slightly below that peak. If packing peaked at nine, set it at seven.
3. Watch for two weeks. If a column is permanently full and blocking, that column is your bottleneck. That’s information, not a reason to raise the limit.
4. Only raise a limit when you’ve actually added capacity to that stage. Raising it to relieve discomfort just restores the original queue.

The most common mistake is setting limits so generous that they never bind. A limit that is never reached is decoration.

Reading cycle time and lead time off the board

Two numbers come free once cards carry a start timestamp.

Cycle time is how long a card takes from when work starts on it to when it’s delivered. Lead time is the longer clock: from when the customer ordered to when they received it, waiting included.

The gap between them is your queue. An operation with a four-hour cycle time and a two-day lead time doesn’t have a speed problem. Orders are sitting untouched. Hiring a faster picker fixes nothing there; the fix is upstream, in how orders are accepted and scheduled.

Track the spread, not just the average. The slowest 10% of orders generate a disproportionate share of complaints, and an average hides them completely. Ten orders at two hours and one at nine averages out to something that looks fine, while the nine-hour customer is the one calling.

Once you have a fortnight of data, the review is straightforward: which column do cards sit in longest, and what would it take to shorten that? That question, asked every two weeks with the people who do the work, is the engine. The Scrum framework gives that review a formal structure with sprint retrospectives if you want one, which is useful when the fix is a project rather than a tweak.

Kanban for inventory: the pull system it came from

Kanban began at Toyota as a scheduling system for just-in-time manufacturing. The Japanese word means a sign or card, and the original cards were physical tickets that travelled with parts bins. When a bin emptied, its card went back upstream, and that card, not a forecast, authorised making more.

That’s a pull system: actual consumption triggers replenishment. The forecast doesn’t.

The same logic applies to stock behind a delivery operation. A two-bin setup is the simplest version: keep two containers of a fast-moving item, work from the first, and when it empties, that’s the signal to reorder while you work from the second. The reorder point isn’t a calendar date or a guess, it’s an empty bin.

This pairs naturally with smaller, more frequent supplier orders, and it’s why Kanban shows up in inventory contexts as often as in workflow ones. One caution: pull systems assume reasonably steady demand. If your volume triples for two weeks in December, a pure pull system will be chasing itself the whole time, and you should buffer deliberately for the season instead.

When Kanban isn’t the right tool

Kanban manages flow through a process that already exists. It’s poor at three things.

It won’t tell you whether a new service should exist at all. If you’re weighing up Saturday delivery or a new zone, that’s an untested guess and needs an experiment, which is what Lean Startup’s build-measure-learn loop is for.

It won’t diagnose a vague problem. “Customers are unhappy” doesn’t map to a column. Narrowing that to something specific is design thinking’s job, and it happens before the board can help.

And it won’t run a project with a deadline. Kanban flows continuously with no fixed end point, which is a feature for daily operations and a problem when you need something finished by the fifteenth.

Software that keeps the board honest

Past a certain volume, maintaining a board by hand costs more attention than it returns, and the timestamps start getting entered from memory.

What matters in a tool is whether it shortens the loop between a change and its result: real-time driver tracking so “on route” reflects reality instead of an assumption, proof-of-delivery photos so cards close cleanly rather than staying open pending a dispute, automated customer notifications so status questions don’t interrupt the flow you’re trying to measure, and route optimisation so a change to the plan takes seconds.

Metrobi provides these for food, floral, catering and wholesale businesses: multi-stop route optimisation, live driver tracking, photo proof of delivery, and customisable notifications on dispatch, progress and completion. The useful test for any tool is whether the “on route” column can be trusted without a phone call.

Frequently asked questions

What are the columns on a delivery Kanban board?

Received, confirmed, picking, packed, on route, delivered is a reasonable default. The correct answer is whatever stages an order passes through in your business, which you find by following one order for a day rather than by copying a template.

How do I choose a work-in-progress limit?

Run the board unlimited for a week, note the peak number of cards in each column, and set the limit slightly below that peak. Tighten over time. Raise a limit only when you’ve added real capacity to that stage.

Is Kanban the same as a to-do list?

No. A to-do list has no stages and no limits, so it grows without telling you anything. Kanban’s value is the column structure, which shows where work stops, and the limits, which force the stoppage to be dealt with rather than absorbed.

Can Kanban work for inventory as well as orders?

Yes, and that’s its original use. A two-bin system, where an emptied bin is the signal to reorder, is Kanban applied to stock. It works best when demand is reasonably steady and needs deliberate buffering around seasonal peaks.

Put one board up this week

Kanban for delivery operations is unusually cheap to try. A whiteboard, one column per stage, one card per order, and a number at the top of each column. A week of running it unlimited tells you where the pile-ups are, and the limits you set afterwards are what turn the observation into a change.

Start with the stage that frustrates you most. Count what’s sitting there right now. That number is your first limit, minus two.