ISP Subscriber Management and Billing Development: When Billing, the Access Network, CPE Stock and the Install Calendar Are Four Systems That Never Talk

Why the disconnect that matters is between your own systems

A regional fiber ISP with 6,800 subscribers runs a delinquency report on the fifteenth. Forty-one accounts are past due beyond the grace period. Someone marks them suspended in the billing system. Nothing happens on the network. The subscribers keep streaming, because suspension in billing is a status field, and the thing that actually controls their connection is a policy on the access platform or a RADIUS attribute nobody changed. It gets done eventually, by an engineer, in a batch, when someone remembers.

Run the same gap forward and you find the rest of it. A new install requires creating the account, assigning a plan, adding the subscriber to the access control system, recording the ONT or radio serial number, taking it out of CPE stock, and putting a slot on the installer's calendar. Five systems, five chances for one of them to be skipped. The most common outcome is a subscriber who is connected and not billed, which is worse than the reverse because nobody ever complains about it.

This is not incompetence. It is the natural result of an ISP growing past the tools it started with. You began with a billing package, added an access control server when you needed one, tracked routers in a spreadsheet because that was fine at 300 subscribers, and scheduled installs in a shared calendar. Each decision was correct. The combination is now the constraint.

Problem 1: suspension must reach the network or it is theatre

The single most valuable integration in an ISP stack is billing status to network state. Non-payment suspension, restoration on payment, plan speed changes, and temporary seasonal suspension are all the same mechanism: a change in the subscriber record must produce a change in what the network allows.

How that is executed depends on your access technology. It might be a RADIUS attribute change and a disconnect message, a policy update on an OLT for a PON subscriber, a queue change on a fixed wireless platform, or a captive portal redirect. Most ISPs implement one of these paths and leave the others manual, which is exactly why mixed technology operations leak.

What a custom build does: define a small set of network states, active at plan speed, restricted to a payment portal, suspended, disconnected, and implement each one per access technology behind a single interface. Then billing changes trigger network changes automatically, with a verification step that confirms the network actually applied it rather than assuming. That verification is the part people skip and it is what turns the feature from mostly working into trustworthy.

Problem 2: the incumbents are genuinely good, and that matters

We will be straight with you here, because this category is different from most we write about. Sonar, Splynx, Powercode, Azotel, Visp, UISP, Rev.io and Inomial Smile are real products built by people who understand ISPs. Sonar and Splynx in particular cover a lot of ground: billing, provisioning integration, inventory, ticketing, scheduling. If you are a single-technology ISP with a conventional plan structure, one of them will serve you well for years and cost a fraction of a build.

Where they run out is structural rather than featural. Products with fixed wireless heritage carry assumptions about how service is delivered that do not map cleanly onto PON, and the reverse is also true. Multi-entity structures, common with cooperatives, municipal networks and holding companies that acquired several small ISPs, tend to fight products that assume one company with one general ledger. Wholesale and open access arrangements, where you carry another provider's subscribers over your network or vice versa, are usually outside the model entirely. Grant-funded builds bring reporting and eligibility obligations that no product anticipates. And per-subscriber pricing that was trivial at 2,000 subscribers becomes a visible line at 40,000.

What a custom build does: fit the structure you actually have rather than the one the product assumes. That is the only honest reason to build in this category, and if none of those structural mismatches apply to you, buy the product.

Problem 3: serviceability is an address problem you keep answering by hand

Every sales conversation starts with whether you can serve an address. The answer depends on whether the address is passed by your fiber, whether there is capacity on that splitter or that sector, whether the drop is buildable, and whether the address is even a real deliverable location.

Most ISPs answer this with a person, a map and local knowledge. That works until you are selling in more than one town, or until you are filing broadband availability data and discover your internal understanding of what you serve does not match the location data the filing is based on. The gap between what your team believes you serve and what your records say you serve is a reporting exposure and a marketing problem at the same time.

What a custom build does: hold serviceability as data joined to standardised addresses, with the network element that would serve each location and the current capacity on it. Then the website says yes or no instantly, sales stops promising installs that engineering will refuse, and your availability reporting is generated from the same source your sales team uses. Consistency between those two is worth more than either individually.

Problem 4: CPE is inventory with a serial number and a location

Routers, ONTs, radios and mesh units are assets you buy, hold, deploy, recover and sometimes never see again. At small scale a spreadsheet is fine. Past a few thousand subscribers it stops being fine in a specific way: you cannot answer how many units are in a technician's van, how many were deployed to accounts that have since churned, or what your actual capital exposure in the field is.

