Emergency Call-Out Workflow

Emergency work is the most profitable hour a home services business sells, and the easiest hour to lose. A tank lets go at nine at night, a heat pump dies in a cold snap, a breaker panel starts tripping and smelling hot. The homeowner is not shopping; they are dialling. They will ring three numbers in four minutes and give the job to whoever answers with a human voice and a time. If the first call lands in voicemail, that caller is gone before the greeting finishes, and nobody in the business ever learns the call happened.

The businesses that do answer usually lose the job one step later, in the handoff. The dispatcher texts whoever they think is on call tonight. That tech is asleep, driving, or under a sink with wet gloves on. No reply comes back. Nobody is watching the clock, because watching the clock is not anyone's job at that hour. Twenty minutes later someone notices, texts a second tech, and the cycle repeats. By the time a van is moving the homeowner has already booked a competitor, or has accepted the job and is now furious about an arrival window nobody confirmed. Either way the premium that justifies working after hours has been spent on apology instead of margin.

The deeper leak is that none of it is measured. Ask most operators how many emergency calls came in last month, how many were accepted, what the median gap was between call and tech assigned, and how many went unfilled, and the answer is a shrug and an anecdote. Without those four numbers the on-call rota is staffed by guesswork, the call-out premium is set by habit, and one willing tech quietly absorbs every weekend until they resign. This build closes the loop: every urgent inquiry becomes a record within seconds, gets triaged on severity, is offered to on-call staff on a timed ladder that escalates on silence, and is reported on afterwards whether it was won, declined or never filled.

Pipeline and stages

One pipeline, Emergency Dispatch, kept separate from the normal sales pipeline so urgent work never queues behind open quotes. Stages in order:

• Call Received: the record exists and nothing has been judged yet. Every inbound urgent contact lands here within seconds, including abandoned and voicemail-only calls.
• Triaged: severity set, address captured, access notes taken, safety script delivered where it applies.
• Dispatch Offered: the job has been pushed to on-call staff and the clock is running.
• Accepted: a tech has claimed it and submitted an ETA.
• En Route: departure confirmed and the customer has been told a time.
• On Site: arrival confirmed.
• Completed: work finished and the debrief form submitted.
• Declined by Customer: they heard the call-out terms and chose to wait for normal hours. A logged outcome, not a deleted record.
• Referred Out: wrong trade, outside the service area, or a utility emergency the business should not touch.
• Unfilled: the escalation ladder ran out of people. This stage exists purely so unfilled work is visible instead of invisible.

Calendars

• On-Call Rota: a team calendar whose only job is to say who owns tonight. Each shift is an event with the on-call tech as the assigned user, so workflows read the current owner from the calendar rather than from a hard-coded list that nobody remembers to update.
• Emergency Response Slots: a service calendar with short slots, no minimum notice and no booking limit, used to put a real block on the tech's day the moment a job is accepted.
• Next-Day Triage: a service calendar for the can-wait branch, with the first two slots of each working day held back for exactly this traffic.

Custom fields

• Emergency Type: single select: No Heat, No Hot Water, Burst or Leaking Pipe, Blocked Drain or Sewage Backup, No Power, Burning Smell or Sparking, Gas Smell, Lock-Out, Storm or Water Damage, Other.
• Severity: single select: Critical (life-safety or active flooding), Urgent (same day), Can Wait (next working day).
• Service Address, Access Notes (gate code, dogs, parking, which door), Property Type, Tenant or Owner.
• Isolation Confirmed: checkbox, set only when the caller confirms water, gas or power has actually been isolated per the scripted steps.
• Callback Number: captured explicitly, because the number that called in is often not the number the person will answer.
• Call-Out Terms Acknowledged: checkbox, set only when the caller confirms they accept after-hours call-out terms as read to them.
• On-Call Tech, Dispatch Offered At, Dispatch Accepted At, ETA Given, Arrived At.
• Escalation Level: number, 0 to 3, incremented each time the ladder advances.
• Source Channel: Inbound Call, Missed Call, Web Chat, Web Form, SMS, Referral Partner.
• Outcome Reason: short text, set on Declined, Referred Out and Unfilled so reporting has something to group by.

