One table. Three kitchens. Everybody wants their order.
At Lion Hospitality Partners, one table can order food and drinks from several independent vendors in the same venue. I led the KDS work that turned a paper relay into one ticket with live, item-level routes to each kitchen or bar. The waiter knows what's preparing, what's ready and what's sold out before the guest has to ask.
One table, three kitchens
A table orders grilled chicken, goat meat pepper soup and a bottle of Hennessy. At some Lion Hospitality Partners venues, those three things come from three different vendors, each with its own kitchen or bar. The guest made one order. The old operation needed people to carry its instructions around.
Before the KDS, waiters passed paper dockets to runners, who delivered them to the right stations, chased updates and brought information back. With 20 or 30 waiters on the floor, the venue could have about ten people effectively carrying information between rooms.
I led the move to item-level routing. The waiter enters one ticket. Each item goes directly to its vendor's kitchen or bar, which can mark it preparing, ready and picked up. Waiters and managers see those changes live. A kitchen can also switch off pepper soup when it's finished, before someone promises it to the next table.
The new flow reduced the need for runners to roughly two or three per venue, by my operating account. It also removed a particularly irritating conversation: the waiter telling a guest their order is unavailable after someone has already taken it on paper. Those are operational improvements; a precise payroll saving would need comparable-shift records.
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 rules follow the service model. At a table, the waiter sends items to their respective kitchens and charges the table as service closes. Prepaid direct and WhatsApp orders wait for confirmed payment before kitchen release. Marketplace orders enter the same order-state model, with their payment state attached.
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
| Product surface | Problem addressed | My contribution | State |
|---|---|---|---|
| Lion POS + manager tools | Order entry and venue management needed a live foundation to build newer work around. | Treated the existing POS as the operating spine, designing newer surfaces around the order states it already needed. | Live |
| Waiter / QSR ordering | Front-of-house staff needed fast order capture into the same live system. | Front-of-house order capture built on the same live foundation as POS and kitchen display. | Live |
| Kitchen Display System (KDS) | Kitchen production needed a shared, visible order state other systems could depend on. | Made the ready-for-handoff checkpoint the trigger other systems, including inventory, depend on. | Live |
| WIMS (inventory) | Stock needed to reflect how it actually moves, tracked in the unit staff use, not just abstract counts. | Modelled stock as a physical movement — warehouse, transfer, venue — tied to the kitchen’s existing handoff checkpoint. | Live |
| Fulfilment Console | Multiple inbound order sources risked becoming separate queues with separate handoffs. | Designed one queue owned by one role, the Fulfilment Officer, so a new order source is a configuration change, not a new screen. | Live |
| Direct Storefront | Customers needed a direct-ordering channel alongside marketplace delivery. | Added as a live order source into the same unified system, not a separate build. | Live |
| Rewards / credits | Customer loyalty and repeat visits. | Scoped but not yet built. | Held |
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.
The waiter app keeps the table, item categories and active ticket together. One order can contain dishes and drinks from different vendors; sending it routes each line to the right station, and the readiness states return to the waiter while the table stays open.
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.
Give each vendor a live view of the business
The kitchens and bars needed more than order statuses. I worked through what our vendors needed to know each night: how much they earned, where sales dropped off and which dishes performed best. I designed live dashboards that bring those figures together by vendor, with a trading history they can use to forecast their next shift.
That changed what a vendor could do with the system. They could monitor nightly revenue and product performance directly, rather than depend on an end-of-night report or someone relaying numbers. It also gave the group a consistent operating picture of individual vendors across its venues.
We are developing the next use of that data: earnings-backed advances assessed against historical and forecast trading, with percentage-based pricing. The vendor-financing product is in development.
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.
Results in service
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.
The operational numbers behind the change
Between 1 April and 17 October 2026, the platform collected ₦1.95bn (about US$1.4M) across 39,680 paid tickets across 14 venues. Replaced paper dockets with item-level KDS routing and a ready-before-served kitchen gate, cutting runners needed per venue from roughly ten to two or three.
Paper dockets needed roughly ten runners per venue to carry instructions and chase readiness across vendors. Item-level kitchen routing and live ready/picked-up states reduced that requirement to about two or three, based on how I ran the operation.
The August operations report also recorded 362 staff profiles in a new shared management system with five roles. Suspension and exit states now revoke access in the POS and warehouse system together. The design decision was to make the staff record the authority instead of asking each product to manage access independently.
Leading delivery while the restaurants kept trading
I led product and technology across POS, kitchen, fulfilment, inventory and staff access, working with the engineering team and Operations. July's delivery decisions were practical: reuse Combos' quick-service stack for the next venue, put direct Hungry Lion fulfilment on the existing order lifecycle, and defer the separate native app while the owned storefront proved the channel. The August report records the storefront live on 20 August.
Shipping software did not finish the operational work. After a promotion, some completed orders stayed unacknowledged in the Fulfilment Console because staff recorded fulfilment by hand. I separated the product issue from the working-practice issue, called for CX retraining and explicit Operations ownership, and kept incorrect customer status visible as unfinished work.
When screen generation became faster than design review, I wrote the UX and UI rules our Claude Code workflow reads before producing interfaces and rebuilt the shared design layer in Claude Design. Moving consistency into the starting rules let the team continue producing screens without depending on me to manually correct every first pass.
