Om Malik writes about Ribbit, which appears to be creating essentially a carrier-grade IP-PBX (Om uses the term "Class 5 softswitch") that a software-as-a-service (SaaS) company like Salesforce can bolt onto its application to add communications to the service. It's a compelling idea, but ultimately I don't think it'll work for enterprises. Either that or it'll kill enterprise-based telephony altogether. More after the jump:
Om Malik writes about Ribbit, which appears to be creating essentially a carrier-grade IP-PBX (Om uses the term "Class 5 softswitch") that a software-as-a-service (SaaS) company like Salesforce can bolt onto its application to add communications to the service. It's a compelling idea, but ultimately I don't think it'll work for enterprises. Either that or it'll kill enterprise-based telephony altogether. More after the jump:For one thing, I'm hard-pressed to see what advantage Ribbit has over existing carrier-grade softswitches like BroadSoft or Sylantro; in fact, BroadSoft announced an integration with Salesforce.com not too long ago.
One difference appears to be business models; Salesforce's Ribbit integration seems to be exposed directly to the end user, where the Broadsoft/Salesforce "mashup" appears to be positioned as something a service provider could resell to the end user company. This latter model could be bad (layers of integration) or good (integration of layers).
Regardless of whether it's Ribbit- or Broadsoft-powered; sold directly through the ASP/SaaS portal or through a service provider channel--is this a good idea?
It's a division-of-labor, or division-of-resources issue. Do you want to own your telephony capability or outsource it?
Let's say you want to outsource it. If my enterprise goes that route, because some Ribbit-based application on Salesforce delivers exactly what my sales teams need, what do I do about all the rest of my employees? Figure out which application they use most, and find an ASP--sorry, SaaS provider--that can give them that app plus their voice communications?
If the answer is, I keep communications in-house for those employees, does it make sense for me not to spread out the cost of a heavy-duty, performance-critical function (not application) like voice among as many users as possible? And then I customize those capabilities for exactly what my users need?
So the question becomes, for my most business-critical communications functions, are enough of the users best served by a communications platform that lives outside my IT department--whether it's Ribbit/Salesforce, or the wireless network(s) that my road warriors spend most of their time on? If the bulk of my users are the best served by platforms outside my enterprise, then it'll make sense for me to either outsource the remaining plain-vanilla communications to a service provider, or buy a drastically scaled-down IP-PBX/UC platform for my in-house users.
In any case, that wouldn't bode well for the current crop of IP-PBX/UC vendors.
The question is, can Ribbit pull it off? BroadSoft and Sylantro have been at this a long time. The history of public-network VOIP is that everybody underestimates how hard it is to do right, at scale.
In the meantime, IP-PBXs from Siemens and ShoreTel, among others, already integrate with Salesforce.com. So if you want to give your sales teams the ability to use Salesforce.com integrated with voice, you can do that, and do it within the policy and configuration boundaries of your enterprise.
So maybe Ribbit can make it on the SMB market, but I don't see this as an enterprise play.
