How I built a voice agent for our customer discovery calls

I have an AI agent named Annie. She picks up the phone, introduces herself, asks about the caller's business, figures out where they're wasting time, and we use the customer transcript to recommend AI tools they can use immediately in their business. The best part... I didn't write a single line of code to build her.

If you read this full article (or have Claude Code read it) here's what you'll learn:

• Why discovery was a practical first use case in my business
• The five building blocks I used for Annie
• The conversation flow I use to move qualified callers toward a reviewed follow-up
• The prompt structure that makes your agent sound human (not robotic)
• The mistakes that will make callers hang up in the first 10 seconds

Now let's build this thing...

Why Discovery Calls (and Not Something Else)

Most people hear "voice agent" and think customer support. That is a hard first version: support calls are unpredictable, the caller could ask about anything, and errors can affect an existing customer.

Discovery calls are more structured in my business. The conversation usually follows a recognizable pattern:

• Who are you and what does your business do?
• What takes up most of your time?
• How many hours a week does that eat?
• Would you like to see how to fix that?

That's it. The agent leads the conversation. The caller answers. There's a clear beginning, middle, and end. And the outcome is simple - either they book a call or they don't.

That structure made discovery a useful first experiment for me. It does not make the stakes trivial or guarantee revenue. A production system still needs clear AI disclosure, consent and recording-law review for the relevant jurisdictions, protected transcripts, monitoring, and an immediate path to a human.

The Five Building Blocks I Used

This is the structure I implemented for Annie. Other providers and architectures may package these capabilities differently.

1. The Voice

This is what the caller hears. In my implementation, I chose a voice and tuned its pacing for the conversation. Available voices, controls, and interruption behavior depend on the provider, so I test them rather than promise a specific library or feature.

2. The Conversation Flow

This is the backbone. I used a flowchart where each node represents one phase: greeting, discovery, qualification, booking, or goodbye. Transition instructions encourage the intended order, but they do not guarantee a model can never skip or misroute. Tests and human escalation cover those failures.

3. The Global Prompt

This is the agent's personality and hard rules. It applies to every phase of the conversation. Things like: "You are Annie, a friendly AI assistant for Return My Time. You help business owners figure out where they're losing time." Also where your guardrails live - what the agent should never say, never promise, and never do.

4. The Node Prompts

Each box in the conversation flow gets its own prompt. The greeting node knows how to introduce itself. The discovery node knows to ask about the caller's business. The qualification node knows how to put numbers to the time they're wasting. Each node has ONE job. That's the key. One question per turn. One phase per node. When you stack multiple questions into one node, the agent trips over itself and the caller gets confused.

5. The Transitions

These are the rules that tell the agent when to move from one phase to the next. "The caller has explained what their business does" triggers the move from greeting to discovery. "The caller has confirmed they want to learn more" triggers the move from qualification to booking. Without clear transitions, the agent either rushes through the conversation or gets stuck repeating itself.

The Conversation Flow That Works

Here's the exact flow structure I use. Six nodes, each one doing one thing:

1. Greeting - Welcome the caller. Say who you are. Ask one question: "What does your business do?"
2. Discovery - Dig into their daily work. Find out what eats their time. Ask about the tasks they repeat every single day.
3. Quantification - Put numbers on it. "How many hours a week does that take?" This is where the agent turns a vague frustration into a concrete problem.
4. Value Bridge - Connect the stated problem to a possible next step without inventing savings. Reflect the caller's own numbers and label any estimate.
5. Booking - Offer a follow-up call with your team. Give a specific next step. Not "we should chat sometime" but "can I get you on the calendar this week?"
6. Goodbye - Thank them. Confirm the next step. End clean.

Each node has a transition condition based on the caller's response. I test premature transitions and repetition explicitly because prompt instructions alone do not enforce a perfect state machine.

The Prompt Mistakes That Kill Calls

Three things will make your callers hang up:

Stacking questions. If your agent asks "So what does your business do and what tools do you use and how many people are on your team?" the caller freezes. One question. Wait for the answer. Then ask the next one.

Sounding like a script. If your prompt says "STEP THREE: QUANTIFICATION PHASE" the agent might actually say those words out loud. Write your prompts the way you'd talk to a friend. No headers. No numbered lists. No corporate language. The agent speaks whatever you write.

Rushing to the pitch. If the agent jumps to an offer before it understands the caller, the conversation feels scripted. I instruct it to ask relevant follow-ups and move on only after the caller's problem is clear. Adequate depth depends on the conversation, not a universal minimum duration.

What Makes This Actually Work

The value is not only the model. In my tests, a conversation flow with clear phases, one question per turn, and explicit transition rules was easier to evaluate than a free-form “just be helpful” prompt. That is an observed design hypothesis, not a universal performance guarantee.

The pattern gave my team a consistent way to review calls and improve the prompts. Callers should be told at the start that they are speaking with an AI, how recording and transcripts are handled, and how to reach a person. I do not publish conversion or call-volume claims here without the internal evidence needed to substantiate them.

Before launch, I also require test calls for interruptions, silence, angry callers, sensitive disclosures, wrong numbers, scheduling failures, and requests the agent must refuse. Transcripts use minimum retention, and access is limited to the people who need to review them.

All because the conversation was designed to guide them through a specific path - not dumped into an open-ended chat.

That is the lesson from my implementation: model capability matters, but a simpler, testable conversation is easier to operate safely.