On this page
Separate the responsibilities
Treat the phone, your own web checkout and each marketplace as independent intake channels. A channel can send to the same POS without sharing its menu cache, payment state or order identifier. Write the name of the exact product and the location it serves, rather than a vendor umbrella name. Middleware is part of the path and needs an owner too.
For each connection, ask what crosses the boundary. Does the provider send a fully priced order or a list of requested items? Does the destination validate modifiers? Does the acknowledgement mean the request was received, accepted by the POS or routed to a kitchen device? Name those events separately.
A practical channel contract
- Source: where the request begins and which location identifier it uses.
- Authority: who controls menu, prices, availability and fulfillment promise.
- Acceptance: the returned order ID and the rule for treating it as confirmed.
- Production: the kitchen destination and acknowledgement, including printer or KDS failure.
- Recovery: the person and system that reconcile uncertain or rejected events.
A useful contract also says what the channel does not do. If a delivery marketplace manages couriers, do not give your phone service responsibility for courier dispatch unless that capability has been confirmed. If staff collect payment at pickup, document that choice rather than marking payment as missing.
Design the fallback before the rush
A fallback should not create a second order merely because the first request is slow. The staff member needs the source reference, expected destination and latest verified state. If the state is uncertain, search by reference before entering anything manually. If the order is confirmed absent, use the approved replacement process and retain the link to the original request.
Publish a short shift-facing route: who is on call, where the exception queue lives and how a guest receives a corrected promise. Test that route during an ordinary shift before depending on it during peak service.
What to capture in your diagram
Use one arrow per real system boundary and label the message or event it carries. A single line labelled integration hides too much. Include menu updates, order submission, status acknowledgement and payment events as separate connections. For each arrow, record the direction and whether the receiving party can retry it safely.
Turn this map into a validator plan. Review any dependency warnings with the specific providers. A drawing of a connection is not evidence that it is enabled for your plan, location or software version.
Customer evidence for this order workflow
Use these customer workflows to label the arrows in your own system map: phone intake, payment, order acceptance and kitchen receipt. The stories describe phone ordering alongside the rest of restaurant service.
Results and operating context from Loman’s published customer case studies.
Urban Bird
- About $80,000
- sales processed through LomanAcross Urban Bird stores in one reported month; channel sales.
- Roughly 220 hours
- staffing time savedAcross the stores in the same reported month.
Draw the reported Urban Bird path as separate events: phone order, online payment and kitchen ticket for prepaid pickup. Identify which system acknowledges each event in your own architecture.
Read the Urban Bird case study ↗Watch Urban Bird on YouTube ↗
Euro Gyro
- 5 tickets
- seen arriving together in ToastAn owner-observed example of concurrent order flow.
- No manual re-entry
- phone orders flow directly into ToastThe workflow described in Loman’s Euro Gyro case study.
Draw the specific Toast handoff rather than an unlabeled integration arrow. Euro Gyro’s story describes direct phone-order routing without manual re-entry; verify the destination and acknowledgement for your location.
Write one complete channel row
Illustrative row: phone intake → configured ordering service → accepted POS order → kitchen ticket. Alongside that path, record the menu owner, returned order reference, payment owner and shift role that investigates an uncertain result. Leave an unverified connection marked unknown.
Use Loman’s Toast integration description for a POS example and its Olo integration description for a path with an ordering platform between intake and downstream systems. Confirm the actual hops in your setup.