The Takeaway Orders Build Standard

1. What this standard covers

A caller, or a visitor in the chat on the venue’s website, who wants to order for pickup or book a table, at a moment nobody on the floor can take it. The build answers, says it is an AI, and takes the order or the booking the way the venue’s best front-of-house person would: from the real menu, with every choice asked, read back, paid, and into the kitchen once. The phone and the chat follow the same rules. Only the opening line differs, because a chat is not a recorded call.

What is out of scope. Delivery: handing an order to a courier is a separate write with its own failure, and it is not here. Ordering at the table, menu design, specials boards and stock control are out of scope too. So is answering every call: this standard is about the calls the floor cannot take. A venue that wants every call answered, all day, is describing the Client Desk standard, and the two can run on one number.

What cannot meet it, and what can. Any till that can read out its menu by API and take an order into the kitchen can meet it, with any payment provider that can make a payment link and say whether it was paid. Square is one example of a till that does both. What cannot meet it is a till with no API, a menu that exists only as a PDF, or a payment step that asks the caller for their card number. A build on those can take messages, but it cannot pass check 2 or check 9 live.

Is there a ready-made version? Yes. Pickup Orders on Office Voice runs it on your own number and your website chat for $199 a month, up to 450 calls; a busier venue is $499 a month, up to 1,500. Nothing is charged per call. Done for you, where we connect your till, payment provider and booking system and tune it to your menu, is quoted per venue. The standard stays a Draft until the order write into the till has run live for a venue.

2. The menu, and what the build may say

The build says nothing about food that the venue’s own records do not hold. Five things, and where each one comes from:

The pickup list is the one most builds leave out, because the till already has a menu and it looks complete. But a clay-pot dish that leaves the kitchen in a lidded bowl and arrives at the car park as soup is a dine-in dish, and only the owner knows which ones those are. Asked for one, the build says it is dine-in only and offers a pickup dish or a table.

Allergies are answered from the recorded allergens and nothing else. “The noodle salad has peanuts in it. It’s a shared kitchen, so we can’t promise no traces.” Never “that one’s safe.” The allergy goes onto the order, so it prints on the ticket. A caller who says the allergy is serious is handed to a person before anything is ordered: that conversation belongs with the kitchen.

3. Taking the order

1. Say it is an AI, first. On the phone, also that the call is recorded. Before any question.
2. Each required choice, once. A caller who said “two beef pho” is not asked beef or chicken. A caller who said “and a noodle salad” is asked which protein, once.
3. Nothing off the menu. Asked for pad thai at a Vietnamese kitchen, the build says they do not make it and names the closest real dish. It never puts a price beside a dish the venue does not sell.
4. A pickup time the kitchen can make. Inside today’s service windows and after the lead time. After the last window it says so; with the kitchen closed for the day, it says when it next opens and offers a table.
5. Read it back. Every dish with its choices and the pickup time, and the caller says yes. A no means nothing is ordered and nothing is charged.

The price comes last, and from the payment provider. The build never adds up the order itself: the total the caller hears is the one the provider returned when it made the link, from the till’s own prices. A build that says “that’ll be about forty dollars” before then has priced the order, and check 2 fails it.

4. Paid before the kitchen

This is the departure from every other call standard on this site. A pickup order is two writes into two of the venue’s systems: a payment link from its payment provider, then the ticket in its till. The order between them is the standard.

The build texts the caller a secure link, waits for the provider to say it was paid, and only then writes the ticket. A ticket that prints first is a meal cooked for someone who may never come, and in most tills an order marked paid that was not is also a wrong end-of-day. A link that is not paid in the time the venue set is cancelled, so it cannot be paid later for an order the kitchen never saw.

A caller who starts reading out a card number is stopped politely and sent the link. No card number reaches anything the build writes to: not the order, not the log, not the transcript the build keeps. And both writes carry a key for the call, so a dropped line, a caller who rings back, or a retried event finds the order already placed rather than charging and printing it twice.

5. Tables

A table is confirmed only once the venue’s booking system has taken it and given back a reference. Until the booking system is connected, the build texts the caller the venue’s own booking link and says plainly that nothing is held yet. “I’ll pop you down for seven” with no write behind it is a table for six people that does not exist when they arrive.

A party over the venue’s limit, or anything that sounds like a function, goes to the manager for a callback. The build never tries the booking system for it, because a booking system that accepts a table of fourteen at 7pm on a Saturday is not the same as a kitchen that can feed it.

6. The records it keeps, in the shape your developer needs

Six objects. The Menu is read, never stored: the build holds the till's item ids and nothing else about food. The Handoff is the one most builds leave out, because a caller who was told someone would ring back and never was looks the same as a call that went well.

