Requests rarely arrive as forms. They arrive as emails, messages and call notes, and someone has to read each one, work out what it is, check it against the rules, and respond. A well-built system does that first pass: the model reads the free text into structured fields, your rules triage it, and a person keeps the decisions that carry weight. The reading and sorting stop eating the day; the judgment stays human. This is how to build triage that a team trusts.
The work that fills an inbox
In many businesses, a queue of incoming requests eats the time of experienced people. Each one has to be read, understood, checked against what the business can and will do, and answered or routed. It is repetitive, it is high volume, and it is where things fall through: the request that sat waiting for one missing detail, the one that was never going to fit and still consumed a week of back and forth.
The shape of this work makes it a strong candidate for a system, with one condition: the system reads and drafts, and the decision stays governed by explicit rules and a human. Hand the judgment to a model and you get inconsistency you cannot defend. Keep the judgment in rules and you get a system that is fast on the reading and firm on the decision.
The three steps of a triage system
Extract: turn free text into a structured request
The model reads the incoming message and fills a structured record: who it is from, what they want, the details that matter for the decision. Anything that is not in the text is marked as missing rather than guessed, because a plausible invented value is worse than a blank. That structured record is what the rules can then act on.
Triage: check the record against explicit rules
The structured request is checked against the business’s own criteria, each one an explicit condition: a threshold, an excluded category, a required detail. When the conditions of a rule are all met, it fires. This is the part that must not be left to the model, because the business needs the same request to produce the same decision every time, and needs to explain why when asked.
Respond: draft the right reply for the outcome
Depending on which rule fired, the system prepares the response: an email to the requester, an internal note to whoever needs to act. The person reviews and sends, rather than composing from scratch. The drafting is done; the sending stays a human choice.
A real example: an underwriting desk
We built this for a commercial insurance broker, described in general terms because the client stays anonymous. A commercial insurance request arrives as free text, and an experienced person has to read it, understand the risk, check it against the criteria agreed with insurers, and respond. The system does the first pass, and the outcomes map cleanly onto a few cases.
When information is missing, the request is legitimate but incomplete. The system identifies exactly what is absent and drafts an email asking for those items, one per line, with no promises of price or acceptance. This is the most common and most expensive case to handle by hand, and the reply now goes out the same day instead of the request sitting until someone has time.
When the activity is outside appetite, the request is declined cleanly, with an offer to refer elsewhere. No additional data is requested, because making someone gather documents for a “no” wastes their time and the broker’s. The requester gets a fast, reasoned answer instead of silence, which protects the relationship for the next one.
When the risk is sound but exceeds the automatic limit, it routes to a human underwriter with a telegraphic note of what needs deciding. The underwriter stops reading three-page emails to extract four numbers, and receives the risk already structured, knowing immediately why it reached them. And when nothing fires, the request is within limits and complete, so it moves straight to the next step instead of getting lost among the ones that need analysis.
Why the rules must decide, not the model
The single principle that makes this work is that the rules decide and the model only reads and writes. The decision, accept, decline, refer, ask, comes from a table of criteria in code, auditable and editable. This matters for three concrete reasons. It is defensible: when a request is refused and someone asks why, there is a named rule with named conditions, not “the AI thought so”. It is consistent: the same request produces the same decision regardless of who sent it or how they phrased it. And it is controllable: the business owns the criteria and changes a threshold or adds an exclusion itself, without a developer, which matters because those thresholds change as agreements change.
Handling the awkward cases
Two practical details separate a system that survives contact with reality from one that does not. First, language. When requests arrive in more than one language, normalize the extracted data to a single language so the rules work regardless of the source, and write the reply in whatever language the handler chooses. One set of criteria then serves every requester, rather than maintaining duplicate rules in parallel.
Second, editable criteria. The thresholds and exclusions change as the business’s agreements change. If every change needed a developer, the system would drift out of date within months and quietly stop being used. The criteria have to live somewhere the business can edit them directly, with the triage recalculating immediately.
What good looks like
A triage system is working when the reading and sorting stop consuming experienced people, the requests that need a decision are cleanly separated from the ones that do not, and every outcome can be explained by a rule. The measure is how much of the incoming flow is handled without a person doing the repetitive reading, while the consequential decisions still pass through human hands. This is the same model-reads-rules-decide pattern behind our other systems, set out in AI systems that do your business’s repetitive work.
Frequently asked questions
What is AI request triage?
A system that reads incoming free-text requests, structures them, checks them against the business’s rules, and drafts the right response, while a person keeps the decisions that matter. The model reads and writes; explicit rules do the triage.
Should AI decide how to handle each request?
No. The model reads the request and drafts replies, but the decision, accept, decline, refer, ask for more, comes from explicit rules in code. That keeps outcomes consistent and explainable, and lets the business change a rule without a developer.
What happens to requests the system is unsure about?
They route to a person, with the request already structured and the reason it needs a human attached. The system never forces a decision when a rule does not clearly fire or information is missing.
Can it handle requests in different languages?
Yes. The extraction normalizes the data to one language so a single set of rules works regardless of the source, and the reply is written in whichever language the handler chooses.
Is an inbox of requests eating your team’s time?
Triage is often a clear, high-volume place for a first system. Request a strategy call and we will look at what comes in and how much could be handled automatically.
