Tower and Site Asset Management: Why Adding One Tenant Takes Three Weeks of Document Hunting

Why a tower portfolio's real record is a filing cabinet

A tower is a simple asset with a complicated file. Steel, foundations, a set of mounts, and on those mounts a group of tenants who each pay rent. The file behind it contains the original design drawings, foundation records, one or more structural analyses at different loading configurations, mount analyses, modification drawings if it was ever reinforced, inspection reports, photographs from the last climb, tenant equipment schedules, lease documents with escalators, and correspondence about who is allowed on site and how they request access.

Most of that lives in folders named by site number, on a shared drive, organised by whatever convention the person who set it up preferred. Some of it is in a previous owner's naming convention because the portfolio was acquired. Some of it is missing, and nobody knows it is missing until someone looks.

The operational consequence appears every time a carrier submits a colocation application. The revenue is straightforward and attractive: a new tenant on an existing structure is close to pure margin. The process to accept it is not. Someone has to establish what is currently on the tower, at what heights and azimuths, whether the last structural analysis reflects that reality, whether the proposed equipment fits within the existing capacity or requires a modification, and how long the analysis will take. Every one of those steps is a document retrieval task, and the clock on the tenant's deployment schedule is running the whole time.

Problem 1: loading is a calculation and your record is a PDF of one

The governing question for any structure is whether the current and proposed loading passes analysis under the applicable revision of the TIA standard for antenna supporting structures, with the wind and ice criteria for that location. The analysis is done by a structural engineer and delivered as a report. The report is a snapshot of an assumed configuration on a specific date.

Reality then diverges from it immediately. A tenant swaps antennas for a different model with different projected area. Someone adds a remote radio unit at the mount. A decommissioned tenant's equipment is left in place because removal was never scheduled. Six months later the structure carries a configuration that no analysis has ever evaluated, and the only way to know is to climb it or to compare photographs against a schedule that may itself be out of date.

Accruent Siterra and Tarantula both hold site and tenant data properly and are used seriously in this market. What they do not do, and what nothing off the shelf really does, is maintain the loading configuration as a live structured record that changes when a tenant's equipment changes, and flag when the current configuration has drifted from the configuration that was analysed. That drift is the risk. It is also entirely trackable if the data exists in a form a system can compare.

What a custom build does: hold equipment as records with model, quantity, mounting height, azimuth and the projected area figures the analysis cares about, attached to the tenant and the mount rather than to a document. Each structural analysis is stored as a configuration snapshot with its assumptions. Then any change to installed equipment is compared against the analysed configuration automatically, and a site whose reality has drifted becomes a queue item rather than a surprise. The build does not replace the engineer, and should not try. It tells you when to call one, which is the decision that currently gets made late or not at all.

Problem 2: the colocation application is a document hunt with a revenue clock

Carriers submit applications with their own forms, their own equipment naming and their own timelines. Your response requires the current loading position, a view on whether a modification is needed, an estimate, and a schedule. Where that takes three weeks of internal work, the carrier notices, and towercos compete on responsiveness as much as on portfolio.

Sitetracker is genuinely good at deployment project management and will run the workflow once the application is accepted. The gap is upstream: the part where you decide whether you can accept it, which depends on the asset record being trustworthy enough to answer without a climb.

What a custom build does: turn the application into a structured intake with an automatic first pass. Proposed equipment is entered against the mount and height, compared with the analysed configuration, and returns one of a few outcomes: within existing analysis, requires a fresh analysis, likely requires structural modification, or exceeds the structure. That first pass takes minutes and is right most of the time, which lets you give the carrier an indicative answer immediately and reserve the engineering effort for the cases that need it. Modification projects then hand off to whatever project tooling you already run rather than being managed in email. Operators who ship this describe the change in terms of application turnaround time, which is the metric their customers actually judge them on.

Problem 3: compliance obligations that fail quietly

Registered structures carry obligations that are easy to satisfy and easy to forget. Obstruction lighting has to work, and an outage has to be reported and repaired within the required timeframe, with notification to aviation authorities. Registration records have to reflect actual ownership and structure details. Marking and painting have their own conditions. Inspection regimes, whether annual or on the cycle your insurer or the standard requires, produce reports that have to exist and have to be acted on.

None of these fail loudly. A lighting outage on a remote structure is detected by a monitoring unit that may itself have failed, or by a member of the public. An inspection that was never scheduled produces no alert. An ownership record that was never updated after an acquisition sits wrong for years until something forces a look.

