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.

Concretely, the till does not talk to five applications. It writes one event, and each downstream service holds its own contract against it: what it consumes, and what it emits in turn. That is what keeps a new order source from becoming a new integration for every system behind it.

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.

Payment-gated release, whatever the channel. An order does not become kitchen work until its required payment state is on it. At the counter, that means a payment method on the ticket before Send. Direct and WhatsApp orders are likewise held out of the kitchen until payment is confirmed; marketplace orders enter the same shared order-state model.

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.

Each channel arrives incomplete in a different way — a dictated address to geocode, free text to parse, a partner’s schema to map — so each carries its own normalisation step. Past that step the queue row is the same object every time: reference, lines, money, state. The channel tag is a label on the row, not a branch in the code.

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.

The input that matters is remaining prep time as the kitchen display reports it, not a menu estimate, so a backlog on one station moves the trigger for the orders behind it. When travel is longer than prep there is no clever moment — the driver goes immediately and the food is the thing that waits, which is also how the promised time is quoted at the point of ordering.

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.

At the till that means one screen and no modes: a cashier works standing up with a queue behind them, so categories, items and the open order never leave the screen, par level sits on the item rather than being discovered when the kitchen refuses it, and the ticket cannot go to the line until a payment method is on it.

On the line the same order becomes a ticket carrying only what the kitchen can act on: quantity, item, modifier, elapsed time. Tickets are filtered by station so the grill sees only its own work, items are marked ready individually, and the bump that clears the ticket is the checkpoint everything downstream waits on.

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.

A venue never buys; it draws down. Only the central store buys from a vendor, so one movement log holds every transfer, sale and receipt — which is why a par breach at a bar can raise a purchase draft against the store rather than a phone call nobody logs.

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.

What matters as much as the happy path is that every exit has a route. A cancellation after the grill has started is not the same event as one before it, so each exit names who acts, what the customer is told, and what happens to the money and the stock. A void needs a reason; a partial refund records which lines survived.

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.

The resolution runs one way: one item record and one recipe cost, then the venue’s price book, then the channel’s modifier. A beach bar and a rooftop can charge differently for the same platter because that is the venue’s decision, and an aggregator’s commission is applied as a modifier rather than as a second price stored somewhere else to drift.

Customer identity and service recovery

The same guest arrives through different doors: at the counter, over WhatsApp, through the direct storefront. The design holds one shared identity behind all of them, so an order carries who it is for as well as what it contains, and a guest’s history is one record rather than one per channel. That is what guest management stands on, and what the held rewards work would stand on.

Service recovery is designed the same way as the happy path: as states with an owner. A cancellation after the grill has started, a void and a partial refund each have a route that names who acts, what the guest is told, and what happens to the money and the stock — a void needs a reason, a partial refund records which lines survived. Delivery completion is a state of its own: an order is closed when the handoff is confirmed, not when it leaves the counter.

None of this is described here as a specific incident. The venues, staff and guests in these frames are representative, and the recovery routes are shown as the system defines them, not as a record of any one service.

Result and boundary

Point of sale, kitchen display, inventory, fulfilment, direct ordering and customer identity 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 and recorded against the guest. 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.

Every venue, member of staff, item, price and order reference in these frames is representative data drawn for the frame. This is software running a live business, so no venue’s real trading appears here, and no adoption, dispatch-time or inventory-variance figure is claimed.

Next case study

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