AI Receptionist Setup:A 30-Day Launch Checklist

Week 1: Audit your own calls

Pull your phone system's call log for the last month and sort it by hour of day and by outcome: answered, voicemail, hung up. Then listen to or skim twenty or thirty real calls if you record them, or ask the person at the front desk to keep a tally for three days. You're looking for the five or six call types that make up most of the volume, and the one or two that are rare but can't go wrong.

I won't give you a benchmark to compare against, because the published ones don't survive checking. Your log is the only number that matters here, and it's the baseline you'll compare against on day 30.

Week 1: Write the rules

This is the most important document of the launch, and it fits on a page. For each call type, write what the receptionist may do alone, what it must hand to a person, and what it must never do.

• May do alone: answer hours, location, parking, services offered, published prices you approve, take a message, book or reschedule within rules you define.
• Must hand over: anything urgent (define the words: for a plumber that might be burst pipe or no heat), any caller who asks for a person, anyone upset, anything involving money owed or a complaint.
• Must never do: give legal, medical or financial advice, quote a price you didn't approve, promise an arrival time it can't see, or pretend to be a person.
• Where handovers go: a named person or extension during hours, a mobile after hours, and a backup if that person doesn't answer.

Vendors build this in different ways. Jobber lets you set keywords for the receptionist to listen for, and its own examples are "emergency," "no heat" and "burst pipe," which then either transfer the call straight through or send you a text alert. Smith.ai's onboarding starts with customizing instructions, including intake criteria and escalation. Housecall Pro's CSR AI asks for an escalation destination. Different screens, same page of rules. Write it once, in plain language, then enter it wherever your product wants it.

Week 1: Build the knowledge base

The receptionist can only be as accurate as what you give it. For built-in products, that's mostly settings you already have. Housecall Pro's getting started article says CSR AI draws on your booking settings (who is bookable, when, and for which services), your Pricebook line items and your service area. Jobber says it pulls your company profile, services, request forms and booking settings. RingCentral's setup guide walks through a profile (name, language, voice), a company description that it also uses to generate a starting set of FAQs, and location and hours drawn from company settings.

So the week one task for those products is cleanup: are the hours in your software right? Is the Pricebook current? Is the service area what you actually serve? The AI will repeat whatever is there with total confidence.

For platforms and custom builds, you're writing documents. Retell's knowledge base documentation accepts URLs, uploaded files and connected drives, with an optional daily auto-refresh, and its advice for content is sound regardless of platform: write in Markdown with clear headings, keep each chunk about one topic, and be specific with names, dates and units. "We're open most weekdays" is useless to a machine. "Monday to Friday, 8:00 a.m. to 5:30 p.m. Pacific, closed federal holidays" is not.

Week 1: Start the slow paperwork

Three pieces of paper run on other people's timelines. Start all three this week, even if you're not sure you'll need the last one.

Text message registration.If your receptionist will send appointment confirmations or follow-ups by text from a normal 10-digit US number, the sending brand and campaign must be registered. Twilio describes three steps: register the brand, register the campaign, attach the numbers. Since June 30, 2026, Twilio's changelog says campaign submissions through its API must include a privacy policy URL and a terms and conditions URL, so make sure both pages exist on your website before you file. I'm not printing a vetting turnaround here because the page that states one blocked my fetch; treat it as days to weeks and start now.

Recording disclosure.Most receptionists record and transcribe. California Penal Code section 632 prohibits recording a confidential communication without the consent of all parties, with fines up to $2,500 per violation for a first offense. The practical answer is a line in the greeting that says the call is recorded and that the caller is speaking with an AI assistant. Put it in the first sentence, not after the caller has explained their problem. I'm not a lawyer; if you take calls from several states, have one confirm the rule for each.

Business associate agreement. If you're a medical or dental practice and patient details will reach the receptionist, HHS guidance says you must obtain satisfactory assurances, in a written contract, that the business associate will safeguard that information. Sign it before the first test call with real patient data, not after launch. If a vendor says its product is designed around HIPAA (Weave's AI receptionist page says it is "designed to meet and exceed the standards of HIPAA"), that's the vendor's description of itself. The signed BAA is the thing you file. Our guide to BAAs and HIPAA hosting covers what to look for in one.

Week 1: Checklist

