Territory-Based Lead Routing

A one-van business has no routing problem. A three-van business has nothing but routing problems, and nobody notices the transition happening. Inquiries land in one inbox, a dispatcher reads them in the order they arrived, and assignment happens by whoever is mentally closest to hand rather than geographically closest to the job. The result is a van crossing the city at eleven in the morning while another crew sits forty minutes away with a gap in the calendar, and neither of those facts appears in any report.

Out-of-area work is the expensive version of the same failure. Someone two hours away fills in the inquiry form, nobody checks where they are until the quote is being written, and by then the business has either spent an hour on a job it should have declined or, worse, won it. A job won at a normal rate with two hours of unpaid travel attached is a job that loses money, and it is almost always the job that produces the angry review when the crew cancels on the day because something nearer came up. Businesses in this position typically do not know their out-of-area rate, because the system never asked.

Underneath both is an attribution blindness that quietly misdirects the marketing budget. Local advertising, service-area pages and vehicle livery all work at the level of ZIP code districts, but if inquiries are not tagged with a district then nobody can say which districts produce work that converts, which produce tire-kickers, and which produce jobs the business should stop advertising for entirely. The business ends up spending evenly across a map where the returns are wildly uneven. This build makes geography a first-class field: every inquiry is pinned to a territory before anything else happens, routed to the crew that owns it, priced and scheduled according to that territory's rules, declined honestly or referred out when it falls outside, and reported on by district afterwards.

The territory model

Everything here hangs off one decision made before any building: what the territories actually are. They are defined by ZIP code or ZIP prefix (whichever applies in the market) and never by drive-time guesses or by which crew shouted loudest. A working model for a three-crew business:

• Core territories, one per crew, each a named list of ZIP code districts with a single owning crew. In the examples below these are North, Central and South.
• Extended: districts served, but only where the calendar allows and only clustered with other work. These feed survey days rather than same-day calls.
• Surcharge: districts served on different commercial terms because of travel. The terms themselves live in the quoting process and are confirmed by a person; the territory record only carries the flag that they apply.
• Not covered: declined, politely and immediately, and referred out where a partner exists.

Each territory record holds the district list, the owning crew, a secondary crew for overflow, the coverage status, the travel band, which calendars it maps to, and which referral partner applies when it is not covered. Maintaining this as one lookup rather than as conditions scattered across a dozen workflows is the difference between a build that can be changed in ten minutes and one nobody dares touch.

Pipelines and stages

A dedicated Inquiry Routing pipeline sits in front of the normal sales pipeline. Every inquiry passes through it and is only promoted once it has a territory and a crew.

• Captured: the inquiry exists. No judgment yet.
• Location Needed: no usable ZIP code. The most common reason a lead stalls, and it deserves its own stage so it can be worked rather than waited on.
• Territory Assigned: ZIP code matched to a territory.
• Routed to Crew: offered to the owning crew and awaiting acceptance.
• Crew Accepted: promoted into the sales pipeline from here.
• Extended Area, Clustered: accepted but held for a survey day in that direction.
• Surcharge Offered: the customer has been told different terms apply and has not yet decided.
• Out of Area, Referred: passed to a partner, with the partner recorded.
• Out of Area, Declined: no partner available, declined honestly.
• Unroutable, Manual Review: the ZIP code exists but matches nothing in the model. Every record here is a gap in the territory definition and should be reviewed weekly, because the model is never finished.

Calendars

• Crew North, Crew Central, Crew South: one service calendar per crew, each with its own working hours, buffers and daily job limits. The booking link a customer receives is chosen by their territory, so they only ever see slots a crew can actually reach.
• Survey Days by Direction: class-style calendars that exist on fixed days for each direction of travel, so extended-area work is clustered rather than scattered. A Thursday that is already going west is the cheapest way to serve a far district.
• Overflow: a collective calendar across two crews, used only when the primary crew's limit is reached, with visibility of the travel implication before a slot is offered.

Custom fields

