Booking workflow reliability QA
This is the level and structure delivered for the fixed USD 10 trial. The example is synthetic: no client workflow, credentials, recordings, or customer data were used.
Decision: HOLD before client handoff. The happy path works, but a retry after a slow calendar response can create two appointments for one caller. Fix the idempotency boundary, then rerun the three acceptance tests below.
1. Intended state contract
| Boundary | Required input | Success evidence | Stable key |
|---|---|---|---|
| Voice → workflow | service, requested time, contact channel | validated request envelope | conversation_id |
| Workflow → calendar | normalized UTC interval, service duration | one provider event ID | booking_request_id |
| Calendar → confirmation | event ID plus committed status | one customer confirmation | event_id |
| Confirmation → CRM/log | event ID, caller reference, audit timestamps | record points to the same event | event_id |
2. Failure-path audit
| Priority | Failure | Current risk | Required behavior |
|---|---|---|---|
| P0 | Calendar call times out after the provider created the event. | Workflow retries and creates a duplicate. | Reuse one idempotency key; reconcile by key before creating again. |
| P1 | Two callers request the final slot concurrently. | Both availability checks can return free. | Make reservation atomic or recheck during the write transaction. |
| P1 | Event created but CRM write fails. | Caller is booked, team dashboard says unbooked. | Persist the event ID in an outbox and replay the CRM update safely. |
| P2 | Email/phone is missing or malformed. | Booking may succeed without a usable confirmation route. | Return a structured clarification request before reserving. |
| P2 | Cancellation arrives while confirmation is queued. | Customer can receive a stale “confirmed” message. | Read the latest booking state immediately before notification. |
3. Synthetic acceptance tests
| Test | Stimulus | Expected evidence | Sample result |
|---|---|---|---|
| Retry idempotency | Send the same request twice; first provider response is delayed. | One calendar event, one CRM record, one confirmation. | FAIL — two event IDs observed |
| Concurrent slot claim | Submit two different callers for one remaining slot. | One confirmed; one receives alternate-slot response. | PASS |
| Partial-write recovery | Force CRM write to fail after calendar success. | Calendar event retained; queued replay links CRM to same event. | PASS |
4. Highest-priority fix
Generate booking_request_id = SHA256(conversation_id + normalized_slot + service) before any external write. Store it with status pending, pass it through the calendar metadata, and on every retry query by that key before creating an event. Promote the record to committed only after receiving one provider event ID. Confirmation and CRM steps must consume the committed record, not the original webhook payload.
5. Re-test gate
- Retry idempotency test passes five consecutive runs.
- Exactly one provider event ID exists for each
booking_request_id. - CRM and notification records reference that same event ID.
- No production or real customer data is required for verification.
A paid review is tailored to one supplied redacted journey. Findings are evidence-based and limited to the provided flow; no claim is made about systems that were not inspected.
Return to the fixed USD 10 audit