AI Receptionist Guide: From Phone Number to Live Agent

An AI receptionist is a voice agent that answers your business phone, understands why the person called, and does something useful about it: books the job, takes a message, answers a real question, or hands the caller to a human. I run several of these in production, including one on my own agency's main line, and the difference between the ones that work and the ones that get switched off in a week has almost nothing to do with which platform you picked.

It comes down to plumbing, scope, and testing. Here is the whole path, in the order I actually do it.

Step 0: Decide what it is allowed to do

Before touching a platform, write down three lists. This takes twenty minutes and saves you a month.

Things it must do. Usually three or four: identify the caller's intent, capture name and callback number, book or schedule, transfer to a human on request.

Things it must never do. Quote prices you cannot honor, promise arrival times, give medical or legal advice, argue.

Things it does not have the ability to do. This one is not obvious and it is the most important list in the whole build. I once had a receptionist confidently tell a caller it had blocked their number. It had no such ability. It invented the capability because the prompt never said it lacked it, and a helpful-sounding model will fill a gap. The fix was an explicit "abilities you do NOT have" section in the system prompt. Every agent I ship now has one. More on that failure mode in stopping chatbot hallucinations.

Step 1: Get a number, and decide how calls reach it

You have two structures, and picking the wrong one causes most launch delays.

Structure A: new number, forward to it. You provision a fresh number on a telephony provider, build the agent against it, and then forward your existing business line to it when you are happy. This is what I do for almost every client. Your real number keeps working the whole time, you can test the AI privately, and rollback is one setting.

Structure B: port your number. You move the business line itself onto the provider. Cleaner long term, but porting takes days to weeks, and during that window you do not want to be debugging a prompt.

Start with A. Consider B later, or never.

Provision a local number in the area code your customers recognize. It costs about a dollar a month. Do not use a toll-free number for a local service business; local numbers get answered when the agent calls back.

Step 2: Get the forwarding right

This is where projects stall, and it is nearly always the existing phone system rather than the AI.

If you are on a plain mobile or landline, forwarding is a carrier code or an app toggle, and you have options: forward everything, forward on no-answer, or forward on busy. For most small businesses, forward on no-answer after four rings is the right default at launch. Humans get first crack, the AI catches the overflow, and nobody feels replaced.

If you are on a business phone system, read the manual before you assume. On one carrier-hosted business system I had to use group forwarding rather than the built-in auto-receptionist to get calls out to the AI number, because the auto-receptionist would answer first and swallow the call. The symptom was "the AI never rings." The cause was two receptionists fighting over the same call. I wrote the general patterns up in phone forwarding for AI agents.

Also decide now what happens to voicemail. If the AI answers, you generally want the old voicemail box out of the path entirely, otherwise you get a race and callers land somewhere nobody checks. For lead-gen sites I sometimes do the opposite and go voicemail-first with the AI handling the callback, but that is a deliberate choice, not an accident.

Step 3: Build the knowledge base before the prompt

The prompt is personality and rules. The knowledge base is facts. Mixing them is why agents go stale.

Load: services, service area, hours, pricing structure (even if it is ranges), what you do not do, common objections, parking or arrival instructions, insurance or licensing basics. Pull it from your real website pages rather than writing it fresh, because then your site and your phone stay in sync. On demo builds I scrape a prospect's site into a knowledge base in minutes, and it is genuinely enough to hold a credible conversation about their business.

