Is There Money in Voice APIs?

53 Comments

I’ve been covering the VoIP space since 2004, and lately it seems like every other press release sent my way is from a company announcing the addition of an application programming interface (API) to its telephony platform. The promise of APIs is that they make it easy to integrate different services — even those provided by different vendors — into a single application. The press release from one carrier even went so far as to claim that its API would “boost innovation and development of new apps exponentially.”

But is simply providing an API to your telephony infrastructure enough to prompt the world to beat a path to your door? Don’t count on it.

To be sure, these APIs are necessary, particularly in the world of voice mashups. Voice mashups combine voice as well as data and applications across multiple systems to create a new, useful service.

One example of a voice mashup is Twitterfone, a free service that takes your voice, converts it to text and sends it to Twitter. MAXroam provides the overall infrastructure and inbound telephone numbers, Dial2Do does the speech-to-text part, and Zong provides some inbound SIP termination. APIs are needed all around — including on the voice side — to make this happen seamlessly.

Voice mashups can be useful in the business space. They can save a ton of money, and can help to enforce both business process quality and consistency. Imagine calling an airline and speaking to an interactive voice response (IVR) system. A certain percentage of calls could easily be handled by the IVR, which can ask all the correct questions to ensure customers have the right information.

There are, of course, times when speaking with a live human being is necessary. So imagine that all the data collected by the IVR about your call is then sent to a customer service representative so that by the time the two of you are connected, they already know exactly why you’re calling. The call could even be routed to a particular rep based on the reason you’re calling.

This is the power of a voice mashup — the ability to treat voice and data interchangeably. While large companies have been able to afford the cost of developing these custom voice mashups, tools and services are now becoming available that let you make your own.

Jaduka started out by providing a voice API to their telephony infrastructure, which is maintained by their parent company, NetworkIP. But Jaduka quickly discovered that while developers signed up for the API, few were actually using it to launch services. The company now offers customized voice-enabled applications to enterprise customers.

Jaduka’s customers currently use over 4 million minutes a month, a number that is trending upward. But that’s a drop in the bucket compared to the more than half a billion minutes a month their parent company serves.

Ifbyphone provides a number of voice-related small business services as well. They also offer a voice API, but it’s essentially driven by web forms, which makes it easy to integrate their telephony services into any web site without needing to be a programmer.

And while not everyone agrees that what Ifbyphone provides would qualify as a proper API, it does offer a range of useful services to small businesses, such as interactive voice response, intelligent call routing and voice broadcast. They are all designed to help small businesses interact directly with their customers in the most efficient manner possible.

Indeed, APIs enable some great solutions. But APIs aren’t solutions in and of themselves. Nor do they necessarily make money.

Consider Ribbit, a company whose business model is to make telephony available through APIs. The thinking is that they’ll make their money on revenue shares as developers create interesting applications.

If Jaduka’s experience is any indication, however, I don’t expect Ribbit will last too much longer without a complete change of strategy. Ribbit might have 4,000 developers, but how many of them are actually making applications on which Ribbit is able to share revenue? I don’t put a lot of stock in the rumor that BT has purchased Ribbit for $55 million.

Even where you’ve got more than just an API, such as the case with Jaduka and Ifbyphone, the prospects for making a pot of money just don’t seem that great. The combined revenue of Jaduka and parent company NetworkIP is thought to be north of $150 million a year. Assuming Jaduka’s share of minutes per month also translates into share of revenue, that suggests Jaduka is responsible for $1.2 million of the revenue. Ifbyphone would not disclose customer numbers or revenues.

I think the market has a lot of potential, but so far, that’s about it. Go ahead and make those telephony APIs available, but don’t expect the world to beat a path to your door, and don’t expect to make any money just by publishing APIs. Figure out who your customers are, find out what problems they have, and develop solutions to meet their needs. APIs can certainly be a part of the overall strategy, but relying on APIs alone to generate revenue is a pipe dream.

53 Comments

Jordan

“I don’t put a lot of stock in the rumor that BT has purchased Ribbit for $55 million.”

Yeah. $105 mil is more like it. :)

Dameon Welch-Abernathy

It’s great to see the conversation continue here. I guess I hit a nerve!

