Technician Dispatch and Job Status

In most home services businesses the real schedule lives in three incompatible places: a whiteboard in the office, a group chat on the crew's phones, and the dispatcher's head. The software of record says a job is booked for Tuesday. It does not say that the part did not arrive, that the technician is still on the morning job because the access panel was screwed shut, or that the afternoon customer has now called twice. Nobody is lying; the system simply has no way to represent a job that is in motion.

The customer feels this as silence. They took a day off work, they were given a window, and at 2pm they have no idea whether the crew is coming. So they call. The office cannot answer, because the office does not know either, so someone texts the technician, who is under a house and does not reply for twenty minutes. That one unanswered question generates three phone calls, two interruptions to billable work, and - more often than anyone admits - a review that says nothing about the quality of the repair and everything about the waiting.

The money leaks in four places at once. Billable hours go to status chasing instead of work. Second visits get booked because nobody recorded that a part was needed, so the technician arrives again without it. Invoices go out days late because the completion details sit in a text thread rather than on the job record. And the review request - the single cheapest source of new work a home services business has - gets sent manually to whoever the office happens to remember, usually days after the job, when the customer's goodwill has already cooled. This build makes the job record move as the crew moves, so the status is never a question anyone has to ask.

Pipeline and stages

One pipeline, Jobs, and it is the single source of truth. The design rule is that every stage is something a technician can trigger from their phone in one tap. A stage only a dispatcher can move is a stage that will be wrong by mid-morning.

• Scheduled - on the calendar, not yet dispatched.
• Parts Pending - cannot proceed until a part lands. A branch off Scheduled, not a dead end.
• Dispatched - assigned to a technician for today and released to their day sheet.
• En Route - technician has left the previous site. Fires the on-my-way message.
• On Site - arrived. Starts the on-site clock.
• Work In Progress - diagnosis done, work authorized, tools out.
• Awaiting Customer Decision - extra work found, needs approval before continuing. The most commercially important stage in the pipeline.
• Awaiting Parts On Site - started, stopped, needs a part. Distinct from Parts Pending because the customer's home is already open.
• Work Complete - physical work finished, details captured.
• Invoiced - invoice issued.
• Paid - settled.
• Follow-Up Required - return visit or callback needed, with a reason.
• Canceled, Aborted On Site - the second for jobs that could not proceed after arrival, which is a cost worth seeing separately.

Calendars

• Dispatch Board - one calendar per technician, each a resource with its own working hours, skills and territory. The board is the union of them.
• Job type durations set per service: a service call at 60 minutes, a water heater replacement at 240, a full system install as a multi-day block. Wrong durations here are the root cause of most late-day collapse.
• Travel buffer of 30 minutes after every job, non-bookable.
• Emergency Overflow - a deliberately empty two-hour slot at the end of each technician's day, closed to online booking and opened only by a dispatcher. This is what absorbs the burst pipe without destroying three other appointments.
• Return Visit - a separate calendar for Follow-Up Required jobs, so return work is scheduled rather than squeezed.

Custom fields

On the opportunity unless stated. These are the spine of the build.

• job_number - text, auto-generated, used in every customer message so phone calls have a reference.
• assigned_technician - user reference. second_technician for two-person jobs.
• job_type - single select: Service call, Repair, Replacement, Install, Warranty, Maintenance visit.
• job_address, access_notes, arrival_window.
• dispatched_at, en_route_at, on_site_at, work_complete_at - datetimes, each written by the stage move that reports it. The gaps between these four fields are the only honest operational data the business will ever have.
• eta_minutes - number, set by the technician when they go En Route.
• diagnosis_notes - long text, written on site.
• additional_work_found - checkbox. additional_work_description - long text. additional_work_authorized - single select: Yes, No, Deferred.
• parts_required - long text. parts_eta - date. parts_ordered_by - user reference.
• completion_photos - file. customer_signature - file or confirmation reference.
• invoice_sent_at, payment_received_at - datetimes.
• warranty_expiry - date, written at completion from the job type's warranty term.
• review_requested_at - datetime, so nobody is ever asked twice.
• job_satisfaction - number 1-5 from the completion survey, captured before any public review is requested.

Tags

