811 Damage Prevention Software: Can You Prove the Marks Were Right Two Years Later?

The moment your programme is actually judged

An excavator hits a gas main. Nobody is hurt, this time. Within a week you are in a dispute where the contractor states the marks were absent, wrong or faded, and your locator states the facility was marked correctly and the excavation was outside the tolerance zone. That tolerance zone is a defined distance either side of the mark in your state's statute, commonly around 18 to 24 inches, and the whole argument turns on where the marks were versus where the bucket went.

Your evidence, right now, is a ticket text file, a positive response code submitted to the one call centre, a locator who remembers a Tuesday from fourteen months ago, and if you are lucky some phone photos in a folder named by date. The contractor has photos too, taken after the strike, which show no marks because the strike destroyed them.

That is the case you are defending, and everything upstream in the 811 process exists to make that moment survivable. Repair cost, outage cost, third party claims, regulatory attention under the pipeline damage prevention requirements, and in the worst case a fatality investigation all funnel through the quality of the record you kept before anybody knew there would be a dispute.

Why ticket volume alone breaks a manual process

A mid sized utility takes thousands of tickets a day in dig season. Each one arrives as text from a state one call centre in that centre's format, describing a work area in prose that ranges from precise coordinates to a description like the alley behind the Baptist church. Some fraction of those tickets touch your facilities. Most do not.

Screening decides everything downstream. Screen too tightly and you miss a ticket, which is the scenario where an excavator digs with no marks and hits your main. Screen too loosely and you send locators to thousands of sites with no facilities, which is where your locating budget quietly disappears. Every utility we have worked with has both problems simultaneously, in different parts of the service territory, because screening buffers were set once by someone who has since retired and were never revisited against actual outcomes.

The clock is the other pressure. 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. Weekends, holidays and the definition of a working day differ across state lines. If you operate in four states, you are running four sets of clock arithmetic, and a manager tracking that in a dashboard built for one state is going to be wrong somewhere.

Positive response and the contract locator problem

Many states require you to post a response code back to the one call centre saying what you found: marked, no conflict, could not gain access, and so on. The code is your legal statement. When it is submitted by a dispatcher from a status field that the locator updated at the end of the day from memory, the code and reality can drift.

Most utilities do not employ their locators directly. You contract them, and you pay per ticket or per hour, and you are supposed to be managing quality across a workforce that does not report to you. The questions you cannot currently answer with data: which locator has the highest damage rate per thousand tickets, which crews are closing tickets in improbably short times, which areas produce repeat damages regardless of who locates them, and whether the contractor's invoice count matches the tickets your system says they completed. Every one of those questions is answerable if the field capture is right and unanswerable if it is not.

What Irth, KorTerra, Pelican and ProStar actually deliver

• Irth Solutions UtiliSphere is the most widely deployed ticket management platform in North America and it does the core job: intake from one call centres, screening, routing, positive response and reporting. It is a managed product with pricing that generally scales with ticket volume, which is exactly why high volume operators start doing the arithmetic on building. Screening logic, workflow and reporting work their way, and changes to fit your operation go through their roadmap rather than yours.
• KorTerra covers similar ground with ticket management, dispatch and analytics. Same shape of trade off: solid product, their model, your operation adapts.
• Pelican Corp brings real depth from markets with different one call structures. That is a strength in breadth and a consideration in fit, since North American state by state variation is the specific thing you need modelled well.
• ProStar PointMan is a different animal, focused on precision GPS capture of facilities as they are located and as they are installed. That capability is genuinely valuable and it is the part most utilities are weakest at. It is not a ticket lifecycle platform, so it complements rather than replaces the rest.

The consistent gap across the managed platforms is ownership of two things: your GIS as the screening source of truth, and the evidence package. Screening quality depends on buffer rules tuned against your own damage history, which requires joining ticket outcomes back to facility data you control. And a defensible claim file needs ticket text, screening decision, dispatch record, locator GPS track, timestamped photos, positive response submission and your as-built records assembled as one artefact. That artefact is what wins a subrogation case, and assembling it by hand from four systems after a strike is how programmes lose recoverable money.

What a custom damage prevention platform must include

