811 Locate Ticket Management: Why Screening, Dispatch and Positive Response Break Above a Thousand Tickets a Day

The clock starts whether or not anyone has read the ticket

A contractor calls 811 on a Monday afternoon to report a dig at an intersection. The one call centre transmits a ticket to every member utility with facilities in the notification polygon. Your operation receives 2,200 tickets that day across four states, in three different text formats, and the statutory response clock on each one started at transmission, not at the moment your dispatcher opened it. Somewhere in that batch is a ticket in a corridor where your client has a 12 inch transmission main. If it is screened as no-conflict by mistake, or assigned to a locator whose queue is already 30 deep, or marked complete without a positive response code posted back to the centre, you have three separate ways to end up in front of a lawyer after a backhoe finds the main.

The operation running underneath that is genuinely hard, and it is not appreciated by anyone who has not sat in a locating dispatch office. Tickets arrive as semi-structured text with a description of the dig site that a human wrote over the phone. They have to be screened against your client's facility mapping to decide whether you have anything in the dig area at all. The ones that survive screening get assigned by geography, priority, ticket type and locator skill. The locator drives out, marks, paints, flags, photographs, and then something has to travel back to the one call centre as a positive response code before the clock expires. Then the evidence has to survive being asked for eighteen months later when a damage claim lands.

The economics are brutal and specific to this sector. Contractors are typically paid per ticket, and the margin on a ticket is thin enough that a wasted truck roll to a site where the client has no facilities is a direct loss. Screening accuracy is therefore not a compliance nicety, it is the profit lever. On the other side, a single struck gas main can produce an injury claim, an outage, a regulatory penalty and a lost client contract, and the defence against all four is the evidence package. Most operations are excellent at the first and improvising the second.

Screening is where your margin lives, and it depends on your own GIS

The screening decision is: does my client have facilities inside this dig polygon, and if so which ones, and does this warrant a field visit. Get it wrong toward caution and you roll a truck for nothing, which at scale is thousands of unbillable or barely billable visits a year. Get it wrong the other way and you have a no-locate on a live asset.

Irth Solutions, KorTerra and PelicanCorp all handle ticket intake and screening, and they handle the genuinely tedious part, parsing dozens of one call centre formats, better than most people expect. That is real work and you should not casually assume you will rebuild it in a sprint. Where they run out of room is when the screening decision depends on things only you know: that your client's mapping in a particular township is known to be 15 feet off because it was digitised from paper, that a specific ticket type from a specific excavator always turns out to be a hand dig that needs no visit, that a corridor was recently rebuilt and the as-builts have not made it into GIS yet. Those are local corrections that live in the dispatcher's head and get applied inconsistently.

What a custom build does: make the screening buffer a rule set rather than a global setting. Buffer distance varies by facility class, by mapping confidence in that area, and by client policy, all of which you configure rather than beg a vendor to change. Every screening decision is recorded with the polygon, the facility layer version and the rule that fired, so when a damage happens you can show precisely what the system knew at the time rather than what GIS looks like today. And screening outcomes get fed back: when a locator arrives and finds nothing, that becomes data about mapping quality in that area rather than a shrug. Over a year that feedback loop is what moves your unbillable visit rate.

Every state has its own clock, its own response codes and its own exceptions

Statutory notice periods, what counts as a business day, how emergency tickets are handled, what positive response codes exist and whether posting them is mandatory: all of that varies by state and province. A contractor working four states is running four rule sets, and the penalty for applying the wrong one is not a warning email, it is a missed statutory deadline on a live excavation.

The packaged platforms do carry jurisdiction rules, and for a straightforward single-state operation that is enough. The friction shows up in the layered obligations on top of the statute. Your utility client has an internal SLA that is tighter than the law. A second client requires a call to the excavator before marking on high-priority ticket types. A third has a rule about re-marks that only applies to their transmission assets. Now the effective deadline on a ticket is a function of jurisdiction, client, ticket type and asset class, and it changes when a client renegotiates.

What a custom build does: model the clock as a computed field with a stated derivation, not a due date somebody typed. The system knows the jurisdiction rule, the client overlay, the ticket type and the holiday calendar for that state, and it publishes both the statutory deadline and the client deadline separately so nobody confuses the two. Escalation runs off predicted breach rather than actual breach, meaning a ticket that is going to miss based on current queue depth and travel time surfaces hours before it does, when a dispatcher can still act. Any operation that only alarms on breach has built an incident log, not a dispatch system.

Field evidence on a personal phone is not evidence

Eighteen months after a locate, a damage claim arrives. The question is what the site looked like when your locator left it. If the answer is that the locator took photos on his own phone, texted some to his supervisor, and has since left the company and changed his number, you have no defence. This is the single most common evidence failure in the sector and it is entirely avoidable.

