Utility Vegetation Management: Why You Cannot Prove the Span Was Cleared Until the Tree Is Already on the Line

Why line clearance is an evidence program that happens to involve chainsaws

A tree takes out a 12kV circuit in a wind event. Two days later somebody from the commission, or from your own legal group, or from an insurer, asks a specific question: when was that span last cleared, what was the prescription, who did the work, what did it look like when they left, and was there a refusal on file for that parcel. The vegetation manager starts assembling the answer from a contractor production report, a work planner's notebook, an email chain about a landowner who would not allow a trim, and a photo that may or may not be of the right pole.

That assembly is the job. Vegetation management is one of the largest recurring operating expenses at any distribution utility, and it is the single program most reliably examined after a tree-caused outage or a fire. The trimming itself is contracted out and reasonably well understood. What is not well managed at most utilities is the chain of evidence that connects a mile of circuit to a completed piece of work to a photograph to a payment.

The tooling reflects that. Clearion is a genuine system of record built on the Esri platform and it does the workflow job. AiDash and Overstory apply satellite and remote sensing analytics to identify risk and change, and they are legitimately good at spotting encroachment across a large footprint faster than a patrol can. But an analytic produces a score, and a score is not a work request, a completed span, a signed refusal, an approved invoice line or a defensible record three years later. The gap between the analytic and the evidence is filled by foresters, work planners and spreadsheets.

Problem 1: the work unit is a span on a circuit, and generic field tools have no circuit

Line clearance work is described in the language of the electrical system: circuit, section, span, structure to structure, plus a side of the road and a parcel. A work request covers a set of spans. A prescription applies to a span. Compliance is measured in miles of circuit completed against miles due. A tree is a feature within a span, and its risk depends on its height and lean relative to the conductor it could reach.

Generic field service platforms model a job at an address. That is not close enough. A job at an address cannot roll up into circuit miles, cannot express that a crew completed spans 14 through 22 but skipped 18 due to a refusal, and cannot answer whether a circuit is on cycle. So utilities that adopt a generic field tool end up maintaining a parallel spreadsheet with the circuit math in it, which defeats the purpose.

What a custom build does: take the circuit hierarchy from GIS as the backbone and hang everything off it. Work requests are span sets. Completion is recorded per span with a timestamp, crew, prescription applied and photographs. Miles complete becomes a query rather than a report someone assembles. If your GIS model is weak on section and span identity, that is a real prerequisite and should be scoped honestly rather than discovered in week nine.

Problem 2: contractor production claims and completed work are two different data sets

The contractor submits production: crew days, miles, trees, sometimes units by type. You pay against it. Your own verification is a general foreman spot checking a sample and a work planner's impression. When the numbers are large and the pay structure is unit price, the incentive is obvious and the reconciliation is weak. When the structure is time and equipment, the incentive flips to slow work and the reconciliation is weaker still, because you are paying for presence rather than output.

The disputes are rarely fraud. They are definitional. Does a span with three trees trimmed and one refused count as complete. Does a removal on the edge of the right of way count under this contract or is it extra work. Does mobilization on a rained out day get paid. Every contractor and every utility has answers, and they live in a contract document that nobody is consulting while approving an invoice.

What a custom build does: encode the pay rules against your contract, per contractor, with versions and effective dates, and compute the payable amount from recorded completions rather than from a submitted claim. Then the contractor's production report becomes a reconciliation input rather than the source of truth. Variances go to a queue with the specific spans in dispute attached, including the crew's own completion record and photographs, so the conversation is about evidence rather than about totals. Utilities that make this change usually find the argument volume drops before the dollar amounts do, which is the more valuable outcome.

Problem 3: refusals and hazard trees are legal records kept in a truck

A landowner refuses a trim. A forester identifies a dead ash outside the right of way that is tall enough to strike the line. Both are moments of transferred risk, and both generate obligations: notification, documentation, escalation, sometimes a legal process to obtain access. Right now both usually end up as a note, a photo on a phone and an email.

When a tree comes down and the question is whether the utility knew, the difference between a documented refusal with dated notification and an undocumented conversation is the entire case. The same applies to a hazard tree that was identified, prioritized and scheduled versus one that was noticed and forgotten. This is the part of the program where the software either protects the utility or does not.

