Articles routing

Lead routing accuracy is four different numbers, not one

A routing accuracy figure usually hides four separate failures with four separate fixes. Here is how to take them apart and which one to work on first.

Somebody says lead routing is about ninety per cent accurate. It is worth asking what the other ten per cent is, because it is almost always four different problems wearing one number, and they have nothing in common except where they were noticed.

The four

The address was never located. A typo, a new development, a rural address the geocoder does not know, a unit number in the street field. Nothing downstream had a chance, and no routing rule can fix it.

The address was located badly. The geocoder returned a point, and the point is the centre of a postal area or the middle of a long street rather than the building. The routing then works perfectly on a location that is a quarter of a mile from the truth. This is the failure that produces confident wrong answers, which is the worst kind.

The map was wrong. The point was right and the boundary was not: a gap nobody had noticed, an overlap resolved by an accident of ordering, a territory somebody moved last month.

The rule was wrong. Everything geographic worked, and the enquiry still went somewhere that could not handle it, because the rule did not know about a capability, a capacity limit or an hour of the day.

Four failures. Four fixes, in four different places, owned by different people. One number tells you nothing about which to work on.

Take them apart before you improve anything

The measurement that matters is not the total. It is the split, and getting it requires that a decision records enough to be classified afterwards:

  • Whether an address was located at all, and how precisely: a building, a street, or the centre of an area.
  • Which territories contained the point.
  • Which rule produced the outcome.

With those three, every misrouted lead sorts itself into one of the four buckets without anybody guessing. Without them, every investigation is an argument about what probably happened.

They are not equally expensive

A bad geocode is the most expensive per incident, because it is silent. Nobody reviews it. The answer looks exactly like a correct answer, and the only evidence is a complaint weeks later that will be blamed on something else. The mitigation is not a better geocoder, it is knowing the precision and refusing to treat a postal-area centroid as a rooftop.

An unlocated address is the cheapest, because it is loud. It can be queued, corrected, asked about. Systems that quietly fall back to a region centroid so that every address gets an answer convert this cheap failure into the expensive one. That is a bad trade dressed up as coverage.

A map error is usually systematic. One gap produces a steady trickle from the same neighbourhood, and it stays until somebody looks at coverage as a picture rather than as a list.

A rule error is usually recent. Somebody changed something. This is why the change history is worth more than it looks.

The number that is easier to move than accuracy

Time to correction. When a lead is misrouted, how long until somebody knows, and how long until the cause is fixed rather than the instance.

A network with eighty per cent accuracy and a same-day correction loop is in better shape than one at ninety-five per cent where nobody can explain a single failure. The first one is improving. The second one has a number.

What “accurate” cannot mean

It cannot mean that every address gets assigned. Some addresses are outside every territory, and saying so is the correct answer. A system tuned to assign everything has a perfect assignment rate and is lying about coverage, which surfaces later as jobs nobody could do.

The honest target is that every decision is either right or visibly refused, and that the refusals are counted. The refusals are also the most useful thing you have: a list of addresses where demand exists and coverage does not is where the next branch goes.

Related: geocoding precision is the input to all of this, and a serviceability API is where the refusals become visible.