It is 5:07 p.m. A pipe has burst above a customer's kitchen. They call the plumber whose number is already in their phone.
What happens next tells them whether that plumber still has the job.
"Please leave a message after the tone" may be perfectly reasonable for a routine estimate. It is useless when water is coming through a light fixture. The answer is not to wake the owner for every call. The answer is to decide, in advance, which calls deserve to wake them.
Start with the closed-hours greeting
The first message should confirm the business, say that the office is closed, and explain what the system can do. Keep it short. A caller with a flooded basement does not need the company history.
You have reached North Street Plumbing. Our office is closed. If there is immediate danger, leave the property if needed and call 9-1-1. I can check whether your plumbing problem meets our after-hours criteria, take a routine service request, or send a message for the morning team.
If the system records or transcribes the call, disclose that here and state the purpose. The Office of the Privacy Commissioner of Canada says businesses subject to PIPEDA must inform customers about recording, explain why, and obtain consent.
Separate danger from business urgency
"Emergency" is a dangerous word because customers and businesses use it differently. A customer may mean "I need this fixed tonight." Public emergency services mean threats to life, safety, or property that need trained responders.
Put the public-safety instruction first. The CRTC advises callers using 9-1-1 to provide the nature and location of the emergency and notes that VoIP service can have location and outage limitations. A business automation should not intercept or simulate that service.
After that boundary, define the company's urgent conditions. For a plumber, active uncontrolled water may qualify. A dripping tap does not. For property management, fire, active flooding, no heat in severe weather, or a failed exterior lock may qualify. A request for a parking sticker can survive until morning.
Use a six-stage flow
1. Identify the caller
Collect the name, callback number, location, and relationship to the business. Confirm the phone number aloud. Caller ID is useful, but people call from a partner's phone, a hotel, or the neighbour's kitchen while theirs becomes a paddling pool.
2. Classify the reason
Ask one open question: "What is happening?" Then ask only the follow-ups needed to choose a route. A rigid menu can work for predictable calls, but "press 4 for catastrophic mystery" is rarely available.
The system should classify into a small set such as urgent existing customer, routine service request, sales enquiry, billing, supplier, or unknown. Unknown is a valid category. It is much safer than confident invention.
3. Apply customer and location rules
Check whether the caller is an existing customer, whether the address is inside the service area, and whether the contract includes after-hours response. This is also where a VIP bypass code can help. Property managers, key clients, or building staff may need a route that is not advertised to every caller.
Keep bypass codes revocable and do not use them as proof of identity for sensitive account changes. A four-digit code shared among forty tenants is a routing hint, not Fort Knox.
4. Choose the destination
The call should end in one of five places:
- Immediate transfer: the on-call person receives a warm transfer with the collected details.
- Priority alert: the system sends a text or push alert and asks the owner to accept the call.
- Scheduled follow-up: the caller chooses an approved appointment or callback window.
- Morning queue: routine details go into a digest or work list.
- External direction: the caller receives a pre-approved public or vendor number when the business is not the right responder.
Do not transfer first and explain later. The on-call person needs the caller's name, location, problem, and reason the rule fired. Otherwise automation has merely added hold music.
5. Confirm expectations
Tell the caller what happened. "I sent your details to the on-call technician" is different from "a technician is on the way." The second sentence creates a promise that the system may not have authority to make.
Give a realistic response window only if the business can meet it. If timing depends on the on-call person accepting the job, say that. Calm accuracy beats synthetic reassurance.
6. Write the record
Store the caller, timestamp, reason, answers, route chosen, alert result, transfer result, and recording or transcript location. If the transfer fails, the record should say so. "Completed" is not an acceptable status for a call that rang six times and disconnected.
Build the failure path first
Phones go offline. Speech recognition misses addresses. The on-call person sleeps through an alert. APIs fail. Internet services have the occasional character-building evening.
Decide what happens when:
- the caller stays silent;
- the system cannot understand two attempts;
- the caller will not consent to recording;
- the transfer destination does not answer;
- the calendar or customer database is unavailable;
- the call disconnects after an urgent condition is identified.
A sensible fallback may be a plain voicemail, a second on-call number, a human answering service, or an alert containing only the details collected before failure. The caller should never remain trapped in a loop because the computer dislikes their postal code.
A trades example
The plumbing caller reports active water. The flow asks whether the main shutoff can be reached safely, but it does not instruct the caller to enter a dangerous space. It collects the address and callback number, checks the service area, and alerts the on-call technician. If accepted, the call transfers with a short summary. If not, it tries the backup and tells the caller exactly what has and has not been arranged.
A caller asking for a bathroom-renovation estimate follows a different route. The system collects the address, preferred callback time, and rough scope, then places it in the morning sales queue. Nobody gets woken up to discuss tile.
A professional-services example
A law office may need names and contact details but should avoid collecting a detailed confidential history before checking conflicts and consent. An accounting firm may accept document-deadline questions from existing clients while placing new tax-planning enquiries in the next-business-day queue.
The useful design question is not "Can the AI answer this?" It is "What is the safest useful action the system is authorised to take?" Sometimes that action is collecting a number and stopping.
The morning digest closes the loop
Send one clear digest when the office opens. Group calls by urgent, callback promised, routine request, failed automation, and spam. Include direct links to the record and make ownership visible.
Then somebody must work the list. Automation that creates a beautifully formatted queue nobody reads is just voicemail with stationery.
Test it every month
Call from an unknown number after hours. Try an urgent case, a routine case, a mumbled address, a refusal to be recorded, and a failed transfer. Confirm that alerts arrive and that the morning digest contains the truth.
Review misclassified calls and adjust the rules. Do not give the model broader freedom merely because one caller used an unexpected phrase. Better examples and a safe unknown route usually beat a longer prompt with heroic ambitions.
The diagram comes before the robot voice.