The CEO/Customer Service director/Head of Marketing (delete as appropriate) just called. Apparently customers are complaining about the phone system, and he expects you to fix it. You give it a call, everything seems OK. You call him/her back: “All OK here, what’s wrong?”. Their response: customers are going to the wrong agents/not completing their payments/complaining on Twitter that it sounds like a robot etc. You’re tempted to remind them that it does exactly what they told you it should do… but fearing that might be a career-limiting move you decide there must be a better way. Is there? We think so. Here are a few tips we picked up through 12 years of fixing bad IVRs, building nice ones and making voice part of a multichannel experience.
You need a design, and you need to test it. Ideally before you start building it.
I used be an engineer. I also used to design IVR systems. I was rubbish. I put prompts in that said things like ‘Sorry, I didn’t catch that’, and got caught out with things that seemed right, like “Do you want Sales, or Service?” (not thinking about the people who interrupt with “Yes!”). Then I met some real designers and it all became clear. Engineers can’t design IVRs. In fact, very few people in the world are really good at it. So hire one of them (or a team of them) so you don’t get blamed when the system does exactly what it’s designed to do, but the design doesn’t work. Even great designers don’t get it right all the time, which is why early usability testing is essential too. Get the designs tested with real customers before you start coding. It’s possible with a technique called “Wizard of Oz” testing (where real customers who believe they are engaging with an automated system are in fact experiencing a human-driven system). This helps you understand what works and what doesn’t when it’s easy to make changes: before you start cutting code.
Understand the integration points and limitations
Before the designers go crazy and sell a vision to the business that just can’t be built (this side of 2017), figure out what integration points you already have. You may already have some integrations with your existing IVR, but look more widely too. The web team may have some nice RESTful web services that the smartphone app uses, or the new CRM system might have standard APIs (e.g. Sugar CRM, or Salesforce are good examples of this). The usual suspects are: Payment Gateway (for processing debit/credit cards), ACD (for querying queue lengths and providing automated call backs), CRM and billing systems (for account queries etc.), Provisioning and order tracking systems. Oh, and CTI. Please don’t forget CTI. You owe it to your customers not to make them repeat themselves (we all hate that).
On-premise or hosted
If your existing systems are more than a couple of years old, it’s worth considering whether they’re still in the right place. The “Cloud” is of course the big, annoying buzzword of the day (a couple of years ago it used to be called ‘hosted solutions’, but that wasn’t as marketable). But it is worth considering whether it’s really worth your while managing the infrastructure yourselves. We do this stuff for a living, and nowadays we prefer to use cloud services than build our own datacentres… the price point is going down all the time, and it’s one less thing to worry about. The information security folks can get a bit het-up about it, but it’s swings and roundabouts. With on-premise, you have less to worry about in terms of opening up routes into your network, but it’ll be much more expensive in terms of doing all the patching and scanning you need to keep it up to date for things like PCI compliance.
Do you want to write the code yourself?
Of course you do, right? You write code for a living (or at least, your team do). The good thing is that there are some pretty solid standards for IVR systems. VXML is the main one – which lets you create the structure of the dialogue, but there are others like SRGS (for writing grammars that tell the speech / DTMF recogniser what to listen for) and CCXML. The problem is that these are pretty low-level standards, and anyway, it only covers the call flow. There’s integration, reporting etc. to think about too. Suffice to say that building IVRs is a pretty specialist type of coding, and you need to think carefully before diving in and starting from scratch.
Everything’s gone multi-channel, or omni-channel, or X-channel, depending on who you speak to. Customers interact with your organisation online, on Facebook, via smartphone apps, Twitter… and of course, by phone. While the digital stuff gets a lot of attention, the voice channel is still really important. For many organisations it still accounts for a large proportion of their customer contact, and it’s often seen by customers as the place to go when they can’t get help anywhere else, so their patience is running out. That’s why it’s essential to look at IVR as part of a multichannel experience. What happens if a customer gets stuck while using your smartphone app? Are you going to make them hunt for the right number and go through an IVR, or will you join things up so they can just click a button in the app and get straight through to the right person, without having to repeat themselves? You might also want to nudge your customers in the other direction. You could send them a SMS that will help them get signed up for self-service online or via your smartphone app. Ultimately it will be up to the business and customer experience guys to decide what’s right for the customers, but be ready to connect IVR with your digital channels and vice-versa.
To build a great IVR - especially one that uses speech recognition - you don’t just need artists (to dream up a great customer experience) and engineers (to build it), you need scientists too. Speech scientists build the ‘grammars’ that tell the speech recogniser what to listen out for and then run experiments to figure out how to ‘tune’ the recogniser for best results. It’s a pretty specialist skill, so you may need to bring someone in to help with this. They’ll expect you to have a hard disk full of ‘utterances’ (recordings of real people speaking to the system) so make sure you turn on ‘utterance recording’ and keep the data safe!
Testing / test data
This bit is usually a nightmare. Write a test plan early, figure out what scenarios you need to cover and get started finding or setting up accounts so that you can test them. When it comes to testing, there’s a hard way (writing out a million test cases by hand) and an easier way (testing directly against your design and requirements). I highly recommend the easier way, but you still need to be really methodical and systematic and track what’s tested and what’s not.
Reporting / KPI / Biz case / investigation
So you’re live. Woohooo! How’s it performing? Ah… you did remember to log the right things and define the metrics that will tell you if the business case is being met, didn’t you? And if it’s not performing, you did put in more detailed logging and metrics so you can find out why, didn’t you? You did? Phew!
Monitoring the platform and your applications
Going live is the start of another process, now you need to ensure that your end users receive the service they expect. Proactive monitoring of your telephony, your infrastructure, your data connections and the status of your applications is required. Your support team will need to provide 24-hour coverage: monitoring; upgrading; patching; and issue management. When issues are raised, your 1st line support team will need to handle them effectively, liaising with the appropriate teams and partners to identify the cause, often discovering that the problem is nothing to do with the IVR or the platform itself, but is connected to that upgrade that is happening on your SAP system. Good, clear, timely communication with all affected parties is required. Linking all of this with your Reporting system means that you will have confidence that your applications are performing well, and visibility when things start to diverge from standard.