Turn your IVR into a CRM tool with SAS

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

more share options
Embed For WordPress.com

Without related presentations

Good afternoon. My name is Brian Coughlan, I am a consulting business analyst currently working for a major multinantional ISP ... That is, it was an ISP last time I checked. As with the entire indusrtry, the company I currently work for is in major transition, and its getting harder to seperate the telcos from the ISP’s frankly. These are challenging times, even for major players, and cost effective optimisation is fast becoming a must, as opposed to merely a nice to have. I will be talking today about using SAS to address some of those challenges, specifically how to automate call handling and routing in the operational call centre environment of a major organisation. That means lots of calls, lots of products and plenty of complexity. I expect that some of you may be familiar with the terms I’ll be using, but for those of you new to the field here are a few bits of call centre Jargon I’ll but trying, but likely failing to avoid. IVR – Stands for something, there seems to be a number of opinions as to what exactly, in my mind its synonomous with ”phone system”. CLI – Customer line idenification. It’s the number that pops up on the display when someone calls you. CED – Slightly more obscure stands for customer entered digits. Basically when a customer has no CLI they have to punch in the number themselves. 1 min

So, I'll be going through our whimsically titled ”JEDI” system, actually that is not an acronym, our department has a regretable critical mass of geeks and this is the kind of thing that happens. I have had a few trys at getting it to make some kind of acronym sense, but to no avail, so if any of you have suggestions, please let me know. If you are familiar with star wars holy writ, you’ll recall the skill of the JEDI, to make you do what they want you to do, or to make you forget want they want you to forget ... Here is a short clip to demonstrate. In this analogy I am Obi Wan Kenobi, the stormtroopers are the customers, and the Force is the IVR. That is what we do with our customers basically. They think they are in control ... But we are pulling the strings in the background. Anyway, I'll be going through the system outlining the SAS components of the JEDI process, basically the bit that does the really heavy lifting, in greater detail. I’ll be talking about the reasons we made the decisions we did, the outcomes of those decisions, and identifying the key resources you’ll need to set up something similar in your own organisations. 1 min

First of all why did did we get started down this road? Why did we essentially build and implement a fairly complex call routing system, instead of just, you know, buying one? Well, money is the simple answer. We had a limited budget to work within, and it didn't stretch to a major overhaul of the phone system. If you are at all familiar with Avaya or Aspect, you’ll know that every module comes with a price tag, running in some cases into hundreds of thousands of € and that was the situation here. Thus we were forced to work with the tools immediatly available too us, and fortunately one of those tools was SAS. In the context of the IVR, the organisation was dealing with the issues of choice, confusion and cost too much of all of the above. Too much choice, is frankly a bad thing, (In tour notes I’ve added a reference to a fascinating study on the subject) and too much choice in an IVR is an especially bad thing, but to run the gauntlet of choices only to be peppered with additional questions is a very bad thing indeed. And this was our situation at the outset of the project. A customer is calling to ask you questions, they don't want to endure a blizzard of irrelevant (or at least from their perspective irrelevant) pestering before they can get to the point. The scale of choices on offer in the organisations phone system was causing confusion not just among customers, but even among staff. In terms customers getting to the wrong place, articulating what the wanted quite poorly, or beign misunderstood and being transferred potentially to the wrong place, yet again. The bottom line? It was costing money, not enough money to buy a real phone system mind you, but enough to generate quite a bit of frustration and basically for everyone. A senior management had arrived at the conclusion that the IVR needed to be more efficient, streamlined and handle simple calls. However, all of this was to be acheived without the benefit of the kind of capital investment typical for call automation. So there we were. 1 min