• job-active - on the contact while any job is between Dispatched and Work Complete. Suppresses all marketing sends. Nothing kills trust faster than a promotional email arriving while a crew is in someone's kitchen.
• job-today, job-en-route, job-on-site - mirror the live stage for quick filtering.
• awaiting-approval - extra work quoted, no decision yet. Drives the escalation.
• parts-hold - waiting on a part, either before or during the job.
• running-late - applied when the current job has overrun its duration by more than 30 minutes.
• second-visit-required, warranty-job, repeat-callback - the last one applied when the same address has two jobs for the same fault inside 90 days. This tag is a quality signal and should be reviewed by a human every week.
• detractor - job_satisfaction of 3 or below. Blocks the public review request and routes to the owner.
• promoter - job_satisfaction of 5. Routes to the public review request.
• sms-opted-out.

Forms

• Technician Arrival Check - one tap: arrived, plus access problem yes or no. Anything longer will not be filled in.
• On-Site Diagnosis - diagnosis_notes, additional_work_found, additional_work_description, parts_required. Submitted before work starts.
• Additional Work Approval - a customer-facing page describing the extra work found, with the technician's photos, and an explicit Approve or Decline. The price is placed on it by the technician or office, never by BO.
• Job Completion - work done, completion_photos, parts used, customer signature, follow-up required yes or no with reason.
• Post-Job Satisfaction - a single question, 1 to 5, sent by text as tappable numbers. This is the gate before any public review ask.

BO's role and guardrails

BO owns customer communication about status. BO owns none of the operational decisions.

• BO answers "where are you?" from the live stage and timestamps - and this is the highest-value thing BO does all day. "{{technician_first_name}} is on site at a job before yours and running about 40 minutes behind. I will text you the moment they are on the way."
• BO never dispatches, never reassigns, never reschedules a job that is already Dispatched. Those go to the dispatcher as a task.
• BO never states a price for additional work found. It sends the approval page the technician prepared and answers scope questions from the description on it. On any pricing question it does not have an answer to, BO gets the technician or office on the line.
• BO never authorizes additional work on a customer's behalf, and never interprets an ambiguous reply as approval. Anything that is not an explicit Approve stays unapproved.
• BO never promises a precise arrival time; it reports eta_minutes as the technician set it, with the word "roughly".
• BO never requests a public review from a contact tagged detractor, and never offers an incentive for a review.
• BO hands off immediately on: any safety concern, any complaint, any dispute about price or work done, any mention of damage to the property, and any insurance or warranty claim.

Numbers and channels

• Customer line - one local number for all job-status messaging, registered for application-to-person SMS. Every message carries job_number.
• Dispatch line - a second number used only for technician-facing traffic, so crew notifications never compete with customer threads in the same inbox.
• Per-technician caller ID masked to the business number on outbound calls, so technicians never expose personal mobiles and the customer sees a number they recognize.
• A technician-facing mobile view of the Jobs pipeline with the stage buttons as the primary interface. If a technician needs more than two taps to report arrival, the data will not be there.
• An internal dispatcher channel - in the platform or mirrored to Slack - carrying only exceptions: running late, awaiting approval, parts hold, aborted on site.

One job that goes slightly wrong - which is the only kind worth walking through, because a job that goes perfectly needs no system.

