Installed snapshot · independent audit

Restaurant automation with a broken payment handoff.

A node-level review of Votel’s v2 restaurant snapshot: order intake, reservation capture, contact creation, Stripe payment links, payment webhooks, notifications, food-safety gaps and the repairs required before activation.

Votel library v2Reviewed Sep 18, 2026Agency-level installNo live channels used
VOTEL SNAPSHOT AUDIT12 / FOOD & BEVERAGE

Restaurant Order
& Reservation

Installed agent1
Agent workflows1
Workflow nodes28
Open outputs12
Launch statusBlocked
1Installed workflow
28Functional nodes
19Connected edges
22Audit findings
0Active channels
01 · Executive verdict

A smart restaurant pattern is trapped inside unsafe, source-specific configuration.

The snapshot demonstrates useful Votel-native architecture: an order/reservation router, callable global handoffs, structured extraction, contact upsert, multi-agent order normalization and Stripe payment-link creation. But the connected path uses test-mode payment nodes, reusable credentials are embedded in the workflow, installed webhook URLs are invalid, and first-time contacts fall off both primary paths.

Reusable

Core pattern

Conversation → order or reservation → structured capture → contact → fulfillment.

Broken

Payment path

Test mode is connected; live mode is disconnected; both installed payment webhooks are stale.

Risk

Credential safety

Test and live payment credentials ship inside reusable API nodes.

Do not activate this snapshot as installed. Revoke the embedded payment credentials, regenerate signed webhooks, reconnect first-time contacts, separate internal/customer notifications, add real reservation infrastructure, and validate every commerce payload.
View the live remediation report →
02 · Installed inventory

One inactive agent contains one large, commerce-oriented workflow.

AssetStatusVerified detail
Restaurant Order & ReservationInactive

GPT-5.6, Katie by Cartesia, multi-language, zero active channels, 2,182-word prompt.

Restaurant fulfillment workflow28 nodes

Order and reservation intake, ten extracted variables, contact lookup, four LLM nodes, two Stripe APIs, two webhook triggers, email, SMS and hangups.

Installed items2 of 2

The library did not disclose a manifest; the observed delta was one agent placed in an Archive folder.

Payment modeMiswired

The connected order branch uses test-mode mapping and the test Stripe API; the live branch is disconnected.

Payment webhooks2 stale

Votel reports that both generated URLs point to triggers that no longer exist.

Email / SMSUnconfigured

No email channel or SMS number is selected; the connected payment email targets a fixed external address.

Reservation systemMissing

No calendar, availability, capacity, booking, modification or cancellation node is installed.

Knowledge / toolsNone

No knowledge base, custom tool or enabled built-in tool. The main prompt’s menu section is empty.

State distinction: the agent and workflow are installed. Channels, reservation infrastructure, safe credentials, working webhook endpoints, portable restaurant data and validated payment fulfillment are not configured or tested.
Asset inventory summary of the installed snapshot: one inactive agent, one workflow with 28 nodes, 19 edges and 12 open outputs, three triggers, ten extraction variables; three global variables referenced but not installed; no pipelines, stages, tags, forms, calendars, templates, websites, funnels or AI Assistant assets
Inventory summary, installed 2026-09-18 (source v2). Counts by Votel snapshot category; the detailed inventory above stays the record. Dashed groups are referenced by the prompt or absent from the snapshot.
Text version of this diagram

Installed by the snapshot: 1 agent (inactive, 0 active channels); 1 workflow with 28 functional nodes, 19 connected edges and 12 open outputs; 3 triggers (conversation started plus two stale payment webhooks); 10 extraction variables (5 order, 5 reservation). Referenced but not installed: 3 global variables (hours, city, delivery areas) and no selected shared knowledge (the prompt holds a menu placeholder). Not part of this snapshot: pipelines, stages, tags, forms, calendars, booking nodes, message templates, websites, funnels and every AI Assistant asset type.

Snapshot architecture: the inactive agent runs the DA Sea Food Agent workflow, which is entered by the conversation-started trigger and two stale payment-webhook triggers, extracts ten variables into contact lookup, creates Stripe payment links, sends email without a sender, and is disconnected from SMS; the prompt reads three global variables and expects a menu knowledge base that is not installed; no calendar exists
Architecture, reconstructed from traced connections (2026-09-18). Assets grouped by Votel snapshot category; account-level and external services sit outside the snapshot. Every arrow is a traced edge or a stated dependency; nothing is inferred.
in the snapshotaccount setup / externalopen output or defectdisconnected or inheritedconnected but wrongsaved repair or approved
Text version of this diagram