What a custom build does: model obligations as recurring items attached to the structure with owners, evidence and escalation, and ingest lighting monitoring alarms directly so an outage creates a tracked incident with the reporting clock visible rather than an email someone may action. Inspection reports get filed against the structure with their findings extracted as items, so a recommendation to repair a guy anchor becomes a work order rather than a paragraph in a PDF nobody reopens. The whole point is converting documents into obligations with dates, which is the same discipline that makes the rest of the portfolio manageable.

Problem 4: the asset record and the revenue record are run as separate businesses

Operations knows what is physically on each tower. Finance knows what each tenant pays, when the escalator applies, when the term expires and what the ground lease costs underneath. Those two records are usually held in different systems by different teams, and the gaps between them are where money goes missing.

The specific leaks are well known to anyone who has done a portfolio audit. Equipment installed under an amendment that was never billed. A tenant who upgraded their configuration years ago and is still paying the original rate. A decommissioned tenant still being billed, which is worse than the reverse because it ends in a credit and a bad conversation. Ground lease escalators applied inconsistently. And on acquisition, a portfolio where the seller's rent roll and the physical reality of the towers do not match, discovered slowly over the following year.

What a custom build does: connect the tenant's physical configuration to the lease terms so that a change on the tower raises a commercial question automatically. An amendment adding equipment triggers a billing review. A decommission triggers a termination workflow and stops the charge. Escalators run from structured lease terms rather than from a diary. On the cost side, ground lease payments and any landlord revenue share are computed from the same tenancy data, which is what lets you see net site profitability per structure rather than gross rent, and that number changes which sites you invest in.

What a tower asset build costs and how long it takes

From Digital Heroes delivery experience, a first release covering the structured site record, mounts and tenant equipment schedules, loading configuration tracking against analyses, and the colocation application intake with a first pass assessment runs $65,000 to $140,000 and ships in 12 to 16 weeks. A full platform adding compliance obligations with lighting alarm ingestion, inspection and maintenance regimes with work orders, site access management, and lease and revenue linkage runs $170,000 to $400,000 phased over 7 to 12 months.

What drives cost up in this portfolio type specifically: data capture, which dominates everything else. Turning a filing 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. Structure variety, since guyed towers, self supporting towers, monopoles and rooftops have different mount models and rooftops add landlord complexity. Multi country portfolios, because standards and registration regimes differ. And whether you want photographic or drone survey data linked to mounts, which is valuable and is its own workstream.

What keeps cost down: capturing the sites that generate colocation applications first, which is usually a minority of the portfolio, and backfilling the quiet rural sites over time.

When Siterra, Sitetracker or Tarantula is the right call

Buy if your shape matches theirs. Accruent Siterra handles site lifecycle and lease administration and is a reasonable fit for a large conventional portfolio. Sitetracker is strong at deployment project management and 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 for a straightforward towerco it may cover most of what you need.

Our position on when to build: when two or more of these are true. Your loading configuration is not maintained as data, so every application starts with document 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 differ enough per tenant and per landlord that generic lease administration cannot compute your net position. Or you compete on application turnaround and cannot currently measure it.

The tipping point is that products in this space model sites, tenants and leases well, while the question that generates your revenue is a structural one: can this tower take this equipment. Answering that quickly requires holding loading as live data and comparing it against analyses, and that is a portfolio specific model built from your own structures and your own engineers' conventions.

How to choose a developer for tower asset software

Ask them to model a tower on a whiteboard. The right answer has structure, mounts, mounting positions with height and azimuth, equipment records with the physical attributes an analysis consumes, tenant, lease and a configuration snapshot with a date. Someone who draws site with an attached documents folder has built a document management system, which is what you already have and are trying to escape.

Ask how they would detect that a tower's current configuration differs from the analysed one. If they have no answer, the system will store documents neatly and tell you nothing you did not already know.

Ask what they will do about structural engineering. The correct answer is that the system does not perform analysis and does not pretend to, it tracks configurations and tells you when an analysis is required or stale. Be sceptical of anyone offering to compute structural capacity in software, because that is a licensed engineering activity with liability attached.

Ask who owns the code, the repository and the hosting, in writing, before kickoff. At Digital Heroes it is yours from the first commit. A useful first step: 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 measurement is your business case and your baseline.