How Zip Based Call Routing Works

Why address comes before availability

A booking system that shows open times before it knows the address risks offering a slot no nearby crew can actually fill. Zip based routing flips the order: the agent collects the service address first, resolves it to a territory, and only then looks at the calendar for crews assigned to that zone. Everything downstream, the technician list, the travel buffer, the earliest opening, is already filtered to what is physically possible.

This also catches out of area callers immediately instead of after a time is offered and then walked back. The agent can say plainly that the address falls outside the service area and hand off to a human path, rather than booking a visit that later gets cancelled.

What the territory map actually contains

A territory is more than a boundary on a map. It pairs a set of zip codes or drawn zones with the crews assigned to cover them, the skills those crews hold, and any travel buffer your dispatcher already builds in between jobs. HumCrew does not invent this structure. Discovery captures the territory rules your dispatcher already uses, including overlap zones where more than one crew can take a job and edge cases like a zip code split between two crews by street.

Because the map is configuration, not a hard coded list, it changes when your coverage changes. A new crew, a retired territory, or a seasonal expansion into a neighboring zip code is a rule update, not a rebuild.

How a call moves through the routing logic

The agent answers, tells the caller it is an AI assistant, and asks what is going on and where. The address resolves to a territory. The territory narrows the technician list to crews who cover that zone. Crew skill narrows it further, since not every crew handles every job type. What is left is the actual set of valid openings, and the agent offers from that set instead of the full calendar.

If no crew in the territory has an opening that fits the caller's timing, or the job type needs a specialty crew that is booked out, the call routes to a human with the address and job details already captured. Nothing about the routing logic guesses. It either finds a valid match or hands off.

Where this shows up in your dispatch software

The HumCrew booking carries its territory and crew assignment inside HumCrew. A customer-specific project can map approved fields into ServiceTitan, Housecall Pro, Jobber, or another system only after that connector is separately scoped, built, and verified. No external write is part of the current core.

A technician routing dashboard built on the same territory data gives the office a live view of who is where and what is queued next, so the routing rules that booked the call stay visible after the call ends.

Common questions