The agent (GPT-5.6, Cartesia voice, 2,182-word prompt) runs the DA Sea Food Agent workflow. The workflow is entered by a conversation-started trigger for chat, voice or SMS and by two payment-webhook triggers whose URLs are stale. It extracts ten variables that feed contact lookup or creation, creates Stripe payment links through test and live API nodes with embedded credentials, sends email with no sender selected, and has SMS nodes that are disconnected with no number. The agent prompt reads three restaurant global variables that are not installed and expects a menu knowledge base that is not selected. No calendar or table system exists although booking is promised. The opening-greeting channel is present with a blank greeting and no channel is active.

03 · Workflow map

The intended handoff is sophisticated; the connected execution is not.

Restaurant Order & Reservation
● INACTIVE

Workflow

RESTAURANT FULFILLMENT

Agent

Prompt BuilderTools & IntegrationsShared Knowledge
ORDER + RESERVATION · 28 NODES
ConversationChat · voice · SMS
Order or reservation?AI router
OrderGlobal handoff
ReservationGlobal handoff
Extract + contact10 captured fields
Normalize + mapLLM → price IDs
Test payment APILive branch disconnected
Sanitized workflow reconstruction. No credential, webhook URL, merchant price ID, external email address, private contact or account identifier is shown.

1 · Order

Global handoff→Extract + contact→Normalize + map→Test payment API

Only existing-contact Match continues. The no-match contact-creation output is open. The final email has no sender and targets a fixed external address, not the extracted customer.

2 · Reservation

Global handoff→Extract + contact→Internal-style email→Hangup

The “restaurant owner” email is sent to the customer. No table availability or booking action exists.

Subflow 1: conversation started leads to the router, which sends Place Order to the order conversation and Reservation to the reservation conversation; each conversation is expected to invoke a global handoff node, untested, and each has an open default output
Workflow subflow 1 of 4: entry and routing (edges 1 to 3, observed 2026-09-18). The dotted arrows from the two conversations to the global handoffs are the intended model invocation, which no simulator evidence proves.
Text version of this diagram

The conversation-started trigger (chat, voice or SMS) leads to the router. Place Order leads to the order conversation, an AI node with a one-sentence instruction and Auto-Continue off; Reservation leads to the reservation conversation. Neither conversation has a deterministic outgoing edge; each is meant to invoke a global static-response node once intake completes: the order handoff says a Stripe link was sent by SMS, the reservation handoff says the restaurant will call. Both conversation default outputs are open. The handoffs continue into subflows 2 and 3.

Subflow 2: the order branch from the order handoff through extraction, contact lookup with an open no-match output, the normalize and test-mode price-mapping subagents, the metadata merge, the test Stripe API with an open error output, the payment-link email and hang-up; the live price mapper, live API and SMS nodes are disconnected
Workflow subflow 2 of 4: the order branch (edges 4 to 11). Only the Match output of contact lookup is connected; the live-mode nodes and the SMS nodes exist but have no edge into them.
in the snapshotaccount setup / externalopen output or defectdisconnected or inheritedconnected but wrongsaved repair or approved
Text version of this diagram

The order handoff leads to the five-field extraction (name, phone, order, address, email), then to contact lookup or create matching on phone and email. Only Match continues, into the normalize-order subagent with a hard-coded menu; No match / created is open. Normalize leads to the test-mode price mapper with hard-coded Stripe price IDs, then to the LLM that merges metadata and line items, whose sample JSON is malformed, then to the Test events API that creates a Stripe payment link with an embedded test credential. Its Success output leads to the payment-link email, which has no sender and a fixed external recipient, then to hang up; its Error output is open. The live-mode price mapper, the live Stripe API with an embedded live secret, and the SMS nodes are disconnected.

Subflow 3: the reservation branch from the reservation handoff through extraction and contact lookup, whose first-name mapping reads the order extractor, to the reservation email addressed to the customer with an owner-notification subject, then hang-up; the no-match output is open and no calendar or booking action exists
Workflow subflow 3 of 4: the reservation branch (edges 12 to 15). Amber nodes are connected but wrong; the calendar node is drawn only to show its absence.
Text version of this diagram

The reservation handoff leads to the five-field extraction (first name, date and time, phone, guests, email), then to contact lookup or create, whose First Name field reads the order extractor's name instead of the reservation extractor's first_name. Only Match continues, to the reservation email, which has no sender, a subject that calls it a notification to the restaurant owner, and the customer's extracted email as recipient; then hang up. No match / created is open. There is no calendar, capacity or booking action although table booking is promised.

