Results tagged “APIs” from Emerging Communications Blog
Last Tuesday I had the pleasure of interviewing Irv Shapiro via Skype.
2009-01-13-irv-shapiro-96.mp3The run time is 40 minutes.
Additionally the full transcript is below. To distinguish between us I've indented Irv.(You may also be interested in the video of Irv speaking last March on the topic of Phone Mashups)
How are you?
Things are going well here at IfByPhone. We live in crazy times, but given those crazy times, we're just very lucky. We're lucky because we provide something that, fairly often, saves our customers money. It's a terrible thing to say but having a depressed economy might actually help us grow faster.
That's quite interesting you say that because yesterday I was talking to a company who expected their worse month ever, in December, and actually it was the best month that they've ever had. I'm wondering if the things that they do is to use communications to save companies money, you may not be the only one there? [profiting due to the downturn]
I think those organizations that can focus on how their solution can save money will do very well in this economy. The side effect, which is really a shame, is that no one really wants to be in the business of replacing people with technology.
Well, that depends on your personality, of course. Some people may enjoy that. [humor]
[Laughs] Maybe that's the stereotype of Americans, but [Laughs] yeah, hopefully though, what we do is we allow people that are doing rather mundane tasks to do more interesting things.
A very good example is we have customers that are just mid-sized companies but they're using call centers. They were routing a hundred percent of their traffic directly to the call center. Instead, they used our platform to deploy an IVR solution that prescreens the calls. There is some percent, twenty or twenty-five percent of their calls, that really never need to go to a person, and the end result is that their customers are delighted because they wait in line less time.
Because the IVR has the ability to handle many more ports or simultaneous calls than their particular center purchase. So, their customers wait in line less time and for simple questions, dependent on the business, but it could be "Give me the status of my order". It could be "When is my order going to be delivered?" It could be "What are your hours of operation?" An IVR can handle that very, very well with very little customer frustration and save them a lot of money. Because using a platform such as ours costs them three to five bucks an hour. A call center is twenty to thirty dollars an hour. That seems to be a nice space...
Can I give you some skepticism, though?
Mhmm, sure.
That actually, twenty percent of the calls may not be going to the call center just because as soon as somebody got the IVR tree, they decided to hang up.
No, because we track every call, they know exactly what happened to every call and whether they got to the end point and the IVR delivered the information they want.
Yeah, I don't think you get the average person getting too excited about IVR trees when they call. Certainly, I deplore it when I get an IVR tree.
Well, once again, the key to success in any technology is to keep it as simple as possible. If somebody deploys an IVR tree that is more than one to three questions deep, they're probably going to have a problem. Understand, people want answers quickly and if you can give them answers quickly, you're generally going to be successful.
Okay, so can I jump in here, kind of with a pretty standard question I've had the last couple of times; that is IfByPhone are sponsoring one of the a.m. breaks. If it were not for sponsors, the event just wouldn't be possible because the extortionate costs of the venue. Can I ask then, why IfByPhone has provided such sponsorship?
Because we're selfish, Lee.
Fantastic!
At the last eComm, that was the first telco industry event that IfByPhone had participated in. It successfully introduced our organization to the telco industry and was very, very successful at creating awareness for our company. So, from a business perspective, partnering with eComm is just a good business decision, so it was a very selfish decision on our part.
I'm pleased to hear it and I hope I get more selfish decisions, every year.
[Laughs] Okay
So lately, you've been buzzed about "cloud telephony", and excuse my ignorance, but what I'd like to do is firstly get a feel for what you're meaning by cloud telephony, in the first place. Can you please tell me what you mean?
Sure, what we're doing is we're stealing or borrowing a nomenclature from the general computing world. In the general computing world, cloud computing is a current buzzword that's used to imply that you take a computing resource that traditionally was in-house at an organization, you put it in a shared data center that is accessible from the Internet, and you share that resource across tens, hundreds, or thousands of organizations. By sharing that resource across all those organizations, you can invest more heavily in that resource. You can provide small and mid-sized businesses with a richer computing environment than they could afford on their own.
Cloud computing, in fact, is very, very old and it's really an issue of fashion. Back when I started in the computer industry, we used to call this "time sharing" and when the early mainframes were very expensive, you used to buy time on a time sharing environment. Computers became less expensive and companies brought those computers in-house.
The cost of running in-house computing, however, began to become very expensive, not because of the hardware or necessarily the software, but because of the personnel cost and the maintenance and support costs. People started moving that out to the Internet and called that cloud computing.
So Lee, "cloud telephony" is the exact same story. Historically, telephony has always been in the cloud because we have a shared, central facility-based system. That's what the traditional telcos are often referred to, where there is shared switching equipment that is used to connect all of our telephone calls together.
Then, in fact, starting very late 1960's, 1970's, and 1980's, a very popular alternative - I know here in the States, I believe in Great Britain, and potentially in Europe also, was something called Centrex. In Centrex, you had basically a hosted PBX. You had a PBX at the central switching office that was shared by many companies and partitioned so each company looked like they had their own PBX. In essence, cloud telephony or the idea of putting telephone resources in a shared facility, accessible by many people, in order to provide richer capabilities to everyone, is a very old concept in the telco industry.
Okay, so you're putting something that is to be shared within a certain location. How is this resource - in fact, let's keep it elementary still. Can you give some example of resources that you're referring to, because in cloud computing we're meaning two things. We're meaning storage and processing. It's fairly simple. In cloud telephony, what resources are you meaning?
Okay, so in the telephony world, historically the world is really divided into two domains. There is the domain of transport, the people that are moving the call about. Historically, as we're all aware, those were the people that owned the wires on the poles and the wires underground or the wires across the ocean. Then, there were applications, but in telco, we didn't historically call them applications, necessarily. They were things like switches, PBX's that you bought and put in your business and that roam switch or that Northern Telecom switch, in addition to providing potentially basic switching of calls, also allowed your business to have voice mail features, to have maybe in IVR (Interactive Voice Response) capability, to have a variety of ways to integrate computer integrated telephony with computer systems, do screen pops; those were applications.
The world of telco is really divided into transport and applications. Transport costs, for everyone's good, except for maybe the facility-based carriers, transport costs are falling very, very rapidly. In fact, you and I are using, in essence, free transport right now, on Skype, and potentially a paid service to record it. That paid service is an application.
What we've done is we've taken a very rich suite of telephone applications and we've put those in a shared facility in the cloud, meaning that those applications are available to anyone, and can be provisioned and controlled by anyone who has access to that cloud. The access is over secure links over the Internet, HTTPS. Those applications include very basic things like voicemail or click-to-call, slightly more sophisticated things like "find me" and "follow me" technologies, a little bit more sophisticated things like recording, and go all the way through to very sophisticated applications that allow you to do interactive voice response and to build those interactive voice response dialogs from any web browser. We take applications and we put them in the cloud.
Okay, to me this just sounds like normal Internet stuff, as in there are plenty of people who offer API's for speech detects, and so on. I can call many services, via an API, just like Salesforce.com style, so what I don't understand is why you're calling it cloud telephony when in fact, today, I can access many providers via and API, for many different capabilities our resources. Is there some difference or are you just rebranding, or what is the case?
I think there is a fundamental difference. The fundamental difference is we provide two sets of capabilities. We provide pre-built applications that work with any telephone. While they're in the same ecosystem in the Internet, so to speak, as Salesforce.com, they do very different things. They interface with the end user or the customer over a telephone, which is a very different modality of integration.
Number two, we provide any developer who has basic web development skills with the ability, from a programming environment of their choice, PHP, Java, C#, ASP, etc.; we provide them the ability to initiate a call, to monitor a call, and to receive post-call results.
We allow them to do call control from the web environment. The ability to do call control, and as part of that call control, to route that call to an IVR environment with TTS, with ASR, with recorded audio, with DTMF decoding, and as part of that environment, to use pre-built building blocks that do significant things. We think this takes the world of hosted telephony into a slightly different domain and makes it very much like the Salesforce.com of telephony.
I would like to know some example building blocks, if that's okay.
Sure, absolutely, an example building block is a "find me". As an example, you can use an API call - let's take it a different way. You can provision; you can go to our website, you can provision a local or toll-free number. You can say that that local or toll-free number, as soon as a call comes in, does a call back to a web application. That web application can look at the caller ID of the call coming in and can decide how it wants to route that call. This is happening in real time. A call comes in; we do a call to your web server. It could be on your desk, it could be in a data center. We tell you a call came in, this caller ID, this ANI, and you tell us what you want to do next.
You send us a little snippet of XML back that says, "For this particular call, I want to route it to a "find me". The "find me" has all of the intelligence to do a pre-call screen to ask the caller for their name or whatever information you want, and then to begin doing parallel rings to "n" number of telephones in order to find the recipient. That list of "n" number of telephones can either be provided on an API call, or can be provisioned from a web interface.
All of the intelligence to do the pre-screen, to do the parallel ringing, to handle what to do if nobody answers, to handle terminating the rings once somebody has answered, all of that capability is a pre-built building block or module that we make available. So, instead of having to build that from scratch, every time, that's a building block that many people would use over and over again.
So, you have a bunch of resources and people can build at that kind of granular level, sort of one-to-one with the resources, but they can also have what I might term "scripts" or what you're calling modules but are probably pre-written to interact with one or more resources. Is that correct or not correct?
That would be correct, but some of these modules are complete applications. As an example, one of these modules is a traditional store locator that will do reverse lookup telephone numbers, will find geo-coding data, will interact with the database. That's an example of an advanced module or building block that we make available.
Another one of these modules is that instead of sending these calls to a "find me", you can send the call to a call distributor. A call distributor will look at the number of calls that have been routed to different call centers or locations and based on some fairly sophisticated algorithms, load balancing and other things such as percentage of use and time of day, will distribute the calls - thirty percent to this center, forty percent to this center, thirty percent to this center.
These modules might be very simple things. Another module is voicemail. Anybody nowadays can basically provision voicemail on an Asterisk system, but making that module available in a richer environment to our customers, both from a website where they can provision it with no programming, or via a programmable interface, we're finding is a differentiating environment for us.
Okay, I love that because it overlaps with one of the major conference themes, which is telecoms is becoming software. To me, you are very clearly in that direction. I would like to know; I don't mean for you to list it now, but I had a quick look at IfByPhone.com website and I didn't see a list of resources available and a list of modules available. I mean, are you able to supply that? This is just purely out of my technical interest.
Yes, in fact, on the home page, if you go down the front of the homepage or if you click on the navigation on the left side, each one of those is a separate module that is available. What actually happens when you have an account on the system, and you go to provision a telephone number, depending on what stage of provisioning you're at, you get a pull-down that just tells you what the different modules are.
Finally, we can send you - we actually just had it rewritten; we have a new version coming out shortly, the API Guide that lists every module that's available, depending on the stage or state of the call. So, some things are available to get routed to. Some things are available right off a ring. Some things are available for out dial.
What's interesting about what we do, Lee, is every one of our modules, so to speak, are available from either a click on a website, meaning effectively we call that environment "preconfigure an API and make it an easy click-to-call", via the API, via a ring coming in - in other words, you provision a telephone number, or an outgoing call. You provision a scheduled call or you initiate a call with an API. We make these software building blocks available for a click, a ring, or a dial, which is an interesting environment for our customers.
I'm going to have to throw in a really awkward question but I know you can take it. Where do you feel the most value is? I don't mean in terms of hey, what you're selling, but where do you feel - on quite a personal level, where do you feel you have invested most of your time and energy? What has been the challenging area? Where do you feel you sacrificed some of your life to build something? Where is IPR, where was the challenge?
The challenge is something that no one ever sees. I spent eighteen months, personally coding a third of it, working with a team of developers to build a dynamic VoiceXML CCXML generator. The guts behind everything we do - we have an ability to put a bunch of parameters in a SQL database. Those parameters get into that SQL database. Those controls get into the SQL database via a website or an API call. Then, when a call is processed, we dynamically generate thousands of lines in some case of VoiceXML CCXML because the actual processing of the call, in particular when there is what we call "smart call" or intelligence in the call, is handled by VoiceXML CCXML and it's as close to industry standard as you can get. Unfortunately, as with any standard, as you're well aware, there is a lot of wiggle room and in particular on the CCXML side, today.
We have the ability to process our calls in a very flexible way. That's the IP that underlines everything that IfByPhone does. That's why we're able to extremely rapidly produce an additional building block or enhance a module because the market says we need an enhancement. What we're doing is we enhance it in one place; we enhance the generator to be able to handle another set of conditions and then it's available to everyone using our platform.
From a computer sciences point of view, the ability to do a dynamic code generator was a very interesting activity for me.
I can't help but to want to hone in on this. I don't know how interested others will be, but I want to know more about this dynamic code generator and what's advantageous about it.
Well, what's advantageous about it is we can take advantage of the very latest carrier grade technologies for dial-up processing because we rely on industry standard VoiceXML CCXML. The challenge is that the VoiceXML CCXML environment is viewed by some as somewhat complex and therefore, our typical customer is not likely to build an IVR from scratch in VoiceXML CCXML. If you're United Airlines, you are, or you'll hire a consulting firm to build you and IVR for a gazillion dollars. It's very finely crafted.
But, if you're a mid-sized company, you can't afford that.
So, what are the inputs people are giving to this code generator?
As an example, when they craft an IVR, they choose from about fifteen different types of prompt responses. They literally go to a website and they say, "The next prompt response is 'I want to ask'," and they either use recorded audio or TTS, "I want to ask for your order number, and then in response I want to receive back a ten-digit number and I want to give the user the ability to say that or to use DTMF. If the ASR doesn't recognize it, I want to re-prompt and recommend they use DTMF..." That's all done by pointing and clicking on a website.
Okay, so you're getting to put this pretty paint above the call control and the VoiceXML.
That is exactly right. The same thing would occur for something more mundane, like a "find me". Using this pretty paint, they're listing a series of telephone numbers and they're determining how long they want to try each number for, whether they want to try them serially or in parallel; when they connect, whether they want to record the call; if they're recording the call, if they want to constrain the length of the recording. This is all done by filling in a form on a website.
What that means is the guy in your marketing department at your company can now create a telephone interaction because it's no more complex than what they do to set up AdWords in Google. They can integrate telephony into parts of the businesses without involving telco or IT resources that a small company may or may not have.
Okay, so I have to be awkward to you again. I'm sorry because it's just your morning and maybe you've not had enough coffee today for a Lee hassle [laughs]. You know what I'm like. You know I like to get to the bottom of things. I think to myself, "Surely, there must be lots of people offering paint to draw with in order to generate call control and VoiceXML".
And ninety percent of them have designed what they built for computer geeks. So, let's say they built a Java app and it's point and click and drag and it uses terminology like "barging" and "sensitivity" and "multi-modal controls"; my customer would never understand what you're talking about.
My customer is either a business professional or a web developer. With all due respect to web developers, most of them are not highly sophisticated coders. They work in a scripting environment and they're really good at what they do. But, they're used to fairly simply scripting environments. Therefore, we built an environment for them that doesn't require that they understand the underlying architecture at all.
Our user interfaces are application oriented, in other words, they require the specification of the building block, not VoiceXML CCXML oriented. There is some really nice VoiceXML CCXML, point-and-click, gooey code generator environments designed for enterprises, for very large corporations, and they're designed to be used by programmers. They just look completely different.
So what are you doing to get developers onboard? It doesn't sound like you have a developer program; rather, you seem to be going company by company. Is that correct?
No, we have over three hundred developers and resellers already building applications and reselling our technology.
So, you are reaching out to web developers.
We're reaching out to web developers, very often, that are part of marketing firms and advertising agencies. They work in-house for a ten-million dollar business. They're the guy or the gal that built the website. Or, they're web developers that built a CRM application for the plumbing industry; they know plumbing inside out and they know development well enough to build a CRM for them. Now, they're adding computer integrated telephony to that CRM by using our hosted services. Or, we have a web developer that built a scheduling application for beauty salons, hair salons. This developer has five hundred customers. Now, they're adding automatic reminder calls to that application.
This is wonderful. I love that, I mean, that's just fantastic, these little vertical niches where each application developer knows that sub-domain well.
Right, and these application developers tend not to be computer scientists and they're not telco professionals. If you ask them for the difference between a trunk and a line, they're going to get confused. They just want to build their little applications and some of them are running very successful businesses, by the way, extremely successful businesses. We give them the ability to add telco into that equation, as if it's another web component.
So, this sounds to me, the general speak of it, as if it overlaps with Ribbit. I don't know if you care to distinguish yourself there, with Ribbit who were bought by British Telecom earlier this year.
Sure, Ribbit is a fantastic company. I've immense respect for the folks there. They've chosen a particular path. The particular path included a close relationship with Adobe and a tool set that is designed to be used from Flex. Our developers have never heard of Flex. If you're selling to enterprise, that's a wonderful strategy and they [Ribbit] will be very, very successful with it.
In our environment, we need to pick the least common denominator. The least common denominator is that everyone in the web world knows what a URL is. In essence, the way in the web world that you build web service calls that are URL-like, is you use something that the industry has classified as REST. What it basically comes down to is if you know how to make a request to a URL, with a set of parameters, and receive back a little snippet of XML, then you can do a REST service call.
So, you used REST instead of SOAP, for example. Why?
Because our marketplace doesn't need the sophistication and complications. In fact, the industry, if you look at Google, they started with SOAP, and now they've moved to REST for most of their newer web service calls. The reason is the average web developer gets REST. For the average web developer, SOAP is a little more than they need.
In fact, SOAP is very well designed where you have a directory of resources and you want an API that lets you walk that directory and select a resource. Our developers are doing very simple things. They're initiating the call. They're monitoring a call. They're receiving the CDR from a call. They know exactly what API they want to call. They know exactly what method they want to invoke. There is no need to have all the overhead of directory services and those types of things. What we need is a secure, reliable, easy to use API.
Okay, if it's complex we won't go into this, but give me some idea of the kind of cost model you're working with developers. I'm quite interested in the openness that you're giving this. In fact, you're giving me interest in what you're doing. Just generally, what's the cost model?
It's free. You can sign up at PhoneMashup.com for a developer account. You have full access to the API and a hundred minutes of telephone time, per month, to play with it as much as you want. It's free. If you go over a hundred minutes a month, in a developer account, I believe it's 8 cents a minute. Once you're ready to fully deploy with customers, there are other subscription plans that go as low as three and a half cents 3.5 cents a minute.
What you're getting for those 3.5 to 8 cents a minute is not only transport but more importantly, you're leasing or renting application server environments. You're renting our platform. In the Phone Mashup account that's free, you have access to all of the building blocks I mentioned. In a full account, a platinum account, which is forty dollars a month, you get access to the production environment of all of the building blocks. There is no "pick this, pick that; there's another charge". You get them all.
That's quite interesting. Now, I'll double check in case you're not, but are you aware that we're doing tutorials at 7:30 p.m. on the nights of this conference?
You know, I wasn't Lee.
Okay, so Ribbit is running a tutorial, Voxeo is running one. Obviously, I'm left thinking why you guys are not running a one-hour tutorial at eComm.
That's something we should probably pursue.
Okay, we'll take it up after the call. I've just got one final question on the topic we're covering at the moment. Obviously, I'm dealing with a lot of companies who offer telecom services in a software fashion. What concerns me, and it could be my telco background, I'm not sure, I wonder about the quality. What kind of quality guarantees are in there. For me, the call I'm processing with a customer could have a lot of value and I don't really care if it's 8 cents a minute or 80 cents a minute. Could you tell me how you ensure quality, that things don't fall over, that you have call drops, that a call doesn't work, or that a resource is unavailable?
The first thing we do is our server infrastructure is not posted in the basement of our offices. It's hosted at Equinix Data Centers, our next door neighbors in the data center is AT&T. We're in one cage; AT&T is in the next cage. We're peered with top-tier providers such as Level 3, using QoS, all the way from our servers to the end point, or as close as they'll guarantee. We only use G.711 Codecs because we're selling to businesses and we're not willing to sacrifice quality for additional compression. All of our resources are either N+1 or N+2+ in some cases. As an example, the backend databases that sit behind the code generator are actually fully redundant servers that are then mirrored with fully redundant servers. We have to lose a lot of infrastructure for the IVR generation to stop running.
The challenge for us and everyone else in the industry is our peering partners will not give us the level of service that was historically available in telco. As an example, Level 3 will only give us a 99% service level agreement. They won't go above 99%, and in some cases 99.9%. They won't go above three 9s.
The way we have to work around that issue is we have to peer with a range of providers in order to ensure that if any single point fails we can still handle your call. Probably the best testament to that, I'll share one other thing that just went live on our website. There will be a series of press releases. One of the spaces that we have a lot of customers in are the voice broadcast space. The reason is that when we do voice broadcast, it's not a voice blast where it blasts out a message and somebody picks up the phone and blasts out a message. We can deliver interactive dialogs, such as, "Mrs. Smith, your couch is scheduled to be delivered at 10:00 today; will you be home? Please say yes or no". If you don't say yes, we transfer you to a call center and reschedule your appointment.
For those calls, our competitors that do just blast out calls basically have no guarantees. People look at their actual results and they find that it was scheduled to go out at 9:00 and it went out at noon or at 15:00 in the afternoon. We are releasing, effective now; we went live just two days ago, a hundred percent delivery guarantee. If we don't deliver your call within five minutes of the scheduled time, it's free. We're very serious about quality.
In that string of conversation, you happened to mention Google Analytics. Now, that reminds me, sorry for not having paid enough attention, but I heard the name Irv Shapiro with Google Analytics. We're told that somehow, and again, excuse me for not knowing, that you had linked up it up in a telephony fashion. I don't know about this, but I know a lot of people were saying what you did was cool. So, could you tell me what it was you were doing with Google Analytics that people liked so much?
We did something very simple. When you go and provision a telephone number, using our web interface, you can specify in your Google Analytic account ID. Every call that comes into that number will get logged to Google Analytics as if it's a page view. The page will be the name you give it. It can be "My Main Telephone Number".
That allows you, if you're in the marketing and advertising space, and you're running a campaign, and you want to monitor web traffic, but you're also running radio commercials, television commercials, or print ads with telephone numbers, you can also monitor all of your traffic that's coming in those phone lines, simultaneously with your web traffic. You get a complete picture of your campaign.
Hey, that sounds pretty neat. Can you get a demo of that somewhere?
I'm trying to think if it's available on phone mashup accounts. I'd have to check to see if it's available on the completely free phone mashup account. Surely, I'd be happy to do a glance session, like a WebEx session with you, and show you an account that has it activated.
Okay, as far as I understand, you're not a fan of telephone API's?
I'm a fan of API's being a piece of the equation. I think it's a very important piece. An analogy would be, Lee, that Salesforce.com did not release a cloud-computing environment with an API as their first product, and say to people, "Come build something". Instead, they released an application that delivered value to thousands of businesses, and then they released an API to interface with that application. Then, they took it a step further and said, "You also can use our platform".
We've taken the exact same path. We first released a series of very basic applications, click-to-call, virtual voicemail, etc. We then began to release an API for interfacing with those building block or components. Now, if you look at our suite of services, it goes from API's that let you do basic call provisioning, never touching one of our building blocks, or more importantly, because the building blocks or modules exist, you can very quickly deliver to a customer or to a business real business value. If we were in just the API business, you have to write an awful lot of code to deliver value.
Okay, I understand. So, how do you think that cloud telephony, as you've called it, will affect the facilities-based carriers? That's my final question for you.
I think the traditional telco providers, and in fact the newer telco providers, let's say the cable companies, are all in a very interesting position. They're all scurrying to deliver transport. Transport pricing is declining so they're very often all in price battles on who can deliver transport least expensively to a given end point. I believe that cloud telephony application environments such as ours provide these traditional telcos and the newer telcos such as cable companies with an opportunity to deliver suites of services to businesses that are more than transport. By delivering more than transport, it will give them an opportunity to price in a way that's better for their business, to effectively have a form of premium pricing.
What makes it interesting is that a traditional telco can do an experiment or a trial, with IfByPhone as an example, very easily, because we're in the same VoIP/SIP mesh environment as everyone else. No differently than our peering relationship, which are used to deliver calls, a traditional telco could peer with us, could choose to route certain calls to us. We process the IVR, we do the intelligent "find me", and we do the intelligent voicemail. At the completion of the call, if there is a transfer or other event, we can route back to their environment and it makes it a very easy integration because of the VoIP/SIP world.
Anyway, I know you said you could only spare fifty minutes with us, and we're just coming up to that, so I'm going to thank you for your time. Thank you again for the IfByPhone sponsorship of eComm 2009. Listen, I hope you have a fantastic day, you drink lots of coffee, and you're super productive.
[Laughs] Thanks so much, Lee, and have a good evening. I appreciate the opportunity.
