The repeat caller keeps arriving as a brand-new customer

The matcher is looking for the wrong object. A trades business does not serve people, it serves addresses with equipment in them, and the person on the phone is whoever happened to pick it up this time. Match on the caller and you get a new record every time the husband rings instead of the wife, the tenant instead of the landlord, or the site manager instead of head office.

The cost is not the tidy database. It is the membership that does not apply, the two-year-old install nobody sees, the technician arriving without the model number, and the follow-up sequence firing at a customer of six years as though they were new — which is one of the ways review requests fire at the wrong moment.

Confirm it before you change the matcher

Two measurements. The first tells you how big the problem is and where it enters; the second tells you which field is failing. Neither takes longer than an afternoon.

1. Compute a duplicate rate by acquisition channel. For every customer record created in the last 90 days, test whether a customer already existed at the same normalised service address. Split the result by channel — phone agent, web form, technician-created, imported — because a blended figure hides which one is bleeding.
2. Pull 50 near-duplicate pairs at random from that set. For each pair, record exactly which fields matched and which differed: number, surname, street line, unit designator, postcode, equipment serial.
3. Tally the differing field. One field usually accounts for more than half the pairs, and that tally is your ranked cause list rather than the generic one below.
4. Check the agent's read scope before anything else. Confirm by reading the credential, not by asking, that the intake agent can query customers and service history at all. An agent with write access and no read access produces a duplicate on every call, and the symptom looks identical to a bad matcher.

Five causes, ranked by how often they turn out to be it

The first two dominate almost everywhere. Caller ID fails because a number identifies a handset, not a household: two adults share a landline, a mobile is ported between people, a landlord's number appears on jobs at addresses they will never visit, and withheld or spoofed numbers arrive with nothing at all. Address matching fails because nobody normalises before comparing, so 'Flat 2, 14 Oak St' and 'Apt 2 14 Oak Street' are different strings and therefore different customers.

That second failure has a twin worth knowing about, because it is the same broken address doing two jobs. An address that will not normalise usually will not geocode either, so the same call that creates a duplicate also passes a boundary test it should have failed — the mechanism behind jobs booked ninety minutes outside the service area. Fix normalisation once and both symptoms move.

The match order an agent can actually run mid-call

Three signals, in strength order, each one narrowing the last. The agent stops at the first unambiguous hit and spends no further conversational turns on identity.

1. Normalise the inbound number to a single canonical form — E.164 is the usual choice — and look it up, so a national format and an international one collide rather than diverge. One match is a candidate, not a decision. Zero means continue; more than one means continue, and do not guess.
2. Ask for the service address, normalise it, and match on the location. This is the real key. Parse to structured components — building, unit, thoroughfare, locality, postcode — expand abbreviations on both sides, and compare the components rather than the string. Then geocode and treat coordinates within a few metres as the same place even when the text disagrees.
3. If the address still resolves to two or more records, ask about the equipment. What is on the plate, where the unit sits, roughly when it went in. Equipment is the strongest identifier a homeowner can supply from memory and the one an existing customer usually answers instantly.
4. Confirm before writing. One question, phrased against something the caller can verify, and an explicit fallback to a new record when the answer is no.
5. Write a link, never a merge. If two records still look like one place, attach the job to the more complete record and flag the pair for review with both identifiers. Merging is a reviewed operation with an undo path, not something decided in the eleventh second of a phone call.

The one question that resolves most calls

The failure here is asking a question that puts the burden of matching on the caller. 'Are you an existing customer?' gets an unreliable yes from people who called a different company two years ago and a no from people whose partner booked the last visit. Ask instead about a fact the record already holds.

• Anchor on the place. 'Is this for the property on Oak Street?' A caller either recognises the address or does not, and there is no judgement involved.
• Anchor on the equipment when the address is ambiguous. 'Is this the unit in the loft, or the one in the garage?' Two units at one address is exactly the case a pure address match cannot split.
• Anchor on the last visit only when it was recent. 'We were with you in March about the boiler pressure — same property?' Beyond a few months this reads as surveillance rather than service.
• Never read back a full address to an unverified caller. Offer the street or the first line and let them complete it. This costs nothing conversationally and is the difference between confirming a record and disclosing one.

One caution on where these questions sit. Identity work belongs after the caller has said what is wrong, not before it. Front-loading verification into the opening turn is one of the reliable ways to lose the call outright, which is the pattern in callers hanging up in the first eight seconds. Take the problem first, match while they talk, confirm once.

A phone number tells you which handset dialled. It does not tell you which house has no hot water, and the house is the thing you are being asked to fix.

The model that stops it recurring

Most platforms already separate these objects and most operators use only the first. If your records collapse them, no matcher will hold, because the matcher is being asked to make one row mean four things.

The tenant-versus-owner case is where this earns its keep. The occupier is the contact who must be called to arrange access; the landlord or agent is the customer who authorises and pays. Modelled as one row, whichever of them rings last overwrites the other. A third-party warranty dispatch has the same two-party shape for a different reason, set out in why a home warranty dispatch books differently.

What to build, and what to leave alone

The deliverable is small and specific: one match service, called by every channel, returning a ranked candidate list with a score and a reason per candidate. Phone, web form and technician app all call the same endpoint, because three matchers guarantee three definitions of duplicate. Behind it sits a review queue with a named owner, a daily clearing time and a merge that can be undone. Against a platform like ServiceTitan, Jobber or Housecall Pro that is a narrowly scoped piece of internal tooling and operations software reading the operator's own API access, not a migration.

Two things to leave alone for now. Do not attempt a retrospective mass merge before the inbound rate is fixed, or you will merge into a system still producing new pairs. And do not confuse this with reconciling records across two systems after a migration, which has different keys and belongs with platform integration and data.

The rest of the intake path — what a booking must capture, how tiers are decided, what an agent may promise — is mapped across intake and call capture, within our field service and trades work.

• intake
• customer data
• deduplication
• voice agents