Tags

• emergency on every record in this pipeline. The master switch other automations read.
• after-hours applied when the inquiry lands outside published opening hours.
• severity-critical, severity-urgent, severity-can-wait.
• dispatch-accepted, dispatch-escalated, dispatch-unfilled.
• safety-script-delivered: the audit trail proving the isolation instructions were read out.
• repeat-emergency applied automatically on a second emergency record at the same address inside ninety days.
• callout-declined, referred-out.
• no-sms honoured globally: any contact carrying it gets voice and email only, with no exceptions written into any workflow.

Forms

• Emergency Intake: the single source of truth, used three ways: embedded on the emergency landing page, filled by BO from a voice or chat conversation, and opened by a dispatcher while still on the phone. Conditional logic drives the safety script, choosing Gas Smell or Burning Smell reveals a mandatory isolation-instruction block and an acknowledgement checkbox that must be ticked before the form will submit.
• Dispatch Response: a two-question form the tech opens from the dispatch SMS: Accept or Decline, and if accepting, ETA in minutes. Submitting writes Dispatch Accepted At and ETA Given and advances the stage, which means acceptance is a timestamped event rather than a text message someone has to interpret.
• Job Debrief: completed on site: work done, parts used, follow-up needed, whether the fault is likely to recur, and whether the property is a candidate for a service plan.

BO's role and guardrails

BO answers the emergency line and the web chat when no human picks up inside four rings, and answers everything that arrives outside opening hours. BO's job is triage and capture, never diagnosis.

• BO establishes, in this order: whether anyone is in danger, what is happening, the service address, the callback number, and access notes.
• BO reads the scripted isolation steps for the chosen Emergency Type and sets Isolation Confirmed only on an explicit yes.
• On a suspected gas leak or active electrical fire BO stops triage entirely, delivers the emergency-services and utility instruction, tags the record severity-critical, and escalates to a live human immediately instead of finishing the form.
• BO never diagnoses a fault, never estimates a repair and never states a price or a call-out charge. BO says that after-hours call-out terms apply, confirms the customer accepts them in principle, and says the attending tech will confirm the detail before any work starts. Anything further goes to the duty manager or a booked call at bookings.appbo.io.
• BO never promises an arrival time. Only a tech's submitted ETA produces a time, and it is the workflow that sends it.
• BO hands off to a human on request, on a second repeat of the same question, or on any sign of distress.

Numbers and channels

• The published main line, with a ring group of office staff during opening hours and a time-based route into the on-call flow outside them.
• A dedicated emergency number used on vehicle livery and the emergency landing page, so emergency volume reports separately from general inquiries.
• An on-call ring group containing only the user assigned to tonight's rota event, with a whisper message announcing an after-hours emergency call so the tech knows what they are picking up before they speak.
• Voicemail with transcription on every branch, and missed-call capture on both numbers. The abandoned call is the record this build cares most about.
• Outbound SMS from the business number for customer updates, and the same number for tech dispatch so every reply threads into one inbox.
• Internal notifications into a dispatch channel in Slack or Microsoft Teams, so the ladder is visible to whoever happens to be awake.