Given Om’s piece on the downward spiral of the ad-funded economy (along with the rest of the overall economy, refer to http://gigaom.com/2008/07/17/why-silicon-valley-should-be-worried/ ), I have to call into question whether or not simply relying on ads to cover your costs will be enough, at least without some volume. For the VoodooVox folks, having a Plan B wouldn’t be a bad thing (e.g. getting more Nike-type deals).

Granted, any scheme involving monetizing voice APIs doesn’t have to make a ton of money, so long as it covers your overhead with a little extra Nothing wrong with being more modest in your returns or your expectations for them.

J. Scott Hamilton

Hi there,

Scott Hamilton, pres/ceo of voodoovox here. I commented to a post by Om earlier today and mentioned our take on voice apis. I’ll reiterate that here since the discussion is so lively.

We believe there are many interesting voice/web mash-ups just waiting to be built, and we’re trying to foster their development through our free and very simple MyVox api. s we’re all in the know on this thread, MyVox really is just a phone-based voice capture utility that passes a file to the developer to do with it what they will. I have no idea how novel that is compared to any service offered by others on this board, but I can tell you that in less that 3 months of release we have hundreds of developers who have utilized the service to generate very novel voice/web mash-ups, two of the most interesting being from Nike (a karaoke app for the Olympics; go to their basketball site) and a fun service from Ludacris’s WeMix site. Together these app generate only a few million calls a month, but the number of apps is growing daily, and the killer app is just waiting to be developed.

Our revenue model is to provide the voice api for free in return for the rights to insert audio ads into the call stream (exception being Nike, who paid us). We take the calls generated by our MyVox api “publishers” and aggregate them with the calls generated by the rest of the VoodooVox network.

For us, voice is a feature that simply makes some apps/svcs better. We released our voice capture utility to get avails. And with the exception of Nike, I don;t think we have a simple publisher who would have paid for a solution. I don’t know if that says anything for the voice api space in general, or just points out we have a distinct group focused on novelty apps more so than mission critical business apps.

Tony Rybczynski, Nortel

In enterprise:
1. Voice will be an app within a broader set of functionality called Unified Communications.
2. Voice APIs will be part of a suite of UC APIs
3. These APIs will work into a SOA-enabled agile communications environment which will abstract these communications services to create communications enabled business processes.
4. It will be an open environment, working across multi-vendor and cross-domain (carrier-enterprise) environments.
5. Lots of money to be made in solutions, toolkits and professional services.

I discuss these trends in my blog at
http://blog.tmcnet.com/the-hyperconnected-enterprise/index.html

omfut

This is one of the best conversations I have seen in longtime. Thanks Dameon
@Martyn
You make a good point on using standard based API’s. Another point to mention here is- if your target audience is Web 2.0/Voice 2.0 kind of mashups, then supporting some kind of REST/SOAP/XML based API makes it easier for the web developers to understand. Most of the developers and startup entrepreneurs are not core Telco guys. This is a big Plus.

@voodoolabs
Supporting Web friendly API’s is one thing. To me the bigger issue is Finding a Web 2.0 destination platform that needs this kind of app. Looking at the statistics of Voice apps on some of these platforms makes me wonder where does these apps fit in. I guess enterprise might be a better target, Ribbit has figured out that.

voodoolabs

Martyn makes a crucial point in talking about a move to web services and RESTful APIs. Developing telephony applications is simply intimidating to the vast majority of software engineers and entrepreneurs who don’t happen to have experience in the space, but if you can make the technology familiar and easy to at least the Web development community, suddenly you have a much bigger audience and workforce. This, I think, is the key difference between certain modern telephony APIs, and oft-mentioned technologies like VoiceXML: you can’t point a Web developer to VoiceXML and expect great results, but you can with an API that works similarly to the APIs those developers are already using to build Web mashups.

(In fact, I would argue that we are misusing the term “voice mashup” unless we are talking about building applications that follow the web services/RESTful APIs model that have allowed Web mashups to flourish. This is not to say that VoiceXML and its kin are not tremendously valuable, just that they are not enough by themselves to make commonplace voice mashup development a reality.)

Once those APIs exist and are made well-known to the Web development community, there’s room for an explosion of successful app creation. Much of the emphasis in this discussion has (explicitly or implicitly) been on enterprise deployments, but when you put telephony tech in the hands of developers, interactive agencies and entrepreneurs–big and small–who are looking to build novel consumer apps, good things can happen.

Those apps need one more thing, though, which is a business model that makes sense for them. If you are a Facebook developer looking to use the telephone to make voice recordings to post on walls, or a Twitter developer trying to create the next Twitterfone, you want to have a solution to the basic problem of toll charges, or you probably won’t build the app. Enterprise deployments may see enough ROI to soak tolls, but a startup building karaoke into its social networking system (you laugh, but these are real deployments) is going to have a tough time justifying the phone app if its a cost center. In-call media of the type delivered by VoodooVox, Jingle, and some others saves the game here, by paying for the call and access to the API, and even kicking back some share of the revenue to the developer. This completes the ingredients needed for the development of a new class of voice mashups for the consumer space: free APIs that look familiar to Web developers, and free or better access to phone minutes, even to the point of creating a built-in revenue model around usage.

Familiar caveat: I work for VoodooVox, and lead the MyVox API project for the company.

Andrew

@Shai – 3 successes out of 1000’s and 1000’s of applications and 10’s of 1000’s of developers is not what I deem a success, the skype developer program has been great for Skype, but a horrible failure in creating any real value chain that creates business opportunities. They were first and had the chance to be the XP of voice, but failed to get it.

@Ken – my perspective on Jaduka is based solely on my experience of trying to build an app quickly. This was not possible – you can’t ‘sign up’ and play in 2 minutes. Very old school IBM business approach to a 3.0 world.

@Jack – your BT like network is what will attract voice developers, reliability, voice quality etc., but your messaging and marketing are not suited to go after this opportunity. If your sole purpose is to attract business applications designed in house by large business, you’re golden, however if you wish to be a catalyst that creates new businesses you have to make some changes in how you present yourself. Perhaps this is on purpose to start? Happy to discuss – skype me: andrew_hansen

@Martyn – beautifully put, any applications/services that I have been involved with have been at my insistence ‘voice provider agnostic’ – essentially creating our own API that calls others. It would be so much easier if everyone stopped with the ‘lock in’ approach.

Martyn Davies

We’ve got to the stage now where just about every week, some company announces a new proprietary API for voice applications. Meanwhile, there are open voice API standards (like VoiceXML and MSML) that already cater for a lot of basic voice needs (IVR, announcements, voicemail etc).

It’s not hard to understand the dynamics of this: proprietary APIs represent lock-in, i.e. once an application has been developed to an API, then the app will always pull-through sales of the related voice platform, and this is where the “making money” part comes in. In my experience, integrators are very reluctant to change APIs (platforms) once established, or even add a second parallel API for more choice. The reasons for this are many: reluctance to invest; inherent conservatism and fear of the costs of continuing software development; attrition of skills and corporate amnesia, and so on.

By contrast using *ML APIs would make apps portable, so the lock-in effect is not there to guarantee revenue (although many VoiceXML implementations have their own proprietary “tweaks” to achieve lock-in, but this is a story for another day).

The issue for the future is how we can broaden the base of software developers that have access to voice, and this means adopting standards (in the same way that web services and RESTful APIs are democratizing Internet apps). After all, if we end up with 500 different voice APIs then the fragmentation is not going to help an industry emerge.

Dan York

Great to see more excellent comments to this piece. A couple of responses:

@Thomas – I suddenly have some ideas for the next time we share the stage on some panel at some show… ;-)

