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:
- A trusted SI with a PE/VC mindset, taking on risk and skills
- A “Better-than-Gartner” model
- Sub-brand company model (volume business vs managed services)
- A whole-of-industry match-making service
- Affiliate leads / sales programs
- Premium telco services (demand outstrips supply)
- An exponentially better OSS
- Low-code / No-code glue
- Other solutions
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:
- Confidence / Skill-set
We’ll reference these items again in the solution examples below.
Affiliate leads / sales programs
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:
- Buyers engage us in OSS / BSS vendor selection processes, to help them find the best-fit sellers for their needs (ie left to right across the mesh)
- We provide a listing with contact details and key capabilities of all known OSS / BSS sellers (note that this is provided to buyers and sellers on a free of charge basis, not on an affiliate basis)
- Sellers are able to claim their Directory listing and update key details (eg new products) whenever they wish
- We’ve recently added a field that allows Sellers to optionally provide details about their affiliate / partner programs for any interested sales agents
- We allow OSS Buyers to register their RFP / RFI / Procurement events to initiate and streamline buyer – seller connections
Limitations with the current approach
- Most sales connections occur manually, and at great cost / effort, today (ie right to left across the mesh)
- To our knowledge, few (if any) sellers offer affiliate links that would facilitate a more systematic buyer-seller connection system to be developed. We expect that this is likely to change as more OSS sellers begin to offer packaged / containerised solutions through cloud marketplaces in future (Note: Some, but certainly not all, vendors do offer affiliate / partner programs on a more manual basis today though)
- To our knowledge, there are few freelance sales agents / people / organisations within the OSS market that represent the yellow dots in the mesh above
- Whilst our list of sellers (light blue dots) is all but complete, we don’t currently maintain a registered listing of buyers (dark blue dots). We have connections within many buyer organisations, but certainly not the hundreds of thousands that exist globally
- Increasing trust (eg finding reputable affiliate partners), decreasing risks (eg finding reliable affiliate partners) and increasing confidence (eg in the quality of the connection / match-making process) is still a work in progress for us and/or the industry to solve
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.
Premium telco services (where demand outstrips supply)
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.
An exponentially better OSS
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.
Low-code / No-code glue
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:
- Standardisation – The efforts of standards bodies like TM Forum and MEF are providing standardised patterns, language, approaches and knowledge sharing between buyers and sellers. The chasm would undoubtedly be far wider without the efforts of many contributors
- Partnership and Ecosystem Leadership – We’ve touched on mechanisms that help to enhance alliances, and there are many of them, but sometimes the telco industry can be too insular in its thinking. There are many internal-facing problems that are rightly being focused on, to be sure, but the main emphasis of this series is to create a rallying cry for a broader leadership perspective. We need to look and lead beyond our own organisation, having sufficient empathy for, and understanding of, the situations of our clients, partners, ecosystems, etc, which can inform improved ways for us to connect
- Better Procurement Approaches – We’ve already discussed that traditional RFP approaches are failing both buyers and sellers, taking too long and costing too much. We’ve discussed various different approaches throughout this series and many previous articles (including this one that suggest T1 telcos could adopt a mindset more akin to smaller telcos when running their OSS procurement events)
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?”