How We Sort Enquiries Before Work Starts

Most inbox problems do not look dramatic from the outside.

Nothing is on fire. Nothing is technically broken. There is just a familiar low-grade mess waiting for somebody in the morning.

A quote request has come in overnight. A support message is sitting next to a newsletter reply. A vague enquiry needs a human. A personal message is mixed in with three things nobody should spend time reading. Somebody still has to work out what matters, what can wait, what needs context, and what should never have made it into the inbox in the first place.

That sorting job is rarely important enough to feel strategic.

It is still important enough to shape the day.

If the first hour disappears into classification, forwarding, context gathering, and writing the same starter replies again, the team starts reactive. The rest of the day usually follows.

That is the operational problem we wanted to fix.

So we built an inbound triage workflow that does the first pass before anyone is properly at a desk.

Not a magical robot colleague. Not an "AI receptionist" wearing a smart new label. Just a system that reads what arrived, classifies it, routes it, drafts where appropriate, and hands awkward things to a human with enough context to act quickly.

Useful, in other words.

Automatic replies need clear limits

This is the bit that gets misunderstood in a lot of AI conversations.

People hear "inbox automation" and imagine one of two bad versions.

The first is a reckless autopilot that replies to everything with synthetic enthusiasm and eventually says something unfortunate to the wrong person.

The second is a very expensive filter that still leaves a human doing all the real work.

Neither is particularly interesting.

The actual job is narrower and more practical:

• identify what kind of message has arrived
• separate the useful from the junk
• route straightforward things into the right lane
• prepare a sensible first response where that is genuinely helpful
• escalate anything ambiguous, sensitive, or commercially important

That last part matters.

The workflow is not valuable because it removes humans from the loop. It is valuable because it stops humans spending their best attention on the wrong part of the loop.

What the workflow does in plain English

At a high level, the inbound system does five things:

1. reads the incoming message and whatever metadata is available
2. classifies it against a fixed set of categories
3. decides whether it should route, draft, flag, or ignore
4. prepares a first-pass response where the rules are clear enough
5. escalates anything that needs judgement, context, or commercial care

That sounds simple because, structurally, it is simple.

The hard part is not inventing the five boxes. The hard part is defining the rules well enough that the system behaves sensibly when real messages start arriving from real people, often while being vague, hurried, contradictory, or oddly worded.

The happy path is not the hard part. The oddball messages at 06:17 with half a sentence and an attachment called Final_v2_really_final.pdf are where things get interesting.

Clear categories do most of the work

We have found that a lot of inbound workflows live or die on categorisation quality.

If the categories are fuzzy, everything downstream gets fuzzy too. Routing gets worse. Drafting gets worse. Review gets slower. Trust in the system evaporates because the output feels vague in exactly the same way the inbox used to feel vague.

So we keep the categories blunt.

The specific labels can vary by business, but the pattern is usually something like this:

• qualified lead
• possible lead but unclear
• existing client support
• supplier or partner message
• personal or direct contact
• admin or operational
• newsletter or automated noise
• spam or low-value junk
• urgent but ambiguous

The point is not to create an elegant taxonomy to admire in a workshop.

The point is to make the next action obvious.

A good category should imply what happens next. If a message lands in "qualified lead", the system should know what information matters and what sort of first response is appropriate. If it lands in "spam", nobody should have to hold a committee meeting about it.

What gets drafted, and what does not

This is where sensible boundaries matter more than model cleverness.

Some messages are perfectly suitable for a drafted first pass.

For example:

• a straightforward enquiry that needs an acknowledgement and a couple of qualification questions
• a support message that needs routing with a calm holding reply
• a request for basic information that already has a known, approved answer

In those cases, drafting saves time without creating much risk. The human reviewer is not writing from scratch. They are checking tone, accuracy, and whether the system has missed some obvious nuance.

Other things never go out untouched.

That includes:

• sensitive client messages
• commercially significant leads with unusual context
• complaints
• messages with legal, financial, or contractual implications
• anything the system marks as low-confidence or ambiguous

We are not interested in winning some purity contest where the machine gets to send everything by itself. That would be the wrong metric anyway.

The goal is to make human review faster and better, not to pretend judgement is optional.

Human review makes enquiry sorting useful

If you only look at the drafted text, you miss the useful part.

The real value is in the review model around it.

A good inbound workflow needs clear answers to questions like:

• when is a draft good enough to review quickly?
• when should the system escalate without trying to be clever?
• what counts as enough confidence to classify automatically?
• what source information is the system allowed to trust?
• who owns the awkward cases?

Those decisions matter far more than whether the prompt sounds impressive.

In practice, the review model usually ends up looking something like this:

• low-risk routine items can be drafted and queued for quick approval
• categorisation happens automatically, but uncertain cases are flagged
• high-stakes or unusual messages get summarised and handed over, not answered
• the reviewer sees why the system made its decision, not just the decision itself

That last point is easy to overlook.

