Utility Vegetation Management Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the work unit get modelled as a job at an address?

Because that is what general purpose field platforms model, and the first version of the requirement is usually written by someone comparing options rather than by a forester. A job at a latitude and longitude is a perfectly good abstraction for a plumber. It is the wrong abstraction here.

Line clearance 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 height and lean relative to the conductor it could reach.

When the model cannot express that, the utility ends up maintaining a parallel spreadsheet holding the circuit mathematics, which is precisely what the software was bought to remove. Worse, the parallel spreadsheet becomes the number reported to the commission, and it is a number nobody can independently verify.

The fix is to take the circuit hierarchy from your mapping system as the backbone and hang everything off it. Work requests are span sets. Completion is recorded per span with timestamp, crew, prescription applied and photographs. Miles complete becomes a query rather than a monthly assembly job. Write that into the acceptance criteria before design starts, because retrofitting span identity onto address-based history is not practical and the year of data you collect in the meantime is unusable.

What goes wrong with the circuit and span identity you depend on?

Span-level work needs stable span identity, and this is where projects quietly stall in week nine. Many distribution models carry structures and conductor without a durable identifier for the span between them, or with identifiers that change when a section is rebuilt or a pole is renumbered. Some carry section identity inconsistently between operating areas because two teams digitised differently a decade apart.

The failure is not obvious at first. Completion records post successfully, and only when you try to compare this cycle against the last one do you discover that a third of the spans you cleared three years ago no longer exist under the same identifier, so your cycle history has holes in the exact places where work was most active.

Scope this honestly rather than discovering it. Before the build, run a check across your circuit model asking three questions: does every span carry an identifier, does that identifier survive a rebuild, and do section identifiers mean the same thing in every operating area. If the answers are no, the prerequisite is model work and it belongs in the plan with a named owner.

Then design for change. Record completions against the span identifier and against the structure pair, so a renumbering can be reconciled later rather than orphaning history. And keep a mapping table of retired identifiers, because a rebuilt section is the most likely place a tree will take the line down and the most likely place you will be asked what happened there.

Why do remote sensing and contractor feeds break after launch?

Satellite and aerial analytics genuinely find encroachment across a service territory faster than patrols do. What breaks is downstream. Findings arrive in the vendor's taxonomy on the vendor's schedule, and unless they are deduplicated against prior deliveries and against work already scheduled or completed, the same encroachment appears as new every cycle. The team then either processes duplicates or starts ignoring the feed, and both outcomes waste the subscription entirely.

The second failure is silent taxonomy drift. A provider improves a model or renames a category, the ingest maps it to nothing, and a class of findings stops arriving without anyone noticing until the next delivery is compared by hand.

Contractor production feeds break differently. They are usually spreadsheets emailed monthly, so a column added by a crew supervisor or a changed unit label breaks the load, and the fallback is somebody keying it in.

Fix all three the same way. Ingest findings as observations against your span model, deduplicate on geometry and feature identity across deliveries, and alert on any category that appears or disappears between loads rather than accepting it. Reconcile counts per delivery and per contractor submission against the previous period, with a named owner on the alert. Then close the loop so completed work updates the finding, and the next delivery is scored against a system that knows what was cut. That closed loop is what turns remote sensing into something worth its subscription.

What happens when refusals and hazard trees are not first class records?

A landowner refuses a trim. A forester identifies a dead ash outside the right of way tall enough to reach the line. Both are moments where risk transfers, and both generate obligations: notification, documentation, escalation, sometimes a legal process to obtain access. In most programmes both end up as a note, a photograph on a phone and an email chain.

When a tree comes down and the question is whether the utility knew, the difference between a documented refusal with dated notification and a remembered conversation is the entire case. The same applies to a hazard tree that was identified, prioritised and scheduled against one that was noticed and forgotten.

Contractor payment has a related gap. When the payable amount is computed from the contractor's submitted production rather than from your own recorded completions, every dispute is about totals, and totals are settled by whoever has better records. Most of these disputes are definitional rather than dishonest: whether a span with three trees trimmed and one refused counts as complete, whether a removal at the edge of the right of way is extra work, whether a rained out mobilisation is payable.

Make refusals and hazard trees records with required fields, position, photographs, parcel and owner linkage, notification history and a lifecycle with no state called forgotten, escalating automatically on age and risk. Encode the pay rules per contractor with versions and effective dates and compute the payable amount from your completions, so the contractor report becomes a reconciliation input and variances arrive with the disputed spans and their photographs attached.

Should you build custom or configure what you already own?

If you are a mid-size distribution utility with a conventional programme, one or two contractors, a single pay structure and under roughly 2,000 line miles, buy Clearion and run it properly. It is a genuine system of record, it sits on the mapping platform your geographic information group already runs, and a custom build would be capital spent reaching parity.

Keep buying the analytics whatever else you decide. AiDash and Overstory are doing work that is genuinely hard to replicate, and the right posture toward them is integration rather than replacement. The gap you are filling is between the finding and the file, not the detection itself.

Build when two or more of these are true. Several contractors on different pay structures make invoice reconciliation a monthly argument. You operate where a tree-caused ignition is an existential risk and your evidence chain has already been tested and found thin. Your programme spans transmission and distribution with different compliance regimes under one team. Findings arrive faster than anyone converts them into work. Or your cycle compliance number is produced by a person in a spreadsheet, which means the most examined statistic in your programme cannot be independently verified.

How do hidden costs get into the quote?

Covering transmission alongside distribution is the largest and it is regularly priced as an extra module. The evidence expectations under the transmission vegetation management standard for designated applicable lines are a distinct compliance regime from distribution clearance rules, and they should be modelled separately rather than bolted onto one workflow. Confirm applicability for your own facilities with your compliance group and price the two regimes as two pieces of work.

Operating in a high fire threat jurisdiction is the second. Clearance rules such as those under California's Public Resources Code and the state commission's General Order 95 carry their own documentation demands, and documentation demands are software scope.

Then contractor count and pay structure count, each of which adds a rule set rather than a setting. Circuit model remediation where span identity is weak. And offline capability, because crews work where connectivity is unreliable, photographs are large, and a lost day of completions destroys crew trust permanently. Test that by disabling connectivity for a full crew day during the pilot rather than trusting a demonstration.

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

Start with one region, one contractor and the completion plus evidence loop only. Cycle mathematics and payment computation are worth far more once you trust the completion data, and you will not trust it until crews have been recording for a season. Utilities that launch the whole programme at once spend the first year arguing about numbers derived from data nobody has validated.

Interview on the domain rather than the interface. Ask a candidate developer to explain a work request in terms of your circuit model. If they describe a job with a latitude and longitude, you are about to buy a generic field application and keep the spreadsheet that does the mileage. Ask how they will deduplicate a sensing delivery against last year's delivery and against completed work, because a developer who has not confronted that will underestimate it badly. Ask what happens to a refusal, and expect a lifecycle, notification history, age-based escalation and a report your risk group can run unaided. A status field is not an answer.

Settle ownership in writing before kickoff, including the right to export every completion record and photograph in an open format. These records are evidence in outage investigations and liability proceedings that may occur years later, so a vendor holding your photographic history is a risk worth refusing outright.

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.