1. Scheduled. A furnace repair is booked for Wednesday 1-3pm. The opportunity sits in Jobs at Scheduled with job_number assigned, job_type set to Repair, job_address and access_notes carried over from the estimate, and a four-hour duration block on the technician's calendar.
2. Tuesday 4pm - dispatch run. The dispatcher confirms tomorrow's board. Each job moves to Dispatched, dispatched_at is stamped, job-active and job-today go on the contact, and all marketing sends to that contact are suppressed from this moment until completion.
3. Wednesday 7am - day sheets out. The technician gets one message: three jobs in window order, each with address, job_number, job_type, access_notes, the customer's own description, and a map link. The customer gets a short text: "Today, 1-3pm, job {{job_number}}. {{technician_first_name}} will text when on the way."
4. 11:20am - the morning job overruns. The technician is still On Site at a job whose duration expired 35 minutes ago. The overrun watcher applies running-late, posts to the dispatcher channel, and - this is the part that saves the afternoon - sends the 1-3pm customer a message before they wonder: "Heads up on job {{job_number}} - we are running about 40 minutes behind this morning. Still expecting to reach you inside your 1-3pm window. I will confirm when {{technician_first_name}} is on the way."
5. 1:35pm - En Route. The technician taps En Route and enters 20 minutes. en_route_at is stamped, the stage moves, job-en-route goes on, and the customer gets: "{{technician_first_name}} is on the way, roughly 20 minutes out. Job {{job_number}}."
6. 1:55pm - On Site. One tap on the Technician Arrival Check. on_site_at is stamped, the stage moves to On Site, and the customer's thread shows arrival. Nobody called the office.
7. 2:10pm - diagnosis. The technician submits On-Site Diagnosis: the fault is a failed inducer motor, and while in there they find a cracked heat exchanger panel that is not part of the original scope. diagnosis_notes is written, additional_work_found is ticked, additional_work_description is filled in, and two photos are attached.
8. 2:12pm - the approval stage. The job moves to Awaiting Customer Decision, awaiting-approval is applied, and the Additional Work Approval page - the technician's description, their photos, and the price the technician or office put on it - is sent by text and email. The on-site clock keeps running, which is exactly why the next step matters.
9. 2:14pm - the customer approves, in writing. They tap Approve. additional_work_authorized is set to Yes, a timestamped record of the approval is attached to the job, awaiting-approval is removed, and the job moves to Work In Progress. The business now has written authorization for the extra work, which is the difference between an invoice that gets paid and an argument.
10. 2:40pm - the part problem. The replacement panel is not on the truck. The technician moves the job to Awaiting Parts On Site and writes parts_required with a parts_eta of Friday. parts-hold and second-visit-required are applied, the dispatcher channel is notified, and the customer is told plainly: the repair done today is complete, the panel needs ordering, and a return visit will be booked on the Return Visit calendar for Friday.
11. 3:05pm - partial completion. The technician submits Job Completion for today's work: what was done, three completion photos, parts used, and a customer signature on the device. work_complete_at is stamped. Because second-visit-required is set, the job moves to Follow-Up Required rather than Work Complete, and the Friday return visit is booked and confirmed before the technician leaves the driveway.
12. 3:20pm - invoicing the completed portion. The invoice for today's authorized work - including the approved addition - is generated and sent, invoice_sent_at is stamped, and the job's financial state is tracked separately from its physical state.
13. Friday - the return visit. The panel arrives, the return visit runs, and the job finally reaches Work Complete. warranty_expiry is written from the job type's warranty term. job-active comes off the contact and marketing suppression lifts.
14. Friday, two hours after completion - the satisfaction gate. The Post-Job Satisfaction text asks one question: 1 to 5. The customer taps 5. job_satisfaction is written, promoter is applied, and only now is a public review requested - with a direct link and no incentive attached. Had they tapped 3, detractor would have been applied, no review would have been requested, and the owner would have had a task to call them within the hour.
15. Payment and close. Payment lands, payment_received_at is stamped, the job moves to Paid. The record now holds four timestamps, a written approval, photos, a signature and a satisfaction score - which is the whole month's operational reporting, assembled without anyone writing anything down twice.

Nine workflows. Build 1 through 3 first and run them for a week before adding the rest - if the stage moves are not happening reliably on technicians' phones, nothing downstream can work.

1. Dispatch Run and Day Sheets

Trigger A: job stage moves to Dispatched.

1. Stamp dispatched_at. Apply job-active and, if the appointment is today or tomorrow, job-today.
2. Suppress all marketing and nurture sends to this contact while job-active is present. Build this as a global condition on every campaign, not as something to remember.
3. Send the customer SMS - "You are confirmed for {{arrival_window}} on {{job_date}}, job {{job_number}}. {{technician_first_name}} will text when on the way. Reply to this thread any time."

Trigger B: 7:00am daily, per technician with jobs today.

1. Assemble today's jobs in window order. Send the technician one message on the dispatch line: job_number, arrival_window, job_address with map link, job_type, access_notes, the customer's description, and any parts_required already on the record.
2. Flag any job where access_notes is empty, or where parts-hold is still present, so the technician can call before driving.
3. Send the dispatcher a board summary: job count per technician, total scheduled duration against available hours, and any job still at Parts Pending that is scheduled today. That last line catches the most expensive mistake in the trade - dispatching a job whose part never arrived.

