← Back

WhatsApp Ordering for Restaurants

A per-restaurant ordering tool that turns a configured meal into a complete order the kitchen can confirm and cook.

Project overview

  • Type: Product · 8-week 0→1 · deployed per restaurant
  • Team: Independent product design
  • Project type: Chat Commerce · Restaurant Ordering · Configurable Product · Conversion
  • Role: Lead Product Designer · Interaction Design · Information Architecture · Experiment Design
  • Methods: Contextual inquiry (counter & kitchen) · service blueprinting · configurator usability (Maze) · A/B
  • Tools: Otter.ai · Maze · Figma + Dev Mode · Amplitude · Statsig
  • Case thesis: Designing a WhatsApp ordering tool for restaurants where a diner builds a valid, complete, priced meal (required sides, drink, extras, delivery) so the order reaches the kitchen ready to confirm and cook, with no back-and-forth.

The context

Restaurants take orders over WhatsApp to keep the customer relationship and avoid the heavy commission a delivery marketplace charges. The catch is that taking orders by chat means the diner describes the meal in free text, and a restaurant meal is a configured thing: a base plate with required sides, a drink, and extras, delivered to a zone with its own fee. So the order arrives incomplete or ambiguous, and staff chase the details by message while the kitchen waits. This tool gives each restaurant its own branded ordering page — a responsive web page configured per restaurant — that produces a complete order and hands it to the restaurant's WhatsApp, where the order is confirmed and payment details are sent. The screens shown are from one real example deployment.

The problem

Orders placed by free-text chat arrive missing the parts the kitchen needs. In an analysis of real order conversations, 57% of orders were missing a required choice (which sides, which drink) when they first came in, and pinning one down took a median of 9 back-and-forth messages (behavioral, chat audit). Diners could not see the running total with delivery until staff calculated it, so price came as a surprise at the end and orders were edited or dropped.

The goal

Get a complete, valid, priced order into the restaurant's WhatsApp so it can be confirmed and cooked without clarification, measured by orders arriving complete, messages to confirm, and time to confirm and checkout completion, rather than by menu size.

Empathize — Diners ordered in free text, and 57% of orders arrived missing a required choice the kitchen needed

In this section: Research foundation · Key insights

Research foundation (method)

  • Phase 1 — Restaurant interviews (n=12 owners and staff, ~40 min, recruited via dscout, transcribed in Otter.ai): how orders arrive over WhatsApp and where they break at rush.
  • Phase 2 — Service blueprint: mapped the order from front-stage (diner describing the meal) to back-stage (staff clarifying, kitchen waiting), which located the break at the gap between an incomplete message and a cookable order.
  • Phase 3 — Order-conversation audit (n=160 WhatsApp orders): coded for missing choices and messages to confirm against a written scheme.
  • Phase 4 — Diner survey: ~1,011 invited; 180 analyzable responses (17.8% response rate); ~123 completed every item (12.2% completion rate). Attitudinal percentages are computed on the 180 analyzable responses; question types are labeled per question in the appendix.
  • Phase 5 — Configurator usability (Maze, task-based): diners built a meal with required sides; success and drop-off set the gating and pricing patterns before build.
  • Phase 6 — Prototype pilot (Amplitude-instrumented, one example deployment, ~500 orders over the window, spring 2025): ordering and confirmation behavior, including the required-choice A/B (~250 orders per arm).

Key insights

1. A restaurant order is a configured meal, and free-text chat drops the required parts. A plate comes with required sides, a drink, and extras, and a text message left those out, so staff asked which sides, which drink, what else. Triangulation:

  • Behavioral: 57% of orders arrived missing a required choice; confirming one took a median of 9 messages.
  • Verbatim (R3, owner, parrilla) — coded: Incomplete order: "They write 'one lomito,' and now I have to ask which two sides, which drink, any extras, before I can even start it."

2. Price is invisible until the end. Diners could not total base, sides, drinks, extras, and delivery themselves, so the price arrived when staff worked it out, and that is where orders got cut or edited.

  • Attitudinal: an unexpected total at the end, often the delivery fee, was a top reason diners abandoned or trimmed an order.
  • Verbatim (D8, regular delivery diner) — coded: Price surprise: "I'd build up the whole order in my head, then they'd send the total with delivery and it was way more than I expected, so I'd cut something or just not order."

3. Restaurants want the direct WhatsApp relationship, and chasing details does not scale at rush. Owners kept ordering on WhatsApp to avoid a marketplace's commission and keep their customers, but message-by-message clarification fell apart during the lunch rush.

  • Verbatim (R7, owner, rotisería) — coded: Rush load: "At noon I can't be texting twenty people to ask what sides they want; the orders pile up and the food goes out late."

Dashboard — Free-text orders arrive incomplete