What a custom build does: make refusal and hazard tree first-class records with required fields, geolocation, photographs, parcel and owner linkage, notification history and a status lifecycle that does not include a state called forgotten. Escalation is automatic on age and risk. Reporting answers, at any moment, every open refusal on a circuit and every identified hazard tree not yet resolved, which is a question your risk group should be able to ask without a two week data pull.

Problem 4: remote sensing produces findings, and findings are not work

Satellite and aerial analytics have genuinely changed the inspection side. Change detection across a whole service territory, canopy height, growth rate estimation, encroachment flags. The vendors in this space do real work. The failure is downstream: a delivery of thousands of findings arrives in the vendor's portal in the vendor's taxonomy, and the vegetation manager now has a second system to look at and no automated path from a finding to a crew.

Worse, findings arrive again next cycle. Without deduplication, the same encroachment appears as new every delivery, and the team either processes duplicates or starts ignoring the feed. Both outcomes waste the money spent on the analytics.

What a custom build does: ingest findings as observations against your span model, deduplicate against prior deliveries and against work already scheduled or completed, and convert surviving findings into work requests through a prioritization rule set that is yours: circuit criticality, customer count, fire risk designation, cycle status. Then the loop closes, because completed work updates the finding, and the next delivery is scored against a system that knows what was cut. That closed loop is what makes remote sensing worth its subscription rather than an interesting map.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the shape here is consistent. A first release covering span-level work requests off the circuit model, crew completion capture with photographs, refusal and hazard tree records, and contractor production reconciliation runs $70,000 to $160,000 and ships in 12 to 18 weeks. A full program adding remote sensing intake with deduplication, cycle compliance calculation, unit-price payment computation against contract terms, parcel and landowner management and audit-grade reporting runs $200,000 to $500,000 phased over 8 to 14 months.

What drives it up: transmission alongside distribution, because NERC FAC-003 evidence expectations on applicable transmission lines are a distinct compliance regime from distribution clearance rules and should be modeled separately rather than bolted on. Operating in a high fire threat jurisdiction, where clearance rules such as those under California's Public Resources Code and CPUC General Order 95 carry their own documentation demands. The number of contractors and pay structures. And the quality of your circuit model, since span identity is the backbone and a weak model has to be improved before anything else works.

What keeps it down: start with one region, one contractor and the completion-plus-evidence loop. Cycle math and payment computation are worth more once you trust the completion data, and you will not trust it until crews have been recording for a season.

Build versus buy, and when buying is right

Buy Clearion if you are a mid-size distribution utility with a conventional program, one or two contractors, one pay structure and under roughly 2,000 line miles. It is a real system of record, it sits on the Esri platform your GIS group already runs, and a custom build would be spending capital to reach parity. Keep buying the analytics too. AiDash and Overstory are doing work that is genuinely hard and not worth rebuilding, and the right posture toward them is integration rather than replacement.

Build when two or more of these are true. You run several contractors on different pay structures and your invoice reconciliation is a monthly argument. You operate in a jurisdiction where a tree-caused ignition is an existential risk and your evidence chain has already been tested and found thin. Your program spans transmission and distribution with different compliance regimes and one team. You are ingesting remote sensing findings that nobody is converting into work at the rate they arrive. Or your cycle compliance number is produced by a person in a spreadsheet, which means nobody can independently verify the single most examined statistic in your program.

Our position, plainly stated: this is a records program with field work attached, not the other way around. If your vegetation manager cannot answer the tree-on-the-line question for any span in under an hour, more analytics will not help. The gap is in the chain between the finding, the crew and the file.

How to choose a developer for vegetation management software

Ask them to explain a work request in terms of your circuit model. If they describe a job with a latitude and longitude, they are about to build a generic field app and you will keep the spreadsheet that does the mileage math.

Ask how they will deduplicate a remote sensing delivery against last year's delivery and against completed work. A developer who has not confronted this will underestimate it badly, and duplicate findings are the fastest way to lose a team's trust in a new system.

Ask what happens to a refusal. The answer must include a lifecycle, notification history, escalation on age and a report your risk group can run unaided. A status field is not an answer.

Ask who owns the code and get it in writing before kickoff, along with export of every completion record and photograph in an open format. At Digital Heroes the client owns the code from the first commit. Then take a candidate developer to a real span with a real refusal on file and ask them to model that day. The forester standing next to you will tell you within the hour whether they understood it.