← All white papersBuild plan · October 2026

Takeaway Orders on Microsoft 365

The menu read from the till, one order per call, and a kitchen ticket that waits for the payment provider.

9 min read·Free to implement·Published by AI Pathway

Used by

AI Officer
Business Systems Analyst
Venue Manager

How to get this live in your business

Have it done for youStart with the 8-minute diagnosis: it maps how your week runs to what is already built and what is worth building. Free, no email. If it fits, the $500 audit turns it into a plan, credited against what follows.

Build it myself

Free. The Takeaway Orders Build Standard: the objects, the checks in order, and the pass test.

Ready for

Microsoft 365Google WorkspaceGrok Bot

A venue on Microsoft 365 usually takes phone orders on a notepad by the till and books tables in whatever the booking system is. This plan puts the venue’s phone and chat agent on SharePoint lists and Power Automate for the parts the till does not hold: which dishes go out for pickup, the order the caller agreed to, whether it was paid, and who needs a call back.

In short

What this is
A build plan for the Takeaway Orders standard on Microsoft 365. Five lists, three flows, and a payment status only the payment provider writes.
The core rule
The ticket flow prints only after it reads paid from the provider, once per order.
What it does not do
It holds no copy of the menu and no card number. The till and the payment provider keep those.
The hard part
Waking the ticket step from the provider's webhook, not from the moment the link was made.

Take the spec to Claude, ChatGPT or Copilot. The sentence to paste is one click away.

Want the whole thing by email?

This paper, plus the rest of the library. One click to stop them.

1. Before you start

Read the Takeaway Orders build standard first. It owns the menu rules, the read-back, the payment order and the handoffs. Where it and this page disagree, it wins. The shared conventions for this stack are in building the standards on Microsoft 365.

Microsoft 365 is not the conversation. The phone and the chat are a voice or chat agent, and the menu, the payment and the ticket are the venue’s till and payment provider. This plan is what sits between them: the lists the agent writes to, and the flows that move an order from paid to printed.

2. The lists, with their columns

Five lists. There is no Menu list: the till is the menu, read on every call. PickupList holds only what the till cannot say reliably, and OrderKey is unique so a call cannot be charged or printed twice.

For your developer. Show the fields for your developer

Site: PickupOrders

