02 · Remediation report

Every feature repaired. Nothing switched off.

The order and payment chain, the payment webhooks, reservations, menu answers and the review request were each fixed where they stood.

Repair account cb9a…bff1Agent 574e…9c5a3 workflows rebuilt0 live channels
VOTEL REMEDIATIONORDERS & RESERVATIONS

Restaurant
Corrections

Source findings22
Features keptAll
Steps and links43 · 49
Dangling links0
01 · Approach

Fix each feature where it stands.

An earlier pass on September 18 reduced the core flow to intake and acknowledgement, detached the payment chain, deleted the webhooks and added a fail-closed "safe baseline". On September 24 the snapshot was rebuilt instead: the order-to-payment chain, payment confirmations, reservations, menu answers and review request were restored and repaired, six contact fields, a Menu Price Catalog variable and a Table Reservation bookable were created, and the safe baseline was removed.

Safety boundary: the agent stays inactive, the bookable is a draft and the Stripe key is a placeholder, so no payment, message or booking reaches anyone. Steps that need the owner's accounts are owner setup, not removed.
02 · Saved corrections

Every source finding has a disposition.

FindingStatusCorrection
REST-001 / 004 / 012Fixed

No secret ships in the snapshot. One payment step calls Stripe with a [Stripe Restricted Key] placeholder; the owner supplies a restricted key and chooses test or live mode by the key they paste.

REST-002 / 013Rebuilt

A new webhook trigger (URL generated on install) accepts Stripe events and acts only on completed checkouts; everything else is noted and ignored.

REST-003 / 006Fixed

The payment link goes to the customer by text and email; order and reservation notices go to the restaurant team email.

REST-005Fixed

Payment confirmation finds or creates the customer; both lookup outcomes continue.

REST-007 / 019Built

A Table Reservation bookable (90 minutes) with text and email confirmations and reminders is booked in the conversation; a failed booking creates a staff task.

REST-008Owner setup

SMS and email steps stay in place and are flagged until connected.

REST-009Fixed

The customer hears the link was sent only after it is created and sent.

REST-010 / 018Fixed

Menu, hours and delivery answers come from the knowledge base; restaurant details are globals, not prompt copy.

REST-011Fixed

Every order asks about allergies; notes are saved, flagged on the order and PAID emails, and never answered with a safety guarantee.

REST-014 / 015Fixed

One pricing step with structured outputs replaces three chained AI steps; any item not in the owner's catalog sends the order to staff instead of dropping it.

REST-016 / 017 / 020Fixed

Explicit routes replace the untested global-node handoff; one conversation works on voice, text and chat with a scripted greeting.

REST-021 / 022Fixed

Copy rewritten; every branch ends in a confirmation, task, note or email.

Found in testingFixed

The eight-question order step re-asked answers and asked for a delivery address on pickup orders; pickup or delivery is now a menu choice with the address asked only for delivery, and short spoken lead-ins stop the call going quiet before each question step. The table booking failed because Votel generates default booking questions with an invalid type for bookables created through its API; the booking step now lists name, phone and email explicitly. The source's sample order email signed the original restaurant's name. A leftover integration-probe agent from an earlier session is in the repair account and must be excluded from the master snapshot.

03 · Before & after

The same design, now able to run.

Restaurant before and after
Before: installed v2. After: rebuilt copy, September 24, 2026.
Text version of this diagram

Before: Stripe secrets were embedded in workflow steps with test mode connected and live mode disconnected; three chained AI steps priced orders from a hard-coded catalog and silently dropped unknown items; the payment link went to a fixed outside address and the owner notice went to the customer; the payment webhooks pointed at deleted triggers; and table booking was promised with no calendar, an empty menu and no allergy boundary. After: one API step uses a placeholder restricted key the owner supplies; one pricing step uses the owner's catalog and sends any unknown item to staff; the payment link is texted and emailed to the customer and the restaurant gets the order; a new webhook confirms completed payments; and a Table Reservation booking with reminders, knowledge-base menu answers and flagged allergy notes are built in.

Restaurant conversation workflow
Restaurant Conversations: Orders, Reservations and Questions, saved September 24, 2026. Voice, text or chat. Dashed steps need the owner's Stripe key, SMS number or email sender.
Text version of this diagram

A customer calls, texts or chats and is asked whether they want to order, reserve a table or ask a question. Questions are answered from the restaurant's knowledge base, never with a guarantee that a dish is allergy-safe, and the customer can move on to an order or a reservation. For an order the assistant asks pickup or delivery, takes the delivery address when needed, then the name, mobile number, items, allergy or dietary notes and an optional receipt email, all saved to the contact. An AI step prices the order only against the owner's menu price catalog. If every item matches, a Stripe payment link is created and texted and emailed to the customer, the restaurant is emailed that the order is awaiting payment, and the customer hears that the order is confirmed once paid. If an item is not on the menu or the link fails, the customer is told staff will call, the restaurant gets the order by email and a task is created. For a reservation the assistant asks party size and special requests, then books a Table Reservation; the restaurant gets an email with the time and details and the customer gets confirmations and reminders. If the booking fails, staff are asked to call.

Payment confirmations and review requests
Payment Confirmations and After the Visit: Review Request, saved September 24, 2026.
Text version of this diagram

A Stripe webhook for completed checkouts finds or creates the customer by phone or email, emails and texts the customer that payment was received, and emails the restaurant a PAID notice with the order and any allergy notes so the kitchen can start. Other Stripe events are ignored with a note. Two hours after a Table Reservation ends, the guest gets a text and an email asking for a review at the restaurant's review link.

04 · Validation ledger

Checked in the editor and the simulator.

CheckResultEvidence
Graph integrityPass

43 steps and 49 links survive a save in Votel's editor with no dangling links.

OrdersPass

With texts and emails bypassed for the test, 17 simulator runs: orders ran 20 to 23 steps and scored 90 to 96 across pickup, delivery, unmatched items and failed links. With the placeholder catalog every priced order correctly went to staff.

Reservations and questionsPass

A table was booked in the conversation (98 after the booking fix); a failed booking creates a staff task (96); a menu question alone scored 96.

Behavior11 / 11

11 of 11: allergies asked and never guaranteed, no card numbers, no invented menu items, no false confirmations, no table promised before booking, do-not-contact respected.

Payments, texts and emailOwner test

Need a restricted Stripe key, catalog prices, the webhook configured in Stripe, an SMS number, sender and balance; run the acceptance tests in Stripe test mode.

Remediation complete.

The rebuilt account is ready for final acceptance and master snapshot generation.

Open final audit →