Two rules. First, put a "last updated" line in the source content so you can spot drift. Second, if a fact changes weekly (today's availability, current promo), do not put it in the knowledge base. Fetch it at call time with a tool, or leave it out. See chatbot knowledge base guide.

Step 4: Write the prompt

Structure I use, in order:

1. Identity and role. Who it is, what business, one line of tone. "You answer the phone for a residential lawn care company in the Chicago suburbs. Friendly, brief, never pushy."
2. The goal of the call. State the single primary objective. Agents with three co-equal goals meander and your minutes bill goes up.
3. Information to collect, in order, with what to do if the caller refuses.
4. Abilities you do NOT have. The explicit denial list from Step 0.
5. Escalation rules. Exact conditions for transferring to a human, and what to say while doing it.
6. Style constraints. Short sentences. One question at a time. Never read a list of more than three options aloud. Confirm phone numbers digit by digit.

Keep it as short as it can be while still being unambiguous. Long prompts are not more controlled, they are more contradictory.

One mechanical thing that has bitten me: if your platform substitutes variables into the prompt, verify the substitution actually happened. Leftover unsubstituted {{placeholder}} tokens sitting in live instructions silently degrade the whole prompt, and the agent just gets subtly worse with no error anywhere. Read the rendered prompt, not the template. See dynamic variables.

Step 5: Pick a voice and tune the conversation feel

Voice matters more than founders expect and less than they fear. Pick something plain and regionally neutral to your customers, at a slightly slower rate than the default. Then test two things specifically:

• Barge-in. Can the caller interrupt? If not, every impatient caller hangs up. See barge-in.
• Silence handling. What happens after two seconds of nothing? A good agent prompts gently once, then asks if the caller is still there, then wraps up. A bad one waits forever and bills you for it.

Choosing a voice for your agent goes deeper.

Step 6: Wire the actions

An agent that only talks is a fancy voicemail. The actions worth wiring first, roughly in order of payback:

• Send a lead notification (SMS or email) to the owner the second a call ends, with the caller's number and a two-line summary. This alone converts more jobs than anything else.
• Book an appointment against a real calendar with real availability. See chatbot appointment booking.
• Transfer to a human.
• Text the caller a link (booking page, quote form, directions).

Transfer deserves its own warning. The transfer tool must reference the live call's control identifier, not a hardcoded or stale value. I have watched transfers fail with a validation error because the tool was configured with a fixed ID, and from the caller's side that is indistinguishable from being hung up on. Test transfer on a real call, every time, before launch. Call transfer flows covers the patterns.

Step 7: Configure the failure paths

Production voice fails in specific ways. Configure for them up front:

• Fallback model. If your platform supports a secondary model and you leave it empty, a provider outage becomes dead air on your main business line. Set it.
• Empty variables. An assistant configured with empty dynamic variables can produce total silence on answer. It looks like a carrier problem. It is not. Validate that every variable the prompt expects actually arrives.
• Tool failure. If the booking API is down, the agent should say so and take a message, not loop.
• Human backstop. A number that a caller can always reach by saying "person" or pressing zero.

Step 8: Test like it is going to fail, because it is

The single most useful discipline I have: call and text your own cell phone before any client rollout. Not the simulator. The simulator cannot inject real system variables like caller ID, so an entire class of bug only surfaces on an actual PSTN call.

My pre-launch call list:

1. Normal booking call, straight through
2. Caller who interrupts mid-sentence
3. Caller who asks for a human immediately
4. Caller who asks something not in the knowledge base
5. Caller who tries to get it to promise something it cannot do
6. Wrong number, hangs up at three seconds
7. Call from a blocked or unknown caller ID
8. Call outside business hours

Then verify the wiring, not the logic. Green tests inside the builder mean the builder works. Replay a real call end to end and confirm the lead notification actually landed in the owner's inbox. I have seen unit tests pass while a live integration quietly dropped leads. Testing voice agents has the full checklist.

Step 9: Launch narrow, then widen

Go live on no-answer forwarding only. Read every transcript for the first two weeks. You will find three or four recurring things the agent gets wrong, and fixing those is 80% of the total quality gain. Once it is clean, consider after-hours-only, then full-time if it earns it.

Track: calls answered, calls that produced a captured lead, transfers requested, and calls where the caller hung up in the first 15 seconds. That last number is your honesty metric. See chatbot analytics.

FAQ

How long does it take to get an AI receptionist live?

The agent itself is a day of work. Realistically, plan two weeks: a few days building and testing, and the rest waiting on phone system access, forwarding changes, and the client actually deciding what the bot should say about pricing. The AI is never the bottleneck.

Will callers know it is not a person?

Many will, and that is fine if it is helpful and fast. What annoys people is an agent that pretends hard, cannot answer, and will not transfer. Be pleasant, be brief, and always honor a request for a human on the first ask.

Should the AI answer every call or only missed ones?

Start with missed calls only. It removes all the risk and immediately captures revenue you were already losing. Many businesses stay there permanently and are happy. Compare against the alternative in AI receptionist vs answering service.

What if it gives a caller wrong information?

Assume it will, at least once, and design so the blast radius is small. Keep volatile facts out of the knowledge base, tell it explicitly to say "I'll have someone confirm that" rather than guess, and read transcripts weekly. The agents that cause real damage are the ones nobody is reading.

Can it handle multiple locations or departments?

Yes, and this is where AI beats a phone tree badly, because the caller just says what they want instead of navigating menus. Build routing as an explicit step with a small set of destinations, and make sure each destination has a working transfer target and a fallback if nobody picks up.