Creating an API enablement programme is not easy – and repeated efforts to do so show how hard this can be. Nevertheless, it can be done. Here are some key tips, based on more than a decade of success.
For years, the telco industry has repeated the mantra “if you build it, they will come” in relation to API-enablement platforms. Repeated efforts over the last couple of decades to galvanise developers have shown that this isn’t necessarily the case. In fact, for most operators, the opposite has been true. Initiative after initiative has been loudly heralded, only to disappear – with a few notable exceptions, like Telenor.
Now, a new GSMA-led initiative hopes to change this, as we noted in a recent post. Essentially, it’s another set of APIs that operators can expose to developers. In our earlier post, we noted that commercial models are essential to ensure the success of such initiatives. Now, we’d like to share another nugget, to help operators understand what it takes to replicate the success of market leaders that have pursued winning strategies and delivered compelling propositions.
So, back to “build it and they will come”. The truth is, they probably won’t – at least, not in the droves you imagine. And, when they inevitably don’t, the simple conclusion will be that the API wasn’t right, or that they’re not interested. What will likely happen is that some will come, there’ll be a bit of experimentation (with some nicely packaged sandbox) and then…nothing that drives the expected business returns.
Interestingly, consultancy STL Partners has published a timely report on network APIs. STL Partners, you may recall, used the concept of ‘two-sided’ business models some years ago to highlight new opportunities for telcos. In “Network APIs: Driving New Revenue Streams for Telcos”, two kinds of API are defined:
The report suggests information APIs will drive volume (lots of location update requests, perhaps), while configuration APIs will be reserved for premium cases and customers.
The timing of the report suggests that the original two-sided vision is far from reaching fulfilment, but it is interesting, none-the-less. However, our experience suggests that both kinds of API are important – and it’s not a simple binary choice.
That’s because status can be used to drive changes, as can location – so knowing the status and location of a user or device allows you to trigger actions in response. And this is important – because the value to the operator is then from the increased engagement that results from the action. It’s a useful definition, to be sure, but it’s only a framework for discussion.
However, we have some insights from our own experience that can definitely help other operators that seek to embark on this journey.
If it’s consumers, then forget it. If it’s for B2B – what do you really mean by B2B? Do you mean companies that will integrate and develop on your API directly? If so, that’s going to take a huge effort. Everyone is busy and, no matter how simple the APIs are to work with, and how well documented they are, the fact is that it’s unlikely that you’ll drive the mass adoption you seek. You will definitely win a number of customers, but it’s unlikely to meet expectations.
No, you need to have a very clear target in mind. One such is Systems Integrators that work with multiple enterprises, perhaps supporting highly specific applications. These companies are likely already tailoring enterprise services, so will be more receptive to extending functionality through the capabilities your APIs can unlock.
Moreover, they are likely to perform integration with their own applications – so as they roll these out, they will bring on more enterprise organisations by default. In time, more businesses may work with you directly, but in the near-term, you need to target the audience that is most likely to see immediate advantages.
Having selected your audience, ensure that you optimise the resources you deploy to support this. If you are working with Systems Integrators, they will find the API consumers for you. Similarly, other service providers or organisations that might wish to use your network to reach their customers or to leverage capabilities that enhance their offer.
These must be your core targets, because they can act as multipliers, spreading the integrations they build to their own customer base. When they gain customers, or upsell a new set of capabilities, you benefit from increased subscription to the API.
Access to the API isn’t just about releasing a set of specifications. You want to drive consumption, but it’s not as simple as a blanket policy of transactional models. The kind of API might dictate the best approach. If you are offering information such as location data, then higher volumes might benefit from a tiered approach, while control capabilities might be used less frequently and but have a higher value – so transaction models can work here.
In all likelihood, a mix of models will make sense – but they must all accrue value, so you can expect to get it wrong before getting it right. In fact, flexibility is key – be prepared to change and to consult extensively with key stakeholders. The APIs have to work for them too.
Exposing network APIs – in whatever form – and capturing value from doing so is tricky. So tricky, that many have failed. However, our partners have succeeded, and they have done so by carefully targeting the right user segments, building scale through selected partners, and getting the prices right.
They’ve also succeeded by using the right gateways – like our Telco Services Gateway platform, which provides access to a wide range of network APIs and is the foundation of a number of industry-leading API enablement programmes that drive revenue and growth.
Want to learn more about Gintel, our mission and our technology