The Telco API: Services examples with the potential to raise ARPU by up to 36%

In a previous weblog article I discussed how the Telco API is much more than a method of exposing capabilities from telco networks to third party applications.  As these slides show, Telco API.pdf, the Telco API impacts all services in an operator’s business.  Using the classic demand curve, we can break its impact into three main segments:

  • Operator Branded Services.  Here the impact can be in enabling 3rd party features to be mashed up with an existing operator branded service, or as a standard within the operator to enable capabilities to be efficiently reused across operator branded services.
  • Co-branded Services.  Any emerging category of services, exemplified by 3 with their X-Series, that co-brands services, e.g. Skype powered by 3.
  • Long-Tail Services.  There are three important categories within the long tail.  Enabled Applications that do not necessarily have an operator brand association (e.g. 1800 services).  Endorsed application with a preferred search position and endorsement of the operator.  And the wild wild west of Internet Applications.

The previous weblog article described how the Telco API has the potential to raise ARPU by between 12-36% depending upon the operators’ situation.  Adding a little more ‘meat onto the bones’ of the enabled services, this sample database shows a small subset of applications and application categories, their positions on the demand curve, potential business models and example suppliers.

The business model is broken down further into pricing options, addressable segments and longevity (is it a fad or a core service).  This is a critical change in service management for operators, voice and messaging are examples of core long-tern services; but many new services are more likely to be fads; that gain some traction and then fade into obscurity.  Some even consider social networks a fad!

The number of services in the full database is rather long, and faces the classic issue: is it a service or is it a feature.  For example, ‘Brewey finder’ can only exist within a package of location based services from an “operator branded” perspective.  However, there is a small segment of the market that would just want a brewery finder, here it may exist as a standalone third party application, and perhaps due to some inspired cross-marketing achieve a level of adoption not possible if it were operator branded.  This is an important point in evaluating the services enabled by the Telco API – operators must let their ADCs (Application Developer Community) freely innovate with services that may appear competitive to some operator branded features, in the limit the market will decide based on the value an operator presents to the customer.

Here is a list of just some of the services in the table.  As you can see it’s a mix of specific services and broader service categories.  The reason is in part because it is a small sample from a much large database, and also because some service categories are understood in more detail than specific services:
Ad Insert Platforms; Ad Supported gaming; Address Book Community; Asset Tracking; Bill management; Blogging / MicroBlogging; Brewery finder; Call Management, CityInformation; Co-branded Widgets, Internet Mobilization, STB Widgets; Communication enabled business processes; Community enabler; Community Widget; Conferencing / Collaboration; Conferencing widget for social network; Content search and display; Converged Communications; Couponing; CRBT (Caller Ring Back Tone); Create mobile / STB content; Dating; Directory Services; Earthquake!; eGovernment; eHealth / Telemedicine; eInclusion; elearning; Emergency Alerts; Enhanced Voice; Enterprise Community; Enterprise LBS; Enterprise mash-up enabler; Enterprise mobilization; Family Management; Family Security; Family smart limits…