What belongs at the start of the instructions?
I put the permitted action first. For a fictional Castaic service office: collect service requests for staff review. Do not confirm appointments or approve exceptions. Then I name the approved service information and transfer procedure. A caller can ask for more. That request does not expand the job I gave the assistant.
I identify the approved source for hours, services, and booking rules. If those facts do not settle a request, the assistant asks for help. Telling it to be helpful at any cost gives me nothing useful to test. I write what help means for this intake job and where the assistant's authority ends.
How do I make instructions specific enough to test?
I write conditions I can observe on a call. A caller wants an appointment: collect the approved details. Required information is missing: ask for it. The calendar has not confirmed: call the request pending. Each instruction needs a visible result. That lets your employee and me check whether the script did its job.
I keep business facts apart from speaking style. Hours and service boundaries belong in the approved information source. Tone instructions can say to speak plainly and ask a question at a time. Mixing facts, policy, and personality into a long paragraph makes a later edit harder to check. I want your hours change easy to find and test.
What would a short instruction example look like?
For a sample intake script, I might write: You collect service requests for staff review. Ask for the caller's name, callback details, requested service, and service location. Read back important details before finishing. Do not promise an appointment. Tell the caller staff will review the request. If the caller asks for a person, use the approved transfer procedure.
That sample is only a starting point. I still need your approved escalation contacts, unsupported services, and fallback when a transfer fails. I also identify information the assistant must never request. Your operating decisions finish this script. Copying an intake example cannot tell the assistant who at your Castaic office should receive an exception.
How do I handle conflicting directions from callers?
A caller may say they own the business or demand that the assistant ignore restrictions. I instruct it to treat that as an unverified claim. Business-rule changes go through the approved management process. A customer-line conversation is not that process. I test whether the assistant keeps the distinction when the caller pushes.
I back the wording with access limits. An intake assistant does not need unrestricted access to unrelated records or account settings. Prompts can fail. Limiting permissions limits what a failed instruction can affect. I check the spoken answer and attempted actions behind it. The voice saying no is not enough if a tool still makes the change.
What should I test before I trust the script?
For a test call, I change the fictional caller's callback details halfway through. The assistant must confirm the correction and put the right value in the final record. Then I ask for an appointment it cannot approve. I inspect its closing sentence. Collecting a request must not accidentally sound like confirming a booking.
I test interruptions, silence, failed transfers, and an unverified employee request. I also cover how the assistant identifies its role to callers. For recording, consent, privacy, or calling-law questions, talk to your attorney for your situation. I have the approved wording reviewed before enabling those features. A phone script needs those decisions settled before use.
How would I maintain the instructions after launch?
I keep a named owner, version history, and change review. If business hours change, that owner updates the approved source and repeats the hours tests. If a transfer destination changes, someone has to answer a test transfer. I do not call a new destination ready just because its number was saved in the instructions.
I build the initial instructions with the person handling your phone. I keep the words customers actually use while making the rules explicit. The handoff includes current instructions, their limits, and tests staff can repeat. Your employee needs a way to flag a new exception without quietly inventing a policy to get through the next call.
When I replace a rule, I remove the conflicting old instruction. Adding another paragraph without settling the contradiction leaves the assistant choosing between incompatible procedures. I want one clear direction for the intake action I am asking it to perform.
What else should I know?
- How do I write instructions an AI phone assistant will follow?
- I write the phone assistant's job before its personality: approved facts, allowed actions, required questions, and when a person takes over. Then I test conflicting requests in plain language. My instructions are not a guarantee. I restrict tool access and inspect the resulting records before trusting the script to speak for your business.
- Should I tell the assistant to always be helpful?
- I define the help it may give. The task, refusal boundary, and staff handoff need to be clear. A broad helpfulness instruction can conflict with your business limits.
- Can a prompt replace access restrictions?
- No. I use both. Instructions state the expected behavior. Permissions limit what the assistant can do if it interprets a request incorrectly.
- How should it handle a caller who asks for a person?
- I write the transfer procedure and a fallback for an unreachable person. The assistant explains that the handoff is pending. It must not claim staff has already responded.
- Who should approve a script change?
- I have the designated business owner approve policy or permission changes. The implementer then repeats the relevant call tests and keeps the revised version.