If a human cannot tell why the system classified something the way it did, review becomes slower, not faster. Now they are not only checking the answer. They are reverse-engineering the reasoning as well. Nobody sensible wants that before coffee.

Where AI sorting gets enquiries wrong

It gets things wrong in the same places humans tend to struggle, which is useful to know and mildly annoying in equal measure.

The weak spots are usually not dramatic. They are borderline cases.

Things like:

• a message that looks like a lead, but is really a supplier pitch
• a support email written like a complaint but actually asking for clarification
• a vague enquiry that sounds low-intent until you read the final line properly
• a personal note sent from a business address with almost no context

These are not failures of intelligence in the grand sense. They are classification problems with messy inputs.

That is why we pay close attention to false positives and false negatives.

A false positive can waste time by treating noise like an opportunity.

A false negative is often worse. That is the one where something commercially useful gets parked in the wrong lane because the system was too cautious or too literal.

You do not fix that by shouting "be smarter" into a prompt.

You fix it by tightening the categories, improving the source context, refining the escalation rules, and reviewing the misses properly.

Five changes made enquiry sorting useful

The biggest gains did not come from the fanciest model behaviour. They came from boring operational decisions.

Clear categories

If the system has to choose between messy buckets, you get messy output. This was one of the first places we tightened.

Better source context

A message on its own is not always enough. Sometimes the workflow needs contact history, known client status, or internal notes about what counts as a lead, support issue, or partner message.

Grounding matters here as much as it does anywhere else in AI. If the workflow has thin context, it makes thinner decisions.

Explicit escalation rules

"Use judgement" is not a rule.

"Escalate if the message mentions pricing, urgency, dissatisfaction, legal risk, or unclear intent" is a rule.

The system behaves better when the handover points are explicit.

Drafts written for a person to review

This one is easy to miss. A lot of generated copy gets worse because it is trying too hard to sound polished.

For internal review workflows, we want something calmer:

• clear
• correct
• proportionate
• easy to edit

Nobody needs a holding reply that sounds like it swallowed a sales brochure.

Clear rules for uncertain enquiries

The workflow got better when we stopped pretending every decision needed to look decisive.

A useful system should be allowed to say, in effect, "this looks like support, but confidence is low, so a human should check it first."

That is not weakness. That is operational honesty.

The team sees better-prepared enquiries

The value of this kind of workflow rarely shows up as a dramatic before-and-after story.

It shows up in smaller, more practical ways:

• the day starts with a clearer queue
• qualified leads surface faster
• support items reach the right person sooner
• people review drafts instead of writing every opener from scratch
• fewer useful messages get buried under low-value clutter

That is the kind of improvement we care about.

If the only way to explain the benefit is with a complicated dashboard and a very confident tone of voice, it is usually the wrong kind of benefit.

The good version feels more ordinary than that. Slightly less friction. Slightly less drag. Fewer pointless decisions before 9am.

That is enough to matter.

People still handle ambiguous enquiries

There is a fashionable version of AI commentary that treats human review as a temporary embarrassment on the way to full automation.

We think that is mostly nonsense.

In real businesses, edge cases are not a rounding error. They are where tone, judgement, context, and relationships live.

Some messages need somebody to notice:

• this client is frustrated but trying to stay polite
• this enquiry sounds casual but is potentially valuable
• this reply needs a specific human voice, not just the correct information
• this message should trigger a call, not another email

Those are not bugs in the system. They are part of the work.

The right workflow respects that.

Good automation removes repetitive sorting and first-pass drafting. It does not pretend every business interaction should be flattened into a ticketing problem.

Start with the sorting rules

The lesson from inbound triage is not "everyone needs an inbox agent".

The broader lesson is that useful operational AI tends to work best when:

• the workflow is explicit
• the categories are clear
• the handover points are designed on purpose
• the system is grounded in real business context
• the team can inspect and correct what it is doing

That is a less theatrical story than "meet your new AI teammate".

It is also the story that survives contact with production.

When people ask us about AI automation, this is the shape we trust most. Not because inbox triage is glamorous. It obviously is not. But because it reveals the real design questions quickly.

What is the job?

What counts as a good decision?

What should happen automatically?

What should stay with a human?

What does the reviewer need to see to move quickly and safely?

Those are the same questions that decide whether most AI systems become useful or become expensive furniture.

Start by mapping your enquiry types

Before building anything, write down:

1. the categories you actually need
2. the messages that should never be answered automatically
3. the information the system can trust
4. the review points where a human should step in
5. the signs that a message is valuable, risky, or just weird

If that exercise is muddy, the workflow will be muddy too.

If it becomes clearer while you do it, that is usually a good sign. You are getting closer to the actual job rather than the fashionable description of the job.

That is how we think about inbound triage, and most practical AI work more broadly.

Make the workflow explicit. Be honest about edge cases. Keep the categories sharp. Let the machine do the repetitive bit. Keep humans where judgement still earns its keep.

If that sounds like a workflow worth building in your business, talk about an AI build. We will tell you plainly where automation is likely to help, where it is likely to get annoying, and what should stay human.