• Service ZIP code: the whole build turns on this one field, so it is captured first and validated on entry.
• ZIP code District: the normalized prefix, derived by workflow. Matching on the district rather than the full ZIP code is what keeps the territory lists short enough to maintain.
• Service Address, Address Verification Status: Verified, Partial, Unverified, Failed.
• Territory: single select of the named territories. Written only by the routing workflow.
• Coverage Status: Core, Extended, Surcharge, Not Covered, Unknown.
• Assigned Crew, Secondary Crew, Travel Band (Band 1 nearest through Band 4 furthest).
• Routing Method: District Match, Geocode Fallback, Manual. Recording how a lead was routed is what tells you whether the district lists are good enough.
• Routing Confidence: High, Medium, Low. Low-confidence routes are reviewed by a person before any promise is made to the customer.
• Geocode Latitude, Geocode Longitude, Distance Band From Depot: populated by the address-verification step and used for the fallback path.
• Surcharge Flag: a yes or no indicator only. No figure is ever stored on the contact record; the commercial terms are applied by a person in the quote.
• Out of Area Reason: Outside Service Area, Wrong Trade, Island or Restricted Access, Commercial Premises, Other.
• Referral Partner, Referral Sent At, Referral Outcome.
• Source Tracking Number: the number the caller dialled, which is how territory-specific advertising gets attributed.

Tags

• territory-north, territory-central, territory-south, and one per territory in the model.
• coverage-core, coverage-extended, coverage-surcharge, out-of-area.
• routed-auto, routed-manual, routing-low-confidence, unroutable.
• crew-accepted, crew-declined, reassigned, overflow-used.
• referred-out, referral-reciprocal: the second for partners who send work back, which is worth knowing when deciding who to refer to.
• territory-boundary-case: applied to any ZIP code district that sits in two territories' lists, so boundary disputes are visible rather than argued about.

Forms and pages

• Coverage Check: a single-field widget on the home page and every service page: enter a ZIP code, get an immediate honest answer. In-area visitors go straight to that territory's booking calendar. Out-of-area visitors are told so at once, which saves them time and saves the business a wasted lead. Putting this first on the page costs some raw inquiry volume and improves almost every number downstream.
• Inquiry: the main form, with Service ZIP code as the first field and address autocomplete behind it. Asking for the ZIP code before the name feels unusual and works: it means no inquiry can enter the system unrouted.
• Crew Response: Accept or Decline with a reason, opened from the routing SMS, writing acceptance as a timestamped event.
• Territory Exception Request: the controlled way a crew or the office asks for a one-off route outside the model, captured with a reason so exceptions become data rather than habits.
• Service-area landing pages, one per meaningful district, each pointing at the correct territory's calendar and carrying that district's tracking number. These are how local search traffic arrives already routed.

BO's role and guardrails

• BO asks for the ZIP code before anything else. Not the name, not the problem. The ZIP code. On a voice call BO can also accept it on the keypad, which is more reliable than speech recognition for alphanumeric ZIP codes.
• BO checks coverage against the territory model and gives a straight answer. In area: offer that territory's booking link. Extended: explain that it is served on specific days and offer those. Not covered: say so immediately and offer the referral.
• BO never states or implies a travel charge, a surcharge amount or any other figure. For a surcharge territory BO says different terms apply because of the distance and that the office will confirm them before anything is booked, or offers a call at bookings.appbo.io.
• BO never promises coverage for an unroutable ZIP code. Low confidence or no match means BO says a colleague will confirm within the hour and creates the task, rather than guessing.
• BO never offers a crew's calendar outside that crew's territory, even when the customer pushes. Routing rules are not negotiable by chat.
• BO escalates boundary arguments, partner disputes and any request to cover an area the business has declined.

Numbers and channels

• A tracking number per territory or per advertising placement, so Source Tracking Number reveals which district's advertising actually produced the call. This is the cheapest attribution any home services business can buy.
• An inbound voice flow that captures the ZIP code by keypad before routing, then sends the call to the owning crew's queue with a whisper message naming the territory.
• Missed-call capture on every tracking number, with the recovery text asking for a ZIP code first.
• SMS from the business number for crew routing offers and for customer confirmations.
• Internal notifications per crew channel in Slack or Microsoft Teams, so a crew sees its own territory's flow and not everyone else's.