Exit: end of day, or job canceled.

2. En Route and On Site Broadcast

Trigger: job stage moves to En Route.

Conditions: requires eta_minutes. If the technician did not enter one, prompt them on the dispatch line and hold the customer message for up to 3 minutes rather than sending a vague one.

1. Stamp en_route_at. Apply job-en-route, remove job-today.
2. Send the customer SMS - "{{technician_first_name}} from {{business_name}} is on the way to you now, roughly {{eta_minutes}} minutes out. Job {{job_number}}."
3. Branch - current time is past the end of arrival_window. Send instead - "Apologies {{first_name}} - we have run past your {{arrival_window}} window today. {{technician_first_name}} is about {{eta_minutes}} minutes out. Reply MOVE if that no longer works and we will rebook you at the front of tomorrow."
4. Wait eta_minutes plus 15. If the stage is still En Route, notify the dispatcher - the technician is either stuck or forgot to tap arrival, and both need a human.

On stage move to On Site: stamp on_site_at, swap job-en-route for job-on-site, start the on-site duration clock, and send - "{{technician_first_name}} has arrived. Job {{job_number}}."

Exit: stage reaches On Site, or job canceled.

3. Overrun Watcher

Trigger: on_site_at stamped. The workflow then watches the clock against the job type's configured duration.

1. Wait until the configured duration has elapsed, plus 30 minutes.
2. If the stage is still On Site, Work In Progress or Awaiting Parts On Site, apply running-late and post to the dispatcher channel: job_number, technician, minutes over, and the next job in that technician's day.
3. Immediately send the next customer in that technician's day - "Heads up on job {{next_job_number}} - we are running about {{minutes_over}} minutes behind today. {{technician_first_name}} still expects to reach you inside your {{arrival_window}} window. I will confirm when they are on the way." The message goes out before the customer wonders, which is the entire point.
4. Wait 45 minutes. If still overrunning and the next job's window is now unreachable, notify the dispatcher to decide: move the last job, send a second technician, or call the customer. BO does not make this call.
5. If the dispatcher moves the job, trigger the reschedule message with a plain apology and a named new window - no explanation of internal causes.

Exit: job moves to Work Complete or Follow-Up Required, or the dispatcher clears running-late.

4. Additional Work Approval

Trigger: On-Site Diagnosis submitted with additional_work_found ticked.

Conditions: the approval page must carry a price entered by the technician or office. If it does not, the workflow holds and notifies the office rather than sending an incomplete page.

1. Move the job to Awaiting Customer Decision. Apply awaiting-approval.
2. Send SMS - "{{first_name}}, {{technician_first_name}} found something while on site at job {{job_number}}. Details and photos here, with the cost: {{approval_link}}. Nothing extra gets done until you approve it." Send the same by email for the record.
3. Notify the dispatcher channel so the office knows a technician is standing still waiting on a decision.
4. Wait 10 minutes. If undecided, BO offers a call: "Want {{technician_first_name}} to walk you through it on the phone? Reply CALL."
5. Wait 20 minutes. If still undecided, notify the office to call the customer directly. An on-site technician waiting is the most expensive idle time in the business.
6. On Approve: set additional_work_authorized to Yes, attach the timestamped approval record to the job, remove awaiting-approval, move to Work In Progress, and notify the technician on the dispatch line.
7. On Decline: set additional_work_authorized to No, move to Work In Progress for the original scope only, and write the decline to the job record so a future failure is not the business's liability.
8. On "not now" or any deferral: set additional_work_authorized to Deferred, continue the original scope, and create a dated follow-up opportunity carrying additional_work_description, so the quote is not lost.

Exit: an explicit decision is recorded. Ambiguity never counts as approval.

5. Parts Hold and Return Visit

Trigger: stage moves to Parts Pending or Awaiting Parts On Site.