@Cory – Yes, Angel’s another player in this space. FYI, Voxeo was founded in 1999 and began building out their networking and offering. I indicated 2001 in my reply as that was when they/we started offering the hosted service. A premise version was added in 2006 and you can also use the premise and hosted services together in hybrid models.

@Ben Ortega – You are absolutely right that you have to build your application to scale. You also need to run that application on a *platform* that can scale. In the middle of a crush of new business you don’t want to be running around deploying new servers… you just want the app to scale. Hence the interest now in hosted/cloud-based solutions, which we provide http://www.voxeo.com/products/voicexml-ivr-hosting.jsp , as do others in this space… and it sounds like @Jack does as well.

@Ken – Great comment… yes, indeed, mashups – and the platforms they run on – *do* need a sustainable business model. In the end it does all come down to the volume of minutes and transactions.

@Jack – I’ll have to learn more about what you are doing at Jaduka… we sound like we are on similar paths albeit with different APIs.

Vinay

Great post Phoneboy. I totally agree with my friend Omfut (ravi). I personally believe its a volume game. Only a few companies can do this effectively. Voice mashups/API can only generate money when they are used on large scale. 5000 developers aint going to make u rich.

API as a concept has lot of potential if executed properly at large scale. Look at Facebook, Google etc who did extremely well with API. However expecting API to make money overnight is totally stupid. I would say API busines is still immature and needs large scale implementation. Maybe in the next 2-3 years the market could actually see some potential revenue. However only a few companies would survive till then.

