System Requirements Document for whatsapp-order

1. Introduction

This document specifies an additive WhatsApp notification layer for The Kitchen24 by FIT BISTRO, a neighbourhood restaurant whose existing live website (https://the-kitchen24-by-fit-bistro.ai.studio) already handles menu browsing, room booking, banquet booking, checkout, and an admin panel. The product intent is narrow and deliberate: when a customer places an order, the restaurant should automatically send that customer a WhatsApp confirmation through the WhatsApp Business Cloud API, and the restaurant operator should be able to move each order through Preparing → Ready → Delivered from the existing admin panel, with each status change automatically sending the matching WhatsApp message to the customer.

The audience is twofold: hungry customers who want a warm, human confirmation of their order on the phone number they entered at checkout, and the restaurant operator who wants a calm, legible status control that already looks like their restaurant rather than a SaaS dashboard. The overriding constraint is that nothing that already exists on the website may change — no design, layout, colours, text, menu, pages, room booking, banquet booking, or existing code styling. The work is invisible infrastructure plus a small, humane addition.

2. System Overview

The current delivery is an additive integration on top of the existing live site. It introduces:

• A backend/server function that calls the WhatsApp Business Cloud API to send messages. The frontend never calls the Cloud API directly.
• A post-save hook that fires the order-confirmation message only after the order has been saved.
• A small status control (dropdown/buttons for Preparing, Ready, Delivered) added next to each order in the existing admin panel, preserving the panel's current look.
• A status-change handler that sends the matching WhatsApp message to the customer.
• Error surfacing in the admin panel when a send fails, without breaking the order flow.

Actors. The closed active-human catalog is Customer and Admin / Restaurant Operator. The WhatsApp Business Cloud API is a typed non-persona external provider that owns message delivery.

Ownership. The Customer's ordering and checkout experience remains owned by the existing site and is not modified. The Customer's receipt of WhatsApp messages is owned by the WhatsApp Business Cloud API (external provider surface). The Admin / Restaurant Operator's status work is owned by the existing Admin Panel page. Identity continuity for the operator is owned by a Login page. The public entry is the existing Landing page, unchanged.

Narrow exclusions. No redesign, rebuild, rewrite, or refactor of any existing file. No change to checkout page design. No change to the admin panel's current look. No change to room booking, banquet booking, menus, colours, fonts, or layout. No new ordering, payment, or account-management capabilities.

2a. Product Interpretation and Delivery Boundary

The existing website is treated as a fixed, authoritative surface. All new behaviour lives in new code or new files wherever possible, and the only visible additions are (a) the automatic WhatsApp confirmation that fires after an order is saved, and (b) a small status control next to each order in the existing admin panel, plus the inline error line shown when a send fails.

Message delivery is owned by the WhatsApp Business Cloud API, invoked from a backend/server function. The API token is held in environment variables and never exposed to the frontend. Phone numbers are normalised to the +91 country code before sending.

The operator reaches the admin panel through a Login page (returning verification). The admin panel itself is role-restricted to the verified operator. The Customer does not log in to receive WhatsApp messages; the confirmation is sent to the phone number entered at checkout.

Current vs. future. Everything in this document is current. No future-horizon features are accepted. The file-touch approval gate ("tell me which files you will touch and wait for my approval") is a delivery-process constraint that applies before any change is made.

2b. Source Content Inventory

Not applicable. The reference directive for https://the-kitchen24-by-fit-bistro.ai.studio declares uses: ["domain_context", "feature_reference"] and does not declare content_source; the source could not be loaded (timeout) and no verified factual entities were extracted. No inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information/state. The existing public restaurant entry, unchanged. Presents The Kitchen24 by FIT BISTRO and its ordering offering. No new content is added to this page.
• Primary actions. Existing site actions only (browse, order, book). No new controls.
• Supporting actions. None added.
• Domain entities. Restaurant, menu, existing booking entities — all owned by the existing site and out of scope for modification.
• Component responsibilities. The page is a fixed surface; the WhatsApp layer does not render on it.
• States. Loading, empty, success, and error states remain exactly as they are today. No new states are introduced here.

Login

• Information/state. Returning verification for the restaurant operator before the admin panel is accessible. Shows an identifier field and a credential field, plus a submit control.
• Primary actions. Operator submits credentials to verify identity and reach the admin panel.
• Supporting actions. Recovery from a failed verification (re-enter credentials; error message shown inline).
• Domain entities. Operator identity, session.
• Component responsibilities. Credential capture, submission, inline error display, redirect to Admin Panel on success.
• States.
  • Loading: submit control shows a single hairline progress line while verification is in flight.
  • Empty: fields blank on first arrival.
  • Success: operator is taken to the Admin Panel.
  • Error: invalid credentials produce an inline message; the operator may retry.
  • Recovery: re-submission after correction.

Admin Panel

• Information/state. The existing admin panel, unchanged in look. Each order row continues to show its existing content. Added next to each order: a small status control offering Preparing, Ready, Delivered, rendered as a three-segment capsule built from the existing row height (rust for the active segment, warm cream for inactive ones). The order ID is set in Literata 600 tabular figures, slightly larger than surrounding metadata. When a send fails, a single 14px Karla line in rust appears beneath the order row, prefixed by a small hollow circle glyph, with the exact API error string truncated to one line and a Retry text link.
• Primary actions. Operator selects Preparing, Ready, or Delivered for an order; the status change triggers the matching WhatsApp message to the customer.
• Supporting actions. Operator reads the inline send-failure line and may use Retry to re-attempt the failed send.
• Domain entities. Order (ID, items, total, customer phone number), order status (Preparing / Ready / Delivered), WhatsApp send result (success or error string).
• Component responsibilities. Status capsule (three segments, active state, 120ms colour transition), order ID display, inline error line with hollow-circle glyph and Retry link, 200ms fade-and-rise when the send result appears.
• States.
  • Loading: a single hairline progress line while a status change is being saved and the message is being sent.
  • Empty: no orders — existing empty state unchanged.
  • Success: the active segment updates; the send result fades in over 200ms; no error line is shown.

• Error: the inline rust line appears beneath the order row with the truncated API error and a Retry link; the order flow is not broken and the order row remains fully visible (no modal, no toast).
• Recovery: Retry re-attempts the send; on success the error line clears.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Automatic WhatsApp order confirmation. As a Customer, I should receive a WhatsApp message automatically after I place an order, so that I have a warm, human confirmation of what I ordered.

• Provenance: explicit.
• Trigger: the customer places an order at checkout and enters a phone number.
• Lifecycle: the order is saved first; only then does the backend send-message call run. The message is sent to the phone number entered at checkout, normalised to +91.
• Message text (exact): Thank you for your order at The Kitchen24 by FIT BISTRO. Order #ID: items, total ₹amount.
• Observable acceptance: the customer receives the WhatsApp message containing the order ID, the items, and the total in ₹.
• Failure/recovery: if the send fails, the order flow is not broken; the failure is surfaced in the admin panel (see FR-8).
• Continuation: the order proceeds through the existing flow; the customer later receives status messages (FR-4).

FR-2 — Send only after the order is saved. As the system, I should invoke the WhatsApp send-message call only after the order has been saved, so that the confirmation always references a persisted order.

• Provenance: explicit (and reinforced as required_inference: "Order must be saved before the confirmation send-message call runs").
• Trigger: successful order persistence.
• Observable acceptance: no confirmation is sent for an order that was not saved; the message references the saved order's ID, items, and total.

FR-3 — Checkout page design unchanged. As the Customer, I should see the checkout page exactly as it is today, so that nothing about my ordering experience changes.

• Provenance: explicit.
• Constraint: the checkout page design is not changed; only the send-message call is added after the order is saved.
• Observable acceptance: the checkout page renders identically to the current live site.

FR-4 — WhatsApp status updates from the admin panel. As an Admin / Restaurant Operator, I should be able to set each order's status to Preparing, Ready, or Delivered from the existing admin panel, so that the customer is automatically told what is happening.

• Provenance: explicit.
• Trigger: the operator changes an order's status via the small status dropdown/buttons next to that order.
• Lifecycle: the status change is saved; the matching WhatsApp message is then sent to the customer.
• Message texts (exact):
  • Preparing: Your order #ID is being prepared.
  • Ready: Your order #ID is ready.
  • Delivered: Your order #ID has been delivered. Enjoy your meal!
• Observable acceptance: the customer receives the matching message for the selected status; the active segment in the capsule reflects the new status.
• Failure/recovery: a failed send shows the error in the admin panel (FR-8) and does not break the order flow.
• Continuation: the operator may continue to the next status or the next order.

FR-5 — Status control keeps the admin panel's current look. As an Admin / Restaurant Operator, I should see the new status control sitting naturally inside the existing admin panel, so that the panel still looks like my restaurant.

• Provenance: explicit.
• Constraint: one small status dropdown/buttons (Preparing, Ready, Delivered) next to each order; the admin panel's current look is preserved.
• Observable acceptance: the control is a three-segment capsule built from the existing row height; no other visual change to the panel.

FR-6 — Backend-only Cloud API calls. As the system, I should send all WhatsApp messages through the WhatsApp Business Cloud API from a backend/server function, so that credentials and provider calls never touch the frontend.

• Provenance: explicit.
• Constraint: messages are sent from a backend/server function, not from the frontend.
• Observable acceptance: no Cloud API call originates from browser code; the frontend only calls the backend.

FR-7 — API token in environment variables. As the system, I should read the WhatsApp Business Cloud API token from environment variables, so that the secret is never hard-coded or exposed.

• Provenance: explicit (reinforced as required_inference: "WhatsApp Business Cloud API token must be configured in environment variables for backend sends").
• Observable acceptance: the token is supplied via environment configuration; it does not appear in source or client bundles.

FR-8 — Send failures surface in the admin panel without breaking the order flow. As an Admin / Restaurant Operator, I should see the exact send error beneath the affected order and be able to retry, so that I know a customer was not messaged and can recover.

• Provenance: explicit.
• Trigger: a WhatsApp send fails (confirmation or status message).
• Observable result: a single 14px Karla line in rust beneath the order row, prefixed by a small hollow circle glyph, with the exact API error string truncated to one line and a Retry text link. Never a modal, never a toast that hides the order.
• Constraint: the order flow is not broken.
• Recovery: Retry re-attempts the send; on success the error line clears.
• Continuation: the operator can keep working on other orders.

FR-9 — +91 country code for phone numbers. As the system, I should normalise customer phone numbers to the +91 country code before sending, so that messages reach Indian numbers correctly.

• Provenance: explicit.
• Observable acceptance: the number used for sending carries the +91 country code.

FR-10 — File-touch approval gate. As the site owner, I should be told which files will be touched before any change is made, and my approval should be awaited, so that the strict no-change rule is honoured.

• Provenance: explicit.
• Observable acceptance: a file list is presented and approval is obtained before any file is modified.

FR-11 — Operator verification before admin access. As an Admin / Restaurant Operator, I should verify my identity before reaching the admin panel, so that only the restaurant's operator can change order statuses and trigger customer messages.

• Provenance: required_inference.
• Lifecycle: the operator arrives at Login, submits credentials, and on success reaches the Admin Panel; on failure an inline error is shown and the operator may retry.
• Observable acceptance: the Admin Panel is reachable only after successful verification.

FR-12 — Additive-only implementation. As the site owner, I should have all new behaviour delivered in new code or new files wherever possible, so that existing files are not rebuilt, rewritten, or refactored.

• Provenance: explicit.
• Observable acceptance: existing files are not rebuilt, rewritten, or refactored; additions live in new code or new files wherever possible.

4. User Personas

Customer

• Product context. A hungry diner ordering from The Kitchen24 by FIT BISTRO through the existing website. They enter a phone number at checkout and expect to hear back on WhatsApp.
• Primary goal. Place an order and receive a warm, human confirmation on WhatsApp, then be kept informed as the kitchen prepares, finishes, and delivers it.
• Distinct accepted responsibilities. Enters a phone number at checkout; places the order; receives the automatic confirmation containing the order ID, items, and total in ₹; receives the Preparing, Ready, and Delivered messages as the operator advances the status.
• Relevant inputs or decisions. The phone number entered at checkout (normalised to +91); the order itself (items, total).
• Interactions with other accepted participants. The Customer's order is the trigger for the Admin / Restaurant Operator's status work; the operator's status changes produce the messages the Customer receives. Delivery of the messages is owned by the WhatsApp Business Cloud API.
• Observable success. The Customer receives the exact confirmation text and the exact status texts on the phone number they entered.
• What makes this role different. The Customer never touches the admin panel and never logs in to receive messages; their entire relationship with the new layer is inbound WhatsApp messages triggered by their own order and by the operator's status changes.

Admin / Restaurant Operator

• Product context. The person running The Kitchen24 by FIT BISTRO's orders from the existing admin panel. They want a calm, legible panel that already looks like their restaurant, not a SaaS dashboard.
• Primary goal. Move each order through Preparing → Ready → Delivered so the customer is automatically told what is happening, and know immediately if a message failed to send.
• Distinct accepted responsibilities. Verifies identity at Login; reviews each order in the Admin Panel; sets the status via the small three-segment capsule next to each order; reads the inline send-failure line and uses Retry when a send fails.
• Relevant inputs or decisions. The status to set for each order (Preparing, Ready, Delivered); whether to retry a failed send.
• Interactions with other accepted participants. The operator's status changes trigger the messages the Customer receives; the operator sees the exact API error string returned by the WhatsApp Business Cloud API when a send fails.
• Observable success. The active segment reflects the chosen status; the customer receives the matching message; on failure, the rust error line appears beneath the order row with a working Retry link, and the order flow continues unbroken.
• What makes this role different. The operator is the only human who initiates outbound status messages, and the only human who sees send failures. Their work is a small, repeated, per-order decision inside an existing panel whose look must not change.

5. Core User Flows

Flow A — Customer places an order and receives the WhatsApp confirmation

1. The Customer arrives at the existing Landing page (unchanged) and proceeds through the existing ordering experience.
2. At the existing checkout, the Customer enters their phone number and places the order. The checkout page design is unchanged.
3. The order is saved. Only after the save does the backend send-message call run (FR-2).
4. The backend normalises the phone number to +91 (FR-9) and calls the WhatsApp Business Cloud API from the server function (FR-6), using the token from environment variables (FR-7).
5. The Customer receives the exact message: Thank you for your order at The Kitchen24 by FIT BISTRO. Order #ID: items, total ₹amount.
6. If the send fails, the order flow is not broken; the failure is surfaced in the Admin Panel (Flow C, step 5). The Customer's order continues through the existing flow.

Flow B — Operator verifies identity and reaches the admin panel

1. The Admin / Restaurant Operator arrives at Login.
2. The operator enters their credentials and submits. A single hairline progress line shows while verification is in flight.
3. On success, the operator is taken to the Admin Panel.
4. On failure, an inline error is shown; the operator corrects and re-submits.
5. The operator is now able to review orders and change statuses.

Flow C — Operator changes an order's status and the customer is messaged

1. The operator is in the Admin Panel, viewing the existing order list. Each order row shows its existing content plus the small three-segment status capsule (Preparing / Ready / Delivered) and the order ID in Literata 600 tabular figures.
2. The operator selects a status for an order — for example, Preparing.
3. The status change is saved; the active segment updates with a 120ms colour transition.
4. The backend sends the matching WhatsApp message to the customer via the Cloud API:
   • Preparing → Your order #ID is being prepared.
   • Ready → Your order #ID is ready.
   • Delivered → Your order #ID has been delivered. Enjoy your meal!
5. Failure path. If the send fails, a single 14px Karla line in rust appears beneath the order row, prefixed by a small hollow circle glyph, with the exact API error string truncated to one line and a Retry text link. The order row remains fully visible — no modal, no toast. The order flow is not broken.
6. Recovery. The operator clicks Retry; the send is re-attempted. On success the error line clears.
7. Continuation. The operator advances the same order to the next status (Ready, then Delivered) or moves to the next order. The Customer receives each matching message in turn.

Flow D — Customer receives status updates

1. After Flow A, the Customer's order is in the kitchen.
2. When the operator sets Preparing, the Customer receives Your order #ID is being prepared.
3. When the operator sets Ready, the Customer receives Your order #ID is ready.
4. When the operator sets Delivered, the Customer receives Your order #ID has been delivered. Enjoy your meal!
5. If any of these sends fails, the Customer does not receive that message; the operator sees the failure in the Admin Panel and may retry (Flow C, steps 5–6).

6. Visuals, Colors and Theme

The creative direction is Warm editorial calm for a restaurant's quiet WhatsApp layer, after the muse Frank Chimero. The headline idea: the new surfaces should read as restaurant hospitality — a note from the kitchen — while staying visually quiet enough to sit beside the existing site untouched. All new UI lives in new components and new files only; the existing site's colours, fonts, layout, menus, and checkout design are not changed.

Palette (light mode).

No blue anywhere. No WhatsApp-green brand imitation.

Typography.

• Headings: Literata, weight 500–600, tracking −0.01em, sentence case, generous size contrast. Headings read like a menu or an essay, never like a dashboard title.
• Body: Karla.
• Scale: 1.25 modular — 40 / 32 / 24 / 18 / 16 / 14, with clamp(28px, 4vw, 40px) for the largest heading and 16px body at 1.6 line-height.

Shape language. Soft, honest rectangles: 10px radius on cards, 8px on controls; 1px hairline borders in #E4DCCD. No blobs, no glass, no shadows beyond a 0 1px 2px rgba(42,38,34,0.06) lift. Status pills are full-round capsules so they read as stamps, not buttons.

Layout. Single readable column at max-width 680px for confirmation/status copy. The admin status control docks to the right of each existing order row on a 12-column grid at ≥768px and stacks beneath the order summary at 375px. Generous 32px section padding; nothing sits closer than 16px to a neighbour.

Motion. Restrained: one 200ms fade-and-rise when the WhatsApp send result appears, and a 120ms colour transition on the status pill. No spinners beyond a single hairline progress line, no bounce, no marquees.

Imagery. No photography in scope. Illustration is limited to a small hand-drawn WhatsApp-style speech-bubble glyph and a 1px dashed rule that separates the message preview from the order summary, echoing Chimero's essay openers.

Readability. Headlines, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit. Decoration may be cropped or bled; readable text and controls never are.

7. Signature Design Concept

The first screen of the new confirmation surface is a single warm cream card, 680px wide, centred on a #F7F1E6 ground:

• A 32–40px Literata line, flush-left at the top: Order #1042 confirmed.
• A 1px dashed hairline rule in #E4DCCD running the full width of the card, separating "what the kitchen sees" from "what the customer receives".
• Beneath the rule, the exact WhatsApp message body quoted verbatim in Literata 18px, with a small mustard (#C8963E) speech-bubble glyph pinned to its left margin.
• Beneath that, a rust (#8C4A2F) pill reading Sent to +91 ••••• 43210.

No centred headline stack, no gradient, no illustration blob. The composition is a menu card, not a SaaS hero. The message is shown as a live preview card before it sends, with a rust Delivered tick that fades in over 200ms once the Cloud API returns 200.

In the admin panel, the status control is a three-segment capsule (Preparing / Ready / Delivered) built from the existing panel's row height, using rust for the active segment and warm cream for the inactive ones — it reads as a rubber stamp, not a dropdown. Send failures appear as a single 14px Karla line in rust beneath the order row, prefixed by a small hollow circle glyph, with the exact API error string truncated to one line and a Retry text link — never a modal, never a toast that hides the order. The admin order ID is set in Literata 600 tabular figures, slightly larger than surrounding metadata, so the number the customer will hear on WhatsApp is the loudest thing in the row.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief. The public entry is the existing Landing page, which is unchanged; the "hero" of the new layer is the confirmation card described in Section 7. Its focal subject is the verbatim WhatsApp message body in Literata 18px with the mustard speech-bubble glyph in the left margin. The input→transformation→outcome thesis: the operator's status change (input) triggers the backend send (transformation), and the rust Delivered tick fades in over 200ms once the Cloud API returns 200 (outcome). Motion vocabulary: a single 200ms fade-and-rise when the send result appears, a 120ms colour transition on the status pill, and a single hairline progress line while a send is in flight. Composed first frame: the cream card at 680px on the #F7F1E6 ground, the Literata headline flush-left, the dashed hairline, the quoted message, and the rust "Sent to +91 ••••• 43210" pill — all static until a send result arrives. Reduced-motion state: the fade-and-rise and colour transition are removed; the send result appears instantly and the status pill changes colour without transition, while the hairline progress line remains as the only motion cue.

9. Non-Functional Requirements

• NFR-1 — No change to existing site. No design, layout, colours, text, menu, pages, room booking, banquet booking, or existing code styling may change. Provenance: explicit. Rationale: the site owner's strict rule.
• NFR-2 — Additive-only delivery. Do not rebuild, rewrite, or refactor any file; only add the small features in new code or new files wherever possible. Provenance: explicit.
• NFR-3 — Approval gate. Before changing anything, tell the site owner which files will be touched and wait for approval. Provenance: explicit.
• NFR-4 — Checkout design unchanged. The checkout page design is not changed; only the send-message call is added after the order is saved. Provenance: explicit.
• NFR-5 — Admin panel look preserved. The admin panel's current look is kept. Provenance: explicit.
• NFR-6 — Backend-only provider calls. Messages are sent through the WhatsApp Business Cloud API from a backend/server function, not from the frontend. Provenance: explicit.
• NFR-7 — Secret handling. The API token is kept in environment variables. Provenance: explicit (reinforced as required_inference).
• NFR-8 — Country code. Phone numbers use the +91 country code. Provenance: explicit.
• NFR-9 — Failure isolation. If sending fails, the error is shown in the admin panel and the order flow is not broken. Provenance: explicit.
• NFR-10 — Everything else unchanged. Everything else on the website stays exactly as it is now. Provenance: explicit.
• NFR-11 — Readability at all viewports. Readable text and controls stay whole at 375px, 768px, and 1280px. Provenance: creative direction.
• NFR-12 — Reduced motion. With prefers-reduced-motion, the new surfaces provide a usable static arrangement. Provenance: creative direction.

10. Tech Stack

• Frontend. The existing website's frontend is preserved as-is. New UI (the status capsule, the inline error line, the confirmation card) is delivered in new components and new files only. No framework migration or refactor is performed.
• Backend. A backend/server function (extending the existing backend where one exists) owns all WhatsApp Business Cloud API calls. It reads the API token from environment variables, normalises phone numbers to +91, sends the confirmation after the order is saved, and sends the status messages on status change.
• External provider. WhatsApp Business Cloud API (message delivery).
• Storage. The existing order storage is reused; the order's status (Preparing / Ready / Delivered) and the last send result (success or error string) are persisted so the admin panel can display them.
• Configuration. Environment variables hold the WhatsApp Business Cloud API token and related provider configuration.
• Deployment. No new services are introduced beyond what the existing site already runs; the backend send function is added to the existing backend process.

11. Assumptions and Constraints

• A-1. The existing live site at https://the-kitchen24-by-fit-bistro.ai.studio is the authoritative surface and is not modified beyond the additive features described here. The reference URL could not be loaded during analysis (timeout), so no existing-site facts beyond those stated by the user are assumed.
• A-2. The existing site already saves orders and already has an admin panel listing orders; the new features hook into those existing points without changing their design.
• A-3. The customer's phone number is captured at checkout and is available to the backend after the order is saved.
• A-4. The WhatsApp Business Cloud API token and related configuration are supplied via environment variables by the site owner.
• A-5. The operator's identity is verified at Login before the Admin Panel is reachable (required_inference).
• A-6. The file-touch approval gate is a delivery-process constraint; no file is modified before the site owner approves the list of files to be touched.
• C-1. No change to design, layout, colours, text, menu, pages, room booking, banquet booking, or existing code styling.
• C-2. No rebuild, rewrite, or refactor of any file.
• C-3. No change to the checkout page design.
• C-4. The admin panel's current look is preserved.
• C-5. All provider calls originate from the backend, never the frontend.
• C-6. The API token lives only in environment variables.
• C-7. Phone numbers use +91.
• C-8. Send failures are shown in the admin panel and never break the order flow.
• C-9. Everything else on the website stays exactly as it is now.

12. Glossary

• WhatsApp Business Cloud API — Meta's hosted API used by the backend to send WhatsApp messages to customers.
• Order confirmation — The automatic WhatsApp message sent to the customer after an order is saved, containing the order ID, items, and total in ₹.
• Status update — The automatic WhatsApp message sent to the customer when the operator changes an order's status to Preparing, Ready, or Delivered.
• Status capsule — The three-segment control (Preparing / Ready / Delivered) added next to each order in the admin panel.
• Send failure — A non-success response from the WhatsApp Business Cloud API, surfaced as an inline rust line beneath the order row with a Retry link.
• Retry — The text link that re-attempts a failed send.
• Operator — The Admin / Restaurant Operator who verifies at Login and manages order statuses in the Admin Panel.
• +91 — The Indian country code applied to customer phone numbers before sending.