LIST  PickupList            (the owner's, one row per dish that goes out)
  ItemId          Text            indexed, UNIQUE, REQUIRED. the till's own id for the dish
  DishName        Text            for people reading the list; the till's name wins
  AddedBy         Person          a person decides what goes out for pickup

LIST  Orders                (one row per call or chat)
  OrderKey        Text            indexed, UNIQUE, REQUIRED. the call or chat id
  Channel         Choice          phone | web_chat
  CallerName      Text
  CallerPhone     Text
  Lines           Note            each dish by till id, quantity and choices
  PickupAt        DateTime
  Allergy         Text            in the caller's words; printed on the ticket
  ReadBackAt      DateTime        when the caller said yes
  PaymentLinkId   Text            indexed
  TotalCents      Number          the provider's total, never the flow's
  PaymentStatus   Choice          open | paid | cancelled
                                  WRITTEN BY THE PROVIDER'S WEBHOOK ONLY
  TicketId        Text            the till's ticket id, written once
  PrintedAt       DateTime

LIST  Bookings
  OrderKey        Text            indexed. the call or chat it came from
  Party           Number
  At              DateTime
  BookingRef      Text            the booking system's reference; blank means not booked
  LinkSent        Boolean         the venue's booking link was texted instead

LIST  Handoffs
  OrderKey        Text            indexed
  Reason          Choice          REQUIRED. complaint | serious_allergy
                                  | group_or_function | asked_for_person
  Detail          Text            REQUIRED. what the caller said, in words
  CallerPhone     Text
  CalledBackBy    Person          a person closes a handoff; a flow never does

LIST  Log                   (append only)
  OrderKey        Text            indexed
  Event           Text
  Detail          Text
  At              DateTime

The menu stays in the till. Every call reads it; this site never becomes a second menu.

PaymentStatus is written by the payment provider's webhook. The ticket flow refuses a row that is not paid, and writes TicketId once.

There is no column for a card number and none for 'allergy safe'. A list that could hold either would eventually hold one.

3. Every check, and what enforces it

The check	Enforced by	How
The menu and the prices come from the till	Agent tool	The agent's menu tool calls the till on every call. There is no Menu list to drift, and the Orders row stores the till's item ids only.
A dine-in dish is never sold for pickup	PickupList	The agent's menu tool returns only items whose ItemId is on PickupList. Anything else comes back marked dine-in only.
The total is the provider's	Payment flow	The flow sends the lines to the payment provider and writes back the TotalCents it returns. It never adds anything up.
Paid before the kitchen	Ticket flow	Woken by the provider's webhook. It re-reads the payment from the provider, refuses anything not paid, and writes TicketId once.
An unpaid link is cancelled	Expiry flow	Every few minutes, an open link older than the venue's limit is cancelled at the provider and the row set to cancelled.
One order per call	OrderKey, unique	The call or chat id, with unique values enforced on the list, and passed to the provider and the till as the idempotency key.
A person for four reasons	Handoffs	A Choice with four values and no fill-in. A new row posts to the manager's Teams channel.

4. The three flows

For your developer. Show the fields for your developer

FLOW 1  Ask for the payment
  trigger  the agent adds an Orders row with ReadBackAt set
  guard    OrderKey has no PaymentLinkId yet
  logic    send the lines to the payment provider, keyed by OrderKey
           write PaymentLinkId and the TotalCents it returns
           text the caller the link
  never    add up the order, or write PaymentStatus, or print

FLOW 2  Print the paid
  trigger  the payment provider's webhook: a link was paid
  guard    re-read the payment from the provider: paid
           TicketId is blank
  logic    write the ticket into the till, keyed by OrderKey,
           with the lines, the choices and the allergy
           write TicketId and PrintedAt, append Log
           text the caller the order summary
  never    print an order the provider does not say is paid,
           or print it twice

FLOW 3  Cancel the unpaid
  trigger  every five minutes
  logic    for each open link older than the venue's limit:
           cancel it at the provider, set PaymentStatus cancelled,
           append Log
  never    cancel a link the provider says is paid

Flow 2 is woken by the payment, not by Flow 1, so an order that is never paid never wakes the step that prints. The re-read in its guard is what keeps a forged or replayed webhook from printing.

5. The order to build it in

Create the five lists. Make OrderKey and ItemId unique before anything writes to them, and lock PaymentStatus to the flows’ service account.
Build Flow 2 first, with its guard, and prove it refuses an order whose link is open.
Build Flow 1 and Flow 3, then run the pass test below.
Only then point the agent at the lists, and the venue’s number at the agent.

6. Four traps specific to this build

A Menu list copied from the till

It is right on the day it is made. The first time a dish sells out or a price changes, the agent quotes yesterday's menu. Read the till on every call; keep only the pickup list here.

Printing from the payment flow

It is one flow instead of two, and it prints the moment the link is made rather than when it is paid. The ticket belongs in a flow the provider's webhook wakes, and that flow reads the payment again before it prints.

PaymentStatus a person can edit

Somebody ticks paid to get an order moving on a busy night, and the kitchen cooks an order nobody paid for. Break inheritance on the column's list and give write access to the flow's service account only.

Running the flows on one manager's account

The flows stop the day that manager leaves, at 6pm on a Friday. Use a service account, and alert the venue's channel when a flow fails.

7. Where the automation stops

Every Handoffs row. A person rings back and sets CalledBackBy; no flow can.
The pickup list. The owner decides what goes out; the agent only reads it.
A refund. No flow issues one.
A table over the venue's limit, or a function.

The pass test. Two staged checks, neither needing a real customer. First, add an Orders row with ReadBackAt set and let Flow 1 make the link, then leave it unpaid: Flow 2 must not run, nothing may reach the till, and after the venue’s limit Flow 3 must cancel the link. Second, pay a second test order with a test card: Flow 2 must print it once, and sending the same webhook again must print nothing. If the first printed, the kitchen is cooking on trust. If the second printed twice, the key is decoration.