Utility Locate Ticket Software: When a Backhoe Hits Your Line and the Proof Is a Photo

The strike, and the file you cannot produce

A directional bore clips a fiber trunk on a Thursday afternoon. Eleven thousand customers drop. Within an hour the excavator's position is that the line was not marked. Your position is that it was, by a locator, eight days ago. The proof is a photograph on a phone that shows orange paint on asphalt, no scale, no landmark, and a timestamp that the phone's camera app set from a clock nobody can vouch for. The ticket is in one system, the assignment is in a spreadsheet, the locator's notes are a free text field, and the facility record he was working from is a PDF map printed the previous month.

You will spend the next three weeks assembling a defense file by hand, and the outcome will depend on whether a specific locator remembers a specific afternoon. That is the state of damage prevention at a lot of otherwise sophisticated utilities and telecom operators.

The economics are not subtle. A severed fiber trunk is restoration cost plus service credits plus a reputational event. A gas incident is a different category of consequence entirely. Meanwhile the volume side of the problem is grinding: tickets arrive continuously from the one call centre, most of them nowhere near your plant, and a locator's day gets consumed by driving to sites where you have no facilities at all.

Problem 1: this is a screening problem before it is a dispatch problem

Every dig ticket that arrives has to be answered, but most of them do not need a locator. The excavation polygon simply does not intersect anything you own. In operations that have not automated this, a human reads tickets and makes that call, or worse, everything gets assigned and locators discover the answer by driving there.

Automated screening means intersecting the ticket's dig area against your facility geometry with a buffer you set, and clearing the ones that miss. The clearance rate varies enormously by operator and by geography, but at every utility we have looked at, the share of tickets requiring no field visit is large enough that automating the decision is the single highest return feature in the whole system.

The reason this cannot be bought generically is the buffer logic and the confidence question. Your facility records have known accuracy problems in specific areas, usually older plant and anything acquired. Screening logic has to be conservative where your data is weak and can be tight where it is good, and only you know which is which. A build encodes that as a per area or per asset class confidence rule rather than one global buffer, and it logs every auto clear decision with the geometry it used, because the day you auto clear a ticket and something gets hit, that log is the entire conversation.

Problem 2: the response clock is state law and your queue does not know it

Excavation notice laws are set state by state. The notice period, how working days are counted, what a holiday does to the clock, what an emergency ticket means, how long marks remain valid, and what happens on a remark request all differ by jurisdiction and by one call centre. An operator working across three states is running three different rule sets, and a locating contractor may be running a dozen.

Spreadsheets and generic work order tools handle this with a due date field that somebody sets. That fails in exactly the predictable way: a ticket lands late Friday before a holiday, and the person who calculated the due date was thinking in calendar days. A build encodes the clock as a rules engine per state and per centre, computing the response deadline from the ticket type, the receipt timestamp, and the working day calendar, then driving escalation off that. Late risk should surface hours before the breach, not after, and the escalation should reach a supervisor who can move a locator rather than an inbox.

Problem 3: proof of locate is a photo with no context

The field artifact is where most of these systems are weakest, and it is where the money is. A photograph on its own proves almost nothing. What a defensible record looks like is structured: device captured GPS at the time of capture, the facility types marked and the APWA colour used for each, the extent of the area marked, whether the excavator had white lined the site, measurements from a permanent reference point, the presence of the excavator's own markings, and site conditions. Photos attach to that record rather than being the record.

The two details that decide cases are boring. First, offset measurements from something that will still be there in six months, a pole, a curb line, a building corner, because paint and flags disappear and a photograph of paint in a field proves nothing about position. Second, the negative response: documenting that you marked and that you found no facilities in a portion of the dig area is as important as documenting what you did mark.

Any build should also capture this offline. Locators work in trenches, in rural areas, and in urban canyons where the signal drops, and a field app that requires connectivity will be abandoned within a month and replaced by the phone camera you were trying to get rid of.

Problem 4: routing by geography ignores the clock

The common assignment model is territory: each locator owns an area and takes what lands in it. It is simple and it is wrong at volume, because ticket density is not uniform and clocks are not uniform. One locator ends a day with six tickets due tomorrow morning while a neighbouring territory has capacity.

