The three common paths
Teams generally take one of three routes. They can code directly against a voice AI SDK, configure a no-code or dashboard platform, or describe the job in plain language and let a builder draft, test, and publish the line.
The SDK route suits a team that wants to own every layer and has engineers for it; that control also means responsibility for the pipeline. A dashboard platform suits a team that wants configuration without code and its own flow-building conventions. Describing the job suits a team that wants a line without owning the pipeline.
The routes also change the work after launch: an SDK pipeline needs future API fixes, a dashboard needs its configuration reviewed as the business changes, and a brief needs its facts kept current. The choice is less about a universally right route than about the work the team can support over time, including testing the line when its inputs change.
What you must decide up front
Whichever route you take, the same decisions have to be made before the line is any good, and skipping them is why most first attempts sound scripted or get stuck.
- The greeting — the first thing a caller hears, and the tone it sets for the rest of the call.
- What it may answer — the exact facts it’s allowed to state, not a vague sense of "knows about the business."
- What it hands off — every category of question that goes to a person, named specifically, not left implicit.
- Hours — when the line runs, and whether it behaves differently outside business hours.
Writing a brief that actually works
A vague brief produces a vague line. “Answer questions about the business” does not say what to do when the phone rings. A working brief names specific facts and rules: hours, approved answers, how to respond to a refund request, and who receives a hand-off.
A short first brief leaves more for the line to guess, which an honest receptionist line should refuse to do. Write down more facts than feel necessary at first, then trim what is unnecessary after testing.
Test with real calls before publishing
A brief that reads well can still fall apart when a caller interrupts, asks something sideways, or presses on a missing answer. Before a line goes live, test those gaps rather than only a friendly happy path that confirms what you already expected.
A Callable is tested this way by default: the builder plans caller scenarios — including ones meant to break the draft — and grades the transcripts before you ever publish. See /how-it-works for the full mechanism, from a sentence to a published line.
Getting started
None of the three routes is a one-way door. A team can move from a dashboard to an SDK when it needs more control, or begin with a brief before taking on the underlying pipeline. The important choice is the work the team wants to own after the line is running, not a permanent commitment made on day one.
If you want to describe the job and have it built and tested, start at /start. /templates has starting briefs to review first, including the facts and hand-off rules a written brief needs. That makes later revisions easier to plan and test.