811 Damage Prevention Software Problems: The 5 That Lose Damage Claims, and How to Avoid Them

Why does ticket screening get scoped as a polygon intersection?

Because that is what it looks like on a slide. A ticket has a work area, your facilities have geometry, the system intersects the two and dispatches a locator. Elegant, testable, and wrong for a large share of real tickets.

Real ticket text describes a work area in prose that ranges from precise coordinates to the alley behind the Baptist church. Some one call centres supply geometry and some do not. Descriptions reference landmarks, cross streets that do not exist in your basemap, and address ranges that resolve to three places. A screening engine that only intersects polygons will confidently clear tickets whose location it never actually determined, and that is the ticket where an excavator digs with no marks.

Screening decides everything downstream, and it fails in both directions at once. Screen too tightly and you miss tickets. Screen too loosely and you send locators to thousands of sites with no facilities, which is where the locating budget quietly disappears. Most utilities have both problems simultaneously in different parts of the territory, because buffers were set once by someone who has since retired and were never revisited.

What a competent design includes: geometry where the centre provides it, geocoding with fallback strategies where it does not, buffers that vary by facility type since a transmission main warrants a wider margin than a service line, an explicit confidence level on the location, and a manual review queue where ambiguity is surfaced rather than hidden. Then the loop that nobody builds: when a damage occurs, check whether screening had cleared that ticket, and tune the buffers against actual outcomes over a season. That feedback is the main advantage a build has over a bought platform, and it is invisible in a demonstration.

What goes wrong when your GIS facility data is not clean?

The screening engine produces confident wrong answers, which is worse than producing no answer, because a clear decision with a stated reason gets trusted.

Facility data in most utilities carries known problems that nobody has had budget to fix. Older service lines were recorded from paper sketches and sit tens of feet from where they are. Abandoned facilities are still in the layer with no attribute distinguishing them from live ones. Depth is missing or inherited from a default. Recent installations exist in a construction as built backlog that has not been posted to the operating layer, so the newest facilities are the ones the screening engine cannot see. Attribute schemas differ between systems acquired at different times.

The mistake is treating this as a data cleanup project that must finish before the software starts. It never finishes, and the project stalls waiting for it.

Run them together instead. Attribute a confidence level to each facility class and each area, and let screening buffer wider where confidence is low, so poor data produces caution rather than false clearance. Feed the as built backlog into the same pipeline, because a facility installed last month is the one most likely to be struck. And use the damage feedback loop to prioritise cleanup, since the areas that generate repeat damages regardless of locator are usually the areas where the map is wrong. That turns an open ended data programme into a ranked list with a business case.

Why do centre intakes and positive response feeds break after launch?

Because each state one call centre is a separate interface with its own format, transport and change schedule, and none of them will tell you before they change something.

The intake side breaks when a centre adds a field, reorders a section or alters how it encodes an emergency ticket. A parser that was written against last year's sample will either reject the ticket, which you notice, or misparse it, which you do not. Build a normalisation layer that turns every centre's ticket into one internal object, retain the original raw text forever because the original is evidence, and alert on parse anomalies as well as on failures.

The positive response side breaks more quietly and matters more, because that code is your legal statement about what you found. The common design has a dispatcher submit the code from a status field the locator updated at the end of the day from memory, so the code and reality drift apart, and the drift only surfaces when a claim is disputed. Submit positive response automatically from the locator's completion in the field, and retain the submitted code, its timestamp and the centre's confirmation as a record rather than a log line.

What happens when field evidence capture is not covered?

You keep paying claims you could have recovered, and you cannot tell which locator is responsible for which damages.

The claim file that wins a dispute has a specific chain: the original ticket text, the screening decision and its reasoning, the dispatch record, the locator's satellite positioning track of the actual walk, timestamped and geotagged photographs of the marks before excavation, the positive response submission with its confirmation, and your as built records. Photographs of the marks taken before the dig are the single most valuable artefact in the whole system, and almost nobody captures them systematically, which is why the contractor's post strike photographs showing no marks go unanswered.