• Name the launch owner on your side, with authority to change forwarding and to roll back.
• Export last month's call log and tally call types, by hour of day and by outcome.
• Write the one-page rules: may do alone, must hand over, must never do, where handovers go.
• Clean up hours, services, prices and service area in your existing software, or write the knowledge base documents.
• File A2P 10DLC brand and campaign registration if the receptionist will send texts, with privacy policy and terms pages live.
• Draft the greeting, including the AI disclosure and the recording disclosure, in the first sentence.
• Sign the BAA if any protected health information will reach the vendor.
• Book test-call time with two or three staff for week three.

Week 2: Choose the number route

There are three ways to get calls to the receptionist. You can publish a new number that belongs to the AI, forward your existing number to it, or port your existing number to the provider. My rule: forward first, port later if ever.

Why forward first? Because forwarding is reversible in seconds and porting isn't. When you forward, the number stays with your carrier and your carrier just redirects calls. When you port, the number itself moves, and moving it back is another port on another queue. The FCC's consumer guide on porting is useful here for one warning in particular: don't cancel your old service before the new one is working, or you can lose the number.

If you do port later, Twilio's US guidelines list what you need: a signed Letter of Authorization, a name and address that match the Customer Service Record at your current carrier, a phone bill dated within the last 30 days, your account number and a PIN if your carrier uses one. Twilio says the most common rejection reason is a name or address mismatch. Call your carrier and ask what's on the record before you file, because "Smith Plumbing LLC" and "Smith Plumbing" can be two different companies to a porting desk.

Week 2: Set up forwarding, conditionally

Most carriers support two kinds of forwarding: forward everything, or forward only when you don't answer, are busy or are unreachable. The second is called conditional forwarding, and it's the backbone of the staged launch in week four.

Verizon's support page is plain about it: star 72 plus the 10-digit number forwards all calls, star 71 plus the number forwards only calls you don't answer, and star 73 turns forwarding off. The destination must be a 10-digit US number. For AT&T and T-Mobile I'm relying on a carrier code table published by 800.com rather than the carriers themselves, so call your carrier to confirm before you rely on it.

Goodcall's help center recommends conditional forwarding for the same reason I do: the phone rings you first and only goes to the AI when you can't pick up. It also warns that regular forwarding can create loops in some setups, which may need a second line to solve. If you've ever had a call bounce between two voicemails, you've met that loop.

One vendor warning deserves to be read twice. My AI Front Desk offers a QR code shortcut for forwarding, and its help page says: "Scanning the QR code will immediately forward all calls from the registered number on that device to your AI Receptionist." Immediately, and all calls. Don't scan it in week two while you're still testing.

Some products won't start until forwarding exists. Rosie's support article says Rosie won't start working until your calls are forwarded. Smith.ai's Dialpad article says to forward only once you've signed up and completed onboarding, and to set caller ID so the original caller's number passes through; otherwise the receptionist sees your number on every call. Housecall Pro makes forwarding step one and sends a text guide after you attach the product.

Week 2: Hosted phone systems

If you run a hosted phone system, forwarding is a call handling rule rather than a star code. A RingCentral community thread describes the overflow pattern: in the user's incoming call rules, set "if no answer" to forward to the AI Receptionist extension, or set a call queue's maximum wait time to overflow to it. RingCentral's guide adds that the AI Receptionist is an add-on with its own extension, and that it goes live when you assign it in the auto-receptionist's call handling or IVR menu. To remove it you must unassign it from both the business hours and closed hours rules. Note that last detail now; it's your rollback in week four.

The same setup guide has a backup extension setting for calls the AI can't resolve, and transfer by name is on by default. Decide deliberately whether you want callers to be able to reach any employee by saying a name.

Week 2: Platforms and custom telephony

On a developer platform, someone has to connect a number. Vapi's documentation shows importing a Twilio number with the Twilio Account SID and Auth Token, then assigning it to an assistant. Retell's custom telephony documentation recommends an elastic SIP trunk and notes that its simpler dial to SIP URI option doesn't support native call transfer, which matters if transfers are in your rules (they should be).

Transfers themselves come in flavors. Retell documents cold transfer (the call is handed off with no introduction), warm transfer (the agent briefs the person first) and an agentic warm transfer, and notes that transfers work on phone calls, not web calls, to an E.164 number or a SIP address. My preference is warm for anything urgent, so the person picking up already knows why the caller is there. Our voice agent architecture article goes deeper on how those pieces fit.