MenuItem                          # read from the till on every call
  - id (the till's), name, price
  - pickup                          # from the owner's pickup list
  - choices [{group, required, options [{name, price?}]}]
  - allergens                       # as recorded; absent is never "free of"

Order                             # one per call or chat
  - key                             # the call or chat id; unique
  - channel (phone | web_chat)
  - caller {name, phone}
  - lines [{item_id, qty, choices}] # every required choice filled
  - pickup_at                       # inside today's windows, after the lead time
  - allergy                         # the caller's words, printed on the ticket
  - read_back_at                    # when the caller said yes

PaymentLink                       # the provider's, not the build's
  - id, order_key
  - total                           # computed by the provider from the till
  - status (open | paid | cancelled)

Ticket                            # in the till; one per order
  - id, order_key, payment_link_id
  - printed_at                      # after a read that said paid

Booking
  - order_key, party, at
  - ref                             # from the booking system; none means not booked
  - link_sent                       # the venue's own link instead

Handoff
  - order_key
  - reason (complaint | serious_allergy |
            group_or_function | asked_for_person)
  - detail, caller_phone, called_back_by

A Ticket whose PaymentLink was not paid when it printed is the defect this standard exists to make unrepresentable. A total the build worked out itself is the other.

7. The checks, in order

The order is the claim. The disclosure comes before anything is asked, the menu is read before any dish is discussed, the read-back comes before the link, and the payment comes before the ticket.

1. It says it is an AI and that the call is recorded, first. Before anything else is said or asked, the caller hears that they are talking to an AI assistant for the venue and that the call is recorded.
2. The menu comes from the venue's till, and the total from its payment provider. Every dish, option and price is read from the venue's own menu before anything is offered. The build never states a price of its own: the total the caller hears is the one the payment provider returned.
3. A dine-in dish is never sold for pickup. Only dishes on the owner's pickup list are offered for pickup. A dine-in-only dish is declined in plain words, with a pickup alternative or a booking.
4. A dish that is not on the menu is not invented. Asked for something the venue does not make, the build says so and offers the closest real dish. It never names a price for it.
5. Every required choice is asked, once each. A dish with a required choice (beef or chicken, pork or veg) is never ordered without it. Each missing choice is asked on its own, and a choice the caller already gave is not asked again.
6. Allergy answers come from the menu, never call a dish safe, and go on the ticket. An allergy question is answered only from the allergens the venue recorded, with a shared-kitchen warning and never the word safe. The allergy is carried onto the order. A serious allergy goes to a person before anything is ordered.
7. No pickup time the kitchen cannot make. A pickup time is inside today's service windows and after the kitchen's lead time. When the kitchen is closed for the day, it is bookings only, and the caller is told when it next opens.
8. The order is read back and confirmed before anything is charged. Every dish and its choices are read back and the caller says yes before a payment link is requested. A no means nothing is placed.
9. The kitchen ticket prints only once the order is paid. The ticket is written into the venue's till only after the payment provider says the link was paid. A link left unpaid is cancelled so it cannot be paid later, and no ticket prints.
10. A card number is never taken by voice. Payment is a secure link. A caller who starts reading out a card is stopped and sent the link, and no card number reaches any system the build writes to.
11. No table is confirmed without the booking system. A table is confirmed only once it is written into the venue's booking system. Until the system is connected, the caller is texted the venue's own booking link. A party over the venue's limit goes to the manager.
12. A person is brought in for four reasons, and only those. A complaint, a serious allergy, a big group or function, or a caller who wants a person. Each handoff names its reason. A routine order is never handed off.
13. A retried call never charges or prints twice. The payment request and the ticket carry a key for the call, so a dropped line or a retried event finds the order already placed.
14. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
15. The pass test passes. A real call to the venue's forwarded number orders a dish with a required choice, is paid by link, and prints in the venue's own till with that choice; an unpaid order never prints; a dine-in dish is never sold.

The handoffs, a closed list:

8. What stays with a person

• ✓Every complaint. The build takes the details and a manager rings back.
• ✓A serious allergy, before anything is ordered. The kitchen knows what touches what; the build does not.
• ✓A group or a function over the venue's limit.
• ✓Any caller who asks for a person.
• ✓The menu, the pickup list, the kitchen hours, the lead time and the group limit. The build reads them; the owner sets them.
• ✓A refund. The build never promises one.

9. Run it on what you already use

The conversation needs a voice or chat agent; everything around it can live where the venue already works. Three ways, all held to the same checks:

• Existing tools only. A shared sheet or Microsoft 365 lists for the pickup list, the orders and the handoffs, with the agent writing into them and a flow that prints only paid orders. The Microsoft 365 plan lays out the lists and flows.
• A personal dashboard. Hand this page to a coding agent and it builds a small page for the owner: the pickup list to tick, today’s orders with their payment status, and the handoffs to ring back, against the stub until the till has to be real.
• A long-lived bot. The agent on the venue’s forwarded number and its website chat, with the payment provider’s webhook waking the step that prints the ticket.

How to run any standard each of these ways is in run a standard anywhere.

10. What your developer builds, and the step that needs care

Three steps not to hand-roll, and they are one step really: reading the menu from the till, asking the venue's payment provider for a link it prices, and printing the ticket in the same till only once that link is paid. Everything else a coding agent builds against the stub in an afternoon.

provider:
  stub:       local.mock_venue
  production: office_voice.restaurant   # Office Voice / Restaurant, sold as Pickup Orders
  default:    stub                       # no live mapping in the conformance kit yet

the stub                             # local.mock_venue
  - a menu with a choice that sets the price, a dine-in-only
    dish and recorded allergens
  - today's windows, a lead time and a group limit
  - a payment provider that prices from the menu and a caller
    who pays, or does not
  - a till that prints whatever it is given, and records
    whether the link was paid at that moment
  - a booking system that refuses when it is not connected

the hard step: the money, then the kitchen
  - read the menu from the venue's till on every call
  - ask the venue's payment provider for a link, with the
    order's lines; take the total it returns
  - print the ticket only after a read that says paid;
    cancel a link left unpaid
  - one key per call on both writes

stays local                          # yours, and the standard
  - the conversation, the choices, the read-back
  - the pickup list, the hours, the handoffs and the log

cannot meet the standard
  - a till with no API, or a menu that exists only as a PDF
  - a payment step that takes the card number by voice

A vendor selling an AI phone line for restaurants is usually selling the conversation. Ask them three things: what the kitchen sees when the caller never pays, where the price the caller hears comes from, and what happens when the caller asks for a dish that is on the menu but not for takeaway.

11. A checklist to hold any build or supplier to

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. It says it is an AI and that the call is recorded, first. Before anything else is said or asked, the caller hears that they are talking to an AI assistant for the venue and that the call is recorded.
• ✓2. The menu comes from the venue's till, and the total from its payment provider. Every dish, option and price is read from the venue's own menu before anything is offered. The build never states a price of its own: the total the caller hears is the one the payment provider returned.
• ✓3. A dine-in dish is never sold for pickup. Only dishes on the owner's pickup list are offered for pickup. A dine-in-only dish is declined in plain words, with a pickup alternative or a booking.
• ✓4. A dish that is not on the menu is not invented. Asked for something the venue does not make, the build says so and offers the closest real dish. It never names a price for it.
• ✓5. Every required choice is asked, once each. A dish with a required choice (beef or chicken, pork or veg) is never ordered without it. Each missing choice is asked on its own, and a choice the caller already gave is not asked again.
• ✓6. Allergy answers come from the menu, never call a dish safe, and go on the ticket. An allergy question is answered only from the allergens the venue recorded, with a shared-kitchen warning and never the word safe. The allergy is carried onto the order. A serious allergy goes to a person before anything is ordered.
• ✓7. No pickup time the kitchen cannot make. A pickup time is inside today's service windows and after the kitchen's lead time. When the kitchen is closed for the day, it is bookings only, and the caller is told when it next opens.
• ✓8. The order is read back and confirmed before anything is charged. Every dish and its choices are read back and the caller says yes before a payment link is requested. A no means nothing is placed.
• ✓9. The kitchen ticket prints only once the order is paid. The ticket is written into the venue's till only after the payment provider says the link was paid. A link left unpaid is cancelled so it cannot be paid later, and no ticket prints.
• ✓10. A card number is never taken by voice. Payment is a secure link. A caller who starts reading out a card is stopped and sent the link, and no card number reaches any system the build writes to.
• ✓11. No table is confirmed without the booking system. A table is confirmed only once it is written into the venue's booking system. Until the system is connected, the caller is texted the venue's own booking link. A party over the venue's limit goes to the manager.
• ✓12. A person is brought in for four reasons, and only those. A complaint, a serious allergy, a big group or function, or a caller who wants a person. Each handoff names its reason. A routine order is never handed off.
• ✓13. A retried call never charges or prints twice. The payment request and the ticket carry a key for the call, so a dropped line or a retried event finds the order already placed.
• ✓14. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓15. The pass test passes. A real call to the venue's forwarded number orders a dish with a required choice, is paid by link, and prints in the venue's own till with that choice; an unpaid order never prints; a dine-in dish is never sold.

Facts that can change, and when we checked them