As communications API provider Twilio gathers developers in San Francisco this week for its two-day Signal conference, we find it at an interesting juncture. The company is at once building up an API portfolio and strategy catering to the enterprise developer while contending with the decision of a premier enterprise account, Uber, to scale back its use of Twilio APIs.
Uber, an oft-cited Twilio customer, has been the poster child for large-scale use of communications APIs. However, earlier this month in an earnings call, Twilio CEO Jeff Lawson disclosed that Uber would be reducing its use of Twilio APIs over the next year. I asked this week's No Jitter On Air podcast guest, Mark Winther, head of the IDC's global telecom consulting practice and one of No Jitter's go-to experts on comms APIs, for his insight on Uber's decision -- both the implications for Twilio in particular and CPaaS providers in general.
Uber is on target to spend about $60 million with Twilio in 2017, Winther said. At that kind of volume, analyzing its spending on communications APIs and assessing options was the smart business decision for Uber. It's not moving away from the build model -- and, in fact, will still be spending a large amount with Twilio -- but Uber determined that it needed to take "a more aggressive multisourcing approach," Winther said. That, in turn, has meant that Uber has had to invest internally to make sure its developer engineering team has expertise in communications, including messaging and voice, so it could understand its options.
"They didn't need as many people when they were just working with Twilio. Now they need more engineers to analyze what are all their other vendor API options in all the parts of the world that they're in. Evaluating those options is a complex challenge because they've got to look at performance levels, they've got to look at price, they've got to look at how easy is it to work with an API and embed it in their systems," Winther said.
In essence, Uber is now taking more of a do-it-yourself approach to communications APIs. "It's not a complete do-it-yourself -- they're not bringing messaging and voice communications platforms in house by any means, but they are bringing a bit more of the expertise in house in order to mix and match vendors by geography, by use case, etc.," Winther said.
This changes neither the value proposition of communications APIs nor Twilio, Winther said. But it does point out one of the vulnerabilities of Twilio and other CPaaS providers, he added. As he discussed in the podcast, the market right now is dominated by about 20 customers spending large amounts with various providers on communications APIs -- "and then there's an extremely long and skinny tail after that. ... What the Uber dynamic has shown is that it's really important to make that long tail fatter and build a mid-tier, and find more growth there.
Twilio seems to be addressing that market reality with its latest set of APIs, introduced just yesterday, as No Jitter associate editor Michelle Burbick covered in the post, "Twilio Takes Comms APIs to the Next Level." It is now offering a collection of APIs aimed at providing businesses with the workflow logic needed for enabling multichannel communications with customers.
This is a natural next step for Twilio as it "continues to push the edge on the developer experience" and move from basic building block APIs to combined, pre-packaged APIs that relate directly to user activity, Winther said. Twilio Proxy is one such example. This API lets developers build logic for routing, logging, policy enforcement, and so on into the communications between drivers and passengers and similar types of interaction relationships.
Additionally, Twilio today introduced Twilio Functions, an environment through which it will handle the Web infrastructure an enterprise would need to build and run communications applications using the Twilio platform. Absent the need to worry about sizing, setting up, and maintaining servers, developers can focus on their creative work, Twilio said.
Initiatives such as these may be just what the enterprise needs to accelerate use of communications APIs. As Winther noted, enterprises are beginning to understand what communications APIs can do, but often face internal situations in which developer resources may be limited or constrained -- i.e., unavailable for "playing around" on communications.
Follow Beth Schultz and No Jitter on Twitter!
@Beth_Schultz@nojitter
