>> TelXL's technology demonstrations
A demonstration of web-telephony integration
Try it for yourself now:
|
Call 0800 088 7723 to try this demo now!
See your order on the left while you call!
You can call at any time; It's entirely automated.
If you want to know more, scroll down to read about the service.
|
The design of this service:
Start of call: 
Welcome message
Option 0: Thankyou - your order total is (x)...
Prompt complete: ...pounds
Prompt complete: Get delivery details (Audrey)
Prompt complete: 
Get the delivery address
Complete: 
See if CLI was withheld
Option 1: 
Send SMS
Complete: Thank you and goodbye
Prompt complete: 
Hang up
Option 2: 
Goto the collect number node
True: Collect number
Complete: Goto SMS and end
Invalid entry: Try again
Option 1: How many basic pizzas?
Option 0: Goto order completion
Option 1: Goto Main Menu
Invalid entry: Hang up
Option 2: How many veggie pizzas?
Complete: Goto ask if they want more
Invalid entry: Hang up
Option 3: How many meat pizzas?
Complete: Goto ask if they want more
Option 4: How many hot pizzas?
Complete: Goto ask if they want more
What this demonstration shows
This demo gives an example of how you can configure a telephony service on our web site that combines traditional IVR (messages and menus) with database storage of a customers order, and how our telephony systems communicate with our web site in real-time.
The diagram shown above is the sort of thing you can see and edit on our web site when building up your own telephony service. Of course, when editing on the web site you get to see lots more detail about what each "node" does and how it can be configured. However, the general idea of building up a service that starts with a welcoming message, then a menu (which in this case is literally a menu, offering pizzas) and so on should be apparent. There are quite a few GOTO nodes in this configuration, so you'll see it jump around a bit. This reduces the number of nodes required and avoids the problems of duplication.
When you phone the service, you will hear that much of it is a computer generated voice. Of course, the final result of these services go on to use professional presenter's voices, but we left the temporary ones in to show how we offer computer generated speech for "rapid prototyping", which is a jargon term for trying out various ideas quickly and easily before coming up with the final design.
There are loads of other features used within this demo, but it only really counts for anything if it gives you ideas for things you can really make use of. If you want to know more about the details of a particular feature, just get in touch and ask.
How this demo came about
There's a bit of a story behind this particular demonstration, which might tell you something about the opportunities our system offers.
Back in the summer of 2007, I (the technical writer and Telephony Services Architect) added some new data handling functionality to our bespoke IVR configuration system, allowing it to add and multiply values it had previously stored or collected from the caller. I wanted to make sure that my colleagues all understood the potential that this functionality could offer and so set a challenge to a group of them:
Using bespoke IVR and the new "SET node" in particular, design a telephony service that allows the caller to choose pizzas from a menu, specify how many they want and be told the total price.
The challenge was taken up by two programmers, our systems administrator and our network engineer. I was bombarded with questions about the "rules" and on that Friday afternoon, I presented the award for the winning entry. It wasn't easy to judge.
All four of the configurations used the computer generated speech (none had recorded their own voice messages for it), but had used very different ways to achieve the same result, to the degree that each learnt new ways of configuring IVR solutions from the other:
The network engineer had concentrated on making the IVR smooth and seamless, making for a very easy to follow process as you go through the menus. His configuration sounded great, although because of all of the extra time invested in this, it was incomplete.
The junior programmer built a service which communicated by means of an HTTP request to a third party web site which kept a database of who had called before and what they had ordered. Thus, when you called a second time, it asked you if you wanted the same thing again. This was an amazing bit of third party integration (all done using our web site IVR configuration tools). Sadly, the IVR quality, which our network guy did so well, wasn't very good and the service was confusing in places.
The lead programmer remembered some work he had done a few years back and a "node" called "buy a single product". While this node was available in the standard toolbox available to everyone, others had passed over it. This was their loss, as it contained a ready-to-use set of options for storing the relevant details for buying one or multiple items. With this advantage, he was able to very rapidly develop the core of the service and then do the sort of fine-tuning that makes a service really work well. He added a credit card processing payment facility and something to collect and record the delivery address. This was the winning entry.
Our systems administrator built a less fancy service, which was based on the specification given. Without the background in credit card processing, third party integration using HTTP requests and so on, he built a well presented service that did exactly what was asked. So, while he didn't win, it's his service that you can see at the top of this page (with a bit added on that collects delivery details).
Who'd have thought there were so many ways to program something to take a pizza order? The managing director didn't take part, but pointed at "one he built earlier" that not only took the details and the payment, but also looked up your postcode and forwarded the request to your nearest pizza place. That's pretty clever, and that's the sort of stuff that we love doing.