Tower Site Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a tower asset build turn into another document repository?

Because the existing pain is document retrieval, so the obvious remedy is better document handling. Someone spends three weeks per application chasing the last structural analysis, so the project scopes a site record with an attached files area, decent search and permissions. It ships, it is better than a shared drive, and application turnaround does not move, because retrieval was the symptom rather than the cause.

The cause is that loading exists only inside portable document files. A structural analysis is a snapshot of an assumed configuration on a specific date, delivered as a report. The moment a tenant swaps antennas for a model with different projected area, adds a remote radio unit at the mount, or leaves decommissioned equipment in place after a lease ends, the structure carries a configuration nobody has evaluated. A repository holds both the analysis and the newer tenant schedule and cannot compare them, because neither is data.

The fix is to model equipment rather than documents. Each item is a record with model, quantity, mounting height, azimuth and the physical attributes an analysis consumes, attached to a tenant and a mounting position. Each structural analysis is stored as a configuration snapshot with its assumptions. Any change to installed equipment is then compared automatically against the analysed configuration, and drift becomes a queue item instead of a surprise. That single capability is what turns a colocation application into a minutes long triage rather than a document hunt, and it is the thing no filing system can be configured into.

What goes wrong when you capture data from existing site files?

Data capture dominates this project, and it is the line most often underestimated. Turning a cabinet of structural reports and tenant schedules into structured equipment records is human work, and the volume scales with site count and with how many previous owners the portfolio has had.

Three specific problems recur. The first is that equipment naming is inconsistent across carriers and across decades. The same antenna appears under a manufacturer part number in one schedule, a carrier internal code in another and a description in a third. Without a normalised catalogue, comparison against an analysis is arithmetic on incompatible units. Build the catalogue first, seeded from your own analyses, and treat unmatched items as a review queue rather than as failures.

The second is that some files are simply missing and nobody knows until somebody looks. An acquired tranche often has no foundation records or no current analysis for a subset of structures. That is worth discovering deliberately, because a site with no analysis on record is a commercial and risk position, not a data gap. Capture should output that list as a first deliverable.

The third is sequencing. Capturing the whole portfolio before anything is usable is how these projects lose their sponsor. Capture the sites that actually generate colocation applications first, which is usually a minority of the estate, get the triage working on them, and backfill quiet rural sites over the following year.

Why do lighting alarms and finance integrations break after launch?

Because both fail quietly by nature. Obstruction lighting monitoring is the clearest case. A monitoring unit reports outages, and monitoring units also fail, so the absence of an alarm is ambiguous: either everything is lit or the reporter is dead. A build that only ingests alarms will show a clean board on a structure that has been dark for a week.

The fix is to treat the heartbeat as the signal rather than the alarm. Every monitored structure should report presence on a schedule, and a missing heartbeat should raise the same kind of incident an outage does, with the reporting clock visible. That is a small design decision with a large consequence, because a lighting outage found by a member of the public is a different conversation entirely.

Finance integrations break for a structural reason. Operations knows what is physically on each tower and finance knows what each tenant pays, and those records are usually maintained by different teams in different systems. An integration that copies rent amounts across gets stale the first time an amendment is signed and not entered. What holds is connecting the tenant configuration to the lease terms so a physical change raises a commercial question automatically: an amendment adding equipment triggers a billing review, a decommission triggers a termination workflow and stops the charge.

Inspection reports are the third quiet failure. A report filed as a document is a recommendation nobody executes. Findings should be extracted into work orders with owners and due dates at the point of filing, so a note about a guy anchor becomes a task rather than a paragraph in a file nobody reopens.

What happens when compliance obligations are tracked as documents?

They fail without noise. Registered structures carry obligations that are easy to satisfy and easy to forget: lighting must work and outages must be reported and repaired within required timeframes with notification to aviation authorities, registration records must reflect actual ownership and structure details, marking and painting have conditions, and inspection regimes produce reports that have to exist and have to be acted on.

None of those produce an error message. An inspection that was never scheduled generates nothing. An ownership record never updated after an acquisition sits wrong for years until a filing forces a look. A repainting condition is satisfied or not, and the file looks identical either way.

The remedy is to model obligations as recurring items attached to the structure, each with an owner, a due date, required evidence and an escalation path, rather than as documents in a folder. That is the same discipline that makes the rest of the portfolio manageable: converting documents into obligations with dates.

Two details make the difference between a compliance module and a compliance system. Evidence has to be attached to the completion, not filed separately, so proving a repair happened is one click rather than a search. And the record has to be append only, because an obligation history that can be edited after the fact proves nothing about what happened when.

Should you build custom or configure Siterra, Sitetracker or Tarantula?

Configure, if your shape matches theirs. Accruent Siterra handles site lifecycle and lease administration and is a reasonable fit for a large conventional portfolio with clean records. Sitetracker is strong at deployment project management, so if your pain is running build and upgrade projects at volume, that is the product to look at. Tarantula is built for tower asset management and towerco commercial operations and may cover most of what a straightforward towerco needs.

Before commissioning anything, run one measurement. Pick five sites at random and time how long it takes your team to produce the current loading configuration and the date of the analysis that covers it. That number is both your business case and your baseline, and if it comes back in under an hour your problem is smaller than you think.

Build when two or more hold. Loading is not maintained as data, so every application starts with retrieval. Your portfolio came from multiple acquisitions with incompatible records. You own structures that are not conventional towers, such as broadcast masts or rooftop estates with unusual landlord arrangements. Your commercial terms vary enough per tenant and per landlord that generic lease administration cannot compute net site profitability. Or you compete on application turnaround and cannot currently measure it.

How do hidden costs get into a tower asset software quote?

Data capture is first and it usually exceeds the software. Price it per site with an explicit assumption about file quality and about how many previous owners contributed records, because those two variables move it more than site count alone.

Structure variety is second. Guyed towers, self supporting towers, monopoles and rooftops have different mount models, and rooftops add landlord and access complexity that towers do not have. A quote built against monopoles and delivered against a rooftop estate is a different project.

Jurisdiction count is third, since registration regimes, standards and lighting requirements differ, and each set is its own obligation library rather than a configuration switch.

Survey data is fourth and should be phased rather than assumed. Linking photographic or drone survey imagery to specific mounts and mounting heights is genuinely valuable, because it turns a survey into evidence you can compare against the equipment schedule and catches configuration drift without a climb. It is also its own workstream with its own capture cost, and it does not arrive free with the asset record.

What separates a tower asset build that works from one that fails?

Knowing what the software must not do. It should not perform structural analysis and should not pretend to. That is a licensed engineering activity with liability attached, and any vendor offering to compute capacity in software deserves scepticism. What the system does is track configurations and tell you when an analysis is required or stale, which is the decision that currently gets made late or not at all.

The second separator is the first pass on a colocation application. Proposed equipment entered against a mount and height, compared with the analysed configuration, returning one of a few outcomes: within existing analysis, requires a fresh analysis, likely requires structural modification, or exceeds the structure. That takes minutes and is right most of the time, which lets you give the carrier an indicative answer immediately and reserve engineering effort for the cases that need it.

The third is whether the physical record and the commercial record are joined. The known leaks are equipment installed under an amendment that was never billed, tenants who upgraded years ago and still pay the original rate, decommissioned tenants still being charged, and ground lease escalators applied inconsistently. Every one of those comes from two teams maintaining two records. Joining them makes each physical change raise a commercial question automatically.

The fourth is ownership. The repository, the hosting and the structured asset data should be yours from the first commit, agreed in writing before kickoff. The equipment and configuration register you build is the asset that outlives the software.