1. A homeowner searches for a bathroom fitter and lands on the service-area page for their district. The page carries that district's tracking number and points at the right crew's calendar, so the lead is already half-routed before anyone has typed anything.
2. They use the Coverage Check widget and enter their ZIP code. The widget matches the district to the Central territory with Coverage Status of Core and replies immediately: yes, we cover you, here are the next available dates.
3. They open the Inquiry form from there. Service ZIP code is pre-filled from the widget, address autocomplete captures the full Service Address, and address verification writes Address Verification Status as Verified along with the coordinates.
4. On submission the routing workflow derives ZIP code District, matches it to Central, writes Territory, Coverage Status, Assigned Crew, Secondary Crew and Travel Band, sets Routing Method to District Match and Routing Confidence to High. Tags territory-central, coverage-core and routed-auto are applied. The record enters Inquiry Routing at Territory Assigned.
5. The stage moves to Routed to Crew. The Central crew lead gets an SMS with the district, the job type and a Crew Response link. The Central channel in Slack gets the same summary. The other two crews see nothing, which is the point.
6. The crew lead taps Accept. The stage moves to Crew Accepted, crew-accepted is applied, and the record is promoted into the normal sales pipeline with the opportunity owner set to that crew.
7. The customer gets a confirmation naming the crew and carrying the Crew Central booking link only. Never a generic link that could put a Central job in the South calendar.
8. They book a survey slot. The standard appointment reminder ladder takes over and the territory fields travel with the record for the rest of its life.
9. Meanwhile a second inquiry arrives by phone on the main tracking number. BO answers and asks for the ZIP code first, taking it on the keypad. The district matches the Surcharge list.
10. BO says plainly that the business does cover that area but on different terms because of the distance, that the office will confirm the detail before anything is booked, and offers a call. Surcharge Flag is set, the stage moves to Surcharge Offered, and a task goes to the office. BO does not state a figure at any point.
11. A third inquiry arrives from a ZIP code ninety minutes out with no partner nearby. The workflow sets Coverage Status to Not Covered and Out of Area Reason to Outside Service Area, moves to Out of Area, Declined, and sends an immediate honest message rather than letting the lead sit in a queue for two days before someone breaks the news.
12. A fourth arrives from a district that exists but is on nobody's list. A new estate on the edge of the map. The geocode fallback runs, finds it inside Band 2 of the depot, sets Routing Confidence to Low, tags unroutable, and raises a task. A person routes it manually within the hour and, crucially, adds the district to the North list so the next one routes itself.
13. By mid-afternoon the Central crew hits its daily job limit. The next Central inquiry is offered to the Secondary Crew through the overflow calendar, tagged overflow-used, with the travel implication shown before the slot is offered rather than discovered the next morning.
14. At the end of the week the territory report shows inquiries, routes, win rate and average travel band by ZIP code district, alongside which tracking number produced each one. Two districts in the Extended list have produced steady work that converts; one Core district has produced nothing in three months. Those are two decisions the business could not previously make.

1. Location Capture and Normalization

Trigger: Inquiry form submitted, Coverage Check submitted, inbound call answered by BO, missed call on any tracking number, or inbound SMS or chat on any channel.

Conditions and branches: branch on whether a usable ZIP code is present. Branch on Address Verification Status. Branch on whether the contact already has a Service ZIP code on file from a previous job, in which case use it and skip the asking.

Actions in order:

1. Create or match the contact. Create the opportunity in Inquiry Routing at Captured. Write Source Tracking Number from the number dialled, or the page URL for a web inquiry.
2. Normalize whatever ZIP code was supplied: strip spaces, upper-case it, and derive ZIP code District as the outward prefix. Do this in one place so every downstream match is comparing like with like.
3. Run address verification. Write Address Verification Status, the full Service Address, and the coordinates where returned.
4. If a valid district is present, hand to workflow 2 immediately. Routing should be the first thing that happens, not the last.
5. If no ZIP code is present, move to Location Needed and send one SMS: "Thanks for getting in touch. So we can get the right crew to you, what's the ZIP code for the property? Just the ZIP code is enough to start."
6. Wait ten minutes. If no reply, send one chase: "Still here, reply with the ZIP code and we'll tell you straight away whether we cover you and when we could come out."
7. Wait thirty minutes. If still nothing, create a task for the office to call, because a lead stuck at Location Needed is not progressing on its own.
8. Wait four hours. If still no location, leave the record at Location Needed for the daily review. Never guess a ZIP code from an area code or a surname, and never route a record without one.
9. If verification returns Failed or Partial but a district was parsed, continue to workflow 2 with Routing Confidence set to Medium and a note explaining why.

Stop and exit conditions: exits as soon as a district is present. Two automated messages then a human task. Never re-enters for the same inquiry.

2. Territory Assignment and Crew Routing

Trigger: ZIP code District written by workflow 1.