1. Apply parts-hold. Require parts_required and parts_eta before the stage move completes - an undated parts hold is how jobs disappear for three weeks.
2. Notify the dispatcher and whoever is named in parts_ordered_by.
3. Send the customer SMS - "Update on job {{job_number}}: {{technician_first_name}} needs {{parts_summary}} to finish this properly. It is on order and expected {{parts_eta}}. I will book your return visit as soon as it lands, or sooner if you would like to pick a window now: {{return_booking_link}}."
4. If triggered from Awaiting Parts On Site: apply second-visit-required and require the technician to book the return visit on the Return Visit calendar before leaving site. Booking it in the driveway is far more reliable than booking it from the office three days later.
5. One day before parts_eta: notify parts_ordered_by to confirm arrival.
6. On parts_eta with no confirmation: escalate to the dispatcher and send the customer an honest update with a revised date. Never let a parts date pass in silence - that silence is what produces the complaint.
7. On parts arrival confirmed: remove parts-hold, notify the customer, and confirm or book the return visit.

Exit: parts received and return visit booked, or job canceled.

6. Completion, Invoice and Payment Chase

Trigger: Job Completion form submitted.

1. Stamp work_complete_at. Write warranty_expiry from the job type's warranty term.
2. Branch - follow-up required ticked: move to Follow-Up Required, apply second-visit-required, and book the return visit before closing the form. Otherwise: move to Work Complete and remove job-active, which lifts marketing suppression.
3. Send the customer a completion summary by email: what was done, the completion photos, parts used, warranty_expiry, and the signature on record. This document prevents most future disputes.
4. Wait 15 minutes. Generate and send the invoice for authorized work only - original scope plus anything with additional_work_authorized of Yes. Stamp invoice_sent_at, move to Invoiced.
5. Wait 3 days. If unpaid, send SMS - "Hi {{first_name}}, invoice for job {{job_number}} is still open. You can settle it here: {{payment_link}}. Any questions, just reply."
6. Wait 4 days. If unpaid, send email with the invoice attached and the completion summary restated.
7. Wait 7 days. If unpaid, create a task for the office to call. Stop automated chasing after this point - a human owns collections, because a fourth automated nudge costs more in goodwill than it recovers.
8. On payment: stamp payment_received_at, move to Paid, and send a short thank-you that does not ask for anything.

Exit: paid, or handed to the office.

7. Satisfaction Gate and Review Routing

Trigger: job reaches Work Complete.

Conditions: exit if review_requested_at is already set, if sms-opted-out is present, or if this job carries warranty-job or repeat-callback - those customers get a call from a human instead.

1. Wait 2 hours, so the technician has actually left and the customer has seen the work.
2. Send the Post-Job Satisfaction SMS - "{{first_name}}, how did we do on job {{job_number}}? Reply 1 to 5, where 5 is great. That is the whole survey."
3. Wait 1 day. On no reply, send once more and then stop. Two asks is the limit.
4. Score 5 - apply promoter. Wait 30 minutes, then send - "That is great to hear, thank you. If you have a moment, a short public review genuinely helps a local business like ours: {{review_link}}." Stamp review_requested_at. Never offer anything in exchange.
5. Score 4 - no public ask. Send - "Thanks {{first_name}}. What would have made it a 5?" and route the reply to the owner. A 4 is information, not a review opportunity.
6. Score 3 or below - apply detractor. Send no review request at all, ever, for this job. Notify the owner immediately with the job record and create a call-back task due within one hour. Send the customer - "Thanks for being honest, {{first_name}}. {{owner_first_name}} will call you shortly to put it right."
7. On a public review being left, notify the owner so it can be responded to - every review, positive or negative, gets a reply from a person.

Exit: score captured and routed, two asks elapsed, or opt-out.

8. BO Status Answering

Trigger: inbound customer message while the contact carries job-active.

1. Identify the live job by job_number or, failing that, the most recent active job.
2. Where-are-you intent (where, how long, still coming, what time, eta): answer from the live stage and timestamps. At Dispatched - "{{technician_first_name}} is booked for your {{arrival_window}} window and will text when on the way." At En Route - "On the way now, roughly {{eta_minutes}} minutes out, left at {{en_route_time}}." At On Site on a prior job with running-late present - "{{technician_first_name}} is finishing a job before yours and running about {{minutes_over}} minutes behind. I will text the moment they set off."
3. Reschedule intent: do not reschedule. Create a dispatcher task, reply - "I will get {{office_contact}} to call you in the next few minutes to move that properly."
4. Price, invoice or dispute intent: hand to a human immediately, no attempt at an answer.
5. Safety intent (gas, smoke, sparking, water spreading, feel unsafe): stop BO, alert the dispatcher and the owner by call and SMS, and reply with the business's agreed safety instruction only.
6. After three exchanges without resolution, hand to a human and say so plainly.