Intake first. Each state one call centre delivers tickets in its own format over its own transport, and the formats change. Build a normalisation layer that turns every centre's ticket into one internal object with a common structure, retaining the original raw text forever because the original is evidence. Ticket types matter: normal, emergency, update or remark, design, and no response tickets each behave differently and each has its own clock.

Screening is the highest value engineering in the system. Parse the work area geometry where the centre provides it, geocode where it does not, buffer against your facility layers with rules that vary by facility type since a transmission main deserves a wider buffer than a service line, and produce a clear decision with the reasoning recorded. Then close the loop: when a damage occurs, feed it back and check whether screening had cleared that ticket. Over a season that feedback tunes your buffers against real outcomes rather than against a guess made years ago. This is the single feature that separates a build from a bought platform, because it requires your GIS, your damage history and your rules together.

Dispatch and clock management need to be per state and per ticket type, with the due time computed against that state's working day definition and holiday calendar. Locator workload should balance across the day with priority by clock risk rather than by arrival order. Managers need a queue that shows what is going to breach in the next four hours, not a report at the end of the week.

Field capture is where the evidence gets made. The locator app records the GPS track of the actual locate walk, photographs the marks with timestamp and location embedded, records the equipment used and the sweep pattern, notes conditions like snow or existing paint, and captures the tolerance zone context. Offline operation is mandatory. Photos of marks taken before the excavation is the single most valuable artefact in a damage dispute and almost nobody captures them systematically today.

Positive response submission should be automatic from the locator's completion in the field, not re-entered by a dispatcher. The response code, the timestamp and the confirmation from the centre all get retained.

Then the damage module. A reported damage links back to its ticket, pulls the whole chain into one claim file, computes repair and outage cost, tracks the claim through recovery and records the outcome. That outcome data is what makes your screening tuning and locator scoring meaningful instead of theoretical.

Cost, timeline and what moves the number

A first release with multi centre intake and normalisation, GIS screening, dispatch with per state clocks and automated positive response runs $80,000 to $160,000 over 12 to 18 weeks. The full platform adding the locator mobile app with GPS and photo evidence, contractor performance scoring, damage claim assembly and cost recovery runs $220,000 to $500,000 phased over 9 to 15 months.

What raises cost: the number of one call centres you receive from, since each is an intake adapter plus a clock rule set plus a positive response integration. The condition of your GIS, because screening against incomplete or inaccurate facility data produces confident wrong answers, and cleaning that is its own workstream. Ticket volume, which drives infrastructure and performance engineering once you are past a few thousand a day. And integration with your work management, outage and financial systems for damage cost recovery.

What reduces cost: start in your highest volume state with intake, screening and dispatch. Add states one at a time; the second one is much faster than the first because the abstraction already exists.

One economic note specific to this category. Because managed platforms commonly price per ticket, the build case strengthens as volume rises. Run your own arithmetic on your current annual platform spend against a one time build plus hosting and support. At a few hundred thousand tickets a year the comparison usually stops being close.

When you should buy instead

Buy when you take a modest ticket volume in a single state with straightforward facilities. The managed platforms handle that well and the marginal value of a custom screening engine is low if your whole territory is one buffer rule.

Build when you operate across several one call centres, when your ticket volume makes per ticket pricing painful, when you manage contract locators whose quality you cannot measure, when your damage claims are lost or settled cheaply for lack of evidence, or when your GIS is good and you want screening tuned against your own damage outcomes rather than a vendor default.

How to choose a developer

Ask how they would screen a ticket whose work area is described as the alley behind the Baptist church with no geometry attached. If they only describe polygon intersection, they have not seen real ticket text. The answer involves geocoding, fallback strategies and a manual review queue with the ambiguity surfaced rather than hidden.

Ask how the clock handles a ticket that arrives at 4:55pm on the Friday before a state holiday in one state while the same ticket type behaves differently in the neighbouring state. That question separates people who have built this from people who will discover it in production.

Ask what the locator app captures that would matter in a deposition. If GPS track and timestamped mark photos are not in the first three answers, they do not understand what the system is for.

Ask who owns the code, the data and the cloud accounts, in writing, before kickoff. Ticket and locate records are evidence with long retention needs and can be subpoenaed years later. At Digital Heroes the client owns the repository from the first commit. A useful first step is to send us a week of raw tickets from your busiest one call centre plus your facility layer schema, and we will show you what your screening engine would actually look like.