Pages

Pages

Sunday, December 23, 2012

Do telco network voice/messaging capabilities need to be "exposed" via 3rd party APIs?

For several years now, we've watched telecom operators try to court application developers, offering APIs for a variety of network and database functions. These have ranged from billing-on-behalf, through to SMS and phone call initiation, location lookups, authentication and so forth. Some of these have been offered by operators acting "solo" (most larger operators have developer programmes), while we have also seen standardisation efforts through organisations like OMA and GSMA's OneAPI programme.

All of this is seen as a way for telcos to:
a) Build revenues by charging directly for the APIs
b) Gain mindshare & relevance among Internet & IT developers, building an "ecosystem"
c) Potentially move up the value chain beyond "minutes and messages" into CEBP (communications-enabled business processes) or application rev-share models

Usually, the network APIs have been just a part of a wider developer-facing effort, which has also provided developer tools, testing facilities, and even funding through associated incubators and VC arms. While some seem to have gained quite a lot of critical acclaim (eg Telefonica's BlueVia), the actual results - especially in monetary terms - have been lacklustre. Most operators have now moved away from operating their own appstores, for example.

I see a few problems that have contributed to this state of affairs:

  • While developers understand the role of device-side APIs (for creating smartphone apps, eg on iOS & Android) and web APIs (for creating mashups, eg with Google Maps), they have much less awareness or understanding of the role (and possibilities) of in-network telco APIs
  • Various telco API initiatives have been quite poor - the actual functionality, or the way it has been packaged, has not fit well with the way developers design their applications or services, or has been poorly documents, or have required clunky sign-up or registration processes.
  • Telcos are seen as slow and uncool (important for developers)
  • If you're not a telco person, it's difficult to get your head around how the networks actually work and for whom. If a user calls into a company's call-centre, does the operator API work via the user's network, or the company's provider? Apps are always user-centric (and must be downloaded), but applications are server-side
The last point is really critical. It's the difference between apps and applications, and goes right to the heart of whether operators have a chance to resuscitate their falling SMS and telephony revenues (and usage).

I've long talked about the limitations of telephony, and it's also something that Martin Geddes and I cover in depth at our Future of Voice workshops. Phone calls are old, clunky and really not a great experience - they're often interruptive, there's no upfront indication why someone is calling, there's no context info beyond caller ID, they're charged per-minute (which may be an inappropriate metric), and they come with a whole set of social and etiquette rules that may diminish the value of an interaction.

The question is whether the best way around this is to avoid using "calls" at all, and just shift to other forms of communication: "non-telephony voice apps", or completely abandon voice and shift to messaging or other ways to interact. If I want a taxi nowadays, I use a London cab company's app, which is faster and better because I enter the address, get a price quote, time of arrival, vehicle registration and so on. Much better than trying to speak to a dispatcher, from a noisy pub or restaurant.

But the other option is to try and reinvent  the phone call - and the phone network - to be more useful, and work around some of the deficiencies of the format. We've long seen "call me" buttons on company websites, but how much more valuable would be "call me, with your agent having been sent the web-form I've filled in 80% and then got stuck, so they can help me complete it". That's clearly not interruptive (I've requested it), it's got context (the partially-filled form), maybe it's recorded by me or them, and I'm not paying for it - and maybe they're paying by a metric other than a minute.

The problem has been that that's not just a telco API. It's both a telco AND web API, working together. It's also (probably) not inside a smartphone app, but just uses the regular phone dialler as the UI. Which makes it very hard for a company to specify, a developer to produce, or for a telco to enable. Add in that the company might want to give its customers the option to connect via both traditional phone calls or VoIP ("Skype me"), plus various styles of messaging, and it becomes harder still. They might also want to have all this integrated into a smartphone app that  their regular customers download (eg bank, airline etc). Add WebRTC into that for in-browser comms in future, too.

(There are many other use cases beyond call-centres, but this is a good illustration).

Looked at that way, it becomes clear that the telco network call-initiation API is only an ingredient of a much broader "meta-API" (probably) provided by somebody else.

This is why we're seeing other companies start to sit between telcos and developers - Voxeo and Twilio probably being the best-known examples. They are able to help developers put together those sorts of useful functions that don't need have to have a downloadable app, but run using "legacy telephony" updated with rich context and programmability. They can still exploit ubiquity where appropriate (ie everyone can call/be called), but work around some of the human psychological and behavioural downsides of a 100-year old service.

We've seen various partnerships already - Voxeo & DT, Twilio & AT&T, for example - and I think we will see quite a lot more. Apart from anything else, those companies are "web telephony" players, and don't have the same anti-coolness stigma attached to telco APIs. They may also be in a place to create more sensible business models that don't boil down to minutes.

I see parallels here with other areas of telecoms. Jasper Wireless does much the same intermediary role for M2M - it provides a platform for telcos that turns their network capabilities into something that device manufacturers can actually use to develop new service models. Most telcos wouldn't know how to deal directly with a company that makes washing machines or digital cameras, so having an intermediary layer makes sense. We may also see the same for authentication/ID services, and of course we've long had SMS aggregators or external advertising networks that also essentially help telcos monetise their network resources or customer data assets.

This range of API intermediaries might even be able to salvage something from the wreckage of RCS (certainly, various of them are hoping for it). They could also be the ones who manage to put some lipstick on the IMS pig for developers, although I suspect that will be very market-dependent and won't work on a generalised global basis.

Where I think this approach will struggle is with consumer-to-consumer services, which are increasingly going to be be app-based on smartphones or tablets. There will probably be reasons to bridge between phone calls, SMS and websites on occasions, but I think that Viber, Skype, Facebook and others will still develop the majority of their comms functionality on a direct-to-user basis, without the need for "embedded" telco functionality in the form of telephony. I'm unconvinced that some of the niche-specific uses of voice comms (eg karaoke, baby monitors, voiceprint biometrics etc) will use telco "raw ingredients" rather than app-style OTT VoIP or (in future) WebRTC.

But for companies and brands, this new layer of meta-APIs, which incorporate some telco APIs "under the hood" has some interesting potential. Less clear is what proportion of the value flows to the operators, versus the new tier of Twilio, Voxeo et al in the middle.

2 comments:

  1. Really interesting points here Dean. I wonder if, underlying such things as a common understanding of the API between telco and solution developers, if the success of telephony APIs and telco web APIs is hindered by the Quality of Service needs of the particular scenario.

    There have only been limited in-roads to end user applications. Individual users spread around the internet are more willing to run apps that provide indeterminate QoS. They get by, because their voice traffic is averaged across the network. Indeed, Skype intelligently routes through lowest latency/highest throughput network nodes, making it even more resilient to this effect.

    Contrast this with call centres, where there is a concentration of voice traffic and a need to maintain high QoS. As you point out, the call-centre is one place (I'm sure there are others) where telco API and web APIs flourish at the moment to support features like caller identity integration with CRM and other systems, call-centre worker mobility, smart call routing to centres distributed around the world, and so on.

    All voice/video users want decent QoS, it's just that when you concentrate your users in one place on the internet, you quickly hit the limitations of that network.

    ReplyDelete
  2. IMHO, the enterprise market is eager to services created on top of telco services but fully customized. It makes no sense to build up those services as a turn-key project done by a big integrator but just using telco APIs and perhaps done by an agile company specialized in using those APIs.
    If Voxeo and Twilio are growing and more players are entering in that space is because what they have make sense and they can monetize. Some additional telco services can be exposed and perhaps the telco future revenue, apart from the access business, will be the "fair" (not abussive) monetization of the exposure layer.

    ReplyDelete