Pole Attachment Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the audit-first approach keep failing?

Because it treats inventory as a data problem when it is a process problem. A joint use inventory is not wrong because nobody counted carefully. It is wrong because attachments are created at permit time and never verified again, poles get replaced and identity transfers inconsistently, attachers overlash without notification, and contractors attach without a permit. Every one of those continues happening the day after the audit closes.

The second reason is that an audit produces a document rather than a mechanism. Both parties agree a number, the number goes into a settlement, and the settlement is the last artefact. Nothing in the utility's day-to-day work is different afterwards, so drift resumes immediately at the same rate.

The third is sequencing inside the project. When the audit is scoped as a prerequisite, the software waits for it. Field work slips, the audit vendor delivers in a format nobody planned for, and the build starts eight months late against an inventory that is already three months stale.

The fix is to invert it. Build the mechanism first, then let the audit update a living record instead of creating a new one. Every permit, make-ready job, field visit and inspection photograph becomes a timestamped observation attached to a pole, and the current state is derived from observations with a confidence level rather than being a row somebody typed once. Do the audit when the system exists to absorb it, and target it at the poles where confidence is lowest rather than at all of them. Utilities that sequence it this way get an inventory that improves continuously between audits instead of decaying between them.

What goes wrong when you try to join two pole inventories?

Pole identity is the root problem and it defeats naive migrations completely.

Your geographic information system knows a pole by an asset identifier. The attacher knows it by their own tag number, sometimes only by a photograph and a cross street. A pole replacement creates a new physical object that may or may not inherit the old identifier, depending on who filed the paperwork and when. Several poles stand at one intersection. Metal tags fall off. When the two parties compare lists, they are comparing keys that were never designed to join.

Teams that plan a straightforward import discover this in week three, usually when a match on coordinates returns multiple candidates for a meaningful share of poles and a clean match for far fewer than the plan assumed. What follows is either a manual reconciliation nobody budgeted for or, worse, an automated match with a loose tolerance that silently creates wrong joins. A wrong join is more damaging than no join, because it produces a confident bill you cannot defend.

The other migration trap is history. Legacy attachment records often lack the date an attachment was created, which is exactly the field back-rent calculations and dispute defences depend on.

The fix is a persistent crosswalk rather than a one-time match. Every joint job, permit and field visit improves the mapping between your asset identifiers and each attacher's identifiers, so the next comparison starts from the last agreed position rather than from scratch. Score every match with a confidence level and never let an unconfirmed match feed a bill. And where the creation date is unknown, record it as unknown rather than defaulting it, because a defaulted date in a rate dispute is worse than an admitted gap.

Why do the GIS, notification and loading analysis integrations break after launch?

Three integrations decide whether this system stays useful, and each fails differently.

The geographic information system integration breaks on pole lifecycle events. A pole is replaced, the asset record is updated by the operations team on their own schedule, and the attachment records that pointed at the old asset are now orphaned or, more dangerously, silently pointing at the new one as if nothing changed. Loading, height and class may all differ. If your integration only syncs attributes and not lifecycle events, you will not notice.

Notification integration breaks on follow-through rather than on messaging. Systems such as NJUNS do the notification job, but a notification sent is not a transfer completed, and if your build treats an acknowledgement as progress you will report transfers as on track that have not started.

Loading analysis integration breaks on geometry. O-Calc Pro and SPIDAcalc consume specific structural inputs, and a change in how attachment heights or offsets are captured in the field will produce analyses that run without error and describe a pole that does not exist. Nobody catches that in a test suite.

The fixes are concrete. Subscribe to pole lifecycle events, not just attribute updates, and quarantine attachment records whose pole was replaced until a human confirms the disposition. Track transfer completion on evidence, meaning a dated field photograph, rather than on a returned message. And validate geometry going into loading analysis against ranges that make physical sense, with a rejection path rather than a warning nobody reads.

What happens when the regulatory clocks are not built in as data?

This is the gap that turns an administrative problem into a legal one, and it is almost always introduced by a well-meaning shortcut.

The FCC's pole attachment rules set defined windows for reviewing an application for completeness, surveying the poles, providing a make-ready estimate and completing make-ready, with different periods in the communications space and above it, a one-touch make-ready path for simple communications attachments, and a self-help remedy available to the attacher when the owner misses deadlines. Many states have taken back authority and set their own timelines, so a utility operating across state lines is tracking more than one rule set.

