Satellite Capacity Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them
The most expensive failure in capacity software is holding inventory as bandwidth alone. Sales sees free megahertz on a beam and quotes. The beam is power limited rather than bandwidth limited at that elevation, so the extra carrier does not close at the committed information rate the contract has already promised. Somebody covers the shortfall by allocating more space segment than was sold, and because nothing in the system records why, that extra allocation becomes permanent. You are then paying for capacity you never billed, on the most expensive idle inventory in commercial technology, and the sheet still says the beam has room.
Why does capacity get modelled as one number per beam?
Because that is what the spreadsheet held, and the spreadsheet was correct once. A tab per satellite, rows for carriers, occupied bandwidth in megahertz, a column for the customer holding each slot, and a note about guard bands. One capacity planner maintained it and knew where the fudges were.
Then the fleet added high throughput payloads with dozens of spot beams instead of a handful of wide transponders, and adaptive coding turned throughput into a weather dependent variable rather than a fixed number. The single number stopped meaning anything, but it kept being copied into every new tool because it is the shape everyone recognises.
The consequence is asymmetric, which is what makes it worth fixing properly. Oversell and you degrade customers who paid for a committed rate, on an asset with a service level agreement and a competitor one phone call away. Undersell and transponder capacity sits dark.
Model inventory as bandwidth and power per beam, with your own equivalent isotropically radiated power and gain over noise temperature contours loaded rather than assumed. A sold service is a committed rate against a terminal type at a location or a route, and the system computes required bandwidth from the modulation and coding scheme that closes at your design availability. Planners already do this arithmetic. The point of the build is that it stops being done once at sale and starts being maintained as the population changes.
What goes wrong when you migrate the beam plan and contour data?
Contours are the schedule risk nobody prices. In many operators they exist only as manufacturer PDFs, which means somebody has to turn printed contour plots into usable geospatial data before a single calculation runs. That is real work, it needs an engineer who can sanity check the result, and it sits on the critical path of everything else.
The beam plan itself brings a different problem. The spreadsheet encodes decisions that were never written down: a guard band that is wider than standard because of a known adjacent satellite issue, a slot held for a customer who has not signed, a carrier that is nominally 4 megahertz but has always been run at 4.5. Migrate the numbers without the reasons and the new system will confidently reallocate capacity that a human was protecting.
Handle it by migrating with an interview. Sit with the planner, walk every anomaly in the sheet, and record the reason as a first class attribute on the reservation rather than as a note. Reservations that exist for commercial reasons, held slots and internal use, should be visible as such so utilisation reporting is honest. And validate the migrated plan by recomputing this month's live services and comparing them against what the network is actually carrying. Where the model and reality disagree, the model is usually missing an assumption the planner never had to write down.
Why do hub, network management and billing integrations break after launch?
Because you are integrating with three different worlds that were never designed to agree. Hub platforms from iDirect, Newtec and Comtech expose different data in different shapes, and each is its own integration with its own version behaviour. A firmware upgrade on one hub changes a field, and your occupancy time series quietly develops a gap that nobody notices until a monthly report looks odd.
Billing breaks on identity. The network knows terminals and service identifiers. Billing knows contracts and sites. Nothing links them permanently unless you decide it does, and terminals get swapped, reassigned and reused across customers. A mapping built once at go live degrades every month afterwards.
Design for drift rather than for correctness on day one. Own a canonical terminal and service registry that both the network side and the commercial side reference, with effective dated assignments so a swapped terminal does not rewrite last month's history. Alert on data that stops arriving rather than only on errors, because silent absence is the common failure. And pin the expected shape of each hub feed with tests that fail loudly on a version change, so a firmware upgrade produces an alert instead of a hole in your utilisation numbers.
What happens when service level and outage credit terms are not covered?
The network operations centre works an outage as an engineering event: which carrier, which hub, which terminals. The account manager finds out when the customer calls. Afterwards somebody joins an outage log to a contract by hand, and the two records were never designed to be joined, so the credit is negotiated from memory rather than computed. Whoever argues hardest does best, which is not a policy.
The same disconnect runs the other way. Interference is detected on a carrier, and identifying whose service it affects requires knowing the current assignment, which lives in a sheet that is slightly stale. Carrier identification helps you find the source. It does not tell you who is owed an apology.
Put the contract and the carrier in one data model so an event on a carrier resolves immediately to the affected services, the customers behind them and the availability terms in each agreement. Credits then come from the outage record. The second benefit matters more than it sounds: maritime and government customers increasingly ask for monthly availability evidence, and producing that by hand costs a person several days a month for reports nobody reads unless something went wrong, at which point they are read very carefully indeed.
Should you build custom or configure what you already own?
If you resell a single wholesale block on fixed terms to a handful of accounts, the spreadsheet is fine and it is currently correct. A build would be an expensive way to make it prettier, and the money belongs in space segment.
Buy where the product owns the layer, and most operators already own more than they use. Kratos has deep ground system and signal monitoring capability that you are not going to rebuild. Integrasys is strong on carrier monitoring, commissioning and interference detection. Your ST Engineering iDirect hub tooling is the authority on what the network is doing, and Amphinicy builds serious ground segment software. If your gap is monitoring, commissioning or signal quality, configure what you have and integrate it. Any developer who offers to replace that layer is overselling.
Build when two or more of these are true. Your commercial inventory and your engineering reality live in different places and disagree. You sell committed rates against terminals that move between beams. Link budget recalculation has become a human bottleneck for routine commercial changes. Utilisation reporting cannot be reconciled to billing without manual work. Or you carry capacity from several payloads and wholesale suppliers on differing commercial constructs. The tipping point is consistent: vendor tooling models the network, and your problem is the join between the network and the contracts. Nobody sells that join because it is made of your beam plan, your assumption set and your commercial terms.
How do hidden costs get into the quote?
Ground segment quotes go wrong in five predictable places.
- Hub integrations are counted as one. Each vendor platform is its own data shape and its own version behaviour, and the count of platforms in your estate is usually the largest single cost driver.
- Contour data is assumed to exist. If it lives in manufacturer PDFs, converting it is a project task on the critical path rather than a setup step.
- Mobility is quoted as a reporting filter. Beam occupancy as a time series per terminal is a distinct data layer and it roughly doubles the reporting work.
- Non geostationary capacity is folded into the same model. When the beam is moving as well as the terminal, the occupancy model is different, not just busier.
- Link budget assumptions are treated as configuration. Antenna sizes, terminal characteristics by model, pointing loss allowance, rain model and availability target by region are your assumption set, and agreeing them internally takes longer than implementing them.
The honest bands from Digital Heroes delivery experience are $90,000 to $200,000 over 14 to 20 weeks for a first release covering capacity inventory with power and bandwidth held separately, contract linked reservations and link budget computation against your own assumptions, and $250,000 to $600,000 phased over 9 to 15 months for a full platform adding hub and network management integration, roaming occupancy tracking, utilisation reconciled to billing, outage and credit handling, and customer reporting.
What separates a build that works from one that fails here?
Whether the team draws the right model before quoting. Ask for a whiteboard session. A developer who understands this domain draws payload, beam with power and bandwidth held separately, carrier, terminal, service with a committed rate, and a time dimension on the occupancy, and asks about edge of coverage unprompted. Someone who draws capacity as a single number per beam has built a resource booking system and will discover satellite physics on your budget.
Second, the link budget has to be an object rather than a file. Attached to a contract line, versioned, and recalculated automatically when the beam plan or the terminal population changes, with exceptions surfacing as a queue. That is what stops the radio frequency engineer being a ticket queue for routine commercial changes and returns their time to the calls that need judgement.
Third, mobility has to be in the model even if it is phased. A service assigned statically to a beam is wrong for the entire mobility segment, and retrofitting a time series into a static assignment is a rewrite rather than an addition.
Fourth, phase honestly. One payload and one hub platform first, mobility second if fixed services carry the bulk of your revenue today.
Fifth, ownership in writing before kickoff: the repository, the infrastructure and the assumption set. At Digital Heroes the client owns it from the first commit. A good test costs one meeting: take a live maritime contract and ask a developer to explain how they would prove, from your data, what that vessel actually received in each beam it crossed last month. If they can describe the data path, they understand the problem.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- McKinsey estimates that digitizing the supply chain (Supply Chain 4.0) can cut lost sales by up to 75%, reduce inventories by up to 75%, and lower supply chain operational costs by up to 30%, with up to 30% lower transport and warehousing costs. Source: McKinsey & Company (2016) →
- McKinsey reports that autonomous supply-chain planning can raise revenue up to 4%, reduce inventory up to 20%, and cut supply-chain costs up to 10% while maintaining service levels (the wider 20-30% inventory-reduction figure comes from McKinsey's separate distribution-operations research, not this page). Source: McKinsey & Company (2020) →
- 73% of surveyed businesses now use a headless architecture (up nearly 40% since 2019), and 98% of those not yet using it are evaluating or planning to evaluate headless within 12 months, with 82% saying it makes delivering consistent content easier. Source: WP Engine (2024) →
- Across 1,471 IT projects the average cost overrun was 27%, but one in six projects was a 'black swan' with an average cost overrun of 200% and a schedule overrun of nearly 70%. Source: Harvard Business Review (Bent Flyvbjerg & Alexander Budzier, University of Oxford) (2011) →
Devon looks after direct to consumer accounts, where the store is the business and a bad checkout costs money the same day. He works with brands on commerce builds and site changes, and writes about what to prioritize when every request looks urgent.
View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
How do we find out whether we are already overselling a beam?
Take your busiest beam and recompute every live service on it from the committed rate, the terminal type and the location, using the coding scheme that closes at your design availability rather than a uniform efficiency figure. Compare the total against the beam's power and bandwidth limits separately. Operators usually find the discrepancy at edge of coverage, where the rule of thumb efficiency was closest to wrong and where the mobility customers spend most of their time.
Can we keep our hub and monitoring tools and build only the commercial layer?
Yes, and that is the arrangement we recommend most often. Monitoring, commissioning and signal quality belong to the products that already do them well, and rebuilding that is neither sensible nor cheap. What you build is the join: capacity inventory with power and bandwidth held separately, contract linked reservations, link budgets attached to contract lines, and occupancy reconciled to billing. Confirm early what data each hub platform can actually export, because that sets what the commercial layer can compute.
What do we do if our contours only exist as manufacturer PDFs?
Convert them before the build starts, and treat it as its own task with an engineer who can check the result rather than as a data entry exercise. Every calculation downstream depends on it, so it sits on the critical path whether or not the plan acknowledges that. Operators who already hold contours in a usable geospatial format move through the first phase noticeably faster, which is the single clearest predictor of schedule we see in this category.
How should a terminal that changes beam mid month be handled?
As a time series of beam occupancy per terminal, fed from the hub and network management data rather than inferred from the contract. Utilisation per beam is then computed from where terminals actually were, and the committed rate can be checked against what was deliverable in each beam visited. Any model that assigns a service to a beam as a static attribute is wrong for your whole mobility segment, and that is the part of the market that is growing.
Why do our utilisation and billing numbers never agree?
Because they are computed from different objects. Billing knows contracts and committed rates, the network knows terminals and carriers, and nothing permanently links the two once terminals are swapped or reassigned. Fix it with a canonical terminal and service registry that both sides reference, using effective dated assignments so a swap does not rewrite last month's history. Until that exists, every reconciliation is a manual join and every month it drifts a little further.
Can outage credits be computed automatically?
Yes, provided the contract and the carrier sit in the same data model so an event resolves to the affected services and the availability terms behind them. Today most operators join an outage log to a contract by hand afterwards, which is slow and tends to favour whoever argues hardest. The same data produces the monthly availability evidence maritime and government customers increasingly ask for, which otherwise costs a person several days a month.
How many hub platforms can we integrate in a first release?
Plan for one, and choose the platform carrying most of your revenue. Each additional vendor is a separate integration with its own data shape and version behaviour, and the count is usually the largest single driver of cost in this category. Getting one platform working end to end, from occupancy through utilisation to a customer report, teaches you more about your own data quality than adding a second platform ever will.
Where does the radio frequency engineer's time go after a build like this?
Out of routine plan changes and into exceptions, which is where it was always worth more. When the link budget is an object attached to a contract line, a plan change or a terminal swap triggers automatic recalculation and only the results that fail margin reach a person. The team members who fear being automated out of the process usually become the ones defining the assumption set, which is a more durable role than processing service change requests one spreadsheet at a time.
We already use Fishbowl. When does replacing it with custom software make sense?
How many SKUs are too many for managing inventory in Excel or Google Sheets?
How many people does it take to build inventory management software?
How much should a small business budget for its first custom app or website?
How many SaaS seats do we need before building custom becomes cheaper?
What should I have ready before I contact an agency about inventory software?
What should I prepare before contacting a software development agency?
Who can build a custom inventory management software system?
Digital Heroes builds custom inventory management software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other inventory management software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