omfut

Great post Dameon, Right on the money. Just providing API is not a game changer. I guess what matters really is the infrastructure and the need for such an API. I think providing API is a good strategy for any companies. This I see will bring in lot more innovation. Maybe it’s too early to write them off, but the future is going to be great for mashups and it might not be a pure Voice Mashup. It’s could be a combination of music, video, location with voice as a communication tool.

The question really is not whether API’s make money; it boils down to what API’s need to be supported for developers to build innovative apps. Just because jaduka didn’t make much of headway doesn’t mean API’s are useless. API’s have proved to be a big success on so many different platforms ( youtube, twitter,last.fm,google,yahoo etc)

You provide API for couple of reasons:
• Spurn innovation. Providing API’s for Voice access gives ammunition to hordes of developers that can think so many different ideas and apps. Just look at the number of applications that are built using twitter platform. In fact, Summize gave twitter a perfect business model for revenue generation. That is the power of open API’s
• Voice minutes usage shoots up, If the applications built on top of these apps becomes popular
• Build Voice mashup applications that can bring in data source from different third-party vendors and provide a unified view

This is what an operator should be doing. They have the infrastructure and bandwidth. Instead of becoming a dump data and transport pipe, should open up their platform for third-party developers and even the independent platform providers. I guess BT 21CN is moving in that direction.

Jack

Great piece! When we talk about APIs and voice APIs more specifically, I echo the comments of nearly everybody posting comments. There is money to be made, it is just matter of the path you choose to take.

A few comments:
@Andrew: Our second generation API has nearly 250 methods available that constitute what we consider to be the most sophisticated voice API and one that is future proof. You call it Voice 1.0 I would agree with @Ken. The public facing API is intentionally 1.0 insofar as it enables basic voice functionality, including the ability to initiate communication from any application. We continue to update all our APIs based on user feedback.

In general, while voice APIs are relatively new, Jaduka is seeing increasing adoption among enterprise companies. In today’s increasingly challenging economic environment, every COO or CTO out there has likely been given a charter to reduce costs, and increase customer loyalty and satisfaction. Given the high cost of customer acquisition, no business can afford to lose a customer. Efficiencies can be gained with voice mash-ups.

We’re also excited about this space. We’ve been able to monetize opportunities for voice as a web service. Our advantage is legacy infused with innovation. We know the challenges inherent in building platforms and software apps for NetworkIP has been in business for 10+ years doing just that. Our hybrid PSTN/VoIP platform is solid and our software is version 8.0. Our own patented and innovative software – IQT®, automatically routes calls over our network, ensuring the highest possible call quality.

Reliability and experience are key attributes for success in this space. For those adding voice to the web who value brand reputation, we believe our success in handling the huge business we currently handle bodes well for major brands that want to leverage the power and innovation of our platform.

I know this post is all about voice APIs however the creative thinkers will figure out ways to leverage the real power of any network, the engine that keeps track of all those wonderful transactions, be it voice calls or… more on this at another time.

Dameon Welch-Abernathy

@spg the amount of minutes Jaduka spends on those “demos” is fairly small from what I have been told.

@khyle that’s the key, these APIs open things up to more people.

@Ben Ortega: that’s one reason why Jaduka/NetworkIP will be successful: they have a proven, scalable network.

