Utility Staking and Work Order Design: Why Your Stakers Cannot Price a Job Until They Drive Back to the Office

Why staking is the most expensive clipboard in the utility

A staking engineer is parked at the end of a gravel road with a member standing next to the truck asking one question: what is this going to cost me. He has a tablet with no signal, a roll of flagging, and a construction standards book. He can walk the route, count poles, pick the assemblies and draw the sketch. What he cannot do is answer the member, because the price lives in a spreadsheet on the office network that applies the current unit costs, the labor and overhead loaders, the line extension allowance from the tariff and the revenue credit for the projected load. So he says he will call tomorrow. Tomorrow becomes Thursday. The member calls the co-op three times in between.

That single delay is the visible cost. The invisible cost is bigger and it lands in accounting. The same job gets described four times: as a field sketch, as a CAD or GIS design, as a material requisition, and as a work order with compatible units that eventually unitizes into plant. Four descriptions of one job, maintained by four people, reconciled by none. When the job closes, someone in the accounting group is comparing a completed print against a material issue list trying to work out which retirement units to book and whether the old three phase crossarm assembly came out or stayed. That reconciliation is where utilities quietly lose the accuracy of their continuing property records, and continuing property records are what a rate case is built on.

The tooling around this is real but partial. Futura, Milsoft and Partner Software all do staking, and for a co-op with a conventional construction unit catalog they do it competently. What they encode is a general model of staking. What your operation actually runs on is your compatible unit catalog, your construction standards book, your capitalization threshold, your overhead loader rates and your line extension policy, and those are the things that differ between two co-ops thirty miles apart.

Problem 1: the price is the deliverable, and generic field apps cannot compute it

People think the staking sheet is the output. It is not. The output is a number a member or a developer can act on, and that number is a chain: assemblies chosen, compatible units derived, material at current average unit cost, labor hours at crew rates, equipment, overheads applied per your loader schedule, then the tariff logic that decides how much the utility funds and how much becomes contribution in aid of construction. Change the line extension allowance and every quote in the queue is wrong.

A generic field service app has a work order and maybe a parts list. It has no concept of a compatible unit, no concept of an overhead loader, and no way to express that a single pole change out installs one unit and retires another with cost of removal and salvage on the retirement side. So the staker collects data and someone else prices it, which reintroduces the rekeying the app was bought to remove.

What a custom build does: the compatible unit catalog is the core object, versioned with effective dates, so a job quoted in March prices against March costs and can be reproduced in an audit two years later. Assemblies map to units, units carry material lists, labor standards and the FERC plant account they land in, meaning 364 for poles and fixtures, 365 for overhead conductors and devices, 368 for line transformers. The staker picks assemblies in the field and the price appears in the truck. That is the feature that changes the job, and it is achievable offline because the catalog is small enough to cache entirely on the device.

Problem 2: offline is the environment, not a feature checkbox

Vendors advertise offline mode. What they usually mean is that the app caches a form. Staking needs the map, the existing facilities, the aerial imagery tile pack for the service territory, the full unit catalog, the standards drawings and the last known material costs, all resident on the device, for a full day, with photos and GPS traces accumulating the whole time. Then it has to sync without losing anything when the staker finally hits signal in the parking lot.

The hard part is not caching, it is conflict. Two stakers work adjacent jobs. Both edit the same existing pole record because both are attaching to it. The office changes a unit cost mid-day. A design gets reassigned. If the sync strategy is last writer wins, someone's day disappears and they stop trusting the tool, and once field crews stop trusting a tool it is dead no matter how good the demo was.

What a custom build does: model edits as intents rather than as row overwrites, so two stakers attaching to the same pole produce two additive changes instead of a collision. Keep a per-device change log so nothing is lost even when a merge needs a human. Cache the catalog by version so a device that has been offline for three days prices against the version it holds and flags the difference on sync rather than silently repricing. None of this is exotic engineering. It is the difference between a field app people use and a field app people work around.

Problem 3: the sketch has to become an accounting entry, not just a print

The construction package is what the crew builds from. The work order is what the books are built from. Most staking tools produce the first well and hand you a CSV for the second. Then closing the job means someone comparing what was staked against what was actually installed, because crews change things and should, and deciding what to unitize.

This is where co-ops with USDA Rural Utilities Service borrowings feel it most sharply, because work order procedures and inventory of work orders are exactly the kind of thing an examiner asks about. Investor owned utilities feel it in a different form: capital versus expense determinations at unit level, retirement units and cost of removal booked against the right account, and the continuing property record that has to survive a rate case challenge years later.

