Write a Small-Business Voice Assistant Operations Runbook

A voice assistant operations runbook gives a small business a practical answer to “Who handles this when something goes wrong?” It should be short enough to use during a real problem and specific enough that the operator does not need to reconstruct the original setup.

The runbook is not a technical manual for every provider. It connects business responsibilities, supported workflows and recovery steps. Even if one person initially owns everything, writing those responsibilities down makes cover, holidays and future handover much easier.

Start with the service boundary

Describe which number or channel the assistant handles, its operating hours and the tasks it is allowed to perform. List the important exclusions. If a browser practice demo simulates an action, distinguish it from the live business workflow.

Record the currently accepted configuration and where the review evidence lives. Include the assistant mode, relevant integrations and any route-specific limitations. A new default or recently added feature should not silently expand the runbook's scope.

Burki's testing guide can help define what “accepted” means. The runbook should point to that evidence rather than relying on the memory of whoever performed the first successful demonstration.

Name owners and backups

Assign a business owner for service promises, an operator for daily review and a technical contact for routing or integration problems. Include the billing/account owner for each BYO provider where applicable.

Document how an authorised backup obtains access without placing credentials in the runbook. Check that the backup can locate the relevant account and recovery procedure before an incident occurs.

For a hypothetical two-person business, the owner might review unresolved requests while an implementation partner manages routing. That arrangement can work if response expectations and fallback authority are clear. It fails when each assumes the other monitors the calls.

Provide three incident paths

Keep the initial triage simple. For “calls do not reach the assistant,” collect the time, number and observed carrier behaviour. For “the conversation is wrong,” retain the exact call and the incorrect statement or action. For “the result is missing,” inspect the relevant saved record or provider outcome.

Do not change prompts to fix every symptom. A routing failure, an outdated knowledge answer and a delayed integration write require different evidence. LiveKit's telephony testing guide provides a useful technical reference for following one call across the route.

Each path should state who investigates, what information they need and what condition triggers a fallback. Use plain language so a nontechnical operator can start the process accurately.

Define recovery and communication

Record the previously accepted route or narrower operating mode that can be restored. Identify who is authorised to make the change and how its success will be checked. Saving a setting is not sufficient; verify the resulting caller path.

Prepare a concise internal update format: observed impact, affected period, current workaround, owner and next review point. Avoid claiming a cause before evidence supports it. The business needs a dependable status, not a confident guess.

If customer follow-up is required, assign it explicitly. A technical fix does not automatically resolve requests that were lost or left uncertain during the incident.

Maintain the everyday information

Add the knowledge owner, review triggers, provider funding checks and the process for reviewing unresolved calls. Include a compact change log for prompt, document and permission changes.

Burki's production-safe learning guide supports controlled improvement. Use the same review discipline for a small wording change when it affects a promise or action, while keeping low-impact editorial maintenance proportionate.

Rehearse one scenario

Walk through a hypothetical silent call or missing enquiry with the backup operator. Ask them to find the relevant identifier, contact the owner and locate the fallback without help from the original implementer. Update anything they could not follow.

A runbook earns its value through use. Start with one page covering scope, owners, three incident paths and recovery, then add detail only when an actual operating need makes it useful.