How to build a voice AI assistant around a real business task

Start with the task a caller needs completed. “Answer calls” is too broad to verify. “Explain our approved service area and collect a repair request without promising a price” gives you a useful first assistant and a testable boundary.

Choose the speech architecture

A cascade connects speech recognition, a language model and speech synthesis. A realtime speech model handles spoken input and output directly. These are different configurations; a separate STT or TTS provider is not required for every voice agent.

Burki uses LiveKit rooms for live media and offers managed GPT Live as the default for new assistants. Supported cascade configurations remain available. Provider choice changes the available settings and behavior, so check the selected configuration rather than copying a pipeline diagram into production. See OpenAI realtime and separate voice stacks.

Write a useful business brief

Include the business name, hours, locations, supported services, approved answers and desired outcome. Also list what the assistant must not promise. For a repair business, that might mean no invented arrival time, no binding price quote and no confirmation that a technician has been dispatched.

Create a draft from that description. The free starter gives you editable instructions; optional AI workflow generation is separately priced. Review any generated steps and missing integrations before using them. A generated workflow is an unpublished proposal, not evidence that its actions work.

Add actions only when the connection exists

A prompt can ask for an appointment preference. A real booking requires a supported connection, an appointment type and the required caller details. In Burki, the supported Cal.com action should report confirmation only from the returned booking result. A timeout or uncertain result needs reconciliation before a retry.

For an HTTP tool, define a narrow operation, authenticate it server-side and validate its arguments. Keep credentials out of instructions. Record the outcome of the action, including an error or pending state, independently of the assistant's spoken summary.

Test the exact draft

Practice an ordinary request, a caller correction, an interruption and an unsupported question. Inspect the transcript and activity, edit the instructions and retest. Browser testing does not silently publish the draft.

Eligible trial workspaces receive pooled browser practice, not a telephone number or 200 call minutes. Trial actions are simulated; live external actions and stored recordings require funded usage. See the current trial guide and the allowance shown in your workspace.

Connect callers after readiness checks

Review pricing, fund the workspace, connect a number you control and publish the reviewed version. Verify the actual telephone route, caller-heard audio, hangup and settlement. Test any required handoff separately; a browser conversation does not establish transfer support.

Keep the previous working routing available during a controlled introduction. Review successful business actions, failures and cost, rather than treating every completed call as a resolved customer request. Create an assistant draft when you have a specific scenario to test.