What is OSS and BSS? Getting back-to-basics can be a challenge at times. How to explain what OSS and BSS mean. Concisely. Accurately. There’s always been debate and opinion on their respective roles. And people can’t even agree what OSS stands for. OSS Line shines a light on this thorny but fundamental topic…
What does OSS and BSS stand for?
OSS is either Operational Support System or Operations Support System.
You have too much time on your hands if you want to argue over which is the ‘correct’ definition. Historically, I’ve used Operational, but I acknowledge that Operations sort of makes more sense when you think about it…
BSS stands for Business Support Systems. Simple. No debate.
What are Operational Support Systems?
Software (occasionally hardware) applications that support back-office activities which operate a telco’s network, provision and maintain customer services.
OSS is traditionally used by network planners, operations, architects, support, and engineering teams in the service provider. Increasingly product managers and senior staff under the CTO or COO may also use or rely on OSS to some extent.
What are Business Support Systems?
Software applications that support customer-facing activities. Billing, order management, customer relationship management, call centre automation, are all BSS applications.
BSS may also encompass the customer-facing veneer of OSS application such as trouble-ticketing and service assurance – these are back-office activities but initiated directly by contact with the customer.

above. Super simple relationship between OSS and BSS
Is the separation between OSS and BSS clear?
No way! Apart from service assurance activities being cross-OSS-BSS processes, there are as many overlapping functions as there are clean integration points between the two domains. Indeed, it could be argued that the distinction between OSS and BSS is no longer useful. Yet, these terms continue to be used.
Service Catalogs introduced a grey area between OSS and BSS. No one was sure where they lived. But that's their strength. They exist to bridge the gap.
Similarly Service Management applications allowed greater interaction between OSS and BSS processes.
Before Service Catalogs, before Service Management, a common job like capturing a customer order and provisioning it required a simple BSS-to-OSS interface. “Provision product X for customer Y”. Then networks got more complicated, more flexible, and telcos started to offer a range of differentiated products. OSS and BSS had to start liaising over what could be ordered by the customer, based on what service they already had, based on the network they would use, based on current available resources, based on how far they were from the telephone exchange… and so on.
Views of the network configuration are pushed up in to BSS in the form of Service Catalogs. Service Management processes push BSS decision-making down, close to the network, to determine what is the right service to offer for this customer.
There’s now less debate about what these in-between systems do, but still plenty of uncertainty about who’s budget the implementation project comes out of…