Utility Locate Ticket Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does proof of locate get scoped as photo upload?

Because photographs feel like evidence and they are cheap to specify. The requirement says the locator attaches images to the ticket, everybody nods, and the system ships with a camera button. It is the most common scope failure in damage prevention software and it only reveals itself when a claim lands.

A photograph on its own proves almost nothing. Paint and flags disappear within weeks, so an image of marks in a field says little about position months later. What holds up is a structured record: device captured position at the moment of capture, the facility types marked with the colour used for each, the extent of the area marked, whether the excavator had white lined the site, the presence of the excavator's own markings, and site conditions on arrival. Photographs attach to that record rather than standing in for it.

Two details decide cases and both are unglamorous. Offset measurements from something that will still exist in six months, meaning a pole, a curb line or a building corner. And explicit negative findings, because documenting that you marked a portion of the dig area and found no facilities is as important as documenting what you did mark.

The fix is to write those fields into the acceptance criteria before design starts, and to demand the capture works fully offline. Locators work in trenches, in rural corridors and in urban canyons where signal drops. A field application that needs connectivity gets abandoned within a month and replaced by the phone camera you were trying to eliminate.

What goes wrong with the facility geometry your screening depends on?

Automated screening is the highest return feature in the whole system, because it clears the tickets whose dig polygon does not intersect anything you own and stops locators driving to empty sites. It is also entirely dependent on knowing where your plant actually is.

The failure is not that your records are bad everywhere. It is that they are unreliable in specific places and nobody has written down which. Older plant digitised from paper, anything acquired from another operator, and corridors rebuilt before the as-builts were posted are all candidates. Screening logic with a single global buffer treats all of it identically, so it is either too conservative everywhere, which wastes the benefit, or tight enough to auto clear a ticket over plant that sits several feet from where the map says.

The second failure is that auto clear decisions are not recorded with the geometry that produced them. Two years later, when a cleared ticket has become a strike, the question is what the system knew at the time, and showing today's mapping is not an answer.

Fix both together. Make the buffer a confidence rule that varies by facility class and by area, conservative where your data is known to be weak and tighter where it is good, and log every decision with the facility layer version and the rule that fired. Then close the loop: when a locator arrives and finds nothing, record that as evidence about mapping quality in that area rather than shrugging. If your geometry is not in usable condition at all, the correct first project is remediation with a documented confidence rating per area, not an application. Screening on unreliable geometry produces automated confidence in the wrong answer.

Why do one call feeds and positive response break after launch?

Ticket intake looks like a solved problem until you count the centres you receive from. Each has its own format, its own quirks and its own delivery mechanism, and some still send file drops or email rather than an interface. A parser built against last quarter's sample breaks when a centre adds a field, changes a delimiter or lengthens a description, and it breaks silently, which is the dangerous part. A ticket that fails to parse is a ticket with a running statutory clock that nobody can see.

Positive response fails differently. It works, then a centre changes a code list, or a completion posted in the field does not reach the centre because a queue stalled overnight. The excavator checks status, sees nothing, and 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.

The preventions are specific. Never discard an unparseable ticket. Route it to a queue with an alert and a human, because an unread ticket is worse than a malformed one. File positive response automatically the moment the locate record completes in the field, with the accurate code rather than a generic one, and reconcile daily between completions in your system and responses accepted at each centre, so a stalled queue surfaces the same morning. Ask any developer which centres and which response mechanisms they have handled by name, because there is a large difference between a modern interface and a nightly fixed width file and both still exist.

What happens when the state response clock is not modelled per jurisdiction?

Excavation notice law is 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 stay valid and what a remark request does all differ by jurisdiction and by centre. An operator across three states runs three rule sets.

Generic work order tools handle this with a due date field that somebody sets, and it fails in the predictable way. A ticket lands late on the Friday before a holiday, the person calculating the deadline was thinking in calendar days, and the response goes out after the excavator has already started. The other failure is that alerting fires on breach rather than before it, which produces an incident log rather than a dispatch system.

Model the deadline as a computed value with a stated derivation: jurisdiction rule, ticket type, receipt timestamp and that state's working day calendar. Publish the derivation alongside the date so a supervisor can see why a ticket is due when it is due. Then escalate on predicted breach, using current queue depth and travel time, so late risk surfaces hours before it happens and reaches a supervisor who can move a locator rather than an unattended inbox. Where a utility client or an internal standard is tighter than the statute, hold both deadlines separately so nobody confuses the two.

Should you build custom or configure what you already own?

If you take a few thousand tickets a year in one state with one facility type, buy. Irth Solutions and KorTerra both handle ticket management, screening and workflow at serious volume, they have already absorbed the tedious work of parsing dozens of centre formats and posting positive response, and a build would cost more than the problem. PelicanCorp covers similar ground with a strong international footprint. ProStar comes at it from precision capture and mapping of buried assets, which is a complementary angle rather than a competing one.

If your facility geometry is not in usable condition, buy and spend the difference on remediation. No screening logic saves you from records that are several feet out, and buying a product is the cheapest way to keep operating while the data gets fixed.

Build when the volume is six figures a year, when you receive from multiple centres across multiple states, when screening quality depends on data confidence rules that a configurable global buffer cannot express, or when you have already had a strike you could not defend and the exposure has become a board level number. Even then, the sensible target is the layer where your geometry, your rules and your other systems meet, not a rebuild of ticket parsing.

How do hidden costs get into the quote?

Centre count is the first. A proposal that prices ticket intake as one line has not counted your centres, and each one is a format, a delivery mechanism, a positive response path and a set of quirks discovered in production. Ask for the price per centre.

State count is the second, for the same reason as centres: each is a rule set and a holiday calendar rather than a setting.

Then the ones that surface later. Geographic data work, where consuming live facility layers from an Esri environment is materially harder than reading a monthly export, and where remediation may be a prerequisite rather than an option. Write-back into an existing work management system, which is heavier than producing a file. Rugged device testing if your field kit is unusual. And offline synchronisation done properly, which is a design decision rather than a checkbox and is the single thing that decides whether locators use the application at all.

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

Start narrow. One state, your highest volume facility class, and the screening decision proven before anything else is built. Measure the share of tickets that need no field visit before you fund a routing solver, because that number is the business case and it varies enormously by operator and geography.

Interview developers on the failure modes rather than the features. Ask how they decide whether to auto clear a ticket, and listen for whether facility data confidence by area comes up unprompted. Ask what the field record contains beyond photographs, and expect offset measurements from permanent references and explicit negative findings in the first answer. Ask how the application behaves after four hours with no signal, and expect a real synchronisation design rather than a promise.

Keep a manual override on assignment with a required reason, because dispatch systems that cannot be overridden get worked around within weeks, and a documented override is far more useful than a rule everyone quietly ignores.

Settle ownership of the code, the data and the cloud accounts in writing before kickoff. A good next step costs an afternoon: pull one recent damage claim, put the actual ticket, the assignment record and the field photographs on a table, and ask a candidate developer to show you precisely which fields their system would have captured that would have changed the argument.