Conditions and branches: match the district against the territory lookup. Four outcomes: Core, Extended, Surcharge, Not Covered. A fifth implicit outcome (no match at all) hands to workflow 3. Branch again on whether the district carries territory-boundary-case.

Actions in order:

1. On a Core match: write Territory, Coverage Status Core, Assigned Crew, Secondary Crew and Travel Band. Set Routing Method to District Match and Routing Confidence to High. Apply the territory tag, coverage-core and routed-auto. Move to Territory Assigned.
2. If the district is a boundary case, apply territory-boundary-case and assign to the crew named as primary in the lookup. Do not alternate, do not round-robin: boundary districts need one predictable owner, and the tag is there so the boundary can be reviewed on evidence later.
3. Check the assigned crew's daily job limit on their calendar. If the limit is reached, hand to workflow 7 rather than offering a slot that does not exist.
4. Move to Routed to Crew. Send the crew lead an SMS: "New inquiry: {{ZIP code District}}, {{Job Type}}. {{Territory}} territory, Travel Band {{Travel Band}}. Accept or decline: {{Crew Response link}}"
5. Post the same summary to that crew's channel only.
6. Send the customer a confirmation carrying that crew's booking link and nothing else: "Good news. We cover {{ZIP code District}}. {{Crew name}} looks after your area. Here are their next available slots: {{crew booking link}}"
7. On an Extended match: write Coverage Status Extended, apply coverage-extended, move to Extended Area, Clustered, and send the directional survey-day calendar instead of the open crew calendar: "We do cover {{ZIP code District}}, we work that direction on {{survey days}}, which keeps it efficient for everyone. Here's what's available: {{Survey Day booking link}}"
8. On a Surcharge match: set Surcharge Flag, apply coverage-surcharge, move to Surcharge Offered, and hand to workflow 5. Send no figure of any kind.
9. On Not Covered: write Coverage Status Not Covered and Out of Area Reason, apply out-of-area, and hand to workflow 4.
10. Where Routing Confidence is Medium or Low, apply routing-low-confidence and create a task for the office to confirm before any booking is treated as firm.

Stop and exit conditions: every inquiry leaves this workflow with either a territory and a crew, or a handoff to workflow 3, 4, 5 or 7. Nothing exits unrouted. Stops if the customer withdraws.

3. Geocode Fallback for Unmatched Districts

Trigger: ZIP code District present but matching no entry in the territory lookup.

Conditions and branches: branch on whether coordinates were returned by verification. Branch on the resulting Distance Band From Depot.

Actions in order:

1. Apply unroutable. Move to Unroutable, Manual Review. Set Routing Method to Geocode Fallback and Routing Confidence to Low.
2. If coordinates exist, calculate the distance from each depot or crew base and write Distance Band From Depot.
3. If Band 1 or Band 2, provisionally suggest the nearest crew in an internal note. Do not write Assigned Crew automatically, and do not send the customer a booking link. A provisional guess must not become a promise.
4. If Band 3 or Band 4, provisionally suggest Not Covered or Surcharge in the note.
5. Create a task for the office, due within one hour, naming the district, the coordinates, the suggested band and the suggested crew.
6. Send the customer one honest holding message: "Thanks: {{ZIP code District}} is right on the edge of our patch, so rather than guess I'm getting a colleague to confirm. They'll come back to you within the hour." BO says nothing more specific than that.
7. When the office routes it manually, write the fields, set Routing Method to Manual, apply routed-manual, remove unroutable, and continue into workflow 2's messaging.
8. In the same task, require the district to be added to the territory lookup with a status. This is the step that makes the build improve rather than accumulate manual work, and the task should not be closeable without it.
9. Weekly, compile every record that passed through this workflow into a coverage-review report for the owner.

Stop and exit conditions: stays open until a human routes it. One customer message, then silence until a person has something real to say. Never auto-assigns a crew on a low-confidence geocode.

4. Out-of-Area Decline and Referral Out

Trigger: Coverage Status set to Not Covered.

Conditions and branches: branch on whether a Referral Partner is defined for that district. Branch on Out of Area Reason: Wrong Trade gets different wording from Outside Service Area.

Actions in order:

1. Apply out-of-area. Write Out of Area Reason.
2. Send one message, immediately, with no delay and no softening: "Thanks for thinking of us: I'm sorry to say {{ZIP code District}} is outside the area we cover, so we'd be the wrong people for this. I didn't want to leave you waiting to find that out."
3. If a partner exists, add: "{{Partner name}} covers your area and we'd happily point you their way. Want me to pass your details on, or would you rather just have their number?" Ask before passing anything on, and act only on an explicit yes.
4. On consent: write Referral Partner and Referral Sent At, move to Out of Area, Referred, apply referred-out, and send the partner the details by the agreed method. Log what was shared.
5. If the customer would rather just have the number, send the number and move to Out of Area, Referred with no data shared at all.
6. If no partner exists, move to Out of Area, Declined and send nothing further. One message and done.
7. Suppress this contact from every marketing campaign, nurture sequence and broadcast list permanently, unless they later supply an in-area ZIP code. Marketing to someone you have just declined to serve is the single most irritating thing this build could do.
8. After thirty days, ask the partner for the Referral Outcome through whatever the agreed reporting method is, and record it.
9. Monthly, report out-of-area volume by district to the owner. A cluster of declines in one direction is either a coverage opportunity or an advertising targeting error, and the cluster tells you which.

Stop and exit conditions: exactly one customer message, plus one referral exchange on consent. No follow-up, no nurture, no re-entry. The only way back in is the customer supplying a covered ZIP code themselves.

5. Surcharge Zone Offer and Acceptance

Trigger: Surcharge Flag set.

Conditions and branches: branch on job value band where known. A large job may absorb the travel where a small one cannot. Branch on whether other work is already booked in that direction that week.

Actions in order:

1. Move to Surcharge Offered. Apply coverage-surcharge.
2. Send one message that is honest and contains no figure: "We do cover {{ZIP code District}}, though it's far enough out that our terms are a bit different for that distance. Nothing gets booked before you've agreed them. {{Office contact}} will call you shortly to go through it, or grab a time that suits: {{Plan Consultation link}}"
3. Create a task for the office, due within two hours, to make that call. The figure is communicated by a person, verbally and then in writing, and never by an automated send.
4. Check whether other work is already scheduled in that direction within the next two weeks. If it is, note it on the task, clustering is often what makes a far job viable without changing terms at all.
5. On the customer accepting: record the acceptance, promote to the sales pipeline, and book through the directional survey calendar rather than the standard crew calendar.
6. On the customer declining: move to Out of Area, Declined, set Out of Area Reason to Outside Service Area, and send one short acknowledgement. No haggling sequence.
7. If no answer after two call attempts across two days, send one final message offering a booking link for a call, then close the record.

Stop and exit conditions: two automated messages maximum, and the commercial conversation always happens with a person. Stops on acceptance, decline or no contact after two attempts.

6. Crew Acceptance and Reassignment Ladder

Trigger: stage set to Routed to Crew.

Conditions and branches: branch on whether the Crew Response form has been submitted. Branch on decline reason: Capacity routes differently from Wrong Trade or Already Known To Me.

Actions in order:

1. Wait fifteen minutes. If no response, resend to the crew lead and notify their crew channel.
2. Wait fifteen minutes. If still no response, offer to the Secondary Crew, apply reassigned, and notify the office that the primary crew did not respond.
3. Wait fifteen minutes. If still nothing, assign to the office queue so a human owns it, and log the non-response against the primary crew for the weekly review. Crew responsiveness by territory is a management metric, and this ladder is what produces it.
4. On Accept: move to Crew Accepted, apply crew-accepted, set the opportunity owner, promote into the sales pipeline, and send the customer the crew's booking link.
5. On Decline with reason Capacity: hand to workflow 7.
6. On Decline with reason Wrong Trade: reroute to the correct trade's crew, or hand to workflow 4 with Out of Area Reason set to Wrong Trade.
7. On Decline with reason Already Known To Me: keep the assignment with that crew but flag the relationship, because "I know them" is usually a reason to assign rather than reassign.
8. On Decline with reason Boundary Dispute: apply territory-boundary-case, assign to the office, and add the district to the weekly boundary review. Never let two crews negotiate a boundary through a declined lead.

Stop and exit conditions: three offers across forty-five minutes, then a human owns it. The customer is never told which crew has it until a crew has accepted, so a reassignment is invisible to them. Stops on acceptance or on the office taking ownership.

7. Territory Capacity Balancing and Overflow

Trigger: a crew's daily or weekly job limit reached, or a Crew Response declined on Capacity.

Conditions and branches: branch on the inquiry's urgency. Branch on the Secondary Crew's own capacity. Branch on Travel Band: a Band 1 job is worth overflowing, a Band 4 job usually is not.