Subflow 4: two standalone webhook triggers, Test events and Live events, each with a stale URL and no event filter, lead to a customer confirmation email and then a terminal restaurant order email
Workflow subflow 4 of 4: the payment-webhook chains (edges 16 to 19). Votel reported in both trigger panels that the generated URL points to a trigger that no longer exists.
Text version of this diagram

The Test events trigger leads to a customer confirmation email and then to a terminal restaurant order email; the Live events trigger leads to its own customer confirmation email and terminal restaurant order email. Both trigger URLs are stale after installation and neither has an event filter, a captured sample or a signature check.

04 · Payment contract

The most important side effect has no safe environment boundary.

The connected order path generates a test-mode payment link. A separate live-mode path contains a live credential but is disconnected. Both payment webhooks are invalid after installation, and neither filters for a signed, successful payment event.

LayerStatusInstalled result
Order normalizerLLM output

Understands free sides, premium add-ons and modifiers, but receives no deterministic schema validation.

Product-to-price mapperSource-specific

Large hard-coded merchant catalog; unknown products are silently omitted.

Metadata mergerMalformed example

The prompt’s sample JSON omits required quotes and commas before sending data to Stripe.

Stripe APISecrets embedded

Test and live credentials are stored in reusable API nodes; only test mode is connected.

Payment deliveryWrong recipient

The payment-link email targets a fixed address and has no sender; SMS delivery is claimed but not connected.

Payment confirmationDead triggers

Both installed webhook endpoints point to triggers that no longer exist and accept no validated event schema.

Snapshot standard: use environment-scoped secret storage, install-time merchant mapping, typed payload validation, signed/idempotent payment-success webhooks, verified recipients and truthful delivery status.
Order data flow: the five extracted order values and where each goes: name, phone and address to the contact record and the payment metadata, order to the payment metadata and the payload chain, email to the contact record but not to the payment-link recipient
Data flow, order values (from the data contract). Solid arrows are traced destinations; the dotted arrow marks the value that should be the payment-link recipient and is not.
Text version of this diagram

The order conversation extracts name, phone_number, order, address and email. Name, phone and address are written to the contact record and used in the payment metadata and email body; order goes to the metadata and feeds the payment payload chain; email is used for contact lookup and creation but is not used as the payment-link recipient, which is a fixed external address.

Payment payload chain: the extracted order text is normalized by an LLM into JSON, mapped by a test-mode LLM to hard-coded Stripe price IDs with unknown products dropped, merged by a third LLM whose example is malformed, sent unvalidated to the Stripe payment-link API, whose URL goes to the payment-link email with a fixed recipient
Data flow, the payment payload chain (REST-014, REST-015). Three LLM-generated JSON values cross without deterministic validation before the Stripe API.
Text version of this diagram

The extracted order text goes to the normalize-order LLM, which produces normalize_order as JSON. That goes to the test-mode price mapper, which produces Json with hard-coded Stripe price IDs and silently drops unknown products. That goes to the metadata-merge LLM, whose example JSON is malformed, producing merged_output with no schema validation. That goes to the Stripe payment-link API with a test credential, which returns payment / url, which goes to the payment-link email with a fixed external recipient; the SMS nodes are disconnected.

Reservation data flow: first name, reservation time, phone, guest count and email go to the reservation email, phone and email also to the contact record; the contact creator reads the order extractor for first name; no calendar or capacity check exists
Data flow, reservation values (from the data contract). Amber marks the two wrong mappings: the recipient and the first-name source.
Text version of this diagram

The reservation conversation extracts first_name, customer_reservation_time, phone_number, number_of_guests and email. All five go to the reservation email; phone and email also go to the contact record; email is the recipient of an email whose subject calls it an owner notification. The contact creator's First Name reads the order extractor's name rather than first_name. The reservation time is not validated against any calendar and the guest count has no capacity check.

05 · Defect register

Twenty-two findings, led by exposed credentials and broken fulfillment.

FindingSeverityWhy it matters
Reusable Stripe secretsCritical

Test and live payment credentials are embedded in workflow API nodes.

Two stale payment webhooksCritical

Votel says both installed URLs point to triggers that no longer exist.

Payment link goes to a fixed addressCritical

The connected email does not use the extracted customer recipient.

Test mode is the connected order pathCritical

Live nodes are disconnected while test mapping and API execution continue to fulfillment.

First-time contacts stopHigh

Both No match / Created outputs are open.

Reservation notice goes to the customerHigh

Internal operational instructions are emailed to the diner, not the restaurant.

No reservation booking systemHigh

The library promises table booking, but no calendar, capacity or booking node exists.

No sending channelsHigh

Email and SMS cannot execute as installed.

Premature, wrong-channel successHigh

The agent says an SMS link was sent before link generation; the connected action is email.