When we launched the first iteration of our call routing system, it was much simpler. Or primary goal was merely to seperate BB & NB customers, and provided some very simple troubleshooting specific to the connectivity, before routing the call to staff members. At the time there was enormous confusion amongst customers about which was which. We were using SAS at the time for reporting and analysis, it was simple to draft up a job to produce a CSV file that split the customer base NB/BB. It was as simple as that. However, as the complexity of our product offerings increased, it became very important to differentiate the various types of offerings. For example when we began to market offers with a router, and the entire trouble shooting approach for routers was different and needed to be handled by a dedicated team with specific training, we needed to route those calls to the team without grilling the customer for information, either in the IVR or live. Because it didn’t work. Asking the customer ”do you have a router and a modem” or, ”do you have a router modem combo” or words to that affect, was not getting us the information we needed. Hence we split our simple feed further. In the intervening years of course this has become far more complex, as we now have cable, BT and a variety unbundeled services. As ISP’s vie furiously with each other for a dwindling share of a saturated market, one of the strategies is to try to push down costs by owning as much of the service as possible. But all of this is a bit of headache for customer facing teams, due to complexity. So you can imagine, or maybe you are living it, The routing has become absolutely vital for us to maximise and target our training efforts. The organisation has thousands and thousands of call representatives around the world, if they all had to trained on everything .... Well ... You get the picture and the saving. Note that this is before JEDI has handled a single call in the IVR, these substantial savings are based on routing alone. We next targeted the body of customers calling to ask about the status of their order, the status of their MAC code or to give us a MAC code. All of this was quickly automated, and suddenly a call that cost X (I’m not at liberty to give exact numbers here) was being handled for about 4% of cost X. Basically the difference between playing an automated, but a very speficially tailored message to a customer, or having that same customer spend 3 – 5 minutes exchanging pleasentries with a live representative. One of the most dramatic improvements we affected related to service faults. Despite efforts to reword and revamp our menus, simple technical problems relating to lets say ... installation, web surfing or browser configuration were constantly arriving into our dedicated faults team. Now the faults team should only talk to customers once the customer has been through extensive trouble shooting with first or lower level teams and a determination has been made that the issue is not local to the member, but a service fault on the physical adsl line, something in short that only the network provider, be they BT, NTL or whomever can deal with. At that point a formal fault was raised. By monitoring open faults, and integrating these into routing, we were able to reduce transfers into and out of the fault team by several hundred percent, a saving of hundreds of call minutes daily and in the context of some of our most highly trained and highly paid staff members. As the routing became more complex, we continued to draft adhoc SAS programs to meet requirements, we quickly realised that having solved the problem of getting customer information into the IVR, we needed to formalise the process to produce new routing before it ballooned out of control, both in terms of scale and efficiency. 3 mins

At this juncture we sat down and drafted a modular framework, which would allow easy expansion or scalability if you like, basically a plug and play framework for criteria and routing. We started off with about 3 tables, today we have 15. Every organisation has a plethora of conflicting and overlapping data, managed in a variety of formats, systems and locations. This organisation was no different. It can be very challenging to pull all (or merely most) of this information onto a single platform, and present it in a standardised coherent way. This is what the Organisation ”Data Cloud” represents. A hodge podge of disparate data sources, everything from formal DWH solutions, to the ”new staff” txt file uplodaded intermittently by ”Bob” in HR. From this cloud we extract, or have pushed to us all the data of interest. This is collated onto SAS, and I will go into that process in lots of detail shortly, its collated into SAS which produces the lookups which are pushed onto the SQL server. This in turn interactes with the phone system, passing appropriate routing intructions based on the customers details, and identified through their phone number. The customer either has their CLI picked up automatically, or they are requested to input it where no initial match is made. We this process we matchabout 92% of all callers, and a proportion of the not matched 8% arer simply not customers ... yet. This information is of course in constant flux based on callers, changes in the primary data sources and input from operations and similar frontline sources. Hence the centre section which represents the iterative flow of information between operational staff, knowledge base staff and the JEDI systems. It is easy to underestimate how important these relationships are, and in the early days we did, but if you don't have a clear idea of what your customers are calling about, you can hardly be expected to effectively handle those calls in the IVR. A regular sit down with operations and knowledge teams is heartily recommend if you want your automation to stay relevant. 2 mins