The churn case is the expensive one. A subscriber cancels, the equipment is not recovered because nobody generated a recovery task, and the unit is written off silently. Multiply by a normal churn rate and the annual number surprises people.

What a custom build does: serialise inventory from receipt through van stock to deployment to recovery, tie every deployed unit to the subscriber and the service address, and generate a recovery task automatically on cancellation with a value attached so it can be chased or billed. Technicians scan on and off their van. This is simple software and it consistently returns more than it costs.

Problem 5: installs are a scheduling problem with physical constraints

An install needs a technician with the right skills, the right equipment on the van, a time window the customer accepts, travel time that makes sense, and sometimes a prior step such as a drop build or a permit. Scheduling this in a shared calendar produces the predictable outcomes: technicians criss-crossing the service area, jobs booked without the equipment on hand, and customers given a window nobody could have met.

What a custom build does: schedule against real constraints, meaning skills, van stock, geography and job dependencies, and give the technician an app that shows the job, the subscriber, the serviceability record, the equipment to deploy, and a completion flow that updates inventory and activates service on the spot. Activation at the door rather than back at the office is the difference between a subscriber who is billing today and one who is billing when someone gets around to it.

What this costs and how long it takes

Across projects Digital Heroes has delivered, a subscriber management core runs $80,000 to $180,000 across 13 to 20 weeks. That covers the subscriber and service record, plan and promotion rules including the contract and promotional pricing structures that products usually cannot express, billing and payment with dunning, access control integration with verification, serialised CPE inventory, address-based serviceability, and install scheduling. Extending into a customer self-service portal, a field technician app, support for a second access technology, network documentation and mapping, wholesale or open access billing, and regulatory reporting runs $220,000 to $500,000 phased across 8 to 14 months.

What drives price up here: the number of access technologies, because each one has its own provisioning and policy control path. Multi-entity or cooperative structures with separate ledgers and member accounting. Wholesale and open access arrangements, which effectively double the billing model. Migration from an existing platform, since subscriber, billing history and inventory data all have to move without interrupting service or billing. And grant reporting obligations, which should be scoped with whoever manages your grant compliance before engineering starts.

What keeps price down: keeping your existing billing product for invoicing in phase one and building the provisioning, inventory and serviceability layer around it. Several of our ISP clients never replaced billing at all, because once provisioning and inventory were solved the billing product was fine.

Build versus buy, and why buying usually wins here

Buy if you are a single-technology ISP under roughly 5,000 subscribers with a conventional plan structure and one legal entity. Sonar or Splynx will do the job, you will be live in weeks rather than months, and the money is better spent on plant. We turn away work in this category regularly and we would rather tell you now.

Build once two of these are true of your network, not one. You run genuinely mixed access technologies and no single product handles both well. You are a cooperative, a municipal network or a group that acquired several ISPs, with multiple entities and member or patronage accounting. You carry wholesale or open access traffic where the billing subject is another provider. Your plan and promotional structures cannot be expressed in your current product without workarounds that finance then has to unpick. You are past roughly 25,000 subscribers and per-subscriber licensing is material. Or you have grant obligations that require reporting your product cannot produce.

The honest tipping point is workarounds. Count how many times a month someone does something outside the system to make the system work. When that count is a daily habit rather than an occasional annoyance, the product has stopped fitting.

How to choose a developer for ISP platform work

Ask how they would make a billing suspension take effect on the network, for each access technology you run, and how they would verify it applied. If the answer stops at updating a status field, they have built a billing system and not an ISP system.

Ask what they would do about a subscriber who is connected but not billed. A developer who has done this work treats it as a reconciliation that runs continuously between the network, the inventory and the ledger, because it is the most common revenue leak in the category.

Ask how they would model serviceability and whether they have worked with standardised address and location data. Vague answers here mean your sales team will keep promising installs engineering cannot deliver.

Ask about migration specifically: how they move subscriber history, invoices and inventory off your current platform without an interruption, and whether they run parallel billing for a cycle. Anyone who proposes a single cutover weekend on a live ISP has not done one.

Get ownership of the repository, the access control integrations and the cloud accounts written down before kickoff. At Digital Heroes the ISP owns the repository and the network integration code from commit one. Tell us your access technology mix, subscriber count and entity structure, and we will tell you honestly whether you should be building at all or buying a product and spending the difference on fiber.