Actions in order:

1. Apply overflow-used. Note on the record which crew was at capacity and on what date, because this is the data that justifies the next hire.
2. If the job is not urgent, offer the primary crew's next available slot even if it is further out, and say so plainly: "{{Crew name}} covers your area and their next slot is {{date}}. If that's too far out, let me know and I'll see what else we can do." Honest scheduling beats clever reshuffling.
3. If the job is urgent and the Secondary Crew has capacity, offer it to them through the overflow calendar, with the travel band visible on the offer so they can judge it.
4. If both crews are at capacity, route to the office with a prioritization task rather than letting the system choose between customers.
5. Weekly, report capacity-reached events and overflow usage by territory. Three consecutive weeks of overflow in one territory is a hiring or boundary decision, and it should arrive as a report rather than as a crew complaint.

Stop and exit conditions: stops on a booking or on the office taking ownership. Never silently pushes a job to a crew whose travel band makes it unprofitable; the travel implication is always on the offer.

8. Territory Reporting and Coverage Review

Trigger: weekly schedule, plus a monthly summary.

Conditions and branches: none; this is a reporting workflow and it should run whether anyone is asking for it or not.

Actions in order:

1. Weekly, compile and send the owner: every record still at Unroutable, Manual Review or Location Needed, every district newly tagged territory-boundary-case, and every capacity-reached event.
2. Monthly, compile inquiry volume, automatic routing rate, crew acceptance time, win rate and average Travel Band by ZIP code District and by Territory.
3. Cross-reference Source Tracking Number against booked work per district, so advertising performance is reported geographically rather than as one blended number.
4. List districts in the Extended bucket that produced work which converted. These are candidates for promotion to Core, possibly with a crew based differently.
5. List Core districts that produced nothing. These are candidates for reduced advertising, and they are the finding owners are most surprised by.
6. Create a quarterly task to formally review the territory lookup against this evidence. Treat the model as a living document; a territory map that has not changed in two years is not stable, it is unmaintained.

Stop and exit conditions: internal only. No customer-facing message is ever sent by this workflow.

Geography stops being a thing people remember and becomes a field the system acts on. Every inquiry carries a territory, a crew, a coverage status and a travel band from the moment it exists, which means routing happens in seconds rather than whenever a dispatcher gets to it, and it happens the same way every time regardless of who is on the desk.

Out-of-area leads get an honest answer immediately. This is worth more than it sounds. The business stops burning quoting time on jobs it was never going to take profitably, the customer stops waiting for a call that was always going to disappoint them, and where a referral partner exists the lead turns into goodwill and sometimes into reciprocal work instead of into nothing.

Crews stop crossing each other. A booking link scoped to one crew's calendar cannot produce a job the wrong crew has to drive to, which removes an entire category of daily argument. Extended-area work gets clustered onto directional survey days rather than scattered through the week, and that single scheduling change is usually where the travel saving actually comes from.

And the marketing spend gets a map. Because every inquiry carries a district and a tracking number, the business can finally see which districts produce work that converts and which produce inquiries that waste a morning. Advertising stops being spread evenly across a market with uneven returns.

Metrics to watch:

• Automatic routing rate: the share of inquiries routed with Routing Method of District Match and Routing Confidence High. This is the health check on the territory model itself, and it should climb as the unroutable queue gets worked.
• Unroutable count per week, and whether each one results in a district being added to the model. An unroutable queue that is worked but never reduces the count means somebody is routing manually instead of fixing the lists.
• Median time from inquiry to crew accepted, split by territory. A territory with a consistently slower acceptance time has a crew-capacity or crew-engagement problem, not a routing problem.
• Out-of-area rate, trended, and the Out of Area Reason mix. A rising rate usually means advertising has drifted geographically, which is a targeting fix rather than a sales problem.
• Coverage Check usage and its outcome split: how many visitors check, and what share get told yes. Out-of-area visitors who self-identify before filling in a form are the cheapest leads you will ever not have.
• Referral volume and referral outcome, plus how many partners carry referral-reciprocal. A referral relationship that only flows one way is a decision to revisit.
• Average travel band per booked job, per crew: the clearest proxy for whether routing is actually reducing driving, and it should drift downward as the model matures.
• Overflow usage rate: how often a job goes to the secondary crew. Persistent overflow in one territory is a hiring signal or a territory-boundary signal, and the data tells you which.
• Win rate and job value by ZIP code district, cross-referenced with Source Tracking Number. The report that redirects the advertising budget.
• Exception request volume from the Territory Exception Request form. A handful a month is healthy; a steady stream means the model does not match reality and should be redrawn rather than overridden.