So let me begin to talk about SAS itself now that I’ve laid the groundwork. Several years prior to our jedi project, SAS had been chosen in the context of reporting and analysis, quite a different function really, for its ability to crunch large volumes of data very quickly, its analytical capacity and the powerful sandbox environment. The JEDI demand grew organically, as we realised SAS could produce basically anything we required in terms of slicing and dicing about customers. In addition, it became obvious we could the run the SAS component of JEDI on a surprisingly modest foundation ... just the bare bones. Base SAS, and a few modules to ensure data extraction options were not limited. Thats it. It is almost certain that if you are using SAS already, today, all of these modules are currently available to you. We used SAS for the call routing project, because we had SAS already and we hoped that SAS could deliver the combination of complex criteria definition and fast processing that we guessed we would need. We have not been disaappointed, and we have continued to use SAS, because it continues to deliver the goods. 3 tables, 5, 10, 15 each table representing increased flexibility and savings in the phone system, and SAS in the context of our current setup has plenty of horsepower left over for more expansion. 1 min

Naturally, on top of a foundation we need some building blocks and in the course of the last 5 or so years with SAS, I've have developed, acquired and yes stolen a range of macros to simplify and standardise operations. Thus all ODBC communications run through standardised macros for ease of password control and data repointing. Similarly for FTP. Sorts and loads are simplified and made more powerful and effective through macros Alerts through email and SMS are completely standardised. One need merely supply the address and the message. All of this functionality, and more besides is condensed and formalised to modular building blocks on our SAS system. For the JEDI system itself we similarly make heavy use of macros. Extractions and builds where similarlity exists are standardised as fully as possible. There are 15 lookups or junction points in the IVR as things currently stand. The population of these lookups, as well as the push out to the SQL servers is managed completely through macros. We also have a ”drop in routing” facility that allows the system to take any adhoc group of customers and populate the 15 routing tables with any set of customers and routing isntructions. 1.5 mins

Now we come on to the meat of what SAS contributes to this process. SAS has proven itself to be ideal as both a ”sandbox” and a DWH environment, often in the same environment and even with the same data. This is why we have chosen SAS as the solution to peform the bulk of the ETL for JEDI. The ETL processes’ encompass some 60 scheduled programs, 11 distinct data sources, hundreds of tables and tens of millions of rows of data. It is by orders of magnitude, the most complex and demanding part of the entire system. Despite this complexity, 90% of ETL completes between 01:00 – 05:00 each morning, ensuring the lookup tables are prepared and loaded well prior to 08:00 when the call centre opens. A series of mail alerts are triggered in the event of stoppages or errors. Given that we have succesfully insulated the bulk of the ETL process from the actual server which interacts with the phone system, data issues which do occur have a minimal impact on routing. At worst resulting in slightly out of date data for the duration of the outage. Issues with feeds or extractions typically last no longer than 48 hours. So lets work step by step throough this process Daily Updates - Extract All original sources are polled each day for new data, where this is present, scheduled extracts engage to pull all source data to the SAS Client. These typically run from 23:00 - 05:00. hours Number Integration and Reporting One of the most important issues we faced, was ensuring numbers were standardised, standardised and associated with customers, with duds or duplicates being stripped out based on a series of rules which I won't go into here. There are a range of obvious sources for numbers, but one source in particular bears mentioning. Overnight, SAS pulls all routing data accrued from the previous day from the relevant live server, generally several hundred thousand rows of data. This information is then mined for phone numbers not previously associated with a customer, but which we can now associate because of their inputs to the IVR. These numbers once identified are integrated into to the general body of associated numbers. Should the customer call from this number again, they will route based on CLI (the number passed automatically) rather then CED (the number the member has to input manually), eliminating yet another time consuming customer interaction step. Additionally, this information is of course used to produce reporting. Tracking such factors as match rates for the call routing, and handling rates for the self help sections. Informats and Formats We make extensive use of informats and formats providing ready and standardised access to information such as (read list). So instead of time consuming lookups or merges, we simply indentify critical information by supplying available keys to retreive the information in a single step. Obvious examples in our system would be account/phone_number and vice versa. Builds - Transform When new data arrives, overnight/intraday builds run to integrate the new data into customer profiles. The transform process integrates raw data, builds customer profile datasets and uses these to produce routing lookups. Load of Lookups - Load When the builds have completed, the finished lookups are loaded to the SQL Servers. A series of DTS jobs are triggered on the SQL Servers based on control files sent from SAS as the lookups are produced. There are 3 redundant SQL servers, only one of which is live at any given time. One of these servers is located on a different site for absolute redundancy. SAS determines which server is live and prioritises it, and then loads the backup machines as well. Intraday Updates - Extract A limited range of sources are polled every 30 minutes for new data, where this is present, scheduled extracts engage to pull all source data to the SAS Client. These typically run between 08:00 – 23:00. Specific examples of this are repeat callers, where we trap customers that have called several times in a 48 hour time frame, and route these to a more highly trained team with the explicit remit to ensure the call is resolved regardless of the time and effort. We also run faults, if you recall our discussion on that subject, as an intraday process to ensure new faults are in the system in near realtime, to ensure anxious customers get to the right teams as quickly as possible. 5 mins

