Choose GPT Live or a Voice Pipeline by Workflow Fit

A GPT Live versus voice pipeline evaluation should begin with the business workflow, not a vote on which greeting sounds nicest. A realtime voice mode and a staged speech pipeline may both hold a conversation while differing in controls, observability and the actions accepted in a particular deployment.

For a buyer, the useful question is whether the selected mode performs every required step reliably on the intended route. A mode that sounds appealing but lacks an accepted handoff path may be unsuitable for a workflow built around handoffs, while still being useful for a narrower enquiry pilot.

Write the must-have behaviour first

List the tasks the assistant must complete and the actions it must never claim without evidence. Include listening accuracy, corrections, approved knowledge answers, supported tools, interruptions and call ending. Add transfer or keypad requirements only if the business actually needs them.

Separate requirements from preferences. A specific voice may be a preference. Correctly handling a caller's withdrawn request is a requirement. This distinction keeps a strong demo from outweighing a material workflow gap.

Burki's realtime comparison guide provides background on conversational architectures. Use it to frame questions, then evaluate the exact current configuration rather than assuming all implementations share the same capabilities.

Understand the architecture without overgeneralising

A pipeline separates speech recognition, language-model work and speech synthesis. A realtime voice model handles audio through a different model interaction. LiveKit supports different turn-detection approaches, including realtime-model paths, as described in its turns overview.

That architecture distinction does not determine a universal winner. The surrounding application still owns permissions, business state and integration handling. Features supported by an underlying model or framework may remain gated in a particular product mode.

Burki uses a LiveKit voice runtime and has GPT Live as a default for eligible new assistants. Saved configurations and accepted capabilities should be checked individually. Do not infer complete advanced-workflow or transfer parity from the default label.

Use one acceptance matrix for both modes

A hypothetical evaluation for an enquiry assistant might include a clean question, an ambiguous question, a corrected identifier, an unavailable lookup and an interruption before confirmation. Use the same approved information and expected outcomes in both modes.

For each case, record factual correctness, required clarification, final action state, caller-heard quality and any unsupported step. A clear failure on a must-have behaviour should remain visible rather than being averaged into a high overall score.

If a feature is unavailable in one mode, label it unavailable. Do not replace it with a simulation and then compare that result with a real action in the other mode.

Compare timing on equivalent endpoints

Pipeline component metrics and realtime metrics may not line up directly. LiveKit's observability reference describes fields that are specific to the pipeline. Missing component fields in a realtime run do not mean that its underlying work took no time.

Compare the caller-relevant interval on the same route, and retain internal metrics as explanations where available. Check premature responses and false interruptions alongside delay. Faster speech is not useful if it arrives before the caller finishes supplying a critical fact.

Review maintenance as well as the first call. Determine who can diagnose a failed action in each mode, what evidence is retained and how a configuration change will be checked. A mode with excellent initial speech may require a different troubleshooting process. The team should understand that process before its first customer incident, rather than discovering the difference while trying to reconstruct a missing result.

Make a reversible choice

Document the selected mode, the accepted workflow and the known exclusions. Keep the prior configuration available and decide what observation would trigger reconsideration. A later model or integration change should rerun the relevant cases.

Voice selection can follow once workflow suitability is clear. Burki's TTS guide helps with that narrower decision. Start with the must-have matrix, collect comparable evidence and choose the mode that supports the service you are ready to operate.