We are initiating a structured implementation phase to evaluate execution quality, system reliability, and delivery standards ahead of a potential long-term collaboration with **Levanrohe.com**.
This phase requires building a **complete, production-grade reservation automation pipeline**, starting from AI voice interactions and ending with operational notifications to restaurant staff. The objective is to validate that the system can be delivered **cleanly, deterministically, and without manual intervention**.
Below is the required scope and execution logic.
---
1. Objective (Non-Negotiable)
Build an end-to-end automated flow that:
1. Receives finalized reservation data from **Retell AI**
2. Processes and validates that data in real time
3. Pushes the reservation into **xMenu** in a structured, API-compliant manner
4. Notifies restaurant staff via **Zadarma SMS**
5. Operates entirely through **Make.com** as the orchestration layer
This system must function reliably under real operational conditions.
---
2. Authoritative Flow Overview
**Source of Truth:** Retell AI (call-ended event)
**Orchestration Layer:** Make.com
**Downstream Systems:** xMenu (data sink), Zadarma (notifications)
High-level flow:
```
Customer Call
→ Retell AI (call concludes)
→ Make.com Webhook (authoritative payload)
→ Data validation & normalization
→ xMenu API (reservation / order write)
→ Zadarma SMS (staff notification)
```
No UI-driven steps. No manual confirmations. No hidden dependencies.
---
3. Step-by-Step Technical Responsibilities
3.1 Retell → Make.com (Webhook Ingestion)
* Configure Retell to send **call.ended** events to a Make.com webhook
* Payload must include:
* Guest name
* Phone number
* Date
* Time
* Party size
* Notes (optional)
* Treat this payload as **finalized reservation intent**
Make.com must reject incomplete or malformed payloads explicitly.
---
3.2 Data Validation & Normalization (Make.com)
Inside Make.com:
* Validate required fields
* Normalize date/time formats
* Enforce basic business rules (e.g. party size > 0)
* Generate a deterministic internal reference ID (idempotency)
If validation fails → log + stop flow (do not propagate bad data).
---
3.3 Make.com → xMenu (Reservation Write)
* Use xMenu’s **order write API** to register the reservation
* Reservation may be represented as a structured order (as per API capability)
* Include:
* Guest metadata
* Reservation details in notes / structured fields
* Internal reference ID
Critical requirements:
* Handle API latency and partial failures gracefully
* Do not assume UI-based lifecycle transitions
* Treat xMenu as a **downstream consumer**, not the system of record
Failures must be logged, not silently ignored.
---
3.4 Make.com → Zadarma (SMS Notification)
Once (and only once) reservation data is successfully processed:
* Send an SMS via Zadarma to the restaurant’s staff phone number
* Message must include:
* Guest name
* Date & time
* Party size
* Contact number
SMS delivery must be asynchronous and non-blocking.
---
4. Quality & Acceptance Criteria
This implementation is considered successful only if:
* A real phone call produces a real reservation without manual steps
* Data is consistent across all systems
* Failures are visible, logged, and traceable
* The flow is reproducible and explainable end to end
* The system can be handed over without tribal knowledge
“Mostly working” is not acceptable.
---
5. Engagement Context
This project is intentionally structured as a **delivery validation phase**.
We are evaluating:
* Technical decision-making
* System design discipline
* Attention to edge cases
* Production readiness mindset
Successful execution will directly inform our decision to proceed with a **full-time, long-term engagement** with **Levanrohe.com**.
---
6. Final Note
This is not an experimental prototype.
This is a controlled execution test.
Please proceed with the expectation that:
* Architecture choices must be defensible
* Trade-offs must be explicit
* The final system must be something you would confidently operate in production
We are available to clarify requirements, review intermediate builds, and validate results.