1. It is 9:40pm. A homeowner rings the emergency number. The time-based route sees that opening hours have passed, plays a short greeting confirming that after-hours emergency cover is live, and connects the call to BO.
2. BO asks first whether anyone is in danger, then what is happening. The caller says water is coming through the kitchen ceiling. BO sets Emergency Type to Burst or Leaking Pipe and Severity to Critical because flooding is active.
3. BO reads the isolation script: find the main stopcock, turn it clockwise, and do not touch anything electrical in the affected room. The caller confirms the water is off. BO sets Isolation Confirmed and the record is tagged safety-script-delivered.
4. BO captures the Service Address, the Callback Number, and Access Notes: side gate, dog in the garden, park on the verge. BO states that after-hours call-out terms apply and that the attending tech will confirm the detail before starting work. The caller agrees and Call-Out Terms Acknowledged is set.
5. The Emergency Intake form submits. An opportunity is created in Emergency Dispatch at Call Received, immediately moved to Triaged, tagged emergency, after-hours and severity-critical. Source Channel is set to Inbound Call.
6. The dispatch workflow reads the On-Call Rota calendar, finds the event covering right now, and takes its assigned user as the On-Call Tech. The stage moves to Dispatch Offered and Dispatch Offered At is stamped.
7. That tech gets an SMS and a simultaneous call to their mobile. The SMS carries the address, the emergency type, the access notes and a link to the Dispatch Response form. The dispatch channel in Slack gets the same summary so it is visible to anyone awake.
8. No response after four minutes. Escalation Level increments to 1, the record is tagged dispatch-escalated, and the offer goes out to the second name on the rota alongside a repeat to the first.
9. The second tech opens the link, taps Accept, and types 35 minutes. Dispatch Accepted At and ETA Given are written, On-Call Tech is overwritten with whoever accepted, the stage moves to Accepted, dispatch-accepted is applied, and the ladder stops dead.
10. The customer gets the first message they have received that contains a time: the tech's name, the thirty-five minute window, and the number to reply to. A block appears on the Emergency Response Slots calendar so the morning schedule already reflects a tech who worked half the night.
11. The tech taps the En Route link in their dispatch thread. The stage moves to En Route and the customer gets a short departure message.
12. On arrival the tech taps Arrived. Arrived At is stamped and the stage moves to On Site. The gap between Dispatch Offered At and Arrived At is now a reportable number rather than a guess.
13. Work finished, the tech submits the Job Debrief. They flag that the pipework is old and likely to fail again, and that the property is a service-plan candidate. The stage moves to Completed.
14. Ninety minutes after completion the customer gets a review request. The next working morning the office sees a task to follow up on the recurring-fault flag, and because the debrief marked the property as a plan candidate the contact is added to the service-plan nurture segment.

1. Emergency Intake and Triage

Trigger: any of: Emergency Intake form submitted; inbound call on the emergency number answered by BO; missed or abandoned call on the emergency or main number; inbound SMS or web chat whose first message contains a triage keyword (emergency, urgent, flooding, flood, leak, burst, no heat, no hot water, no power, sparking, burning, gas, smell, sewage, blocked).

Conditions and branches: first branch on whether the current time falls inside published opening hours. Second branch on Severity. Third branch on whether a contact already exists at this Service Address.

Actions in order:

1. Create or match the contact on phone number first, then email, then address. Never create a duplicate for a repeat address. A second emergency at a known property is the most valuable signal in this build.
2. Create an opportunity in Emergency Dispatch at Call Received. Apply emergency. Set Source Channel from the trigger.
3. If outside opening hours, apply after-hours.
4. Apply the severity tag matching Severity.
5. If Emergency Type is Gas Smell or Burning Smell or Sparking: set Severity to Critical regardless of what was selected, and jump immediately to workflow 2 with Escalation Level pre-set to 1 so the first offer goes to two people at once.
6. If a prior opportunity exists on this contact or address with the emergency tag and a creation date inside the last ninety days, apply repeat-emergency and add an internal note naming the earlier job.
7. Move the stage to Triaged.
8. Branch on Severity. Critical and Urgent continue into workflow 2 with no wait. Can Wait exits this workflow and enters workflow 6.
9. Send the customer a single holding SMS, sent once and never repeated: "Thanks. We have your details for {{Service Address}} and we are getting a technician assigned now. You will get a text with their name and arrival time as soon as it is confirmed. Reply here if anything changes."
10. Post the full record to the dispatch channel: address, emergency type, severity, isolation confirmed yes or no, access notes, callback number.

