Updated 2026-11-13. If your team sorts incoming service requests by hand, the routing decision is the cheapest thing to automate and the easiest to get wrong. Here is what a ticket router decides, the four routes nearly every service business needs, and how to test it on your own messages before you trust it.
Before any software choice, it helps to see that "routing" is not one decision. It is five, and they are not equally hard.
Only the first two are worth automating in most businesses. The last one should be a rule that never gets delegated: anything that commits money, a warranty position or safety advice goes to a human, and the router's only job is to get it there fast.
Most owners can write their rules on one page. Write that page first, because it is what you test the software against, and because a router that encodes rules you never agreed to is worse than a shared inbox.
# An example routing sheet. Replace the phrases with the ones your own # customers actually type, taken from last month's messages. emergency: hear: ["no heat", "no cooling", "water everywhere", "burning smell", "sparks"] route: on_call_technician first_reply: within 15 minutes never_do: quote a price, offer a same-day guarantee quote_request: hear: ["how much", "estimate", "quote", "looking to replace"] route: office_queue first_reply: same working day needs_from_customer: [address, photos, access notes] scheduling: hear: ["move my appointment", "can someone come", "reschedule"] route: office_queue first_reply: same working day complaint_or_warranty: hear: ["still leaking", "you were here", "not fixed", "invoice is wrong"] route: owner_review first_reply: acknowledged within the hour, answered by a person
Two things make this sheet better than it looks. The phrases come from real messages rather than from imagination, and every route names what the person picking it up must do next. A routing decision with no next action is just filing.
The hard part of routing is the message with no keyword in it. "The thing under the sink is dripping onto the boxes again" mentions nothing a rule can match, and neither does a photo of a wet ceiling. That is exactly the case a model handles well, because a decision model answers a specific question rather than writing prose. OpenAI's Decisions API documents three question types, and the predicate type is the one that matters here: it returns a probability from 0 to 1 that a condition is true, and the documentation's own advice is to "use it to flag photos for review based on a threshold you choose" [1]. Google shipped a competing endpoint the same month with the same shape, up to 1,000 questions in one pass over text, images, audio, video and PDFs [2].
So a router can ask, of every incoming message and photo, a small fixed set of yes or no questions: is someone unsafe, is this about a piece of equipment we installed, is this an emergency by our own definition. Those answers are enough to pick a lane.
// The questions a router asks of one message, in the two shapes that matter. // A predicate answers yes or no with a confidence; a choice picks one of your // own values. Both are documented, and neither writes a reply to the customer. [ { "type": "predicate", "name": "someone_unsafe", "instructions": "Does this message describe a gas smell, sparks, a live wire or anyone at risk?" }, { "type": "predicate", "name": "equipment_we_installed", "instructions": "Does this refer to a unit, address or account we installed or serviced?" }, { "type": "choice", "name": "lane", "instructions": "Which queue should a person pick this up from?", "choices": ["on_call", "office", "owner_review", "not_serviceable"] } ]
An owner does not have to read that syntax to approve it, but somebody should be able to, and the names in it should match the lanes in your routing sheet rather than a vendor's list.
What a model must not own is the fifth row of the table above. It should not promise a price, agree a warranty position, schedule work beyond your capacity, or give advice about a gas smell. Those stay with people, and the router's job is to surface them immediately rather than to answer them.
Almost every business we look at, from HVAC and electrical contractors to dental and medical clinics, needs the same four lanes, and each one fails in a different way.
Emergency, routed to a person within minutes. The failure that costs money is a missed emergency, so this lane is tuned to over-escalate. If a message is ambiguous, it goes to the on-call person, and someone looks at it. An unnecessary page is cheap; a flooded basement is not.
Quote request, routed to the office with the details already gathered. The failure here is a slow first reply, not a wrong one. This lane should ask for the address and a photo before a person sees it, so the first reply a customer gets is a useful one.
Scheduling change, routed to whoever owns the calendar. The failure is a double booking or a customer who thinks their appointment moved when it did not. Anything that changes a calendar needs a confirmation, not just a classification.
Complaint or warranty, routed to an owner. The failure is a complaint that gets sorted into a queue and answered a week later. This lane is about speed of acknowledgement, and the acknowledgement should come from a person.
This is the step that separates a router that helps from one that quietly loses work, and it takes an afternoon.
Take fifty messages from last month, including the boring ones, the text-speak ones and a few photos. Write down the lane each one actually needed, judging by what your team did in the end. That list is your answer key, and it is worth more than any vendor demonstration.
Then run the router over the same fifty and count two kinds of error separately, because they are not the same size:
The reason to judge on your own fifty rather than on a benchmark is that the measurement work is the point. An engineer who built a labeling product measured the OpenAI decisions API on a hand-labeled dataset of 3,671 items and reported 0.766 macro F1 against 0.91 for a small fine-tune and 0.894 for a distilled classifier, with the API refusing 231 of those items and an expected calibration error of 0.089 that he labels overconfident [3]. His conclusion is the useful part: the model choice mattered less than whether the model had learned his task from labels. A second, independent measurement on images found that a decision model at the default 0.5 cut-off "leaned hard toward 'no' and missed 43% of actual events", with a useful range of 0.2 to 0.3 [4]. Both are other people's datasets and neither is a prediction about your business. What they show together is that the cut-off, not the model, decides how many emergencies you miss.
One more check before go-live: send yourself the ten messages you would least like to see misrouted, and confirm what actually happens to each one. A router that has never been tested against a gas smell or a refund demand is not finished.
Both vendors that ship this kind of endpoint price it by input, and both charge nothing for output. OpenAI's guide states that uncached input costs $0.10 per 1M tokens and that "output tokens are not charged" for that endpoint [1]; Google's announcement states the same $0.10 per 1M input with zero output tokens billed [2]. There is no published price list row for either as a per-decision unit, so any figure you see quoted for "cost per message" is somebody's arithmetic rather than a list price.
The reason the per-message number misleads is that input is billed once per request and shared across every question in that request, so asking twelve questions of one message can cost about the same as asking one. We worked through the arithmetic, with a script you can rerun, in what a decision really costs: the same evidence dropped from $90 per million decisions to $0.225 per million when 400 questions shared a single request.
The cost that actually shows up on a profit and loss statement is not the token bill. It is the hours your office spends sorting, and whether an emergency sat in an inbox overnight. Price the router against that, because the token side will not be the deciding number.
Three things change when routing works, and only the first is obvious.
Your after-hours behaviour changes first, because an emergency now reaches a person instead of a shared inbox. That is a staffing decision disguised as a software decision, and it is worth agreeing who is on call before the router goes live.
Second, the review queue becomes real work. Every router produces a small pile of messages it is unsure about, and that pile is where the value is: read it weekly and you will find both the phrases your rules are missing and the genuine emergencies that were nearly missed.
Third, escalation stops being a matter of who noticed. When the router pages the on-call person directly and logs the reason, "nobody saw it" stops being an explanation. That is uncomfortable for a week and then it is just how the business runs.
Do we need a new phone number or helpdesk? No. The router sits behind whatever already receives messages, and it should log its decision somewhere you already read. Changing the intake channel is a bigger project than routing it.
Can it quote prices to customers? It should not, and we would not build it that way. Prices, warranties and safety advice go to a person. The router's job is to recognise that the message needs one and get it there quickly.
What about photos and voice notes? Both are supported by the endpoints that do this work, images as inline data or a URL and audio and video in Google's case [1][2]. Start with text and photos, because voice notes add transcription failure modes you do not need in month one.
How long does it take to set up? The software part is days. The labeling part sets the schedule, because somebody has to sit down with last month's messages and say which lane each one belonged in. Skipping that work is why routers fail.
What happens when it gets something wrong? A person sees it, which is why every lane ends in a named queue with a first-reply target rather than in an automatic reply. The log records what the router decided and why, so a recurring mistake becomes a rule change rather than a mystery.
Is this the same thing as the AI agent cost article? No, though they meet. That one is about paying for work nobody asked for; this one is about making sure the right request reaches the right person. Both sit inside the automation a small business can run well.
Write the routing sheet on one page. Pick fifty messages from last month and label the lane each one needed. Count how many real emergencies a keyword rule would miss today, because that number is the case for doing anything at all.
If you would rather not do it alone, we build these as small systems you own rather than as another subscription, and the capability half of that work is documented openly. Send a written intake with what arrives in your inbox on a normal Tuesday and we will tell you which lanes are worth automating first.
[1] OpenAI, Decisions API guide, fetched 2026-11-12 and 2026-11-13. Source of the three question types and the predicate probability, the "flag photos for review based on a threshold you choose" guidance, the $0.10 per 1M uncached input rate, the statement that output tokens are not charged for this endpoint, and the supported input types.
[2] Google, "Gemini Decisions API: Fast, calibrated multimodal decisions", 2026-11-11, by Min Choi and Felix Yu of Google DeepMind, fetched 2026-11-12 and 2026-11-13. Source of the 1,000-questions-in-one-pass limit, the multimodal input list, the $0.10 per 1M input price with zero output tokens billed, and the once-per-request billing rule. The vendor's own claims about its own model.
[3] sao.dev, "Decision Models Need Labels", page dated 2026.10.15, fetched 2026-11-12. Independent measurement on a hand-labeled tagging dataset of 3,671 items: 0.766 macro F1 at $19.20 per million billed decisions, against a 4B LoRA at 0.91 and a distilled 33M classifier at 0.894, with 231 items refused and ECE 0.089. His dataset, his conclusion, not a prediction about your business.
[4] Nick Ihm, "Classifying images with Strands Decider 2B decision model", AWS Builder Center, 2026-11-10, fetched 2026-11-11. Source of the 43% missed events at the 0.5 default and the 0.2 to 0.3 useful range. About a different model on security-camera frames, used here for the threshold failure mode it documents.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.