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

Why does the multi-client model get discovered at client three?

Because the first version is always built for the client in front of you. Their service level, their evidence expectations, their quality sampling rate and their invoicing basis get written into the workflow, and it works beautifully for one contract. Client two arrives with a rule about calling the excavator before marking on high priority ticket types, client three wants a different remark rule that applies only to their transmission assets, and each one becomes a code change or a note in a dispatcher's head.

The reason this hurts a locating contractor more than a utility is that your business is the portfolio. Growth means adding contracts, and if every contract costs engineering time, growth is throttled by a development queue. Worse, rules applied from memory are applied inconsistently under load, and the day they are applied inconsistently is a day with two thousand tickets on it.

The fix is a modelling decision made before any code is written. Client is a dimension across the entire system, and rules, service level overlays, evidence requirements, quality sampling rates, invoicing basis and report formats all hang off the client record. Put a test in the plan and hold the build to it: onboarding the second client must require configuration only. If it requires engineering, the model is wrong and it should be corrected before client three, because the cost of fixing it rises with every contract you sign on top of it.

What goes wrong with the client facility layers you screen against?

Screening decides your margin, and screening reads somebody else's data. Most contractors receive a periodic export of the client's facility layers, and the gap between that export and reality is where both wasted visits and no-locates live.

Three things go wrong. The export is stale, so a corridor rebuilt last quarter shows the old configuration. The export is inconsistent, because a client reorganises layers or renames a feature class and the load silently drops a category. And nobody records which version of the layer produced which decision, so a damage that surfaces two years later is investigated against today's mapping rather than against what the system actually knew.

The other data problem is what you are carrying forward. Years of ticket history, completions and photographs sit in the incumbent product, and they are the evidence for claims that have not been filed yet. A migration that moves open tickets and leaves history behind creates a period you cannot defend.

Fix it by versioning every facility layer load with a timestamp and a checksum, refusing a load that drops a feature class rather than accepting it quietly, and stamping every screening decision with the layer version and the rule that fired. On migration, move the historical evidence with the operational data and verify a sample end to end, including that photographs still resolve. Then close the loop on quality: when a locator arrives and finds nothing, record it as evidence about mapping accuracy in that area rather than as a shrug, because over a year that feedback is what actually moves your unbillable visit rate.

Why do centre feeds and client system integrations break after launch?

You receive from multiple one call centres and each has its own format, its own delivery mechanism and its own positive response path. Some still send file drops or email rather than a modern interface. A parser built against last quarter's samples breaks when a centre adds a field or lengthens a description, and it breaks quietly, which is the dangerous version. A ticket that fails to parse is a ticket with a running statutory clock and nobody looking at it.

Positive response breaks in the other direction. A centre revises a code list, or a queue stalls overnight and completions posted in the field never reach the centre. The excavator checks status, sees nothing, and either waits or digs.

On the client side, the recurring breakage is credentials and layer access. Pulling live facility layers from a client Esri environment is a materially different project from consuming a monthly export, and it depends on people at the client who change roles.

Three preventions cover most of it. Never discard an unparseable ticket, route it to an alerted queue with a human on it, and treat the parse failure rate as a monitored number. Reconcile daily between completions in your system and responses accepted at each centre, so a stalled queue surfaces the same morning rather than in a complaint. And name an owner on both sides of every client integration at contract signature, so a layer rename becomes somebody's job to announce.

What happens when damage investigation and quality auditing are left out?

Both get deferred on almost every build, and both are the reason the system exists. When a facility is struck the investigation has a fixed shape: was there a valid ticket, was the dig inside the notified area, were the marks present and accurate, did the excavator maintain the tolerance zone, was a positive response posted. Assembling that from a ticket system, a photo folder and a supervisor's memory takes days per incident, and your clients and insurers will ask for root cause categorisation in a structure that maps to the Common Ground Alliance damage information reporting programme.

Quality auditing gets deferred for a different reason: it feels like overhead until a client audit finds something. Then you are defending your process rather than showing it.

The consequence of leaving both out is that every conversation with a client happens after a bad event, on their evidence. The fix is to make an investigation open directly from the ticket and pull the screening decision, assignment history, locator evidence, positive response and full timeline into one package automatically, then walk the investigator through root cause classification. And sample quality automatically at each client's agreed rate, so the scorecard exists before the quarterly review rather than after the damage. Operations that do this find the arguments get considerably shorter, because the facts are assembled rather than contested.

Should you build custom or configure what you already own?

If you are a single state operation under a few hundred tickets a day serving one or two utility clients, stay on Irth Solutions or KorTerra and spend the money on locators. Both handle the genuinely tedious part, parsing dozens of centre formats and posting positive response, better than most people expect before they try it. PelicanCorp covers similar ground with a strong international footprint. Building at that scale is a distraction from hiring.

Configure harder before you build. Most contractors have more room in their existing product than they use, particularly on buffer settings, ticket type routing and report templates, and the honest first move is to exhaust that before opening a project.

Build when the per-ticket licence cost has become a visible line at your volume, when you serve enough clients that per-client rules are being applied from memory, when your screening accuracy is limited by buffer rules you cannot configure yourself, or when a claim has exposed that your field evidence does not exist in a defensible form. Utility owners reach the same decision from the other direction, wanting screening tied to their own mapping of record and an audit trail they can inspect, and the resulting systems look different enough that neither should buy the other's shape.

How do hidden costs get into the quote?

Centre count is the first and it is routinely priced as one line. Each centre is a format, a delivery mechanism, a positive response path and a set of quirks you meet in production. Ask for the price per centre and the list of centres the developer has actually handled by name.

State count is the second, since each brings a rule set and a holiday calendar rather than a setting.

The third is the mobile application, and specifically offline synchronisation done properly with original capture times preserved. This is a design decision rather than a feature, it is the thing that decides whether locators use the application at all, and it is invisible in a demo. Rugged device testing adds more time if your field kit is unusual.

Then client integration depth, where live facility layers from a client environment are a different project from a monthly export, and migration of historical tickets and photographs, which is evidence work rather than a bulk import. A proposal that omits all five is not cheaper, it is less complete.

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

Launch with your two highest volume states and one client, then add the rest as configuration. That sequencing is also the test of the model, and it will tell you within a few weeks whether the client dimension was built properly.

Interview developers on the specifics that reveal experience. Ask how they would compute a ticket's due time, and expect jurisdiction rules, business day handling with a state holiday calendar, ticket type and a separate client overlay, treated as derived rather than stored. Ask what happens to a locator's photographs after four hours with no signal, and expect offline queueing with original capture time preserved, volunteered before you ask. Ask how a screening decision is reconstructed for a damage that surfaces two years later, and expect the layer version and rule to come up immediately.

Then measure the two numbers that decide whether the build paid for itself: your unbillable visit rate and your average time from ticket receipt to locator arrival, both baselined before anything is built.

Settle ownership of the repository, the cloud accounts and the data in writing before kickoff. Your completion records and photographs are evidence in proceedings that may happen years from now, and a vendor holding them is a risk worth refusing outright.