Thomas "Voice Mashup" Howe Answers Your Questions
As we discussed a few weeks ago, there's a huge opportunity for telcos to help enterprises (big and small) reduce costs in everyday business processes by using telco voice and messaging capabilities. The 'communications-enablement' cost is tiny versus the operational savings.
Enterprise CIOs are starting to see this and telcos are making more and more API's available. But telcos need to insert their platforms into the IT value chain more proactively now. It's specialist developers like Thomas Howe (one of the millions of developer "ants") who are showing the way. Here's his presentation from the last Telco 2.0 event and below that some answers to questions. Thomas will be joining us again on 6-7 May in Nice.
Q: Where is the money in 'Communications-Enabled Business Processes'?
A: The question isn't actually where's the money. We know where that is - the outsourced IT market is currently worth around $750 billion dollars, with business process outsourcing being the second largest sub-segment. The BPO side of system integrators' business is growing fast and, for some companies, is twice as profitable as the larger traditional "turn the screw" segment of outsourced IT. Not only is this a large market, but it is still rather untouched by the advances in communications-enabled business process. The real question for carriers is "in this segment of the market, how can we extract our fair share of revenue?"
Q: So why is it so hard to extract value out of telco data? The ability to 'do the doing' has been around for a while.
A: I disagree that we've had the ability to do [comms-enabled business processes] for a while. To extract value, we need APIs that we can access the data, a mechanism that allows us to access that API outside of the carrier walls, technologies that make it relatively easy to create those applications in the enterprise and the mind to do it. I would argue we have three of four of these in place now, but we had none of them five years ago.
Q: Every operator (and their dog) is talking about opening APIs / SDKs for ISVs and developers like you. Would you ever work with just one? What would dictate who you and who you didn't work with?
A: Woof. That's a fantastic question. I've worked with many, and it typically happens that when I arrive on the scene the application, the customer and even the carrier is selected based on past decisions. About a year ago, I did some work with an API on one vendor's equipment after doing a project with a different vendor's API, causing the first vendor to send me a really nasty letter. It really caught me off guard. One overwhelming thought I had was "How can you really expect anybody to program mashups to just one API?", and the answer is "you can't." The consumer analogy would be: you can only call other people who use your carrier. I've touched everyone else's API since then, trying to leave goodness with each of them, but unfortunately not their's. So, even though I'm fine working on anyone's API, and fully expect to, I suppose some segments of the market have a different opinion on that. Today, most APIs have their pluses and minuses, and when I get to pick, I try to match them up right. For machine-side work, I encourage you to look at Jaduka. Got a web site? Check out IfByPhone. Adobe? Ribbit... and so on.
Q: Are the operators going to make it easy enough to stimulate innovation from developers?
A. I'll just say that I am soooooo amazed with Apple and how they pulled off the iPhone marketplace with the cooperation of AT&T. Simply amazing, and I suppose you need a superman like Steve Jobs to get that done. Now, that said, BT, Orange and Deustche Telekom are doing a great job at working with their developers as well, so it's possible, but I think it takes a lot more effort and a more structured approach to the market.
Q: How do you ensure the quality of the customer experience is maintained in open source API models?
A. In time, I think it will be evident that you can't ensure the quality of the customer experience without open source approaches. Would you really want to deal with technology that's not well tested and widely used?
Q: Enabling the APIs increases cost and needs investment. Operators have a more limited market but we can terminate a call in any market.
A. Perhaps, and if you're simply focusing on termination of calls, then you're right. My advice: start answering the larger issues of integration, smarter termination, etc.
Q: Individual operators are not global nor unique within an area. How does a web site select for example one Click-to-Call offering over another? While one operator may have better data than others it's still not omniscient. Does a web site want multiple Click-to-Call options?
A: Indeed, a web site can (and probably will) have many click-to-call options. The fact that one carrier may have better data might very well be enough that a web site designer will select one over the other. But without regard to that fact, it may also be that the site is provided by a large enterprise that is a strategic partner of the carrier and/or system integrator with a relationship with the carrier.
Q: How are the resulting privacy issues addressed?
A. That's actually quite simple, I think. iPhone customers show that they are willing to share their data as long as you ask and customers see some value to it. If you never ask, and there's never any value that the customer can see you deserve the problems you create. There's an amazing amount of value that can be provided if you simply ask for permission.
Q: Are Voice 2.0 apps predominantly driven out of a data or Web context rather than a voice context?
A: I say they are predominantly driven out of an applications context, and rarely out of a voice application context. The fact that they are delivered by one mechanism or another seems to be un-correlated.
Q: There are ways to answer the question 'is my customer at home?' e.g. using Wi-Fi or femtocells or GPS. But we lack APIs both on the network and on the devices. There also needs to be an alert mechanism for 'tell me when my customer gets home'.
A: Yes, there are ways of answering that, but no standard way for developers to access it, and no standard business approach to monetize it. We need that.<//em>
Q: How do you change the culture for making the business case?
A: Successful stories. See VoiceSage for details. I do.
Q: What should telcos do next?
1.) Educate Enterprise CIOs that telco API platforms offer a much cheaper alternative to upgrading Avaya hardware. 2.) Form partnerships with enterprise software toolset companies
3.) Educate SI's on the opportunities for new recurring revenue streams from re-selling telco API platforms.
4.) Put proper commercial structure and market focus behind the telco API business development.