Two different problems that get treated as one
There are two distinct questions hiding inside "who goes where today," and confusing them costs you money every single day. The first is sequencing: given a truck and a list of stops already assigned to it, what is the best order to drive them? That is the problem route optimization solves, and it is the one most operators think about because it is visible — you can watch a tech backtrack across town and feel the waste. The second question comes earlier and is almost invisible: which stops should have been on that truck at all? That is the territory problem, and it is upstream of routing. No amount of clever sequencing rescues a day where a north-side tech got handed a south-side job because they happened to be the first name free when the call came in.
The reason this matters is that the two problems compound. A well-sequenced route through a badly assigned set of stops is still a bad day — you have optimized the order of a drive that never should have crossed the city. Territories are the structural layer that keeps jobs geographically coherent before the router ever runs, so that when it does run, it is arranging stops that were already near each other. Get the territory layer right and route optimization has less work to do and more to work with. Skip it, and you are asking a sequencing algorithm to paper over a dispatch decision it was never designed to fix.
What a service territory actually is
A service territory is a defined geographic area that you treat as a unit for the purpose of assigning work — a cluster of ZIP codes, a set of neighborhoods, a wedge of a metro drawn around drive time rather than tidy municipal lines. The point of drawing them is not administrative neatness; it is that a job which lands inside a zone has a natural home. When a call comes in for an address in the northeast zone, the dispatcher's first instinct becomes "who is working the northeast today" instead of "who is free," and that single change in the default reshapes the whole day's driving.
Territories are not the same as fixed tech assignments, and treating them as rigid is where operators go wrong. A zone is a bias, not a fence. On a normal day the northeast job goes to the northeast tech; on a day when the northeast is slammed and the northwest is quiet, you deliberately break the zone and send help across the line — but you do it as a conscious exception, knowing what it costs, rather than as the unexamined norm. The territory gives you a baseline that is cheap by default and an exception you can see and price. Without it, every assignment is an exception and none of them are visible.
The unit you draw the zone around should be drive time, not distance and not map aesthetics. Two addresses ten miles apart can be twelve minutes on a highway or forty minutes through surface streets and a river crossing. Draw zones so that any two points inside one are genuinely close to drive, and you have built geography that reflects how your trucks actually move. This is the same instinct that makes arrival windows achievable — a tech working a tight zone can promise a two-hour window and keep it, because the next stop is never a surprise commute.
Drawing the first set of zones
You do not need a GIS analyst to start. You need your own job history, which already contains the answer. Pull the last several months of completed jobs and look at where they physically happened — not where you wish your customers were, but where they actually are. Almost every established service business discovers that its work clusters into a handful of dense pockets with thinner connective tissue between them. Those pockets are your natural zones; the map is telling you where your demand lives.
Draw the zones around those clusters, sized so each one holds roughly a day's worth of work for the number of trucks you want to commit to it. A zone that is too big forces long drives inside it and defeats the purpose; a zone that is too small starves a tech of nearby work and pushes them across the line constantly, which is the disorder you were trying to fix. The right size is the one where a tech can fill a normal day without leaving it. If your demand is uneven — a downtown that generates three times the volume of the outskirts — your zones should be uneven too: small and dense where the work is thick, large and loose where it is thin. Equal-area zones on a map look fair and dispatch terribly.
Then pressure-test the lines against reality. Highways, rivers, bridges, toll crossings, and rush-hour choke points should fall on zone boundaries, not run through the middle of a zone — because a tech should almost never have to cross one to stay inside their territory. If your first draft puts a tech on both sides of a bridge, redraw so the bridge is the border. The goal is that staying inside a zone means staying on the same side of the obstacles that eat time.
Matching territories to your actual fleet and people
Zones are geography, but the work is done by specific trucks and specific people, and the territory design has to respect both. Some of your techs carry skills or certifications the others do not, and a beautifully compact zone is useless if the only job in it today needs a capability the zone's tech lacks. This is where territory thinking and skill-based dispatch have to be reconciled rather than fought. The practical answer is usually a hierarchy: assign by zone first, and let skill requirements override the zone as a deliberate exception — the specialist crosses the line for the jobs only they can do, and works their home zone the rest of the time. Draw the zones for the generalists and treat the specialists as a resource you spend across zones on purpose.
Fleet capacity shapes zones the other way. A zone only works if you can reliably field enough trucks to cover its daily volume; a territory that routinely generates more work than its committed trucks can absorb is not a zone, it is a bottleneck that forces cross-line dispatch every day. When a zone is consistently overrunning its trucks, that is not a scheduling annoyance to route around — it is one of the clearest signals in capacity planning that the area either needs another truck committed to it or needs its boundaries redrawn to shed load onto a neighbor with slack. Territory overflow, watched over time, is also a leading indicator in the decision about when to add a truck: the zone that keeps bleeding work across its border is telling you where the next vehicle should live.
Running the board with zones
Once the zones exist, the daily discipline is simple to state and takes practice to hold. When a job comes in, it inherits its zone from its address, and the default assignment is a tech already working that zone. The dispatcher's job shifts from solving a fresh geography puzzle on every call to managing exceptions against a sensible baseline — which is exactly the posture that makes running the dispatch board sustainable instead of frantic. Most jobs assign themselves to a zone; the dispatcher spends their attention on the handful that do not fit.
Recurring and contract work should be seeded into zones first, before the day's reactive calls land, because it is the most predictable and therefore the most sequenceable. When you schedule recurring jobs into their home zones ahead of time, they form a stable spine for each territory's day, and the incoming emergency and same-day work fills the gaps around a route that is already geographically sound. Do it the other way — let reactive work claim the day and try to slot recurring visits into whatever is left — and you lose the one category of work that was easy to keep tight.
Cross-line dispatch, when you do it, should be a decision with a cost attached and not a reflex. Sending the northwest tech into the northeast because the northeast is drowning is often the right call — but it is a call, and the point of the zone is that you see it as one. Watch how often you break your own zones. Occasional cross-line moves mean the system is flexing the way it should under load. Constant cross-line moves mean the zones are drawn wrong, the fleet is mis-sized, or demand has shifted and the map is stale — and that is information you only get because you drew the lines in the first place. A GPS view of where trucks actually are turns those exception calls from guesswork into a glance: you can see which tech is genuinely closest when a zone needs help.
Territories drift — plan to redraw them
The one certainty about a good set of zones is that they will slowly stop being good. Neighborhoods you barely served fill in with new customers; a commercial corridor you owned goes quiet when an anchor account leaves; a new highway interchange rewrites drive times overnight. Territories drawn against last year's demand quietly misfit this year's, and the misfit shows up as rising cross-line dispatch and lengthening drives inside zones that used to be tight. Treat the zone map as a living document, not a founding decision. Revisit it on a regular cadence — a couple of times a year is enough for most operations — by pulling the same job-location history you used to draw them and asking whether the clusters have moved. When they have, redraw. The cost of a stale territory map is paid silently in windshield time and missed windows, so the redraw pays for itself in avoided drives.
Multi-site commercial customers deserve a note here, because they cut across zones by nature. A regional account with locations in four of your territories should be handled with a deliberate policy — either a named tech who owns the relationship across zones, or a rule that each site is served by its local zone with shared history holding it together. The tooling for that already exists in how you manage multi-site customers; the territory layer just needs an explicit answer for the accounts that refuse to sit inside one line.
The honest boundary
Hosting Field will hold the customer addresses, the job locations, and the assignment decisions that let you run a zoned operation — and its scheduling and dispatch tools make working a territory-first board practical, with recurring work seeded ahead and the day's exceptions visible. What it will not do is draw your territories for you or know your city the way you do. The software cannot tell you that the river crossing at rush hour is really a forty-minute wall, or that the new subdivision on the north edge is about to triple your volume there; that judgment is yours, built from the job history it keeps and the roads you drive. Zones are a discipline you design and maintain on top of the tool: draw them around real drive time, seed them with predictable work, break them only on purpose, and redraw them when the map goes stale. Do that, and route optimization stops being asked to rescue bad assignments and gets to do what it is good at — sequencing stops that were already near each other because the territory put them there.