@Ken Camp: I think Jaduka is being looked at as purely a VoIP play when we both know that’s not entirely accurate. They are one to watch for sure.

Dameon Welch-Abernathy

@shirish: I agree that APIs are but one of many prongs you need to be successful here.

@don: What I’ve heard about Ribbit for Salesforce is that the experience of getting the client pieces installed to use the client is a FAIL. Also, the other piece you need to consider is that people only change their dialing habits if the cost savings is significant (it isn’t) or the experience is significantly better (it isn’t).

@rob: CTI has been around for a while, but instead of just relaying telephone number and other “on file” information, you can relay specific information that can only be gathered through interaction with the customer.

@Thomas Howe: consultants are always going to make money at this game. :) And yes, a complete product helps, too.

@Dan York: Should have talked to you for this article. APIs need to be based on open standards, 100% agreed.

@Jahangir: A big telco like BT making an API available is a game changer and different than a company like Ribbit doing the same thing.

Ken Camp

I have to really disagree with Andrew. Jaduka is more Voice 3.0 that 1.0. They’re ahead of the pack in ways people barely see the dust on. I just wrote about it today here – http://www.realtime-unifiedcommunications.com/unified_communications/2008/07/of_apis_smoke_and_mirrors_vs_s.htm. I get some insights into some Jaduka activity early in the process, and think they’re going to shake a couple of major players in unexpected space with some things they have coming. They’re a true industry disruptor and shouldn’t be overlooked or minimized.

Somewhere we get a skewed perspective of reality. I don’t care how cool and slick a mashup or innovation is. If it doesn’t have a sustainable business growth model behind it, it’s either a prototype or snake oil. We revere too highly a lot of prototypes and snake oil that don’t have a sustainable business plan or model. Just because something seems amazing doesn’t mean it’s worth a business. Sometimes it’s just a cool but worthless thing. I think we are too slow to ask hard questions sometimes. I know I am, especially where friends are involved.

Voice mashups are only as good as the minutes of network traffic or volume of transactions they carry. And I’m not sure we’re good at asking those kinds of questions much of the time.

Shai Berger

Great discussion.

@Andrew:
“Skype even with its developer network and 1000’s of applications, has not made anyone any real money.”

