The routing rule keeps handing enquiries to one consultant: finding out why

Before anyone rewrites a rule, separate 3 things that look identical from the outside: a rule that matches the wrong person, a rule that has no candidate to match, and a rule with nobody free to give the enquiry to. Only the first is a rule defect. The second is a data defect and by far the most common, because a destination specialist cannot be selected for an enquiry that does not say where anyone wants to go.

Designing the assignment method itself — scoring, acceptance, reassignment on no-touch — is a separate exercise covered in assigning enquiries by destination and load. This page is about finding out which of the 3 defects you actually have before you spend a fortnight on the wrong one.

The check: assignments beside matchable destinations

1. Export 4 weeks of enquiries: id, arrival timestamp, channel, the destination field as captured, the consultant assigned, and which rule fired.
2. Classify each enquiry as matchable or not, against the vocabulary the rule actually branches on rather than against your own judgement of the text.
3. Count assignments per consultant per week, and split each consultant's total into matched by specialism and arrived via fallback.
4. Compute match rate per channel. Web form, phone note, inbox, messaging, trade portal — the differences are usually larger than the differences between people.
5. Check the specialist table against the current staff list. Leavers still listed and joiners never added both show up here and nowhere else.
6. Read the rule set in evaluation order and write down what the last branch does. In most configurations nobody in the business has ever read it.

Consultant A's 22 matched enquiries sit in line with everyone else. The other 83 are the fallback branch, and 83 of 214 is exactly the share of enquiries that arrived with no destination the rule could parse. The rule is not skewed. It is being handed 39% unroutable records and disposing of them the only way it was told to.

What counts as a usable destination

Populated and usable are different tests, and reporting on the first is what hides the problem. A field holding "somewhere warm in February, maybe Sicily" is a well-written enquiry and an empty field as far as any rule is concerned.

• It resolves to a value in the controlled vocabulary the rule branches on. If the rule tests country or region codes, prose about a coastline does not match, however clear it is to a human.
• It maps to a specialism at least 1 currently employed consultant holds. A region whose specialist left in March matches nothing and falls through silently.
• It survives the channel. Dropdowns and typeahead produce matchable values; free-text boxes, phone notes and message threads produce sentences. Compute match rate per channel and the ranking rarely surprises anyone once they see it.
• It exists at the moment routing runs. A destination captured on the qualifying call is 2 days too late to route on, which is why the field set is split by what it blocks in what a trip enquiry must contain to be quotable.
• It is not the highest-converting channel's blind spot. Messaging enquiries convert well and route worst, the tension examined in the messaging enquiry that never became a record.

Six causes and the signature each one leaves

Two rules matched and the one you did not expect won

Routing configurations grow by accretion: a rule for honeymoons, a rule for a trade partner, a rule someone added for a campaign 2 seasons ago and never removed. When an enquiry satisfies 3 of them something has to choose, and the choice is made by an evaluation order nobody in the business can describe.

The evidence is a firing audit rather than an opinion. Take 50 assigned enquiries and record, for each, which rules matched, which applied and what it set. Two findings are near-universal: a campaign rule still live long after the campaign, and 2 rules that are the same rule written twice by different people. Then write the surviving order on 1 page and keep it where the sales manager can read it, because a routing configuration that only exists in a settings screen is a configuration nobody owns.

A rule can only be as good as the table underneath it. Reference tables need an owner and a refresh path, or software acts on stale facts with complete confidence.

Availability and load, measured in the units this business runs on

Most routing tools ship with a load metric borrowed from transactional sales: enquiries received this week. In a business where an enquiry can take 6 months to close, that number says almost nothing about who has capacity to take another one.

• Measure open enquiries owned, not enquiries received. A consultant holding 40 live files is full whether or not any arrived this week.
• Weight by stage. An enquiry awaiting a client decision costs far less attention than one being itemised into an itinerary today.
• Write availability from approved leave, never from memory. A working-hours table nobody is required to update is more dangerous than none, because rules act on it confidently.
• Model out-of-hours explicitly. Enquiries that land overnight need a rule that does not pretend somebody is awake, worked through hour by hour in an enquiry arrives at two in the morning.
• Keep the trade channel out of the retail rule set. Portal enquiries carry an agent identity, credit terms and different service expectations, which is why a trade agent portal is a separate rule set rather than a reskin.

Reassignment is not the same operation as assignment

Fixing the skew usually means moving live enquiries, and a live enquiry is heavier than a new one. Anything already quoted carries a stack of itinerary objects, and a handover that loses track of which of them the client actually saw produces a worse conversation than leaving the file where it was. Keep the distinction between version, variant and revision intact through the handover, and give the receiving consultant the client-visible history rather than the latest draft.

Decision tree, with a name on each branch

1. Fallback share matches the unmatchable share. Fix the data. Make destination a structured field with an explicit "not sure yet" branch that routes deliberately rather than falling through, and fix the worst channel first.
2. Specialisms map to people who left or never arrived. Fix the table and give it a named owner with a monthly review. No routing change survives a reference table nobody maintains.
3. Skew follows the user list order. Availability is absent. Add working hours and approved leave, and fail to a queue rather than to a name when the data is older than a stated age.
4. The wrong specialist keeps winning. Run the 50-enquiry firing audit, retire the dead rules, and publish the evaluation order.
5. Everyone is matched correctly and 1 person is still drowning. This is capacity, not routing. Add a load ceiling measured in open files and let the rule skip a full consultant.
6. Ownership keeps drifting after assignment. Move ownership and state into a queue with an explicit owner per enquiry, and make one system authoritative — the split brain that follows from not doing so is traced in follow-ups still chasing a client who already paid.

Nearly all of this is reporting and reference-data work rather than a new platform: an export, a match-rate report by channel, an owned specialist table and a queue with an alert. That is ordinary internal tools and ops territory. The rest of the funnel sits under from enquiry to confirmed booking, inside our travel and tourism practice.

• enquiry routing
• assignment rules
• data quality
• sales operations