This is the fifth of the “buyer / seller” chasm articles (pt1, pt2, pt3, pt4). We’d previously highlighted the issues, the pain points, the sources of friction and more about getting Buyers and Sellers together to build better telcos. But in today’s article we’ll complete the solutions list that we started on in part four, which helps to overcome those challenges by building bridges across the Buyer / Seller chasm.
We’ll explore items 5 to 9 as methods to reduce the size of the chasm:
You’ll also recall that in part 2 of the series, we discussed that a major chasm exists between buyer and seller across many different factors, but the three key ones are:
We’ll reference these items again in the solution examples below.
When it comes to sellers (OSS vendors / suppliers), there are only a few hundred globally (represented as the four light-blue circles in the Buyer – Seller Mesh below).
However, when it comes to potential buyers (carriers, ISPs, utilities, even enterprise), there are hundreds of thousands globally (represented as the eight dark-blue circles in the Buyer – Seller Mesh below).
This graph might imply that there’s a 2 buyer to 1 seller ratio. However, if you look at the lines instead of the circles, you’ll realise that any of the 4 sellers can potentially form a partnership with any of the 8 buyers. Any buyer can have more than one OSS product in their management stack. Instead of a 2:1 ratio, it’s actually an 8:1 ratio. Now if we expand this out to all buyers and sellers, every seller can theoretically pitch their OSS solution to the hundreds of thousands of potential buyers (a 100,000:1 ratio).
In reality, it’s simply not viable for every OSS seller to try to sell to every buyer, so they tend to narrow their focus to certain types of buyer (eg size, purchasing power, required functionality, jurisdiction, etc). i.e. each light blue dot is selective about which dark blue dot to invest time into, which makes a partial, not complete mesh like shown above.
But also consider how the ratio changes again when you factor in that buyers are like whales and may only surface occasionally. Any given buyer may only undertake a significant OSS transformation every 5-10 years. Many of the dark blue dots are effectively greyed out at any given time, but the lines connecting to them must still be maintained to ensure the seller is aware / ready when the buyer next surfaces.
It seems that there’s an opportunity for intermediate sellers, or affiliates (yellow circles in the Buyer / Seller / Affiliate mesh below), to help connect buyer and seller together. You’ll notice the difference in the number of connections (only 16 lines on the graph below instead of 32 in the graph above).
In theory, this means relationship effort / overhead is halved (I know I’m massively oversimplifying here, albeit for demonstration purposes). Ideally, that yellow intermediate step would be much more systematic than the current approach, in the same way that Uber and Airbnb apps act as efficient aggregators of buyer – seller connections. Such an approach is expected to significantly reduce the friction of bringing buyers and sellers to connect across the chasm. It is also likely to increase reach without increasing the size of the sales payroll.
At Passionate About OSS, we partially perform this buyer – seller connection function today:
Limitations with the current approach
If you can think of ways to improve this process and / or have ideas for possible collaboration in mind, please contact us privately or leave us a comment below.
For high-volume, low margin telco services (eg residential and small-to-medium businesses [SMBs]), most telcos will aim for ubiquitous availability and infinitely scalable capacity as a competitive advantage over their rivals. Using this limitless capability mindset makes it almost impossible for demand to outstrip supply (ie supply is nearly infinite). Therefore, we need a highly automated OSS / BSS stack to deliver economies of scale to this market, but we also need to massively reduce OSS transformation friction. We discussed this in the “sub-brand company model” section in part 4 of this series.
However, at the other end of the scale, there are some telco services that are still constrained, where demand does outstrip supply. One area is managed services, where telcos provide sophisticated, and often highly customised telco services for government, large enterprise, etc. The main constraint in this situation is the skilled resources required to offer bespoke solutions (of tech, people, process, offerings, etc).
In my experience at least, telcos tend to build bespoke OSS/BSS solutions that act as a bridge between their client’s OSS/BSS and the telco’s own OSS/BSS. Building bespoke solutions means telcos are limited to how many managed services accounts they can serve in a highly personalised way. Just as an example, a higher cost to serve might limit the carrier to offering premium capabilities to only the companies in the S&P 100 instead of the S&P 500. A well-designed, repeatable OSS/BSS could allow telcos to reach a larger proportion of mid-market customers with personalised services. I’ve seen mid-market customers, often with telco budgets exceeding $1m per annum, that are screaming out for bespoke telco services but are basically only given the same as those offered to SMBs, but at a higher volume.
This mid-market, premium telco service opportunity is primed for telcos to do better and drive up revenues in the process.
Doing so requires the development of a cookie-cutter solution that not only closes the chasm and reduces friction between OSS Buyer and Seller, but also needs to form a highly repeatable / composable solution that decreases the size of the chasm to enterprise clients as well. We refer to it as the Enterprise BOS in this article…
…and also the customer-connecting BOS model to give greater ecosystem value to clients.
As far as I’m aware, there isn’t an off-the-shelf OSS/BSS that’s been designed around the requirements of a managed services ecosystem that caters for premium service delivery. I’d love to hear from you if you’ve seen great examples of it.
What is a better OSS? Better almost certainly means different things to you and me. But the key here is less about what we would consider “better” and more to do with “exponential.”
We’re seeing rapid advancements in “exponential” technologies in adjacent industries. Generative AI, AR/VR, immersive web, quantum computing, quantum networking, AIOps, AI networking, analytics, spatial / situational awareness, database technologies, virtualisation and others are all becoming increasingly mainstream. Yet, as indicated in part 3 of this series, most of our OSS/BSS tools have been built around principles and user interfaces that were first developed decades ago. We’re working on incremental improvements (the blue arrow) rather than experimenting with game-changing features and technologies that we already have a line-of-sight to (the red box and green arrow), let alone stretching for a future that we can’t fully see yet.
We know these technologies will massively change the ways of working in the telco industries. But the funny thing is that the use of these technologies probably just drives the chasm wider in many cases. They represent a bridge too far. As you’ll see in our recent AIOps of the Future Report, many telcos are struggling to make the leap to this new paradigm in operations partly because of the tools being still relatively nascent, but also because of the many human factors of change (eg fear of the unknown, changes in operations models and processes, evolving skills-mix, etc, etc). The confused mind says no and since these technologies haven’t been implemented, there’s a lot of confusion and fear.
So instead, perhaps these exponential technologies allow us to look at age-old problems, such as the OSS Friction Continuums below, through new architectural lenses. Do cloud and Developer Experience (DX) technologies allow us to revisit how we package up products for installation? Do SaaS models allow us to develop pricing models that are easier for carriers to understand and commit? Can modern data pipeline and data cleanse technologies make it easier to get data in / out and through our OSS more easily? Do Learning Management Systems (LMS) and Video sharing platforms provide examples of how to make training more easily consumable, trackable / measurable and more specifically targetable to a particular problem being experienced by a given user? Do immersive technologies provide a 3D rather than 2D way of presenting data to make is easier to collaborate and gain situational awareness remotely?
We can drastically pull the chasm closer just by shifting from left to right across these continuums and exponentially improve our OSS in the process. Moreover, incorporating exponential technologies like AR/VR into smaller decisions will actually will bring greater confidence, trust and risk reduction to ensure the chasm doesn’t become too imposing to even consider crossing.
One of the biggest challenges of undertaking an OSS transformation is not so much the off-the-shelf OSS products. They’re often quite functional straight out of the box and can be demonstrated quickly. The challenge is often more in the plumbing of data flows to reliably connect products together to create seamless, reliable, end-to-end workflows. When conducting end-to-end testing, it’s more common for test cases to fail at the boundary points between applications than within the products themselves. Simple situations like transformation and reformatting of a data field from one system to another can cause issues. It’s not just a single data flow, but the multitude of data flows that combine in massive variant trees that make the integration tax so expensive and time-consuming. In doing so, it widens the chasm for the current buyer – seller engagement, but also the perception of the chasm width for future transformations.
Traditional middleware solutions and mediation devices were often cumbersome and highly customised “products” in their own right. Modern low/no-code integration / automation / orchestration platforms are helping to reduce the size of this chasm. As these platforms continue to improve, integration patterns standardise and tools become more easily used, then trust, risk and confidence factors will all improve.
There are a couple of other long-standing and important solutions for us to mention that are helping to bring buyers and sellers closer together:
In the next part of this series, we ask the question that exemplifies the massive chasm between buyers and sellers – “What’s the worst thing that could happen on an OSS transformation?”
We recently discussed how the “Ultimate Game,” a study in behavioural psychology, might help to explain why there tends to be less initial animosity between
The great thing about the holiday period is you often get the chance to step away from business as usual (BAU) activities. As customer projects
Last year, we published a series of articles about the chasm that exists between OSS/BSS buyers and sellers. “The chasm” is best exemplified by the
Whilst setting up for another new initiative this week I became aware that the PAOSS blog has just ticked past 1 million words. And that’s
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