So what does all this get us in the end? reduction in choice counter intuitively good in this context reduction in confusion which is always good in any context and of course the bottom line, a reduction in cost. Without a major revamp of the phone system or a massive capital outlay. Now of course, you can only handle fairly basic calls auomatically in the phone system. However, studies have shown (and I have referenced a few examples) that as much as 30% of all queries that come into call centres could be handled by automated systems, and possibly far more. We are just beginging to tap that potential, despite the very significant limitations of our current phone system, and SAS is pivotal to that effort. Bear in mind we have voice recognition, no capacity to directly translate text to human speech. We are talking about a very, very basic phone system indeed. Nonethless, our savings are over €1 Million annually, and if I can prise the relevant cash from the finance department, we can trampoline that result by introducing voice recognition systems. This is based on a careful review of genuine handling, and repeat caller rates as well as customer survey comparisons between the phone system and calls handled directly by staff. I’ve been wary throwing in everything and the kitchen sink into our savings claims, so this doesn’t even reflect all of reduction in transfer savings, or for that matter, the savings in training. This saving primarily relates to calls handled in the IVR, and a small number of high profile transfer savings like the faults routing that I mentioned earlier. 1 min

To keep the IVR routing updated and relevant, it is vital to fully integrate two groups into the process. The Telecoms team is absolutely critical to the smooth functioning and integration of the various parts of the system. The interface between the phone system and the SQL Servers being especially vital. If your inhouse telecoms team doesn’t know how to do this, then consultants from the relevant company should. Making the investment to guarantee this interface works as planned is critical, if you can’t talk in some detail to the phone system its a show stopper. Operations (those actually handling customer calls) need to be informed of all changes to the call routing system and the impact of those changes on their staff. Individual staff members need to have a rudimentary understanding of the kinds of issues the automated systems can handle. It is also vital that a regular review of the criteria, troubleshooting and contributing data sources be scheduled and resourced for, with regular overhauls taking place. Ideally the system should fall under the direct control of Operations, as it (the JEDI system) is in principle, merely another team or department tasked with call handling. The telecoms team should be relied on for technical assistance, as well as advice on how best to build the IVR. It is important that senior management in both Operations and Telecoms be engaged to ensure the deployment of the system is a success. Providing ready access to Telecoms, Operations and Knowledgebase expertise as required for ongoing maintenance and improvement. 2 mins

Favorites, Groups & Events

Turn your IVR into a CRM tool with SAS - Presentation Transcript

Automated Call Handling & Routing through SAS (with a bit of SQL …) October 2008 Brian Coughlan
Contents
- Reasons
- JEDI Overview
- SAS Detail
- Outcomes
- Key Resources
- References
- Choice
- Confusion
- Cost
Reasons
- Broadband, Narrowband, HomeNetwork
- Orders and MAC codes
- Issue or Fault
- Cancelled & Confused
- Restarts, Spyware, Vista
More reasons
JEDI Overview Overnight Extraction of Telco JEDI Server interaction Facilitates Analysis Improves Call Match Rate Review of handling and resolution rates Review of match CLI/CED Rates Routing Changes Operations input
SAS - Foundation
SAS – Building Blocks
SAS – Superstructure
- Reduced:
Outcomes
Key Resources
References
- Call Automation - Cost Savings
- Why too much choice is bad for us