What a custom build must include: a locator app that captures the marking evidence as a structured record, not as loose images. Photos carry GPS position, heading, device timestamp and the ticket they belong to, written once and immutable afterwards. Sketch capture of the marked area against a map. The specific facility types marked and the equipment used. Offline first, because rural corridors have no signal and a locator will not wait for a spinner, so the app queues locally and syncs when it can, with the original capture time preserved rather than the upload time. Everything is bound to the ticket, so producing an evidence package for a claim is one action rather than a week of asking people to search their camera rolls.

The same capture path is what makes positive response honest. A completion posted from an office is a claim. A completion posted from a device that was at the coordinates, with photos of the marks, is a record.

Contractors serving multiple utilities have a client problem, not a ticket problem

If you are a locating contractor with a dozen utility clients, your tickets are only half the system. Each client has its own audit programme, its own quality sampling expectations, its own damage investigation format, its own invoicing basis, and its own opinion about what a completed ticket means. Some pay per ticket, some per screened ticket, some blend a standby rate. Reconciling what you did against what you may bill is frequently a spreadsheet exercise at month end, and disputes usually get settled by whoever has better records, which is not always you.

What a custom build does: make client a dimension across the whole model. Rules, SLA overlays, evidence requirements, quality sampling rates, invoicing basis and reporting formats all hang off the client record. The month end invoice is generated from the same ticket data the client can see in their own portal, which removes most disputes before they start. Quality audits get sampled automatically against each client's agreed rate and the results feed a scorecard you can put in front of them at a quarterly review, which is a very different conversation from defending yourself after a damage.

Damage investigation is the part everyone builds last and needs most

When a facility is struck, the investigation has a shape: was there a valid ticket, was the dig inside the notified area, were the marks present and accurate, did the excavator maintain tolerance zone, was there a positive response posted. The Common Ground Alliance DIRT programme gives a structure for reporting damages, and your clients and insurers will ask for root cause categorisation. Assembling that from a ticket system, a photo folder and a supervisor's memory takes days per incident.

What a custom build does: an investigation opens from the ticket itself, pulls the screening decision, the assignment history, the locator's evidence, the positive response and the timeline into a single package, and walks the investigator through the root cause classification. The output is both an internal record and a client-format report. Operations that have this find their damage rate arguments with excavators and clients get considerably shorter, because the facts are assembled rather than argued.

What it costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering one call ticket intake and parsing for your states, GIS screening with configurable buffers and decision logging, geography and skill-based assignment, and positive response with computed statutory and client clocks runs $65,000 to $140,000 over 12 to 16 weeks. A full platform adding the offline locator mobile app with evidence capture, per-client rule overlays and portals, quality auditing, damage investigation with DIRT-shaped output, and client invoicing runs $170,000 to $400,000 phased over 7 to 12 months.

Cost drivers specific to this work: the number of one call centres you receive from, because each format and each positive response mechanism is its own integration and some still use file drops or email rather than an API. The number of states, since each brings a rule set and a holiday calendar. GIS integration, where pulling live facility layers from a client's Esri environment is a different project from consuming a monthly shapefile export. And whether you need the mobile app on rugged devices with specific locator equipment, which adds hardware testing time.

What keeps it down: launching with your two highest-volume states and one client, then adding the rest as configuration rather than code. If the second client requires engineering, the model was wrong.

Build versus buy

Buy if you are a single-state operation under a few hundred tickets a day serving one or two utility clients. Irth or KorTerra will handle you competently, the one call integrations are already done, and the per-ticket pricing is not yet the dominant cost. Building at that scale is a distraction from hiring locators.

Build when the per-ticket licence cost has become a visible line in your P and L at your volume, when you serve enough clients that per-client rules are being applied by memory, when your screening accuracy is limited by rules you cannot configure, or when a damage claim has exposed that your field evidence does not actually exist in a defensible form. Utility owners with a large in-house damage prevention function reach the build case from the other direction: they want screening tied directly to their own GIS of record and an audit trail their regulator will accept, and they are not willing to have that logic sit in a third party product they cannot inspect.

How to choose a developer for locate ticket software

Ask how they would compute a ticket's due time. A credible answer names jurisdiction rules, business day handling with a state holiday calendar, ticket type, and a separate client SLA overlay, and it treats the due time as derived rather than stored. If they describe a date field, they have not understood that the clock is a legal object.

Ask what happens to a locator's photos when there is no cell signal for four hours. Offline queueing with original capture time preserved is the only acceptable answer, and they should volunteer it before you ask.

Ask specifically which one call centre formats and positive response mechanisms they have handled. There is a large difference between a modern API and a nightly file drop with a fixed width layout, and both still exist. Get the centre named, not a general claim about integrations.

Ask how screening decisions are recorded for a damage that surfaces two years later. The system must be able to show the facility layer version and rule that produced the decision at the time, not the current state of GIS. Any developer who does not immediately understand why that distinction matters has not worked in damage prevention. And settle ownership up front: you should own the repository, the cloud accounts and the data, in writing before kickoff. At Digital Heroes the client owns all of it from the first commit.