From Voice to Dispatch: Designing an Event-Driven Order Pipeline

A phone order is not a single action. It is a chain of dependent steps. Modelling the workflow as events makes success, failure, and waiting states visible at each stage.

Why events

If a system exposes only a “create order” function, failures are hard to locate: was the call not received, was speech not transcribed, was the address not extracted, or did dispatch not respond? Once the workflow is split into events, each stage has explicit inputs, outputs, and states, making retries and human hand-off easier.

The events here are a design concept, not an interface specification for a current system. The names are illustrative.

Events in the pipeline

• call.received: an inbound call with an identifier and basic context.
• transcript.ready: a transcript with timestamps and a reference to the audio.
• order.extracted: extracted fields with confidence and source spans.
• order.review_required: low-confidence or conflicting details need human confirmation.
• order.confirmed: a person or rule set has confirmed the order content.
• dispatch.requested: a request has been sent to dispatch.
• dispatch.updated: a dispatch result or state change.

Events should not assume synchronous completion. Transcription may finish seconds after the call, human review may happen minutes later, and dispatch may be temporarily unavailable. The workflow must handle these waits and interruptions.

Failure handling

• Idempotency: resending an event must not create a duplicate order or dispatch request.
• Retry with backoff: decide by error type whether to retry, rather than resending indefinitely.
• Pending queue: events that cannot be processed automatically must be preserved and surfaced.
• Human review: make uncertainty explicit so operators know which field to check.
• Compensation: an incorrect result that has already been created needs a traceable correction path, not a silent overwrite.

The principle is to make failure visible before pursuing automation. If failures remain buried in logs, operators cannot tell whether an order was actually created.

Observability

An event pipeline needs a shared correlation identifier linking the call, transcript, extraction, review, and dispatch. Each stage should record state transitions, processing time, and failure reasons. These records support debugging, operational review, and later test comparisons.

Records also carry privacy risk. Call audio and transcripts may contain personal information, so they need redaction, access control, and retention limits rather than indefinite storage.

Design principle

Event-driven design is not about complexity for its own sake. It gives uncertainty a place to live. For fleet operations, an order waiting for human confirmation is far easier to handle than an order that failed silently.