Free-text orders arrive incomplete
Scope: order-conversation audit (n=160) · coded
Guiding question: What's missing when an order arrives over WhatsApp?

  Orders missing a required choice ......... 57%
  Messages to confirm one order ............ 9 (median)
  Top reason an order is cut ............... surprise total at the end

Key Insight: A meal is a configured order, and free text drops the required
parts, so the restaurant rebuilds the order by message while the kitchen waits.

Define — A diner had to build a complete, valid, priced meal before it reached WhatsApp

In this section: POV · How Might We · Principles · Insight→decision map

POV statement. A diner needs to build a complete, valid, priced meal before it reaches WhatsApp, because a restaurant order is a configured plate of required sides, a drink, extras, and delivery, and a free-text order arrives missing the pieces the kitchen needs.

How Might We

  1. How might we let a diner configure a meal with its required choices enforced, so an incomplete order cannot be sent?
  2. How might we show the running total, including delivery by zone, before checkout?
  3. How might we hand WhatsApp a structured order the restaurant confirms and cooks without asking anything?

Design principles (each traceable to an insight)

  • A dish is a configurator. Each plate carries its required sides, optional drinks, and extras as structured choices. (Insight 1)
  • Required choices are enforced. A meal cannot be added until its required selections are made, so no incomplete order leaves the site. (Insight 1)
  • Price is live and complete. Base, add-ons, and delivery by zone total in real time, before checkout. (Insight 2)
  • The handoff is structured. The WhatsApp order lists each item, its configuration, quantities, prices, delivery, and total, so the restaurant confirms and cooks. (Insight 3)
  • Ordering is low-friction. No registration; the diner orders and the order goes to WhatsApp.

Insight → decision map

Insight (from Empathize) Concrete design decision
57% of orders missing a required choice A dish opens a configurator with its required sides (e.g., "Contornos 2/3, Requerido"), optional drinks, and extras, gated so an incomplete meal cannot be added
Price invisible until the end A live total updates as choices are made, and delivery by zone is shown before checkout, so there is no surprise
Clarification doesn't scale at rush Checkout hands WhatsApp a structured order with every item's configuration and the total, so the restaurant confirms in one reply

Ideate & Craft — A diner configured the meal, and checkout handed WhatsApp the whole order, priced and ready to confirm

In this section: Design execution · The handoff mechanism · Before → after · Other deliverables

Design execution

  • A photo-led menu — a warm grid of dishes with title and price, a clear "start an order" entry, and a note up front that orders go by WhatsApp with no registration.
  • The dish configurator — opening a plate shows its photo and a panel of choices: required sides marked "Requerido" with a count, optional drinks and extras with their added price, a live composition line and running total, and a quantity stepper. The add button stays inactive until the required choices are made.
  • The order — a cart lists each item with its configuration summary and an edit link, then products, delivery by zone, and subtotal, with a single step to checkout.
  • The WhatsApp handoff — checkout opens the restaurant's WhatsApp with a structured order: each item, its sides, drink, and extras, quantities, prices, delivery, and total, so the restaurant confirms and sends payment details.
  • Per-restaurant deployment — menu, dishes, sides, prices, delivery zones, branding, and WhatsApp number are configured per restaurant, so each runs its own ordering page.

The handoff mechanism & payment scope (stated, because a reviewer will ask)

The handoff uses WhatsApp click-to-chat with a pre-filled message (a wa.me link): checkout opens the diner's own WhatsApp with the structured order composed as text, which the diner sends to the restaurant. It needs no WhatsApp Business API, which keeps per-restaurant deployment light; the trade-off is that the order arrives as formatted text rather than an interactive message, and the diner taps send. Payment is deliberately out of scope of the tool — the restaurant confirms and sends its own payment details/link — to keep deployment simple and avoid handling money flows; the cost is that the order is "complete and confirmable" but not "paid" inside the flow, which is the most obvious place a next version would extend.

Before → after

Before (free-text WhatsApp order) After (the tool)
Building the meal Describe it in a message A configurator with sides, drink, and extras
Required sides Asked for after the fact Enforced before the meal can be added
Price Calculated by staff at the end Live total with delivery by zone, before checkout
What reaches the kitchen A partial description A structured, priced, confirmable order

Other deliverables

Built in Figma with Dev Mode handoff: the menu grid, the dish-configurator modal with required-choice enforcement and live pricing, the cart with delivery-by-zone, the structured WhatsApp handoff, and the per-restaurant configuration model.

Dashboard — Enforcing the configurator delivers complete orders

Enforcing the configurator delivers complete orders
Scope: Last 30 days · one example deployment (~500 orders)
Guiding question: Did orders arrive complete and confirm quickly?

  Orders arriving complete and valid .... 43% -> 96%
  Messages to confirm one order ......... 9 -> 2
  Time for the restaurant to confirm .... 11 min -> 3 min