The second loss is contractor management. Most utilities do not employ their locators, they contract them, and they are expected to manage quality across a workforce that does not report to them. Without field capture you cannot answer which locator has the highest damage rate per thousand tickets, which crews close tickets in implausibly short times, which areas produce repeat damages regardless of who locates them, or whether the contractor's invoiced count matches the tickets your system says were completed.

Offline operation is mandatory here, not optional. Locates happen in rural corridors, basements and construction sites with no coverage, so the app has to hold assigned tickets, capture tracks, photographs and notes offline and sync afterwards with the photograph metadata intact. A photograph whose timestamp and location were stripped during sync is much weaker evidence than one that arrived whole.

Should you build custom or configure what you already own?

If you take under roughly 20,000 tickets a year in a single state with straightforward facilities, configure a managed platform and spend the difference on locator training. Irth Solutions UtiliSphere is the most widely deployed option in North America and does the core job of intake, screening, routing, positive response and reporting. KorTerra covers similar ground with ticket management, dispatch and analytics. Pelican Corp brings depth from markets with different one call structures. At that volume the marginal value of a custom screening engine is low, because your whole territory is effectively one buffer rule.

ProStar PointMan sits in a different place, focused on precision satellite positioning capture of facilities as they are located and installed. That is the capability most utilities are weakest at, and it complements a ticket platform rather than replacing one, so it is worth evaluating alongside whatever you do about the lifecycle.

Build when you take tickets from several one call centres, when per ticket platform pricing at your volume has started to resemble a build budget every year, when you manage contract locators whose quality you cannot measure, when damage claims are lost or settled cheaply for lack of evidence, or when your facility data is good and you want screening tuned against your own damage outcomes rather than a vendor default. The consistent gap across managed platforms is ownership of two things: your geographic information system as the screening source of truth, and the evidence package.

How do hidden costs get into the quote?

Centres, counted as one. Each one call centre you receive from is an intake adapter, plus a clock rule set, plus a positive response integration, plus its own change schedule. A quote priced against your largest state has priced roughly a third of the work if you operate in three.

Clock arithmetic is the part that looks trivial and is not. Response windows are set by state statute, commonly around two full working days, with different rules for emergency tickets and for design or planning requests, and weekends, holidays and the definition of a working day all differ across state lines. A ticket arriving at 4:55pm on the Friday before a state holiday behaves differently in neighbouring states, and a dashboard built for one state will be wrong somewhere.

Then facility data remediation, which is a workstream rather than a task. Ticket volume, which drives real performance engineering once you are past a few thousand a day. And integration with work management, outage and financial systems for damage cost recovery.

For calibration, in Digital Heroes delivery experience a first release covering multi centre intake and normalisation, screening, dispatch with per state clocks and automated positive response runs $80,000 to $160,000 over 12 to 18 weeks. Adding the locator mobile app with satellite positioning and photograph evidence, contractor performance scoring, damage claim assembly and cost recovery takes it to $220,000 to $500,000 phased over 9 to 15 months.

What separates a build that works from one that fails here?

The ones that work start in the highest volume state with intake, screening and dispatch, then add states one at a time. The second state is far faster than the first because the abstraction already exists, and trying to launch four at once means every clock rule and ticket format argument happens simultaneously.

They give managers a queue of what will breach in the next few hours rather than a report at the end of the week. A response deadline you learn about after it passed is a compliance record, not a control.

They design the damage module as the reason the rest exists. A reported damage should link back to its ticket, pull the whole chain into one claim file automatically, compute repair and outage cost, track recovery and record the outcome. Those outcomes are what make screening tuning and locator scoring meaningful rather than theoretical.

They ask a developer how they would screen a ticket described only as the alley behind the Baptist church, and how the clock behaves at 4:55pm on the Friday before a state holiday. Those two questions separate people who have built this from people who will discover it in production.

And they settle ownership before kickoff. You should hold the repository, the database and the cloud accounts, in writing. At Digital Heroes the client owns the code from the first commit. Ticket, locate and damage records are evidence that can be subpoenaed years later and carry long retention obligations, so they cannot live only in a vendor's environment.