What a custom build does: the work order carries planned units and as-built units as separate sets, with a variance view the crew supervisor closes out on a tablet rather than on a paper print. Retirements are first-class, with salvage and cost of removal, because the retirement side is where accuracy is lost. Then the posting to your general ledger or plant system carries the account, the unit, the quantity and the job, and a closed job is immutable with an audit trail rather than a spreadsheet someone can still edit.

Problem 4: the engineering checks that get skipped because they are inconvenient

A staked job carries obligations beyond price. Guy and anchor sizing for the tension you just created. Sag and tension for the span and the loading district. Clearance over the driveway and the irrigation pivot. Pole loading analysis, which most utilities now run in O-Calc Pro or SPIDAcalc, especially where there are communications attachments involved. Easement language where the route crosses private ground. Joint use notification when the change affects an attacher.

These get skipped not out of negligence but because each one is a separate tool with a separate handoff and the staker is trying to get eleven jobs done this week. When they get skipped, the failure shows up years later as a leaning pole, a clearance violation found during patrol, or an easement nobody can locate when a landowner objects.

What a custom build does: make the obligations conditional and automatic. Angle over a threshold triggers a required guying calculation before the job can be released. Any attachment on the pole triggers a loading analysis handoff with the geometry already populated rather than retyped. Route crossing a parcel not already covered triggers an easement task with the parcel identifier attached. The staker does not remember these rules. The system does, and the rules are yours, which is exactly why an off-the-shelf product will not carry them.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the shape here is consistent. A focused first release covering offline sketch with existing facilities, the versioned compatible unit catalog, in-truck pricing including line extension and CIAC logic, and a costed work order export runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding material reservation against the warehouse, pole loading handoff, joint use notification, easement tracking, as-built variance capture and full unitization posting runs $180,000 to $450,000 phased over 6 to 12 months.

What drives it up: multiple operating companies with different unit catalogs and different loader schedules, because that doubles the pricing engine's test surface. Deep integration into a specific plant accounting system, since posting into an ERP (Enterprise Resource Planning) is a different problem from producing a file. Underground work at scale, where the sketch has to carry conduit, duct bank occupancy and trench footage rather than spans. And the recurring one: whether your compatible unit catalog exists as a maintained data set or as a binder plus tribal knowledge. If we have to help you rebuild the catalog, that is discovery time and it is unavoidable.

What keeps it down: starting with overhead distribution and new services, which is the majority of job volume, and leaving underground and transmission for phase two.

Build versus buy, and when buying is clearly right

Buy if you are a distribution co-op under roughly 20,000 meters, your construction unit catalog is conventional, your staking volume is a few hundred jobs a year and your accounting rules are standard. Futura, Milsoft and Partner Software are built for exactly that operation, they integrate with the co-op systems you already run, and a custom build would cost more than the problem.

Build when two or more of these are true. Your compatible unit catalog is genuinely yours and no vendor will maintain it the way you need. You operate more than one utility on different accounting rules and want one staking process. Your job volume is high enough that a two day quoting delay is costing you developer relationships and member satisfaction complaints. Your continuing property records have known accuracy problems traceable to how jobs close. Or your staking process has to feed an ADMS-grade GIS model rather than a drafting file, which means the design must carry connectivity and phasing from the moment it is drawn.

Our position, stated plainly: the compatible unit catalog and the pricing rules are the asset. The sketching tool is commodity. Any vendor selection or build decision that focuses on the drawing experience and treats pricing and unitization as an export is solving the wrong half of the job.

How to choose a developer for staking and work order design

Ask them to explain a pole change out end to end: one unit installed, one retired, cost of removal, salvage, and which FERC accounts each side hits. If they cannot, they will build you a drawing tool with a price field and you will still be reconciling in spreadsheets.

Ask what happens when two stakers edit the same existing pole while both are offline. The answer tells you whether they have shipped a real field application or a form that caches. Last writer wins is a wrong answer.

Ask which plant accounting or ERP systems they have actually posted into, by name. Posting into an ERP with real validation is different from writing a CSV, and the difference is usually six weeks.

Ask who owns the code and get it in writing before kickoff, including the catalog data. You should own the repository and the infrastructure accounts, and you should be free to hire anyone else. At Digital Heroes the client owns the code from the first commit. Once that is settled, hand a candidate developer one real completed job folder and ask them to walk it through their proposed model in front of your staking supervisor. The supervisor will know within twenty minutes.