Sales keep selling broadband at addresses we cannot actually serve, and the order fails at survey. What is wrong with the inventory behind that?

Serviceability is four questions pretending to be one

The reason the order fails at survey is that somebody answered a compound question with a single boolean. "Can we serve this address" decomposes into four questions with different owners, different data sources and different confidence, and each of them fails differently.

The first is whether the address exists and is the one the customer means. The second is whether the network physically reaches it, which is a question about presence in the street, the distance and route to the premises, and whether the final drop into the building exists or has to be built. The third is whether there is spare capacity on the specific piece of network that would serve this premises — not in the exchange, not in the area, but on the particular card, splitter, cabinet or radio sector that this address would land on. The fourth is commercial and regulatory: whether you are permitted and willing to sell there, which covers wholesale product availability, any access agreement with the building owner, a moratorium during a planned upgrade, and whether the address falls inside a footprint you have agreed to serve.

A quoting system that returns yes when the answer is "the network passes the street" will sell orders that fail at every one of the other three. So the first thing to fix is the shape of the answer, and the honest form of it is a per-question result with a reason, not a flag.

The address model is usually the actual defect

Engineers reach for the network model, and in practice most fallout of this kind begins with premises data. The network knows where its equipment is; the difficulty is deciding which premises that equipment serves.

Addresses arrive from several places at once — a national address register, the incumbent access provider's own dataset, the sales channel's typed input, a marketing list, and whatever the customer wrote — and they disagree. So the premises has to be a first-class entity in the inventory with a stable identifier of its own, to which the various external identifiers are attached as aliases rather than being used as the key. In Great Britain the Unique Property Reference Number gives you a persistent public identifier for a property, and having something of that nature to anchor on is what makes the aliases reconcilable at all. Without a premises entity, every system holds its own string, and two of them will never agree about whether Flat 2, 14 High Street is a premises you can serve.

The specific cases that generate most of the failures are worth naming because they recur in every market. Sub-addresses in multi-dwelling buildings are the largest: a block appears as one address in one dataset and as forty flats in another, so a serviceable building becomes forty serviceable premises or one, and neither is right. New-build developments exist physically before they exist in any register, so they cannot be matched at all and are frequently sold on the strength of a neighbouring address. Conversions split one premises into several without either register updating. Non-residential and shared-service addresses behave differently again. And geocoding a string to a point on a map will happily place a premises on the wrong side of a boundary that decides which cabinet serves it.

Capacity is not presence, and free is not available

The second recurring cause is treating the network's reach as its ability to take another customer. Those diverge constantly.

Spare capacity has to be counted on the exact resource in the path, and the path is a chain: a spare port on an access node is useless if the fibre or copper to the premises does not exist, if the splitter serving that route is full, if the backhaul is at its planned limit, or if the address is beyond the reach at which the product's speed can be delivered. In fixed wireless and mobile the equivalent is a sector's loading rather than a port count. So a serviceability answer has to be computed along the whole path to that premises, and the number it depends on is the smallest remainder in the chain.

Then there is the difference between physically free and actually available. A port may be counted as spare while it is reserved for another in-flight order, held for a planned migration, faulty and awaiting repair, deliberately kept as a spare for restoration, or occupied by a service that was ceased in the billing system and never released in the network. That last category — records ceased commercially but never physically recovered — is the reason field engineers find live traffic on ports the record calls free, and it is the same decay that makes the number untrustworthy in the other direction, because capacity you have but cannot see is capacity you will pay to build again.

Cached answers rot without telling anyone

Serviceability is expensive to compute along a full path, so almost every operator pre-computes it into a lookup that the sales channels query. That is a reasonable design, and it introduces the failure that produces the most surprising cases: the cached answer is a snapshot, and nothing in the sales journey knows how old it is.

Capacity moves every day as orders complete and services cease, network build changes reach, planned work makes areas temporarily unavailable, and address data is refreshed on a slower cycle than any of it. So a pre-computed answer needs an as-at timestamp, a validity period, and a rule about which questions may be answered from cache and which must be asked live. Capacity in particular is a poor candidate for caching at the point of sale, because it is exactly the value that two orders can consume between refreshes. The workable pattern is to answer reach and address questions from the pre-computed view for speed, check capacity live at the point of commitment, and reserve it against the order at that moment rather than at fulfilment, so the reservation is what protects the promise.

Diagnose by fallout reason before you fund anything

The trap in this scenario is agreeing to improve inventory data quality in general, which is unbounded, unmeasurable and unfundable. The correct first move is to make the failure legible: classify every failed order by which of the four questions was wrong, at what stage it was discovered, and at what cost.

That classification changes the decision entirely. If most failures are address-matching, the money goes on premises data and sub-address handling, and no amount of network survey helps. If most are capacity, the problem is release and reservation discipline, and the fix is in process rather than in data. If most are the final drop into the building or the reach limit, the answer may be that the network genuinely cannot serve those addresses and the quoting rules are too generous. If most are commercial, someone is selling outside an agreement and it is not an inventory problem at all.

The metric that follows from this is not data accuracy but the cost of a wrong yes against the cost of a wrong no. A wrong yes costs a survey visit, an appointment the customer took time off for, a cancellation and often the customer. A wrong no costs a sale you never knew you lost, which is invisible and therefore systematically underweighted. Naming that asymmetry, and deciding where your organisation wants to sit on it, is the judgement the question is really asking for — and the middle position, quoting with a stated confidence and a survey step before any promise is made, is available and usually the right answer for the hard cases.

Answer serviceability as four separate questions with reasons attached, keep the premises as an entity rather than a string, and check capacity at the moment you commit. Then measure fallout by cause, because "improve the inventory" is not a plan.