Routing should optimise against the deadline first and the drive second, with priority weighting for facility risk, so a ticket near transmission gas outranks a ticket near a residential drop even when both are due the same day. Emergency tickets preempt. In a build this is a solver over time windows and travel time, and it does not need to be exotic to beat a territory map. What it does need is honest travel time and a rule that a locator can override with a reason, because dispatch systems that cannot be overridden get worked around.

Problem 5: positive response and the excavator relationship

Most states require you to report your response status back to the one call centre, and excavators check it before digging. When positive response is filed late or filed as a generic code, the excavator either waits, which costs them, or digs, which costs everyone. This is the part of the workflow that most directly changes damage rates and it is usually the least engineered.

A build files positive response automatically the moment the locate record is completed in the field, with the accurate code, and pushes an equivalent notification to the excavator if you keep contact details. Going further, an excavator portal that shows the mark status, the marked area, and a direct line to raise a remark request converts the adversarial relationship into a working one. Utilities that do this well also start collecting the excavator's own evidence, which is very useful the day a claim is filed.

What Irth, KorTerra, PelicanCorp and ProStar actually do

These are established products and they solve real parts of this. Irth Solutions and KorTerra both handle ticket management, screening, and workflow at serious volume and are the default answer for a mid sized utility, and if your operation is standard they will beat a build on cost and time to value. PelicanCorp works across similar ground with strong international presence. ProStar comes at it from precision capture and mapping of buried assets, which is a different and complementary angle.

Where they stop is your facility data and your rules. Screening quality depends on how the buffer logic treats your specific data quality problems, and a configurable global buffer is a blunt instrument compared to per area confidence rules. Deep two way integration with your GIS, your work management system, and your outage or claims systems is where change requests pile up. Contract locating firms hit a different wall: their business logic is per client service level agreements, per client billing units, and locator productivity economics, which no ticket management product models properly because it was built for the utility side of the relationship.

What this costs and how long it takes

A first release with ticket ingest from your one call centres, automated screening against facility geometry, deadline aware assignment, and an offline field app producing structured proof of locate runs $60,000 to $140,000 over 12 to 16 weeks. The full platform adding positive response automation, an excavator portal, damage investigation case files with claims packaging, contractor and locator scorecards, and integration with GIS and work management runs $150,000 to $400,000 across 6 to 12 months.

What pushes cost up in this category: the number of one call centres you receive from, because each has its own ticket format and its own quirks and each is real integration work; the number of states, because each is a rule set; the quality and accessibility of your facility geometry, which is the single largest determinant of whether screening works at all; and whether you need to write back into an existing work management system rather than standing alone. What keeps cost down: start with your highest volume state and one facility class, and prove the screening clearance rate before building the routing solver.

When buying is right, and how to choose a developer

Buy if you take a few thousand tickets a year in one state with one facility type. KorTerra or Irth will do it for a fraction of a build and you should not be writing software for this. Buy if your facility geometry is not in usable condition, because no screening logic saves you from bad data and the correct first project is a GIS remediation, not an application.

Build when the volume is six figures annually, when you are across multiple states or one call centres, when you are a contract locating firm whose entire margin sits in screening accuracy and locator productivity per client, or when you have already had a strike that you could not defend and the legal exposure has become a board level number.

When you interview developers, ask how they would decide whether to auto clear a ticket, and listen for whether they raise facility data confidence by area. A developer who describes a single global buffer has not thought about the failure mode where you auto clear a ticket over 1960s plant that is 12 feet off where the map says.

Ask what the field record contains beyond photographs. If offset measurements from permanent references and explicit negative findings are not in the first answer, they have not read a damage claim file. Ask how the app behaves with no signal for four hours, and expect a real offline sync design rather than a promise.

Ask who owns the code, the data, and the cloud accounts, and get it in writing before kickoff. At Digital Heroes the client owns everything from the first commit and can hire anyone else to continue the work. A good next step is to pull one recent damage claim, put the actual ticket, assignment record, and field photos on a table, and ask a developer to show you precisely which fields their system would have captured that would have changed the argument.