Stop and exit conditions: exits on entering workflow 2 or 6. If the trigger was a missed call with no form submission and no name, the record still persists at Call Received and workflow 5 owns it. Goal: stage is no longer Call Received.

2. On-Call Dispatch Offer with Escalation Ladder

Trigger: opportunity stage changes to Triaged with Severity of Critical or Urgent.

Conditions and branches: the ladder has four rungs, and each rung is a wait followed by a check of whether Dispatch Accepted At has been written. Wait durations differ by severity: Critical uses three minutes per rung, Urgent uses six.

Actions in order:

1. Read the On-Call Rota calendar for the event covering the current timestamp. Write its assigned user into On-Call Tech. If no event covers now, set Escalation Level to 3 and skip to step 10.
2. Stamp Dispatch Offered At. Move the stage to Dispatch Offered. Set Escalation Level to 0 unless workflow 1 pre-set it.
3. Send dispatch SMS to On-Call Tech: "EMERGENCY: {{Emergency Type}} at {{Service Address}}. Severity {{Severity}}. Access: {{Access Notes}}. Accept or decline here: {{Dispatch Response link}}"
4. Simultaneously place an outbound call to the same tech with a whisper message announcing an after-hours emergency, so a sleeping phone gets two chances.
5. Wait the rung interval. Check Dispatch Accepted At. If written, exit to workflow 3.
6. Increment Escalation Level to 1. Apply dispatch-escalated. Send the same dispatch SMS to the second name in the escalation order and resend to the first.
7. Wait the rung interval. Check again. If accepted, exit to workflow 3.
8. Increment Escalation Level to 2. Send to every remaining tech in the escalation order at once, plus a message into the dispatch channel reading "Unclaimed emergency, level 2, {{Service Address}}".
9. Wait the rung interval. Check again. If accepted, exit to workflow 3.
10. Increment Escalation Level to 3. Call the owner or duty manager directly, twice, sixty seconds apart, and send them an SMS. Exit to workflow 4.

Stop and exit conditions: stops the instant Dispatch Accepted At is written. Every rung re-checks this, so a late acceptance mid-ladder still halts it. Also stops if the stage becomes Declined by Customer or Referred Out. A declined Dispatch Response from a tech does not advance the rung by itself; it only removes that tech from the next rung's recipients and posts the decline reason to the dispatch channel.

3. Acceptance, ETA and En-Route Updates

Trigger: Dispatch Response form submitted with Accept.

Conditions and branches: branch on whether Dispatch Accepted At is already set. If it is, a second tech has accepted a job already claimed, so thank them, tell them it is covered, and exit without changing anything. This guard matters at level 2, where several people get the offer at once.

Actions in order:

1. Stamp Dispatch Accepted At. Write ETA Given from the form. Overwrite On-Call Tech with the submitting user. Apply dispatch-accepted.
2. Move the stage to Accepted. Assign the opportunity owner to the accepting tech.
3. Create a booking on Emergency Response Slots at now plus ETA Given, so the block exists on the tech's synced calendar and tomorrow's schedule shows what tonight cost.
4. Send the customer: "{{Tech first name}} is assigned to your {{Emergency Type}} and expects to be with you in about {{ETA Given}} minutes. They will text when they set off. Reply to this message if you need to reach us."
5. Post acceptance to the dispatch channel with the time from offer to acceptance, so the ladder's performance is visible without opening a report.
6. Wait until the tech taps the En Route link. On that event move the stage to En Route and send: "{{Tech first name}} is on the way to you now."
7. Wait fifteen minutes past ETA Given. If the stage is still En Route and Arrived At is empty, send the customer: "Quick update: {{Tech first name}} is running a little behind. We will text again as soon as they are close." Notify the duty manager in the same step.
8. On the tech tapping Arrived, stamp Arrived At, move the stage to On Site, and stop all customer timing messages.

