A demo number is not a client line

The fastest way to show a voice agent is to hand someone a phone number. The fastest way to make a mess is to hand them the number that already answers for a client.

A demo should sound like the system you actually run. Same voice, same pauses, same habit of saying it does not know instead of guessing. It should not share the client's number, the client's hours, or the client's booking tools. Those are two setups. They can use the same kind of software. They cannot use the same line.

We treat the number that was dialed as the boundary. That number picks the prompt, the calendar, the text sender, and the place recordings go. A later step is not allowed to turn a demo into a live write. Something the caller says is not allowed to turn a live call into a demo.

Two ways the line gets crossed

The obvious cross is a prospect who books a real appointment. You are on a call, you say "try this number," and they do. The agent offers a Tuesday slot because that is what the live calendar has. The prospect says yes, because they are being polite or because they want to hear the confirmation. The booking lands on the client's schedule. In the morning someone on staff is looking at a name they do not know, in a slot a real customer could have had.

The quieter cross runs the other way. A real customer reaches the demo. Maybe the number on the website was swapped for a week and never swapped back. Maybe a forward from the old main line still points at the demo. The agent introduces a sample shop, quotes hours that were written for a sales call, and writes the request somewhere nobody on the client's team looks. The caller hangs up thinking they are on the book. They are not.

Both start from the same shortcut. One number, one webhook, one agent config, because the live build was already there and a demo was due tomorrow. It works for a single happy-path call in a conference room. It does not survive a number that real people can dial.

What stays on which side

The number. Demo calls arrive on a number that exists only for demos. Client calls arrive on the client's number. Buy the demo number in its own project at the phone provider if you can. At minimum, give it a name a stranger would not confuse with the client's main line, and do not list it on the client's site, ads, or Google profile.

The business facts. The demo agent speaks for a made-up shop. Made-up name, made-up hours, made-up address, no real prices, no real staff names. It does not say the client's name. It does not read the client's calendar. If the demo needs to show a booking, it books into a calendar that exists only for demos, and it says so out loud before it commits: this is a sample, nothing was reserved, nobody from a real shop will call you about it.

The write path. A demo call can store a transcript so we can listen later. It cannot create a job, a patient, a lead, or a text to a customer. The webhook for the demo number points at a handler that does not have production credentials. If someone copies a live key into the demo config, the handler should refuse to start, not "work anyway." The live handler should refuse demo credentials the same way. Fail closed on purpose. A shared key with a flag in the prompt will get the flag deleted the next time someone edits the prompt.

The transfer. When the demo agent does not know an answer, it does not transfer to the client's front desk, on-call tech, or owner. It says it cannot help with that on a sample line, and it stops. A note, if you take one, goes to your own inbox. A live line does the opposite. It hands off into the client's queue with the fields their staff already use, and it does not invent a callback time the shop did not agree to.

The recordings. Demo audio and live audio do not share a bucket, a retention rule, or an access list. People on a demo say whatever is on their mind, including names from their own company. Live calls can include customer details the client did not agree to mix with sales recordings. Separate storage is the plain version of keeping that promise. When a demo recording is no longer useful, delete it on a short schedule. Do not leave it next to a year of client calls because the bucket was convenient.

The caller does not get a vote. A person on the live number who says "I'm just testing you" is still a live caller. A person on the demo number who says "book me for real" is still a demo caller. If they need the other path, they need the other number. The agent can explain that. It should not switch projects mid-call.

Label the call before the agent speaks

Write the label at the edge, when the call comes in. Store the dialed number, the config id, and an environment value on the call record before the agent says hello. Every later step reads that record. The transcript viewer, the booking tool, the text sender, and the morning report all refuse to treat a demo row as a live row.

Do not do this inside the prompt. A line that says "if the caller says this is a test, switch to demo mode" is how a real customer gets a fake shop, and how a prospect who never says the magic words gets a real booking. Prompts are the wrong place for a safety boundary. They change every week. The number does not.

Do not keep one prompt and prepend "you are in demo mode." That sentence is the first thing a cleanup edit removes. Give the demo its own prompt, its own tools, and its own secrets. The demo project's tool list should not include the live calendar, the live text sender, or the live CRM. If the tool is not there, the model cannot call it on a bad day.

Keep a small map, written down, of number to environment. When someone adds a new client line, the map gets a row in the same change. When a demo number is retired, remove the forward and the webhook the same day, not after the next sales call. Old forwards are how a "temporary" demo becomes the number customers still have on a card.

What the morning pass looks for

Once a day, before anyone treats the overnight calls as finished work, split them by the number that was dialed. You are not scoring the agent. You are looking for crossings.

• A demo number that created or changed a row in a client calendar, CRM, or job system.
• A live number whose transcript uses the sample shop name, sample address, or sample hours.
• A text or email confirmation sent to a phone number or address captured on a demo call.
• A transfer or callback task from the demo agent aimed at a client desk, on-call phone, or staff inbox.
• A recording from one environment stored in the other environment's bucket.
• A new number that arrived overnight and is not on the map at all.

Any one of those stops the normal review. Fix the route first. Then, if a real booking or a real message already went out, a person calls or writes the affected customer and the client's staff and says what happened. Do not leave that to the next automated pass. The agent already had its turn.

When the numbers are actually separate, this pass is short. Almost every row is obviously in one pile. When one number does both jobs, the pass becomes a listening session, because you cannot tell a test from a customer without the audio. That is a sign the boundary is in the wrong place, not a sign you need a longer meeting.

What to say before they dial

Say it before they call, in the email or the meeting, not as a footer they will not read. This number is a sample. It will not book you with a business. It will not text you a real confirmation. If you want to hear the agent with your hours and your calendar, that is a different setup, on your number, after your data is connected.

The agent should say a short version near the start of the demo call, and again before it pretends to book. Same words every time, so a recording of the demo cannot be mistaken for a confirmation later.

None of this makes the demo less honest. We still run it on the same class of stack as the live line: same voice model, same turn taking, same refusal when it does not know. The demo is there so a person can hear the real agent. The separate number is there so hearing it cannot change a client's book, and so a client's customers cannot wander into a sample shop because a forward was left in place.

If you only have time to set up one control, make it this: the demo project cannot see the live credentials, and the live project cannot see the demo number. Everything else in the morning pass is a check that the control is still true.