Exit: handed off, or job-active removed.

9. Repeat Callback and Warranty Watch

Trigger A: job created at an address that already has a completed job of the same job_type within the last 90 days.

1. Apply repeat-callback on the contact and flag the job for the owner before it is dispatched.
2. Suppress the satisfaction and review workflow for this job entirely.
3. Create a task for the owner to review both job records and decide whether this is warranty work. Set job_type to Warranty if so, and apply warranty-job.
4. Weekly, report repeat callbacks by technician and by job_type. This is a quality metric and belongs in a conversation with a person, never in an automated message to a technician.

Trigger B: 30 days before warranty_expiry.

1. Exit if the contact carries detractor, sms-opted-out or an active job.
2. Send email - "{{first_name}}, the warranty on the {{job_type}} we completed at {{job_address}} runs to {{warranty_expiry}}. If anything is not behaving as it should, now is the time to tell us and it costs you nothing."
3. On any reply, create a job at Scheduled with job_type set to Warranty and warranty-job applied, and route it to the technician who did the original work where possible.

Exit: warranty expires, job created, or opt-out.

The phrase "let me find out and call you back" disappears from the office. The live stage is the answer, so whoever picks up the phone - or BO, at 8pm on a Sunday - can say where the technician is and when they will arrive. More to the point, the customer stops needing to ask, because the running-late message reaches them before the thought does. Most status complaints are not about lateness; they are about not being told.

Extra work stops being an argument. Every addition is described, photographed, priced and approved in writing before a tool is picked up, with a timestamp attached to the job. Technicians stop absorbing difficult pricing conversations alone in someone's basement, and the business stops writing off work it did but cannot prove was authorized.

The paperwork stops lagging. The invoice goes out the same afternoon because the completion details were captured on site rather than reconstructed on Friday. The review is requested within hours, from the customers who said they were happy, and never from the ones who were not. And for the first time the business has four honest timestamps per job, which means the questions that were previously settled by argument - are we underestimating durations, is travel eating the day, which job types always overrun - become questions with answers.

Metrics to watch

• Dispatched to En Route lag and En Route to On Site duration. The second is your real travel time, measured rather than assumed, and it should rewrite your calendar buffers within a month.
• On Site to Work Complete duration by job_type, against the configured duration. A job type that consistently overruns by 40 percent has a duration problem, not a technician problem.
• Overrun rate - share of jobs triggering running-late - by technician, job type and day of week.
• First-time fix rate - share of jobs reaching Work Complete without second-visit-required. This is the headline operational number in field service and the one most worth improving.
• Parts hold duration - days between parts_required being written and the part arriving - and how often parts_eta is missed.
• Additional work approval rate and time-to-decision. A slow average decision time means on-site technicians are standing idle; a very low approval rate usually means the approval page is not explaining the problem well.
• Work Complete to invoice_sent_at, and invoice_sent_at to payment_received_at. Days removed from the first number are days of cash flow.
• Satisfaction response rate and score distribution, segmented by whether the job overran or needed a second visit. The correlation is usually stark and usually actionable.
• Review request to review completion rate, and total reviews per month. Never measure this on volume of asks - measure it on reviews earned from promoters.
• Repeat callback rate by technician and job_type. Review this with people, in private, never as an automated scoreboard.
• Aborted On Site count and reasons - every one is a fully loaded truck roll that produced nothing.

Prerequisites