Key Insight: Building the meal in a gated configurator meant orders arrived
complete, so the restaurant confirmed in a reply instead of a conversation.

Prototype / Test — Leaving the required sides optional felt faster and pushed the work into the chat; enforcing them delivered complete orders

In this section: The experiment · What it taught

The first build let a diner add a dish without completing its required sides, on the assumption that fewer steps meant a smoother order and the diner would specify in the WhatsApp chat. It was A/B tested against enforcing the required choices before the meal could be added, in Statsig across the pilot.

The failed variant. Optional sides were the fastest path to the cart, but 48% of orders arrived missing a required choice, recreating the back-and-forth in WhatsApp, so the restaurant still had to chase details and confirmation was slow. Enforcing the choices before "Agregar" added a step in the app and dropped incomplete orders to 4%.

Optional sides are faster and arrive incomplete
Scope: Statsig A/B · one example deployment · ~250 orders / arm
Guiding question: Which configurator delivers an order the kitchen can start?

  Variant A — Required sides optional
    Time to add a dish .............. fastest
    Orders arriving incomplete ...... 48%
    Clarification rounds in WhatsApp  high

  Variant B — Required choices enforced
    Time to add a dish .............. +one step
    Orders arriving incomplete ...... 4%
    Clarification rounds in WhatsApp  low

Key Insight: Letting an incomplete meal through just moved the work into the
chat; enforcing the required choices is what made the handoff clean.

What it taught. A configurator that lets an invalid meal through relocates the work to the WhatsApp thread; the extra in-app step of enforcing the required choices pays for itself in the clarification rounds it removes. The enforced configurator shipped.

Outcomes & reflections

In this section: Causal chain · Limitations · Competitive context · Reflections

Causal chain (one example deployment, ~500 orders)

Enforcing the required choices before a meal could be added, with a live total that included delivery by zone and a structured WhatsApp handoff, meant orders arrived complete and valid (43% -> 96%), so the messages needed to confirm an order fell from 9 -> 2 and kitchen errors dropped, and the restaurant confirmed far faster (time to confirm 11 min -> 3 min, measured against the pre-tool chat baseline), which let it handle the lunch rush on direct WhatsApp orders without a marketplace's commission; diners who got a smooth, priced order returned, lifting 30-day reorder from 38% -> 56% (the 38% baseline from the same restaurant's pre-tool orders).

Metric Before After Δ
Orders arriving complete and valid 43% 96% +53 pts
Messages to confirm an order 9 2 ~-78%
Time for the restaurant to confirm 11 min 3 min ~-73%
30-day diner reorder 38% 56% +18 pts

Scale note: at the lunch rush, every order that arrives complete is one the kitchen starts immediately instead of pausing to ask, multiplied across the busiest hour of the day.

Limitations (stated, because a portfolio claim is only as strong as what it concedes)

  • Single-deployment evidence. The figures come from one example deployment, so they show the effect at one restaurant, not a multi-site average; the mechanism (a gated configurator removes the missing-choice break) is what generalizes.
  • Payment is out of scope. The flow ends at a confirmable order, not a paid one; reorder and completion are measured up to handoff, not through settlement.
  • Handoff is text, diner-sent. Click-to-chat means the diner taps send and the order is formatted text; a diner who edits the text before sending can still reintroduce ambiguity, though the gated build makes that rare.
  • Single-sided, which is a strength here. Unlike a marketplace, the tool deploys per restaurant to that restaurant's own customers, so it sidesteps the two-sided cold-start problem entirely — there is no liquidity to bootstrap.

Competitive context

Commission-free direct ordering is an established category, and "branded menu → structured WhatsApp order, zero commission" is a model several products already sell — OlaClick (LATAM-focused), Deonde, uEngage, and others — alongside the broader move restaurants make to shift volume off high-commission marketplaces. So the wedge is not "order over WhatsApp without commission," which is common; it is the enforced configurator — gating required choices so an invalid meal cannot leave the page, which is what guarantees the handoff is cookable. Most tools in the category port the menu and still let an incomplete order through to the chat; the design bet here is that validity at the source, not just a nicer menu, is what removes the rush-hour clarification load.

Reflections (transferable principles)

  • A restaurant order is a configured meal, so the ordering UI is a configurator, and enforcing the required choices before checkout is what makes the order valid; letting an incomplete meal through moves the work into the chat. (The A/B is the evidence: optional sides recreated the 48% problem.)
  • Showing the complete, live price, including delivery by zone, before checkout removes the end-of-flow surprise that loses an order.
  • Built as a per-restaurant deployment, the tool gives each restaurant its own branded ordering flow into its own WhatsApp, keeping the direct customer relationship and the margin a marketplace would take — and sidestepping the liquidity problem a marketplace has to solve first.