An enquiry that knows where it should go

Ask a service team how long it takes to close a typical case and you will get a number in hours. Measure the same thing in the system and it comes out in days. The difference almost never sits in the work on the case. It sits in the time before anyone decided the case was theirs.

That is the most expensive stretch of the whole process, because nobody sees it. It is not in the service report, because service has not started. It is not in the timesheets, because nobody was working during it. It is, however, with the client, who is waiting and does not know what for.

A shared inbox is not a process

The typical arrangement in a service business looks like this: there is one address everything arrives at, and a person or a rota who goes through that address every so often and allocates. That arrangement has one advantage and three drawbacks.

The advantage: nothing gets lost, because everything is in one place. The drawbacks are more serious.

• Allocation happens in batches. Cases do not move until somebody sits down to the inbox. A case that arrived a minute after the last sweep waits a whole cycle.
• Whoever allocates has to know everything. To assign a case you need to know who is on what today, who is on leave and who already has too much. That knowledge lives in one person’s head.
• There is no trace of the decision. You know who got the case. You do not know why them, or how long it waited before they got it.

The third drawback is the worst, because it blocks improvement. You cannot shorten a stretch you do not measure.

Start by naming the cases, not with a tool

It is tempting to buy a system and start with configuration. That usually ends with the same mess moved into a nicer interface. The order is the other way round: first you need to know which types of case actually come in.

A practical method: take the last hundred enquiries and sort them into piles by hand, with no list of categories decided in advance. You usually end up with five to eight groups covering most of the traffic, and a long tail of one-offs. That is your business’s real taxonomy, not the one from a system manual.

You will also see something else: which cases should not be cases at all. Status questions, requests for a duplicate invoice, appointment confirmations. That can be a third of the traffic, and it is the first candidate for cutting off before anyone starts routing it.

A route is three things, not one

Routing comes down to answering three questions, and it is worth keeping them apart, because they change on different cycles.

• Who - which role takes on this type of case. A role, not a person. People change, fall ill and get promoted; roles stay.
• When - how quickly the first response has to happen. This is not the deadline for closing the case, it is the moment the client stops waiting in silence.
• What is missing - what information the case must have before it can be started at all. An enquiry with no contract number is not a case, it is a question about a contract number.

The third point usually falls out of projects and is the most profitable one. A case that goes back to the client for missing data goes through the whole waiting cycle again. Requiring the full set up front costs the client twenty seconds at the form and saves them a day.

Describe the effect, not the activity

How do you spot routing that has been described too thinly? By how the rules sound. Compare two versions of the same thing.

Service enquiries go to the technical department.

And the same part of the process described so that something can be drawn from it:

A fault reported by a client with a service contract goes to the technician on duty within 15 minutes, with the equipment number and the history of the last two visits. Without the equipment number the enquiry goes back to the client with one question, rather than with a request to complete the form again.

The second version says who, how quickly, with what context, and what happens when something is missing. The first is true and useless. That difference translates directly into whether the system can be configured without questions at every step.

The automation picks the route; it does not answer for it

This is a line worth drawing deliberately. A language model is good at classification: it will read the enquiry, recognise the type, pull the contract number out of the text and propose a route. It is bad at responsibility: it does not know that this client has a complaint open and that every case of theirs should go to their account manager.

The practical split looks like this: the automation proposes and fills in, a person has the right of veto, and every correction is recorded. After a few weeks the corrections themselves show where the rules are too broad. That is cheaper than trying to invent perfect rules up front.

An important detail: the proposed route has to be visible together with the reason. "To service, because the text contains an equipment number and the word fault" can be checked in a second. "To service" on its own has to be verified from scratch, which means the automation saved nobody any work.

What to measure from day one

Three numbers are enough to know whether routing works, and all three have to be collected from the start, because they cannot be reconstructed afterwards.

• Time to pick-up - from arrival to the moment the case has an owner. This is the invisible stretch.
• Re-route rate - how many cases changed owner after the first assignment. A rising rate points to rules that cannot tell similar types apart.
• Incomplete case rate - how many went back for data. This measures the quality of the form, not the quality of the client.

None of these numbers belongs on a board dashboard. All three are tools for the person tuning the process. That distinction is worth keeping, because numbers the board watches stop being a diagnostic tool and start being a target in themselves.

Where this sits in Omnira

Enquiry routing is handled by Desk: it takes the case in, recognises the type, fills in context from the systems you already have and assigns it to a role together with the reasoning. Human corrections go back into the rules, so routes are tuned in the course of the work rather than in a separate project.

You come in with one module, not a whole platform. If you want to see this on your own case types, book a call - we start with those hundred most recent enquiries, not with a slide deck.

Frequently asked questions

Where do you start if everything goes to one inbox today? By sorting the last hundred cases into piles with no categories decided in advance. That single exercise gives you a taxonomy, a list of cases to cut off and a first draft of the rules. It takes half a day and needs no system at all.

Does routing make sense for a small team? In a team where everyone knows everything about everything, the gain from assignment is small. The gain from requiring complete data up front and from measuring time to pick-up is the same at any size.

What if the automation gets the route wrong for an important client? That is why it proposes rather than decides, and why it shows the reason. Hard rules, of the "a client with an open complaint always goes to their account manager" kind, sit above the model and are not subject to its judgement.

How long does routing like this take to set up? It depends mainly on how many systems have to be queried for context, not on the number of rules. Routing itself across five case types is a matter of days. Connecting to a system with no API can take longer than everything else put together.