If you're on Twilio directly, consider SHAKEN/STIR registration in Trust Hub, which Twilio's docs describe as a registration that requires a compliance profile. It helps outbound calls from your numbers (callbacks, for instance) carry verified caller information. Not every receptionist makes outbound calls; if yours does, this belongs in week two.

Week 2: Calendar, messages and listings

• Connect the calendar and confirm the receptionist can only see real open slots, with buffer times and appointment lengths set the way your staff actually book.
• Decide where messages go: an inbox, a text to a mobile, a ticket in your software. Test that each destination receives one.
• Attach your registered text number once 10DLC registration is approved; until then, keep text confirmations off.
• Keep your existing number as the primary on your Google Business Profile and website while you're forwarding. Nothing public changes in week two.
• Record the old voicemail greeting and keep a copy. It's part of your rollback.

Week 3: The test-call script

Give this to two or three staff. Each person runs every line from a real phone, not a browser, and marks pass or fail against the condition. A fail gets a rule fix, then the whole script runs again, not just the line that failed. Changes have side effects.

Add your own lines for the rare but critical call types you found in the week one audit. A law firm might add a caller who is the opposing party. A dental office might add a patient describing swelling. A contractor might add a commercial account name, which Jobber's page mentions as an example of an escalation keyword.

Week 3: What passing means

I'd set the bar at every line passing, twice in a row, from at least two testers. Not most lines. The ones that fail on launch day are the ones that were "mostly fine" in testing.

Keep the script. It's your regression suite for the life of the receptionist: every time someone changes a rule, a price or the hours, the script runs again. Retell's documentation says the same thing in its own words, recommending a checklist of critical paths, both happy paths and edge cases, run before every deployment.

Week 3: Checklist

• Run the text or chat test first to catch knowledge and rule errors cheaply.
• Run the full script by phone, from at least two testers, until every line passes twice.
• Test every transfer destination during hours and after hours, including one where the destination doesn't answer.
• Confirm bookings appear on the calendar with the right name, number, service and time.
• Confirm a text arrives from the registered number, if 10DLC approval has landed.
• Listen to the first ten seconds of five recordings: AI disclosure and recording disclosure both present.
• Write down the rollback steps and have the launch owner do each one once, on a test number or after hours.

Week 4: Stage one, after hours only

Route calls to the receptionist only when you're closed. On a hosted system, that's the closed hours rule. On a mobile or landline, it can be as simple as turning on forwarding when you lock up and off when you open, for a few days. Jobber's page describes routing after hours or after a set number of rings, which is the same idea built in.

After hours is the right first stage because the alternative is voicemail. If the AI makes a mistake, it's being compared with nothing, and you have the whole next morning to read every transcript.

Week 4: Stage two, overflow during hours

Next, conditional forwarding during business hours: the phone rings your staff first, and only unanswered or busy calls go to the AI. Verizon's star 71, the GSM no-answer code, or RingCentral's "if no answer" rule all do this. Now the AI is handling the calls that used to fall through while someone was on another line or at lunch.

This stage is where most small offices should stay. The person answers the calls a person is good at, and the AI catches what she can't reach. Our cost comparison of AI and human receptionists makes the money case for exactly this setup.

Week 4: Stage three, AI answers first

Only if overflow has run clean for a while would I consider sending every call to the AI first, with transfers to staff for anything in the must hand over list. Some businesses want this, such as a solo contractor who is on a roof all day. Many never need it. It isn't a graduation; it's a different design.

Week 4: Monitoring while live

Read transcripts every day in week four. Not a sample: all of them, if volume allows. RingCentral provides transcripts and analytics for its receptionist. Housecall Pro says CSR AI summarizes each call and notifies you. Weave says its receptionist routes calls with a summary of the conversation. Whatever your product gives you, somebody reads it daily this week.

• Every transferred call: did the person who picked up have the context?
• Every call where the caller asked for a person or hung up early: what happened just before?
• Every booking: is it on the calendar, correct, and not a duplicate?
• Every urgent keyword call: did a human hear about it within the time your rule says?
• Anything the AI said that isn't in your knowledge base: that's a rule to tighten today.