The customer journey ends in a kitchen.

The problem

Lion Hospitality Partners runs a multi-venue hospitality group. Point of sale, kitchen production, stock, dispatch and — as new order sources came online — direct ordering could not be treated as separate interface projects, because the same order moves through every one of them.

The starting point was a point-of-sale and kitchen stack already carrying live service. New order and fulfilment paths had to open on top of that without breaking day-to-day trading, and the pieces involved were at different stages of maturity: some were already running production service, others were still being built. The product problem was connecting a live operation to newer surfaces honestly — without describing work still in progress as if it were already shipped.

How I modelled the system

Read it as one order moving through one operating system, not a collection of separate products. Order intake, kitchen production, stock, dispatch and direct ordering are parts of the same operating system handling that order, not independent apps. Modelling the whole stack as a single system — rather than a set of separately owned tools — is what let the group add new order sources, first a delivery marketplace and later a direct storefront, without a rebuild each time an entry point changed.

Product and architecture decisions

Use the existing operating spine. Point of sale and kitchen display already carried live service, so I treated them as the operating spine and designed the newer fulfilment, stock and direct-ordering work around the order states they already needed, rather than inventing a parallel set of states for every new surface.

One fulfilment role, one queue. Every inbound order source — delivery marketplace, direct storefront and the channels the group intended to add over time — was designed to land in a single queue, owned by one role: the Fulfilment Officer. Adding a new order source is meant to be a configuration change, not a new screen and a new handoff.

Model stock as physical movement, not just numbers. Inventory needed to reflect how stock actually moves — sealed stock in the warehouse, a transfer to a venue, a working quantity the bar tracks day to day — and to tie that movement to a checkpoint the kitchen already used, rather than a separate stock-count step nobody had time for.

What is live

Fulfilment Console

The delivery operation began on a single marketplace. The Fulfilment Console was designed to take on more than one order source from the start — marketplace delivery, direct storefront orders, and other channels the group intended to add — without turning every new source into its own queue and its own handoff.

I designed the Console around one accountable role, the Fulfilment Officer: every order lands in a single queue, and one person keeps ownership of it from acceptance through kitchen progress to handoff. That is as much an operating-model decision as an interface one — it assigns a role, not just a screen.

The Console runs in the browser, so order handling is not tied to a licensed counter machine — any authorised device can pick up the Fulfilment Officer role.

Dispatch is designed to trigger at the kitchen ready-for-handoff checkpoint rather than the moment an order first arrives. The reason is operational: a rider sent too early waits at the counter, while one sent too late extends the delivery time. Tying the dispatch request to a kitchen checkpoint keeps that timing decision inside the same system that already tracks kitchen progress.

Point of sale, kitchen display and inventory

Point of sale, kitchen display and inventory now run as one connected backbone. The same checkpoint the kitchen uses to mark an order ready for handoff is the point the inventory model depends on to move stock from committed to consumed, so stock truth is tied to an operational moment staff already pass through, rather than a separate count.

The inventory model starts with the physical movement of stock. A warehouse holds sealed stock with source cost and markup information attached. A transfer moves it to a venue, where the working quantity is tracked in the unit the bar actually consumes. Receiving at the venue closes the transfer. That gives the system a place to distinguish warehouse stock, stock in transit and venue stock, without trying to be a full accounting system.

The state model makes that checkpoint visible rather than implicit. Labels are written for the people using them — Order accepted, In preparation, Ready for handoff, Completed — rather than as internal system codes, and the flow does not allow a line to skip from preparation straight to completed without passing the checkpoint the inventory depletion depends on.

The same item can be positioned differently at different venues, so venue-specific pricing was part of the design from the start: one catalogue entry, a different price per venue, rather than a duplicated item for every venue that carries a different price.

Result and boundary

Point of sale, kitchen display, inventory, fulfilment and direct ordering now run as one connected system across the group’s venues, covering an order from the moment it arrives to the moment it is handed off. That came from treating a live operation and a set of newer surfaces as one system to design, rather than a rebuild bolted onto something already running.

Rewards and credits infrastructure remains held, with no shipped feature to show yet.

Next case study

Prediction is useless until a teacher knows what to do next.