Define the territories before touching the software

• This is the whole build, and it is a business decision, not a configuration task. Sit down with the actual ZIP code districts, the depot or home-base locations, and the last twelve months of completed jobs, and draw the lines from the evidence rather than from habit.
• Be honest about the edges. Every district goes in exactly one of four buckets (Core, Extended, Surcharge, Not Covered) and the Not Covered list has to be a real list that someone is willing to defend on the phone. A territory model with no declined areas is not a model.
• Identify boundary districts deliberately and tag them territory-boundary-case. Decide in advance which crew owns each one, rather than letting it be settled job by job.
• Agree crew capacity: daily job limits, working hours and buffers per crew. Routing without capacity limits just moves the bottleneck somewhere less visible.
• Decide what the Extended survey days are, by direction and by weekday, and commit to them. Clustering only works if the days are fixed.

Platform prerequisites

• All custom fields created before any workflow, with a firm rule that Territory, Coverage Status and Assigned Crew are written only by the routing workflow. Hand-edited territory fields corrupt every report that depends on them.
• One service calendar per crew, with that crew's real hours and limits, plus the directional survey calendars and the overflow collective calendar.
• Crews set up as users with working cell numbers, and the acceptance path tested from a phone in a van with poor signal, which is where it will actually be used.
• The district lists held in one place (a single lookup the workflows read) rather than duplicated into conditions across multiple workflows. Plan for the model to change quarterly, because it will.

Integrations

• Address autocomplete and verification on the inquiry form and the coverage widget. A typed ZIP code with a typo routes a job to the wrong city, so validate at the point of entry rather than correcting later.
• A geocoding service for the fallback path, used to resolve a ZIP code to coordinates and a distance band when the district lists do not match. Google Maps is the common choice; whatever is used, check the license terms permit storing the coordinates you intend to store.
• Google Calendar or Microsoft 365 connected per crew for two-way sync.
• Tracking numbers provisioned per territory or placement, with call recording and missed-call capture on each.
• Slack or Microsoft Teams with one channel per crew.
• Google Ads and Meta Ads connected if advertising is geographically targeted, so district-level performance can be compared against district-level spend rather than guessed at.

Telephony and SMS compliance

• Provision tracking numbers with enough lead time to appear in print, on livery and in directories without a rush. Keep a register of which number is on which asset, or within a year nobody will know what any of them mean.
• A2P and 10DLC registration complete and approved before launch. Crew routing offers are the messages that must not be filtered, since a crew that never receives an offer looks exactly like a crew that ignored one.
• Opt-out handling live and permanent on all customer messaging. Out-of-area declines in particular should be a single message, with no follow-up sequence attached. Nobody wants nurturing by a business that just told them it cannot help.
• Quiet hours enforced on all customer-facing sends. Crew routing messages are internal operational traffic to staff, which is a different category, but set that distinction explicitly in the build rather than leaving it to chance.

Referral partners

• Agree referral arrangements in writing before the workflow sends anyone a partner's name. Who gets what, how outcomes are reported back, how the customer's data is passed and on what basis, and what happens when the partner does a poor job in your name.
• Tell the customer plainly that you are referring them to another business, and get their agreement before passing their details on. A referral the customer did not consent to is a data-protection problem wearing a helpful hat.
• Track Referral Outcome so the partner list can be pruned. Referring work to someone who handles it badly damages the referrer, not just the referee.

Data protection and legal

• Addresses, coordinates and job histories together make a precise map of where customers live. Apply role-based field visibility so a crew sees its own territory, set retention periods, and remove access when staff leave.
• Where coordinates are stored, record why and for how long. Precise location data attracts more obligations than a ZIP code does in several jurisdictions, so store the minimum the routing logic actually needs.
• Differential terms by geography, surcharge zones, need to be disclosed clearly and applied consistently, and in some markets there are specific rules about how and when such terms must be communicated. Never let an automated message be the place a customer first learns a figure.
• None of this is legal advice. Referral consent wording, data-sharing arrangements with partners, location-data retention, surcharge disclosure and quiet-hours treatment should be confirmed with the client's own counsel for their jurisdiction before go-live. For scoping the build, book a call at bookings.appbo.io.