Stop and exit conditions: exits when the stage reaches On Site, or if the customer cancels, in which case the stage goes to Declined by Customer, the calendar block is released and the tech is told to stand down. Hard cap: if nothing advances for four hours, close the instance and raise an owner task rather than leaving a live timer running overnight.

4. Unfilled Emergency Escalation

Trigger: Escalation Level reaches 3 with Dispatch Accepted At still empty.

Conditions and branches: branch on whether the owner responds within ten minutes.

Actions in order:

1. Apply dispatch-unfilled. Move the stage to Unfilled. Set Outcome Reason to "No on-call acceptance after full ladder".
2. Call the owner. If unanswered, wait sixty seconds and call again. Send an SMS carrying the address and the full offer history.
3. Post to the dispatch channel with an explicit ask for a named decision: cover it, subcontract it, or tell the customer honestly.
4. Wait ten minutes. If the stage is still Unfilled, send the customer an honest message rather than silence: "We have not been able to get a technician to you tonight and we do not want to leave you waiting without knowing. If this is a gas, electrical or flooding emergency please contact your utility or emergency services now. We will call you first thing to get you booked in."
5. Create a high-priority task on the owner for the next working morning: review the unfilled job and the rota that produced it.
6. Add the contact to a goodwill follow-up segment so the next working day's outreach is a call from a human, not a marketing email.

Stop and exit conditions: stops immediately if any Dispatch Response Accept arrives, in which case the stage reverts to Accepted, dispatch-unfilled is removed and workflow 3 takes over. Stops if the owner manually moves the stage.

5. Missed and Abandoned Call Recovery

Trigger: missed call, abandoned call, or voicemail left on the emergency or main number with no Emergency Intake form submitted inside two minutes.

Conditions and branches: branch on whether the caller ID is a known contact, and on whether a voicemail transcript exists. Suppress entirely if the number carries no-sms, in which case the branch calls back instead.

Actions in order:

1. Create or match the contact and create an opportunity at Call Received tagged emergency, with Source Channel set to Missed Call.
2. Within thirty seconds send: "Sorry we missed you. This is {{Business name}}. If this is an emergency, reply here with your address and what is happening and we will get someone assigned. Or call us straight back on this number."
3. If a voicemail transcript exists, run an AI step inside the workflow to classify it into an Emergency Type and a Severity and write both to the record. Post the transcript and the classification to the dispatch channel.
4. If the classification returns Critical, do not wait for a reply. Place an outbound call to the caller immediately and, if unanswered, enter workflow 2 on the basis of the voicemail alone.
5. Wait three minutes. If no reply and no inbound call, place an automated callback that connects to BO, so the caller gets a voice rather than another text.
6. Wait five minutes. If still nothing, send one final SMS: "We are still here if you need us: just reply with your address."
7. Wait thirty minutes. If the record is still at Call Received with no contact made, set Outcome Reason to "No contact after missed call" and leave it in place for the morning review rather than deleting it.

Stop and exit conditions: stops on any inbound reply, any inbound call from that number, or any Emergency Intake submission, all of which hand the record to workflow 1. Caps at three outbound messages per record, and never re-enters for the same number inside one hour.

6. Can-Wait Routing to Next-Day Triage

Trigger: Severity set to Can Wait on an opportunity in Emergency Dispatch.

Conditions and branches: branch on whether the customer, when offered the choice, wants a tech tonight under call-out terms anyway.

Actions in order:

1. Apply severity-can-wait. Send: "From what you have described this is safe to leave until morning, which saves you our after-hours call-out terms. Here are tomorrow's first available slots: {{Next-Day Triage booking link}}. If you would rather someone came out tonight, reply NOW and we will arrange it."
2. Wait ten minutes. If the reply is NOW, set Severity to Urgent, set Call-Out Terms Acknowledged, and enter workflow 2.
3. If a booking is made on Next-Day Triage, move the stage to Accepted, confirm by SMS and email, and enter the standard appointment reminder ladder.
4. If no booking and no reply after forty-five minutes, create a task for the office to call this contact at opening time, and send: "We will give you a ring first thing to get you booked in."
5. At opening time the next working day, if the stage has not advanced, notify the office and leave the record visible rather than letting it age quietly.

