On this page
Most local service teams have a daytime script. Very few have an after-hours one. The gap shows up on a Friday at 9:40 PM, when a homeowner sends a message from a phone in a dark garage and gets nothing back until Monday.
The temptation is to solve this by reusing the daytime script after dark. That does not work, and the reason is structural rather than cosmetic. During business hours, an inquiry lands in a room where someone can look at the board, check who is free, and commit to something. After hours, none of that is true. The person or system replying usually cannot confirm a technician, cannot see who picked up the last emergency, and cannot promise a time. If the reply pretends otherwise, you have not won the job. You have created a broken promise that your morning crew inherits.
An after-hours playbook is a separate operating document with its own rules about what can be said, what must be asked, who gets woken up, and what happens at 7 AM.
Start by defining what "after hours" actually means
"After hours" is not one thing. Write it down explicitly, per location, before you write a single reply template.
At minimum, define weekday evenings, weekday overnight, Saturday, Sunday, recognized holidays, and temporary closures such as a shop day, a storm, or a week when half the crew is out. Each of these can have different capacity. A Saturday morning is often nearly a business day. A Sunday overnight is usually not.
Make sure the hours you publish match the hours you actually operate. If you advertise on Google Local Services Ads, your listed business hours affect when your ads can show and when leads arrive, and Google documents how to edit your business hours directly. If you are new to that channel, the Local Services Ads overview explains how those leads reach you in the first place. Listing 24/7 availability you cannot staff is the fastest way to generate inquiries you will answer badly.
Separate acknowledgement from availability
This is the single rule that protects you most after dark.
Acknowledgement means: we received your message, we understand what you are asking, and here is what happens next. Availability means: a technician is assigned, or an appointment exists. These are different statements, and after hours you are almost always in a position to make the first one and not the second.
So the reply never says "someone is on the way," never says "you are booked for 8 AM," and never implies dispatch has happened, unless a human has actually confirmed it. It can say that the request is logged, that the on-call lead has been notified, and when the customer can expect a human answer. Truthful and fast beats generous and wrong.
Build three routes, not one
Sort every after-hours inquiry into one of three routes, and write different behavior for each.
Route 1: routine. A quote request, a scheduling question, a maintenance job, a "how much for" message. Nothing is failing right now. Acknowledge, capture the basics, and set a clear next-morning expectation. Nobody gets woken up.
Route 2: urgent but not a safety issue. No cooling in August, a stopped-up main drain, a garage door stuck open, a lockout on a cold night. There is real pressure but no danger. Acknowledge, ask the one question that determines whether this is tonight or tomorrow, and notify on-call according to your escalation rules.
Route 3: safety or emergency. Gas smell, active flooding, sparking panel, anything involving fire, carbon monoxide, or injury risk. Here the reply gets shorter, not longer. Tell the customer to contact emergency services or their utility if there is immediate danger, and escalate to a human right away. Do not attempt to qualify, quote, or schedule on this route. Your playbook should name the specific triggers for it in plain language so there is no interpretation required.
Write the trigger words for each route down. "Urgent" is not a category until you list what counts.
What the first reply has to accomplish
Four things, in one short message.
- Acknowledge. Name the channel and the request so the customer knows a real system received it, not a void.
- Restate known context. Repeat the service type, the neighborhood, or the detail they already gave. This is the difference between a template and a response.
- Ask one decision-changing question. Not five. One question whose answer changes what happens next: is water still running, is there heat in the house at all, is the vehicle drivable. Everything else can wait for morning.
- Set a truthful expectation. A real window, stated in the customer's terms. "A team member will follow up between 7 and 9 AM" is a commitment you can keep. "Shortly" is not.
If a reply does all four in under sixty words, it is working.
Rules for what can and cannot be quoted
After hours is where pricing discipline breaks down, so make the boundaries explicit in writing.
Safe to state: the services you offer, your service area, published rate-card items, whether a diagnostic or trip fee applies and how much it is, and standing promotions with their conditions. These are facts that do not change based on who is on shift.
Not safe to state: a total job price before anyone has seen the work, a discount that is not on the published list, a firm arrival time, or a guarantee about outcome or timing. Anything outside the rate card should be framed as an estimate that a human will confirm. This is a configuration decision as much as a policy one, and the AI customization controls exist so those boundaries are enforced the same way at 2 AM as at 2 PM.
Escalation, on-call, and quiet hours
Escalation rules should answer four questions without anyone having to think: who is on call tonight, what triggers a notification, what triggers a phone call rather than a notification, and what happens if the first person does not respond within a defined number of minutes.
Quiet hours matter too. If everything pages the owner, nothing does. Route 1 leads should queue silently. Route 2 should notify on-call through the channel that person actually watches. Route 3 should escalate immediately and repeatedly until acknowledged. Give every escalation a defined fallback so that an unanswered alert becomes someone else's alert rather than a dropped lead.
Human takeover should be one action, not a process. Whoever picks up the thread needs to be able to step in mid-conversation and continue with the full history in front of them, and the conversational AI side of the workflow is built around that handoff rather than around replacing it.
Preferred time versus actual booking
There is an important distinction here that keeps after-hours promises honest.
Capturing a preferred time is safe. You are recording what the customer wants, and the morning team confirms it. Booking a calendar slot is a commitment, and it should only happen when your system can actually hold that slot against real capacity.
On InstantResponse.AI, full calendar booking is currently in Beta. Until you have it live and tested against your own schedule, run preferred-time capture instead. A customer who says "mornings work best" and gets a confirmation call at 7:30 AM is a happy customer. A customer who was told they were booked and finds out they were not is a refund conversation.
The next-morning handoff
The after-hours playbook is not finished when the sun comes up. Every overnight thread needs to arrive in the morning with the full transcript, the route it was assigned, the question that was asked and answered, and what the customer was told to expect. If your morning person has to reconstruct the conversation, they will re-ask questions the customer already answered, which reads as disorganized.
Set a standing rule: overnight Route 2 and Route 3 threads get worked before the daily board, not after. Those are the customers most likely to have called someone else at midnight.
Test it, then keep editing it
Write five realistic scenarios and run them through your actual setup before you trust it. A midnight lockout. A Sunday afternoon quote request. A holiday no-heat call with an infant in the house. A spam message. A customer outside your service area. Read the replies as a customer would, not as the person who wrote them.
Then review real transcripts weekly for the first month. You are looking for three failure patterns: promises the system should not have made, questions it asked that did not change anything, and moments where a human should have been pulled in sooner. Every one of those is a one-line edit to the playbook. The product overview is a reasonable place to start if you want to see how these pieces fit together in one place.
Implementation checklist
- Define after-hours windows per location, including weekends, holidays, and temporary closures, and match them to your published hours.
- Write the trigger words for routine, urgent, and safety routes.
- Draft one first-reply template per route that acknowledges, restates context, asks one question, and sets a real expectation.
- List exactly what pricing can be stated and what must be an estimate.
- Assign on-call, define notification triggers, quiet hours, and unanswered-alert fallbacks.
- Use preferred-time capture until calendar booking is confirmed against real capacity.
- Require full transcript and route context on every morning handoff.
- Run five test scenarios, then review transcripts weekly and edit.
After hours is not a smaller version of the business day. It is a different set of constraints, and the teams that write those constraints down answer faster without over-promising. Start with the three routes and the honest first reply. The rest of the playbook builds itself from there.