I thought it would be timely to share a little more on my perspective of the Telco API, given my attendance at some upcoming conferences around Web/Telco 2.0 where this will be topic of discussion:

• TeleStrategies Telco + Web 2.0 Service Creation conference were I’m running a pre-conference workshop on “Successful Strategies for SDP Deployment” and presenting at the conference in the “Telco + Web 2.0 Service Creation: Making the Business Case” session with Tal Givoly, Chief Scientist, Amdocs.
• Spring VON in San Jose next week where I’m moderating the “2.0 This! Rethinking the Service Creation Model” session.
• SofNet 2008 where I’m on the panel session Pragmatic Approach to Developing IMS Services.

The Telco API (aka ANI (Application Network Interface) or 3rd Party API) is often viewed as just a method for operators to expose capabilities from their networks to third party applications.  But as these slides show, Telco API.pdf, the Telco API is much more than that.  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.

Examining these categories in a little more detail:

• Operator Branded Service.  An operator’s existing voicemail service could be enhanced using say SpinVox’s speech to text capabilities.  The business model could be per transaction, a fixed fee or ad-sponsored.  The customer will likely decide their preference.
• Co-branded Services.  An operator’s Facebook widget, so friends can gift ringtones or minutes or share location.  The business model could be a simple 50:50 revenue share.
• Long-Tail Services.  For Enabled Applications it could be a field-force automation tool that a local SI integrates into small and medium businesses.  For Endorsed Applications it could be a vetted and tested application that provides home security, the business model could be a simple 50:50 revenue share.  And finally Internet Applications where the model could be based on a published schedule or ad-sponsored.

Examining the benefits for the operator:

• Operator Branded Services: Cooler features to extract great value from segments within the customer base, as well as lower cost of provision for such features to make targeting segments economic.  As mentioned in previous posts in this weblog, the operators situation has a significant impact on service success, modeling to date shows a potential of 4-10% ARPU uplift.
• Co-Branded Services: Enabling the operator’s customers to access cool communities or brands with a compelling user experience.  Modeling to date shows the potential for a 3-8% ARPU uplift.
• Long-Tail Services: Enabling operators to economically reach SMB (Small Medium Business); extending an operator’s ability to test out the 80% of its service roadmap it never has the resources to implement; and finally co-opting Google’s success to the Telco API.  Modeling to date shows a potential of 5-18% ARPU uplift.

So the Telco API has the potential to raise ARPU by between 12-36% depending upon the operators’ situation.  Which given global voice ARPU continues its 5% annual decline, this uplift can not come quick enough.