I disagree with that one. Funny enough I just had a discussion about this with Jim Courtney from Skype Journal (http://www.skypejournal.com/). There *are* some skype plug-ins that are doing good business. e.g. Pamela, Skylook and Unyte (skype-based desktop sharing which was bought by IBM last year). This hasn’t made money for Skype per se, but it drives use of their platform.

Ben Ortega

Nice piece. I love how this topic pops its head up every so often. Are they useful? Will they make money?

I agree with Dan, there definitely IS money in voice apps and those that will make money will have to be built on standards and interoperability.

One of the items that Dan didn’t mention, of which I think bears equal if not more importance, is scalability. A voice app will miss its mark if it is not built to scale. Period!

Although its not a voice app, I see what is happening with Twitter to be a great example of scalability being an issue. “This is a cool idea, let’s try it out”. 9 months later its hotter than sliced bread and now they are dealing with service issues that impact millions of users. Thank goodness for a forgiving web world, otherwise I think they would be in worse shape than where they are today. The voice world won’t play like that.

When building, use APIs that were built on open standards like SIP & IP, have been tested to interoperate efficiently, and above all, build to scale.

Khyle

A nit: Voice APIs are in no way new. Internally, IVR vendors have used them for years to run complicated inbound and outbound campaigns. The main difference in the market today is that the APIs are exposed to many more developers who are just now coming to the realization that Voice mashups are possible and easy to use. You don’t have to work for a telco based enterprise to voice enable your applications anymore.

And since I think the ROI on mashups is pretty clearly large, I strongly agree with Thomas. The question is how does the market mature. Especially now that the APIs are more easily accessible?

*Note that I work for IfByphone.*

spg

i seriously doubt that the jaduka API accounts for even the limited revenues suggested. i suspect that the vast majority of minutes are used by the free of charge ‘jaduka labs’ demo applications such as earthcaller and dukadial.

Jahangir Raina

It all comes down to monetization. If you can offer a big (paying) potential user base to a developer, your APIs will not be a waste. For new providers like Ribbit, it is a bit of chicken and egg situation .. they cannot get many apps unless they have a big user base and vice versa. For someone like BT (Web21C) you are going to see a faster ramp up of apps. BT is already selling some of the apps that it got thru its web21c APIs (example: Ringcentral).

Cory

Any historical discussion of this space should not fail to mention Angel.com They were founded around the same time as Voxeo and seem to have been growing steadily since 1999. I’m not affiliated with them but I remember looking at what they were doing 8 years ago and thinking they were way ahead of their time.

Dan York

Dameon,

Nice piece – and congrats on posting on GigaOm. I agree with you and the others that have commented here that APIs *alone* will not bring the masses to your door. In fact, I’ve become increasingly disheartened by the sheer number of new voice APIs that are appearing… most of which are NOT based on open standards and are NOT interoperable. So developers are forced to learn Yet-Another-API in order to communicate with a given platform… and a voice application built for that platform can’t run on another platform or even communicate with that other platform.

I am a huge fan of voice mashups (in fact, I’ll be speaking about Voice Mashups using Open Standards next week at O’Reilly’s Open Source Convention(OSCON)) and I believe that we need more openness and more usage of APIs… but I also believe that for the overall industry to be successful, we need to ensure that those APIs provide interoperability and avoid vendor lock-in. Yes, a company will undoubtedly want to provide access through an API to their “special sauce”, whatever it is that makes their platform/service special… but that does, in my opinion, need to be balanced with using open standards so that developers don’t need to re-learn everything just to program for that service. The building blocks are already out there… the Session Initiation Protocol (SIP) for call signaling, RTP/SRTP for voice media, VoiceXML for voice applications (including IVR systems) and Call Control XML (CCXML) for an XML-based API to control signaling on top of something like SIP. These blocks just need to be used in the new APIs.

I’ve been writing about issues like this over on my Disruptive Telephony blog ( http://www.disruptivetelephony.com/ ) for some time, but since last fall I’ve also been employed by Voxeo ( http://www.voxeo.com/ ), a company providing a voice application platform since 2001. We’ve had over 30,000 developers create over 66,000 applications on our hosted platform (http://evolution.voxeo.com/ – which runs on our own computing cloud/infrastructure), and thousands more on our premise platform…. most all based on the open standards of VoiceXML, CCXML and SIP.

We’ve seen customers build some amazing voice applications that integrate deep into other business systems using these protocols and APIs. But you’re right, it’s not solely about the APIs… the APIs are just part of the overall tool set used to help customers solve problems.

Dan

P.S. As to your overall question about is there money in voice APIs, I can say that there *is* money in providing a platform for executing apps built on those open APIs. Voxeo’s been profitable (and growing) for now over 4 years…

Thomas Howe

Yes Markus, I couldn’t let this one go without comment…

http://thethomashowecompany.com/410/is-there-money-in-voice-apis

I wish I was the Pope, I’d tool around town in my Pope-mobile and my Prada shoes. That would be awesome. As it is, I have to hang around and make money from Voice APIs. Seriously, I’m no Pope. Think of me as slightly smaller Friar Tuck.

Here’s the thing (and you imply it in your comment): the question isn’t about the existence of money in Voice APIs. All the money is in APIs. The real question is who gets it and why, and how your company can get its share of it. Certainly there is money to be made providing APIs, as they are a basic enabler for everything that goes downstream of them, and they certainly, certainly, certainly are going to make some serious cheese. The question is how does the market mature, not if there’s a market. Rob is quite right – the market exists. VoiceAPIs makes it grow.

Rob

The voice API space you are talking about already exists at CTI – computer telephony integration.

Unless you were being sarcastic (since it seems to work so rarely), the ability to grab that info from the IVR – as well as other info such as your phone number via Caller ID and the number you called in on – and then pass it on to the contact center agent is well established and has been around for a number of years.

Businesses are already making call routing decisions based on this kind of data – whether you like it or not. An example would be a credit card company that I know of will have you enter your account number and if you are delinquent on your payment will always route you to the “why are you late on your payment” queue, regardless of what you were actually calling to do.

The two biggest players in the field are Cisco with the ICM/IPCC product and Alacatel with Genesys.

r.

Don Thorson

Before you get too carried away judging this new category, you might want to check out Ribbit for Salesforce which was built using the Ribbit API. While it’s only been out since May, it’s getting great traction among Salesforce users for the way it integrates voice directly into the application to increase productivity. Intelligently integrating voice into the actual workflow effectively unlocks a new layer of value for the users, in this case, to the order of around $30.00+ a month.

We believe in the future, voice largely becomes a feature layer inside applications (“dumb” voice goes away over time). So it’s not as much about voice, as it is about intelligent integration and workflow automation. If you think of voice as an under-utilized data object, interesting things start to happen. We are convinced this is just the first example – we know because we have visibility into “work in progress” by other developers. Applications without voice integration will eventually become the exception. Check out Ribbit for Salesforce:

http://www.ribbit.com/salesforce/

Yes, I work for Ribbit :)

Shirish Andhare

Nice write up Dameon. There is a lot of buzz around Web Services for voice. Its great to see voice join the development mainstream from this standpoint. However, I completely agree that having an API is just a third of the three pronged challenge of developing innovative applications, maintaining a robust voice network, and attracting a critical mass of end-users in a win-win value chain that should be measured by usage and revenue generated for the developer.

Most players today are doing the easy stuff – APIs + handful of developers + toy mashups – and declaring victory. Getting to a critical mass (and I mean millions) of end-users almost inevitably means working with an incumbent Telco today, working through their constraints of operationalizing innovative applications at scale, and promoting them to an end user base that only knows of a vanilla POTS service. Only a brave few are focusing on the tremendous potential here. By the way, this is not just a technical problem. It is a huge business and marketing challenge as well.

Dameon Welch-Abernathy

@Shai APIs at the carrier level make a lot of sense. Telcos are built on interoperable standards. APIs are simply a logical extension of that. However, I think the APIs will be geared more at other carriers, not at enterprise and small businesses like Jaduka and IfByPhone are doing.

@Andrew: I don’t see Jaduka being “voice 1.0 in their thinking” as entirely a bad thing. They do have telco-grade equipment with telco-grade reliability at their disposal. Also, while we spent a few years thinking about Voice 2.0 and beyond, the vast majority of enterprises and businesses are just now starting to come to terms with Voice 1.5–the fact voice can go over IP at all.

I think you hit the nail on the head about building your own infrastructure versus depending on someone else’s. That being said, APIs come in real handy when you can wrap your hands around the infrastructure, e.g. a soft switch or PBX.

Andrew

This is exactly what I have been preaching for a year, and I have met with much snickering and eye rolling. Voice API’s (in and of themselves) cannot make money, there are no startups (that I am aware of) that have pitched and closed funding for a business concept that is based off of using someones else’s network or API. Conversely customers of network providers are willing to pay for minutes, but they are NOT willing to pay for the use of an API. API’s are expensive to develop and maintain, and unless your end goal is to provide a toolkit for others to quickly grow a business and have the ability to make a serious margin, they will remain unused.

Credit where credit is due, Ifbyphone seems to be the closest to “getting it” so far, Jaduka although backed by a major network, is still very much Voice 1.0 in there thinking. Skype even with its developer network and 1000’s of applications, has not made anyone any real money.

There will be a major shakeout in this space in the coming 18 months, Voice mashups are great for proof of concept, but when it comes down to the brass tacks, you end up always building your own telephony infrastructure, rather than relying on someone else’s – as no one will fund a startup, that is 100% reliant upon another startup..

Shai Berger

Nice review of the space, Dameon. I think the value of an API is determined by A) what functionality it exposes and B) the power of the underlying infrastructure.

In particular, I think carriers have a lot to gain today from the right API’s. They need innovative services to help differentiate what has become a real commodity (plain old voice). They also need ways to drive consumer loyalty to their brand. But, they are not organizations that are conducive to the kind of creativity this needs.

I know that isn’t entirely on point with your article, but it was fresh in my mind having just read this interesting piece from Alan Quayle: http://tinyurl.com/6fmrko

Comments are closed.