Key Points:
AI lead routing for contractors can speed up intake, but the model should choose only from outcomes the business has already approved. Urgent, unclear, or high-risk inquiries still need a person.
- Automate bounded choices, not open-ended dispatch judgment.
- Set an uncertainty threshold and a named escalation owner.
- Measure routing accuracy and booked-job quality, not speed alone.
A plumbing call arrives after hours. The caller mentions water near an electrical panel, the property sits near the edge of the service area, and the usual on-call technician is already tied up. A fast automated answer is useful only if it sends that situation to the right person.
That is the practical issue behind a new AI release from OpenAI. On October 22, 2026, the company made its Decisions API generally available for fast, repeatable choices such as classifying a request, selecting a route, or scoring an option. For an established home-service company, the opportunity is not a smarter chatbot. It is a more controlled way to move an inquiry to the right branch, queue, or human owner.
What changed for AI lead routing on October 22
The OpenAI Decisions API is built for bounded questions that return a probability, a choice, or a score. It can evaluate text, images, or structured data, and OpenAI says one request can contain as many as 400 questions.
OpenAI also says the service can be up to 10 times faster than running the same decision through GPT-6 Luna in the Responses API. That is the vendor’s performance claim, not evidence that a contractor will book more jobs. The business result still depends on the rules, inputs, office process, and people surrounding the model.
General availability matters because a decision service is easier to place inside a real intake workflow than an experimental demo. Still, I would treat it as one component. A model can choose among defined options quickly. It cannot decide what the company is willing to promise, where it can legally operate, or who carries responsibility when the information is incomplete.
Which contractor lead-routing decisions fit AI
The best candidates have limited outcomes, reliable inputs, and a low cost of correction. I would start with decisions the office already makes consistently from a short set of facts.
| Decision | Useful inputs | Allowed outcome |
|---|---|---|
| Service line | Caller description, selected service, equipment type | Plumbing, HVAC, electrical, restoration, or human review |
| Serviceability | Address, ZIP code, branch rules, license limits | Core area, review area, or outside area |
| Queue ownership | Service, urgency, location, operating hours | Named branch or team queue |
| Follow-up priority | Job type, timing, customer status, available capacity | Immediate, same day, next business day, or review |
The “human review” outcome is not a failure. It is a required route. A useful model has permission to admit that the facts do not support a safe choice.
This works best after the business has a shared definition of a qualified opportunity. Our contractor lead qualification framework separates fit from office handling, which keeps a routing mistake from being mislabeled as a bad lead.
Keep emergency and high-consequence decisions with people
AI should not independently make decisions that create a safety promise, dispatch commitment, legal judgment, or material pricing expectation. A restoration inquiry involving active contamination, an electrical fire risk, or a gas odor should follow an approved emergency path even when the model sounds confident.
The same caution applies to ambiguous high-value work. A commercial HVAC replacement request may look like a standard estimate, but access restrictions, equipment size, permits, or account terms can change who should own it. My rule is simple: the more expensive the error, the narrower the model’s authority.
The NIST AI Risk Management Framework separates governance, context mapping, measurement, and risk management. That is a useful operating model here. Name the accountable owner, define the situation, test the decision, and maintain a response when the system is wrong.
Build the routing policy before connecting the model
A contractor should be able to explain the routing policy on one page before any developer connects an AI service. The document does not need technical language. It needs clear operational choices.
Define the inputs the system may trust
List the fields used for each decision and where they come from. An address entered into a web form is different from a service location confirmed by an office employee. A caller’s description can help classify urgency, but it may be incomplete. Store the original facts alongside the model’s output so a person can review what happened.
Limit the outputs
Use named queues, statuses, or escalation paths that already exist. Free-form destinations such as “send this to the best technician” invite inconsistency. A bounded choice such as “North branch emergency queue, South branch standard queue, or supervisor review” can be tested.
Set the uncertainty and exception rules
Decide which confidence level triggers review, but do not assume one threshold fits every decision. Misclassifying a maintenance request has a different consequence from mishandling a possible gas leak. Add hard exceptions for emergency phrases, missing service addresses, VIP accounts, insurance work, commercial projects, and other situations the team already treats differently.
The website also needs a clean handoff. Our guide to contractor website forms and routing explains why confirmation messages, emergency alternatives, and assigned owners belong in the same flow. If the form itself cannot produce usable information, faster classification will not repair the process.
If the intake path is unclear today, a strategy conversation can map the gaps between traffic, routing, and booked work before more automation is added.
Test with real examples before live routing
A controlled test should include ordinary leads, obvious non-leads, incomplete requests, edge-of-area addresses, urgent language, repeat customers, and deliberately confusing examples. The goal is to learn where the model should stop, not to prove that it can always choose.
I would compare each decision with the office’s approved answer and record four outcomes: correct route, acceptable alternate route, human review, or harmful error. Then review overrides by service line, branch, time of day, and source. A model that sends every uncertain request to a person may be safe but does not reduce workload. A model that routes quickly while hiding dangerous errors is worse.
NIST’s March 2026 guidance on monitoring deployed AI systems emphasizes risk-based monitoring and the balance between automated checks and human validation. Contractor workflows need the same discipline. Routing rules change when territories, hours, staffing, services, or licensing change.
Measure control, not just response speed
The business case for AI lead routing should be visible in operations. Useful measures include the share of inquiries routed correctly, time to a qualified response, human-review rate, override rate, appointments set, booked jobs, and cancellations caused by serviceability mistakes.
Keep the operating record tied to the system that owns each field. The home-service software source-of-truth framework helps prevent a routing decision from overwriting customer, job, or revenue data it does not own.
My recommendation is to automate one bounded decision first, with a visible review queue and a named owner. If the team cannot explain why a request took a route, the workflow is not ready to expand. For contractors that need the intake, follow-up, measurement, and team handoff built as one connected system, the Revved Growth Kit provides the implementation structure.