Empty conversational menuHigh

The main agent must answer menu/pricing questions without a menu or knowledge base.

No allergy or dietary boundaryHigh

The food workflow has no governed safety response or staff escalation.

Source restaurant configuration is hard-codedHigh

Identity, menu and merchant price IDs do not travel safely to a new restaurant.

Webhook validation is absentHigh

No sample, payment-success filter, signature check or idempotency behavior is configured.

Unknown products are silently droppedHigh

The generated payment can omit requested food without stopping the order.

Commerce JSON is not validatedHigh

Three LLM steps pass commerce data onward; the merge example is syntactically invalid.

Call logic accepts chat and SMSMedium

Non-voice sessions can enter hangup-oriented paths.

Global handoff is unprovenMedium

Vague AI instructions and no simulator evidence leave intake completion nondeterministic.

Local operations are embeddedMedium

Hours, city, delivery, timing and restaurant claims require one validated configuration.

Reservation rules lack system supportMedium

Same-day rejection and callback promises are not backed by availability state.

Blank greeting, zero active channelsMedium

The installed receptionist has no verified entry experience.

Copy and naming errorsMedium

Typos and inconsistent restaurant naming weaken customer trust.

Twelve untested open outputsMedium

Completion and failure behavior remain unproven.

06 · Launch checklist

Secure the money path before polishing the restaurant persona.

  • 1
    Revoke and remove embedded credentials

    Rotate every exposed test/live key and move credentials into environment-scoped connection storage.

    Immediate
  • 2
    Rebuild the payment boundary

    Select one environment, validate typed payloads, regenerate webhooks, verify signatures and deduplicate event IDs.

    Required
  • 3
    Repair first-time-contact paths

    Connect both Created/No match outputs and test new and returning diners independently.

    Required
  • 4
    Separate customer and restaurant messaging

    Use verified recipients, channels and truthful delivery-state copy.

    Required
  • 5
    Install real reservation infrastructure

    Add availability, capacity, booking, confirmation, modification, cancellation and fallback.

    Required
  • 6
    Package restaurant configuration

    Parameterize identity, menu, pricing, modifiers, hours, delivery areas, destinations and merchant mapping.

    Portability
  • 7
    Add food-safety governance

    Install allergy/dietary boundaries, staff escalation and a prohibition on unverified safety guarantees.

    Safety
  • 8
    Make commerce deterministic

    Validate product matches, quantity, modifier pricing, unknown items, amount and currency before side effects.

    Required
  • 9
    Configure and separate channels

    Add greeting, email and SMS channels, then restrict voice-only nodes or branch by channel.

    Required
  • 10
    Run synthetic end-to-end tests

    Prove new/existing customer, pickup/delivery, reservation conflict, unknown item, API error and signed payment-success cases.

    Test

Restaurant snapshot pre-audit complete.

This page preserves the installed-state findings. Corrections and saved proof are tracked separately so the original evidence is never overwritten.

Follow the remediation record →
Audit method: read-only agency-account review on September 18, 2026. The agent remained inactive. No webhook was regenerated, no simulator case was created, and no email, call, SMS, payment, reservation or live contact was used.
Dependency map: the snapshot includes the agent prompt and routing, the order and reservation branches, ten extraction variables, contact lookup, the payment-link chain and two webhook triggers; the owner supplies the email sender, SMS number, restaurant identity and hours, the menu, the Stripe account and catalog, a reservation system and a staff destination; four snapshot defects are separate: embedded credentials, stale webhook URLs, a fixed recipient and a test-mode branch; the agency Social account is inherited and not attributed
Dependency map. Setup is not a defect: the middle group is what every restaurant supplies after install; the rose group is what Votel has to fix in the template. The inherited agency Social account is shown so it is not mistaken for a snapshot asset.
in the snapshotaccount setup / externalopen output or defectdisconnected or inheritedconnected but wrongsaved repair or approved
Text version of this diagram

Included in the snapshot: the agent prompt and routing, the order and reservation workflow branches, ten extraction variables, contact lookup and create, the payment-link chain with test and live nodes, and two payment-webhook triggers. Normal account setup the owner supplies: an email sender, an SMS number with consent rules, the restaurant identity with hours, city and delivery areas, a verified menu with prices and modifiers, a Stripe account and price catalog, a reservation calendar or table system, and a staff notification destination with escalation. Snapshot defects, kept separate: credentials embedded in reusable nodes (REST-001), webhook URLs stale after install (REST-002), a fixed external recipient on the payment email (REST-003), and the test-mode branch connected while live is disconnected (REST-004). Inherited account state, not attributed: an agency-level Social account.