Stop and exit conditions: stops on booking, on escalation to Urgent, or on the stage moving to Declined by Customer. Maximum two outbound messages before a human task takes over.

7. Post-Emergency Debrief, Invoice and Review

Trigger: Job Debrief form submitted, or stage moved to Completed.

Conditions and branches: branch on the debrief answers for follow-up needed, likely to recur, and service-plan candidate. Branch on whether payment was taken on site.

Actions in order:

1. Move the stage to Completed if the debrief triggered the workflow. Attach the debrief answers to the opportunity.
2. If payment was not taken on site, generate the invoice and send a payment link by SMS and email through Stripe: "Thanks for having us out tonight. Here is your invoice for the work {{Tech first name}} carried out: {{payment link}}." Push the invoice to QuickBooks or Xero.
3. Wait three days. If unpaid, send one reminder and create a task for the office. Do not run a dunning sequence off the back of an emergency without the owner seeing it first.
4. If follow-up work is needed, create an opportunity in the normal sales pipeline at the quoting stage, carry the debrief notes across, and assign it to the attending tech.
5. Wait ninety minutes from completion, then (subject to quiet hours, deferring to the next permitted send window if necessary) send the review request: "Hope everything is holding up. {{Tech first name}} mentioned you had a rough night. If we got you sorted, a quick review really helps us: {{review link}}."
6. If the debrief flagged likely to recur, add a note to the contact and create a task for the office to call within three working days about a permanent fix.
7. If the debrief flagged service-plan candidate, or if repeat-emergency is present, add the contact to the service-plan nurture segment and let the membership build take it from there.
8. Wait fourteen days, then send a single check-in: "Just checking the {{Emergency Type}} repair is still holding. Reply if anything has changed."

Stop and exit conditions: stops if the contact gains no-sms or unsubscribes, if the review request bounces, or if the office marks the job disputed. In which case all automated sends halt and the record goes to the owner. Review requests are suppressed entirely where the stage reached Unfilled at any point, because asking for a review after a night of waiting is worse than asking for nothing.

The first change is that the abandoned call stops being invisible. Every urgent contact exists as a record within seconds of arriving, including the ones where the caller hung up during the greeting, which means the recovery workflow gets a shot at jobs that previously left no trace at all.

The second is that dispatch stops depending on one person's alertness. The ladder runs whether or not a dispatcher is awake: it reads the rota, offers the job, waits a fixed interval, escalates, and eventually wakes the owner. Nobody has to remember to chase, and the on-call tech no longer gets personally blamed for a text they never saw, because acceptance is a timestamped form submission instead of a message someone has to interpret.

The third is that the customer hears a time, once, from a system that knows the time is real. BO is explicitly barred from promising arrival, so the only ETA a customer ever receives is one a tech typed in. That single rule removes most of the complaint volume that after-hours work generates.

Metrics to watch, all of them available from the pipeline and the call reporting once the fields above are being written:

• Emergency capture rate: records created in Emergency Dispatch divided by total inbound calls on the emergency and main numbers outside opening hours. This should approach complete coverage.
• Median time from Call Received to Dispatch Accepted, and the same figure at the ninetieth percentile. The median tells you whether the ladder works; the tail tells you whether the rota is deep enough.
• Escalation distribution: the share of jobs accepted at level 0, 1, 2 and 3. A rising share accepted at level 2 or above is the earliest signal that the first name on the rota is burning out.
• Unfilled rate: records reaching Unfilled as a share of all Dispatch Offered. This is the number that justifies hiring or widening the rota, and before this build it did not exist.
• ETA accuracy: the gap between ETA Given and Arrived At. Persistent overshoot means techs are being optimistic and the customer message needs padding.
• Declined-by-customer rate, split by Emergency Type: which emergencies people will wait on, which they will not, and therefore where after-hours cover actually earns its keep.
• Repeat-emergency count: addresses tagged repeat-emergency. Each one is a service-plan conversation the business has already paid to earn.