• Technicians with smartphones and the willingness to tap stages. This is the one prerequisite that cannot be bought. Everything downstream is built on technicians reporting En Route, On Site and Complete. Run a two-week pilot with one crew, measure whether the taps actually happen, and fix the interface or the incentives before building anything else. A dispatch system fed by unreliable stage moves is worse than a whiteboard, because people trust it.
• Honest job durations per job_type, taken from historical records rather than estimates. Expect them to be longer than anyone claims.
• A named dispatcher who owns the board each day and is the single escalation point. Automation can route exceptions but it cannot decide which customer gets moved.
• Agreed pricing authority for additional work: who can price it, up to what level, and what needs an office call. Written down before launch, because this is the step where a technician is standing in a stranger's house waiting for an answer.
• Warranty terms per job_type, so warranty_expiry is a fact rather than a guess.
• A written policy for detractors - who calls, how fast, and what they can offer. The satisfaction gate creates a duty to respond; make sure someone has accepted it.
• A decision on what remains in any existing field-service or accounting system, and which system is the record for scheduling. Two schedulers will double-book.

Integrations

• Google Calendar two-way sync per technician, so time off and personal commitments block dispatch.
• Stripe (or the business's existing processor) for invoices and payment links, so payment_received_at is written automatically rather than reconciled by hand.
• QuickBooks or Xero for accounting, receiving invoices and payments from the platform. Decide which system raises the invoice - duplicating invoice numbers across two systems causes months of cleanup.
• Google Business Profile connected for review requests and review monitoring, so the owner is notified of new reviews in the same place the jobs live.
• Slack, optionally, mirroring the dispatcher exception channel if the team already lives there.
• A maps provider for address validation and day-sheet map links.
• Zapier or Make where an existing field-service platform must stay in play - but keep the Jobs pipeline authoritative for status, or the build loses its point.

Number provisioning

• Provision a customer line and a separate dispatch line. Mixing crew notifications and customer threads on one number makes the shared inbox unusable within days.
• Complete brand and campaign registration for application-to-person messaging - 10DLC in the United States, or the local equivalent - before launch. This build is message-heavy: confirmations, on-my-way, running-late, approvals, invoices, satisfaction. Volume that high gets filtered hard if the campaign is unregistered or misdeclared.
• Register the campaign as customer care and account notifications, with sample messages drawn from the copy above. Declare the real expected volume, not an optimistic one.
• Configure caller ID masking so outbound technician calls display the business number. Technicians should never have to hand out a personal mobile, and customers should never reach one directly.
• Keep a separate voice path for inbound status calls during business hours, with the Jobs pipeline visible to whoever answers.

Compliance

• Consent. Job-status messages are transactional and tied to a service the customer bought, but consent still needs collecting at booking, with clear language that the business will text about the job to the number provided, and a visible opt-out path.
• Opt-out handling. STOP, STOPALL, UNSUBSCRIBE, END, QUIT and CANCEL must apply sms-opted-out and halt every workflow. Plan the consequence: a customer with an active job who opts out still needs status updates. Route them to a phone-call task and record the preference - do not quietly keep texting because the job is transactional.
• Quiet hours. 8am-9pm in the customer's timezone for everything except messages about a job happening right now, which the customer has effectively invited. Invoice chasing and review requests are never urgent - hold them firmly inside the window.
• Review integrity. Do not offer discounts, entries or gifts for reviews, and do not suppress negative feedback from reaching the business - the satisfaction gate routes detractors to a human rather than hiding them. Review platforms have their own rules on gating and incentives; check the current terms of each platform used, because they change and enforcement is real.
• Payment data. Never store card details in the platform. Use the processor's hosted payment links so card data never touches the business's systems, which keeps the scope of any payment-security obligation small.
• Property and personal data. Job records will hold gate codes, alarm information, interior photographs and a signature. Restrict visibility to the people who need it, set a retention period for completion photos, and have a documented process for a deletion request that does not destroy the warranty record the business may need.
• Recording and signatures. If calls are recorded, announce it and check one-party versus all-party consent per jurisdiction. If the customer signature is relied on contractually, confirm with counsel that the capture method is enforceable where the business operates.
• None of this is legal advice. Messaging, payment, e-signature and privacy rules vary by jurisdiction and change - have the client's own counsel review consent language, authorization wording on the approval page, retention policy and recording practice before launch.

Scoping the build

This is the largest build in the home services set. Effort scales with crew size, the number of job types, how much has to integrate with an existing field-service system, and how much change management the crew needs. Book a call at bookings.appbo.io to scope it properly.