The shortcut is encoding those periods as conditional logic in application code because it is faster in week two. Then a commission issues an order, the timeline changes, and updating it requires a development ticket, a test cycle and a release. In the interim, the system is confidently displaying due dates that are wrong, and staff are trusting them.

The second failure is where the clock starts. It starts on receipt, not on the day somebody opened the shared mailbox. Applications that sit unread for eleven days have consumed eleven days, and a self-help notice arriving afterwards means an attacher's contractor is working on your poles under a remedy you did not intend to trigger.

The fix is rule sets held as configurable data with effective dates, per jurisdiction, so a commission order is a configuration change rather than a release. Start the clock automatically at intake. Make the completeness review an explicit gated step that either accepts or returns the application with reasons inside the review window. And escalate to a named supervisor before the deadline rather than after it.

Should you build custom or configure what you already own?

Several things in this category should be bought and never built.

Buy the loading analysis. O-Calc Pro and SPIDAcalc are the standards, engineering firms already know them, and nobody should be writing their own structural analysis of a wood pole.

Buy the collaboration layer if it fits. Alden One is a legitimate joint use system of record, and if your attachers already work in it, fighting that is expensive and probably pointless. Katapult Pro is a sensible answer for an attacher or an engineering firm running permit volume, and if you are on the attacher side with a manageable book, it may be the whole answer.

Below roughly 30,000 jointly used poles with two attachers and stable volume, do not build. Buy one of the above and enforce your agreement, because at that scale the discipline matters more than the tooling.

Before commissioning anything, look hard at what your existing systems already hold. Utilities frequently have attachment data in the geographic information system that nobody reports from, and work management systems that could carry make-ready jobs with modest configuration. A review of what you already own is a few weeks and sometimes reframes the whole project.

The build case starts when two or more of these are true. More than roughly 100,000 jointly used poles. More than four attachers on materially different agreements. A last inventory dispute that ended in a negotiated settlement rather than an agreed number. Operations in more than one state with different attachment rules and clocks. Or permit volume multiplied by fibre buildouts, with regulatory deadlines currently tracked in a shared mailbox.

How do hidden costs get into the quote?

The build estimate tends to be honest about screens and silent about the surrounding work.

• One rule set per state. Each jurisdiction you operate in is a rule set to encode, test and then maintain as commissions revise it. Two states is not slightly more than one.
• One billing logic per legacy agreement. Old joint use agreements each carry their own rates, escalators, audit provisions and penalty terms. Count them before anyone estimates, because eight agreements is eight implementations.
• Owner and attacher are different products. If you are both, you are funding two mirrored workflows, not one system with a toggle.
• Field capture hardware and photograph storage. Evidence-grade photographs at scale are ongoing storage and retrieval cost, and they are the part that actually settles disputes.
• Contractor coordination. Bringing make-ready contractors into the workflow means external accounts, access control and a support burden that lands on your team.
• Historical reconstruction. Populating attachment creation dates that legacy records never held is manual research, and it is the data back-rent calculations depend on.

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

Four things, and the first is a modelling decision made in week one.

Pole identity has to distinguish the asset, the position and each attacher's own identifier as separate concepts joined by a crosswalk. A developer whose answer to pole replacement does not make that distinction will produce reconciliation that fails on exactly the poles that cause disputes, which are the ones that have been replaced, moved or contested.

The second is that double wood is modelled as a multi-party workflow rather than a status field. Per-attacher transfer tasks with dependencies, due dates drawn from the agreement, automatic escalation and a dated photograph at completion. Pole retirement should trigger from the last completed transfer rather than from someone noticing the old pole is still standing. Ask any candidate developer what their system does about double wood. Someone who has worked in this space will talk about tasks and evidence immediately. Someone who has not will describe a dropdown.

The third is that a bill can be reproduced. An annual invoice should be generated from versioned rate rules with effective dates, not assembled, so that two years later when a line is questioned you can regenerate exactly what was billed and show why. That single property is what converts an argument into a conversation.

The fourth is ownership, including the data. Get the code and a full export of the attachment inventory in an open format written into the contract before kickoff. At Digital Heroes the client owns the code from the first commit. Attachment inventories are evidence in rate disputes and complaint proceedings that outlast software vendors, and a proprietary lock on that record is a risk worth refusing outright.