Prerequisites inside the platform

• Published opening hours configured accurately, including public holidays, because every after-hours branch in this build reads them. A wrong holiday calendar sends daytime calls to BO and nobody notices for a week.
• Staff set up as users with their real cell numbers, and the On-Call Rota calendar populated at least four weeks ahead. The ladder reads the rota; an empty rota means every job escalates straight to the owner.
• A named escalation order for levels 1, 2 and 3, agreed with the people on it rather than assigned to them. Level 3 should be the owner or duty manager, and they need to know they are the backstop.
• All custom fields created before any workflow is built, so dispatch actions can write to them rather than being retro-fitted.

Telephony and number provisioning

• Provision the dedicated emergency number early and give it time to settle before it goes on livery or print. Porting an existing emergency line takes longer than people plan for, so run the new number in parallel first.
• Call recording and voicemail transcription enabled on both numbers, with the recording notice configured per local requirement.
• Confirm that simultaneous ring to mobiles works reliably on the carriers your techs actually use, and test it at night, from a sleeping phone, before go-live. Do-not-disturb settings on personal phones defeat dispatch more often than any software problem.

SMS compliance

• A2P and 10DLC registration must be complete and approved before launch. This build is SMS-dependent on both sides (customer updates and tech dispatch) and unregistered traffic gets filtered silently, which in an emergency build means a tech who never learns a job exists. Register the brand and the campaign, and allow weeks rather than days.
• Opt-out handling must be live and honoured automatically. Treat the no-sms tag as absolute: the voice and email fallbacks exist precisely so there is no temptation to carve out an exception for urgent messages.
• Quiet hours are the genuine tension in this build. Marketing and review-request sends must respect quiet hours without exception. Operational messages to a customer who has just called you at midnight, and dispatch messages to staff, are a different category, but where that line sits depends on your jurisdiction and your own terms. Configure quiet hours as suppression on every marketing and reputation workflow, keep operational and internal sends separate, and have the client's own counsel confirm the boundary for their market rather than relying on a general rule.
• Capture consent at the point of intake with language that covers operational messaging about the job, and keep that consent record on the contact.

Integrations

• Google Calendar or Microsoft 365 connected for two-way sync, so rota events and emergency blocks appear on the phones techs already look at.
• Slack or Microsoft Teams connected for the dispatch channel.
• Payments connected through Stripe if deposits or on-site card payment are part of the call-out process, and QuickBooks or Xero if the invoice should land in the books without re-keying.
• Where a field-service or job-management system is already in use, decide deliberately which system owns the job record. Running dispatch here and scheduling there works, but only if one of them is authoritative; an inbound or outbound webhook keeps them aligned.

Safety, liability and data

• The isolation scripts BO reads out are safety instructions given to a member of the public. Have them written or approved by someone qualified in the relevant trade, version them, and keep a record of which version was live on any given date. The safety-script-delivered tag is part of that record.
• Define the hard stops in writing: suspected gas leak, electrical fire, carbon monoxide, structural risk, or anyone injured. On those, BO's only job is to direct the caller to emergency services and the relevant utility and escalate to a human. Do not let a triage script become a substitute for that call.
• Call recordings, transcripts, addresses and access notes are sensitive. Gate codes and key-safe details in Access Notes deserve particular care: restrict field visibility by role, set a retention period for recordings and transcripts, and make sure departing staff lose access.
• Nothing here is legal advice. Consent wording, recording notices, quiet-hours treatment of operational messages, retention periods and the scope of safety instructions should all be confirmed with the client's own counsel and their insurer before go-live.