Ask three people at a fiber operator what OSS and BSS mean and you'll get three different answers, and none of them will explain why a technician showed up at a house that wasn't actually ready to be installed. That gap, between what the network side thinks is true and what the business side already promised a customer, is the real story behind OSS and BSS. The category definitions are the easy part.
What OSS was built to do
Operational Support Systems started as the network's system of record: inventory, topology, provisioning, fault management. The idea was sound. The problem is that most OSS platforms became a place where information got updated after the work was done, not while it was happening. A technician finishes a job in the field, and the OSS reflects that job as done sometime later, once someone gets around to entering it. At small scale that lag doesn't matter much. At the scale most fiber operators are building at now, it means your planning team is working from a picture of the network that's already out of date.
What BSS was built to do
Business Support Systems handle the customer-facing and commercial side: orders, billing, revenue. BSS platforms are genuinely good at scale, high order volumes, recurring billing, complex pricing. What they're not good at is knowing whether the network is actually ready for what they just sold. An order gets approved because a serviceable address exists in the system, not because someone verified the drop is live today. Billing starts because a status flag flipped upstream, not because a technician confirmed the service works. That's how you end up promising a subscriber a go-live date the field can't hit.
Why splitting them into two systems creates the problem
Every handoff between OSS and BSS is a place where a delay, a manual step, or a miscommunication can happen. Planning works off network data that may not match field reality. Sales and billing run off the assumption that provisioning finished on schedule. Field crews often don't know what a customer was promised or when. None of this is a people problem. It's a design problem: two systems, two owners, and a seam in the middle that somebody has to manually reconcile every single time.
The six stages an OSS/BSS platform actually has to run
The fix isn't a better OSS or a better BSS. It's stopping the habit of thinking in those two categories at all and looking at the full sequence of work instead. Every fiber operator, whether they call it this or not, is running through six stages:
Plan: coverage mapping, serviceable location data, build-vs-prebuild decisions.
Build: equipment procurement, staging, commissioning, backbone and middle-mile connectivity.
Sell: address qualification, order capture, payment, product and campaign management.
Install: scheduling, dispatch, route optimization, field execution.
Activate: provisioning, connectivity verification, same-day billing.
Run: monitoring, ticketing, support, ongoing service.
Most vendors sell you one of these six. A few sell you two. When nothing in the middle is integrated, reconciled, or chased by a person, that's not because the individual stages got better, it's because the same platform owns the handoff on both sides of it. A closed order schedules the field work. Nobody in the middle. A completed installation provisions the device. Nobody in the middle. A provisioned service bills the same day. Nobody in the middle. That's what "connected lifecycle" actually means in practice, not a slogan, just fewer places where a person has to notice something broke and fix it by hand.
What this looks like when it's real, not theoretical
Ripple Fiber is the clearest example I can point to. It started as a 13-person team with a mandate to build fiber and none of the operational infrastructure that goes with it, no NOC, no helpdesk, no billing platform, no carrier network of its own. Instead of building each of those functions from scratch, Ripple ran its operations on AEX from day one. It's now a 10-state operator passing more than 250,000 homes, doubling both its footprint and its customer base year on year. That's not a projection. It's what already happened, and it's the same reason a gap between provisioning and billing doesn't have to be something you design around.
Where OSS and BSS work actually happens now
In practice, the definitions matter less than the ownership. The AEX Software platform covers the traditional OSS/BSS ground, planning, sales, provisioning, and the monitoring half of ongoing operations. AEX Field Service owns installation and the field half of the build. AEX Network Services owns the physical build and the operations side of running the network day to day. None of that is new terminology dressed up, it's a description of who actually does the work at each of the six stages, which is a more useful question than "is this an OSS problem or a BSS problem."
| Stage | What breaks in the traditional OSS/BSS split | What a connected lifecycle does instead |
|---|---|---|
| Plan | Coverage data drifts from field reality | Serviceable locations reflect current build status |
| Sell | Orders approved on presumed availability | Orders check against verified readiness |
| Install | Field crews unaware of customer commitments | Scheduling reflects actual promises made |
| Activate | Billing starts on an upstream status flag | Billing starts on confirmed connectivity |
| Run | Faults surface from customer complaints | Faults surface from network monitoring first |
The question worth asking
If you're evaluating whether your own systems are working the way they should, the question isn't "do we have OSS and do we have BSS." Most operators do. The question is how many of the six stages above are actually connected to each other without someone in the middle catching the gap by hand. The fewer seams, the fewer appointment failures, the fewer delayed activations, and the fewer subscribers finding out about a problem before you do. I've written before about how each of those stages connects end to end, and about the specific integrations that close the gaps operators run into most often.
Frequently asked questions
What is OSS in broadband?
OSS stands for Operational Support Systems. It's traditionally the network side: inventory, topology, provisioning, and fault management. The gap in most OSS platforms isn't the category, it's that the data reflects the network's intended state rather than what's actually happening in the field right now.
What is BSS in telecom?
BSS stands for Business Support Systems. It covers customer orders, billing, and revenue. BSS platforms handle volume and pricing complexity well, but they depend on accurate signals from the network side to avoid selling or billing something the field hasn't actually delivered yet.
What's the difference between OSS and BSS?
OSS manages the network. BSS manages the customer and commercial side. The friction shows up at the handoff between them, when BSS approves an order or starts billing before OSS has confirmed the network is actually ready.
Why do OSS and BSS struggle at scale?
Because the handoff between them was built for occasional manual reconciliation, not constant volume. An operator expanding into new markets can have network documentation lagging field progress by weeks, which means orders get scheduled against locations that aren't ready yet. The backlog of exceptions that creates is what slows activations and delays revenue during the exact period an operator is trying to grow fastest.
How does field service fit into OSS and BSS?
Field crews are the ones who confirm whether a location is actually ready, complete the install, and trigger activation. When field results don't feed back into the system quickly, planning and billing are both working from guesses instead of confirmed status. Appointment failures and repeat truck rolls are usually an information problem, not a technician performance problem.
What does a connected OSS/BSS lifecycle actually mean?
It means running planning, sales, install, activation, and support off the same data instead of five separate systems that each require someone to manually keep them in sync. In practice, that's the difference between a technician's completed job triggering billing automatically versus billing waiting on someone to check the work has been completed.
