Genesys, Unified Communications and Contact Center Published Articles

Hi Everyone,

In this thread I will be re-producing articles and papers previously published across LinkedIn and other sources. The aim is to provide a few more insights, tips and hints to the world of Genesys and all things Contact Center.

Adam

Tech Tip: Post-Call Reason Codes in Interaction Data

Not many people know that, after a call has ended, Agents can be given the opportunity to add more information to the Interaction, for reporting purposes. Aside from “WrapUp”, you could also apply a udata Field that you might call “ReasonCode”. This is a bit like the Disposition Code (used for Outbound Call Results), but it is intended for Inbound Calls. Basically, the Agent decides what the caller actually wanted and then applies a relevant code, during Wrap Up using additional udata Fields within a softphone or through a CTI toolbar.

But why is this useful?

If your core Routing applies lots of “labels” and “flags” to an Interaction and your reporting is based on, for example, what the caller thought they wanted when they entered the IVR (those pesky digits!) - or perhaps the “final” destination is the Queue used to deliver the call, or the Team it was delivered to - it may not be the end of the journey for that caller. Knowing the difference between what options a caller chose in the IVR - or the route the call took to a Team or Department - and what they actually wanted (and where they ended up) can provide a lot of insights into the effectiveness of your core routing. Think about the addition of a ReasonCode to routing and reporting like this:

IVR Data (what the caller asked for) —> Routing Rules (where the business wanted the caller to go) —>Queues and Targets (how and where the caller was routed) —>ReasonCode (where the caller’s journey ended - and an indication of what they actually needed)

By comparing your reporting, you might just find that a lot of callers are using the same options in the IVR, simply because it is the quickest way to get to a Live Agent (don’t we all?). With the introduction of ReasonCodes, applied to the Interaction (reporting) data by an Agent during WrapUp, it would clearer if callers are taking the path of least resistance and then asking for something completely different and are transferred to another Queue or Department.

This could be a very important additional metric, because a lot of your “post-IVR, post-Routing” information might be giving the wrong impression by reporting on what digits a caller chose - or the Queue that was used to route the call - because it may not be the same as what the caller actually needed or intended. With the right ReasonCodes in place, it means you can define and report on the actual Reason for their call and compare it with your traditional reporting methods. From there, it is a side-step to optimizing your IVR and your Routing, to make sure you get the Right Call to the Right Resource, First Time.

Why Don’t My Statistics Match Up?

A question I have been asked countless times: “Why don’t my stats match up across Genesys Reporting Solutions?”

Here’s a few pointers, for those who are feeling the pain…

1. Different solutions count different objects in different ways. It may be a bit confusing, because they might use the same “Object Name” or “Statistic” or “Time Profile” or “Time Slice” - but they were all built for different purposes. Some look at workflow or workforce requirements, some count volumes, others count interactions and some count legs of interactions. Overlying those basic elements are the “Count” and “Average” and “Maximum” or “Minimum” rules, which may not be the same either.

2. Genesys is not a Solution - it is a Platform. It can contain many different Solutions which were built with specific tasks in mind. Ask yourself if you are using those Solutions for the individual purposes they were intended - or if you are trying to manipulate data sets from different Solutions purely because you think you can. The volumes, counts, statistics, averages, calculations and algorithms within each Solution are applied to thousands - sometimes millions - of units for measurement, so there are bound to be some small scale differences.

3. The majority of statistics are extracted from “Source” via a CTI Link (TServer) or an IServer - or a similar, direct link to that “Source”. So, you might think they should all be the same, right? They are not. Here are a few examples;

“Time Slice B” in one reporting element may include a count from the previous “Time Slice A”, because an interaction began in “Time Slice A”. In another solution, the count may be reported in “Time Slice B”, because that is when it ended. This can cause differences between the counts in both solutions. But they are not discrepancies.

“Average” in one solution may use pure mathematics and include decimals (e.g. 12.56384561 seconds) - another might round up the figure (e.g. 13 seconds). Applying an average to either solution and comparing them will show a difference. Not a discrepancy.

“Object” in one solution may contain a group of elements, such as an Agent Group - or it might be a Group of Agents. They sound similar, right? They are not. An Agent Group is defined in CIM, whereas a Group of Agents can be user-defined within a report. “Objects” can also be dynamic; an Agent Group may have contained 12 Agents at the start of the reporting period, but it is possible to remove/add Agents from an Agent Group on the fly, so it’s possible that you have included or excluded stats from Agents who were removed/added - and this is equally true of Skills/Skill Levels in reporting.

4. There isn’t a “matrix of comparable units” for the statistics across Solutions, because they generally serve different purposes;

CCA, CCP and IWS generally count Call Volumes, using Crystal or Hyperion
GI2 generally counts eServices and other Solution Interactions, using Business Objects
WFM generally counts Work Effort using it’s own proprietary interface and compound statistics

5. As a rule of thumb and as an Industry Best Practice, you should allow for up to 3% differential between reporting solutions. You might be looking for everything to be mathematically equal and - whilst it may be very satisfying to see that - it will not be. Give yourself a break and allow for this differential as a standard, acceptable measure!

First Contact Resolution - Metric, Misnomer or Myth?

First Contact/Call Resolution (FCR) is the name given to a metric used in many Contact Centers, generally indicating a successful task completion. Whether that relates to a successful outcome to an Enquiry, a Problem Resolution or some other business defined metric, FCR remains a topic of debate within our industry. But why?

Sometimes FCR is very easy to define; with Products and Sales it either was - or was not - achieved (but more on this, later!). Within more generalized operational areas, FCR is exceptionally subjective - and very difficult to pin down. Take for example a customer whose enquiry has been dealt with and marked “complete” by an Agent - and then they call back with a subsequent question, which may or may not be related to their original enquiry. Is it an FCR failure if they call again..? Subjective.

In realistic terms, metrics for FCR need to be implemented given the right conditions. If it is possible that subsequent interactions are likely, then FCR may be a good fit. But it can become a complex metric within omnichannel interactions, where it is quite possible that FCR may have failed, across or within another interaction type with the customer or client. So again, FCR is subjective.

What it boils down to is finding a definitive metric for FCR that works for you. Something that has an objective. But what does that mean? FCR sometimes needs to reflect the best intentions of a business to provide the service required. Taking Product Sales as an example; if you get a Sale, then it’s pretty clear cut - you passed FCR - but is that really what FCR is all about? A Sale is already a metric - whether that’s an Interaction in a Contact Center, a purchase in a Store, a Client/Rep agreement or some other method. So, in actual fact - no, FCR is not a metric you should be using in Sales, because that already has a defined metric!

FCR really comes into its own when you have the potential to incur subsequent interactions on a given subject. In those cases, you need to ask yourself if you have business objectives for FCR - or whether they are subjective to the business services you provide:

Is your FCR intended to constrain the number of interactions to the fewest possible, to reach a pre-defined target?
Is your FCR intended to reach a resolution for an interaction, in the shortest possible time frame?
Is your FCR intended to field an enquiry, to the satisfaction of the client?
Is your FCR a convenient way for you to monitor the effectiveness of your staff?
You can probably see that some of these measures for FCR are subjective - and others are objective. If you have targets, those are objectives. If you provide services, then those are subjective. But how do you measure that metric?

Objective = Targets
FCR Objectives need a defined target - and a defined method to reach that target. In most cases, closure needs to be defined - and monitored as a metric. This is usually defined by a business or enterprise.

Subjective = Satisfaction
Subjective FCR is much more complex and should have a less-defined target. This is simply because the measure of success cannot be defined by a business or enterprise. The target is being defined by the level of services provided to an individual - and it is, ultimately, their decision if resolution has been achieved. The best way to apply any type of metric for subjective FCR is simply to ask the caller/client. That could be through a customer satisfaction survey but, if I’m being perfectly honest, consumers hate those..! Sometimes it is enough that your staff complete the FCR by confirming that they did all they could to assist, to the satisfaction of the customer… and, sometimes, that is the best intention you can achieve.

I am sure that, in some sectors, FCR means something completely different - and that is another area worth mentioning. I’ve seen a lot of reports, statistics and metrics about FCR - and even more that are actually about MCR (Multiple Contact Resolution - where a business defines more than one set of metrics for FCR). Everyone has their own view of what FCR is - what it does - what it is used for - and how it can be achieved. And I think it is worth recognizing that FCR is, in fact, not a standard metric across the industry - nor should it be!

IVR: Why it’s Important to take that Customer Journey before your callers do…

I had an issue with my mobile network provider. For the sake of anonymity, let’s call them “Vadofone”, here in the UK. I duly went to their website, looked up their Customer Support number for my PAYG Tariff and dialled… my IVR journey began…

“This number has now changed to … which is charged at a basic rate. If you continue to hold, you will be still be connected to one of our Advisors - but your call will be charged at a higher rate… Welcome to Vadofone Customer Services, please enter a valid …”

00:35: Soooo… the Customer Services number on the website is out of date…? OK - still.. I’ll enter my number, undaunted…

“Welcome - there are several ways to resolve your query, without talking to an advisor. To check your current calling credit or Top Up, you can call , anytime. For a list of resolutions to common issues or to chat to an advisor on-line, free of charge, 24/7 visit vadofone.co.uk slash “contact us”… Alternatively, to speak to one of our Agents, there’ll be a flat 25p charge…”

01:20: So, you’ve warned me that speaking to one of your Advisors will cost me money - and you’ve kindly given me some “tips” to resolve issues I don’t have, that I could “resolve” myself, free of charge. OK - thanks. I also realise I am over a minute in to my call and I am nowhere, yet. But - wait - there’s more…

“…There are 3 Options; If your phone is Blocked, press 1. For Customer Services, press 2. If you are thinking of leaving us, press 3…”

01:45: Got it. Pressing 2 - definitely need 2…

“…Just a moment whilst I put you through to one of the team, who can help…”

01:55: Great! Straight through!

“…This number has now changed to … which is charged at a basic rate. If you continue to hold, you will be still be connected to one of our Advisors - but your call may be charged at a higher rate… if you speak to one of our Agents, there’ll be a flat 25p charge…”

02:30: Erm… o-kay…

“…To speak to us about your PAYG Service, press 1. To speak to use about your Pay Monthly Service, press 2…”

02:45: Now, I do recall that I entered my number, only moments ago - so, in all honesty, you should know what my Service is? Okay - I’ll play ball… Pressing 1…

“Welcome… | …Welcome to Vadofone PAYG. You’ll find lots of ways to get help with PAYG if you visit vadofone.co.uk/help - you can also chat to an Advisor, on-line for free at vadofone.co.uk/contactus … If you speak to an Advisor, there will be a 25p flat rate charge. There are 3 options; If you want to Top Up, add a or understand your credit or going abroad use, press 1. If you need Help or Support, press 2. If you want to upgrade to a Pay Monthly Plan or you’re thinking of leaving us, Press 3…”

03:45: Yes - really - nearly 4 minutes! OK - I listened hard, but Option 1 had, like, three things - or was it four? Anywhooo… I need help and support - so… 2? 2 - yep, that’s it. “2”…

“If your top-up, <etc.> hasn’t activated yet or for any questions about press - 1. For information on network coverage it’s 2. To get technical help, including changing settings on your device, press 3. For information on call barring it’s 4. Or if you want to bring your number from another network, press 5.. press star to hear these options again…”

04:30: What? …What!!! How many… What was that…? . “*”

“If your top-up, <etc.> hasn’t activated yet or for any questions about press - 1. For information on network coverage it’s 2. To get technical help, including changing settings on your device, press 3. For information on call barring it’s 4. Or if you want to bring your number from another network, press 5.. press star to hear these options again…”

05:15: Actually, none of the above. What now..? Got to choose something, I guess… Technical Help? Close enough… “2”…

“… For help with your voicemail, press 1. For help with your internet or picture messaging settings, press 2. To use your phone on another network, press 3. For a PIN unlcok code, press 4…”

06:10: Seriously? None of the above! Where is my Agent, that I would now be glad to have to pay 25p for, having spent over 6 minutes listening to Options..???

Suffice to say, I gave up. Too many Options, too many assumptions, too much narrative per Option, too many repetitious menus, too many loops, misleading and superfluous information, broken menus and - ultimately, being the worst of all - a complete waste of my time!

Lesson learnt? Don’t call “Vadofone” for Customer Services on a PAYG Tariff - go to the website… and good luck with that, too!

Agent Misbehaving?

It happens - sometimes. The wily, weary, worldy-wise Agent. I am providing some scenarios - and solutions - to “Agent Misbehaving”. I’m not going to make any social comments on this post - I think it speaks volumes by itself. Just some things to “be aware” of…

Scenario 1: FIFO Avoidance Tactics
Problem: If your CC uses a version of FIFO for Call Routing (First In - First Out), it’s possible you might find a version of FIFO Avoidance by Agents. This means that an Agent Logging In “last” is generally routed to last, from the Inbound Queue. An Agent constantly Logging Out and immediately back In will effectively place themselves “last” on a frequent basis, affecting their availability/workload.
Solution: Create a (BI) Report of the number of “Log In”/“Log Out” per Agent, per hour. If possible, get the timings for them, too.

Scenario 2: Ready/Not Ready/Ready
Problem: Agent see’s Calls Queueing (on a Wallboard or similar) and times a “Not Ready”/“Ready” to coincide with the call’s arrival, effectively passing it off to another Agent, affecting their availability/workload.
Solution: Create a (BI) Report of the number of “Ready”/“Not Ready” States per Agent, per hour. If possible, get the timings for them, too.

Scenario 3: Short Call/No Call
Problem: Agent is answering calls - and immediately hanging up.
Solution: Create a (BI) Report of the Average Talk Time per Agent, per hour. If possible, get the individual Total Talk Time per Agent, with the Total Number of Calls.

Scenario 4: Answer/Blind Transfer
Problem: Agent is answering calls and transferring them immediately to an internal Queue.
Solution: Create a (BI) Report of the Total Internal Transfers per Agent, per hour. If possible, include Total Number of Calls Answered and Total Number of Calls Transferred.

Scenario 5: Answer/Mute Calls
Problem: Agent is answering calls - on mute. After a delay, they hang up.
Solution: Create a (BI) Report of Average and Total Talk Time per Agent, per hour. If possible, include Total and Average Time on Mute.

Apples & Oranges: Volumes & Interactions

I am going to attempt to articulate the similarities and differences of Contact Volume recording and Contact Interaction recording. Sometimes the lifeblood of a Contact Centre SLA/KPI - and frequently misrepresented, miscalculated or misinterpreted…

Firstly, let’s go for one definition of what could be considered;

Volumes - the total number of Units at any given point in the delivery process.
Interactions - the total number of Requirements at any given point in the delivery process.
There is also another definition of “Interaction” for Work Force - but we’ll get to that, later…

They are all close but… different. The first point to note here is that they are not the same metric. By definition it probably isn’t all that clear. So, let’s go for an example;

A Contact Centre takes 1000 calls from customers. In reality, some customers who have (finally!) got through may well want all of their issues dealt with, in one blow. They have waited very patiently and now, whilst they have your staff on the line, there is always the “…oh, just one more thing…”. Therefore, 1 metric becomes 2 things. In this example let’s say 10% of callers requested further support and were forwarded to a second Service area;

The Volume of calls is 1000.
The Interactions from customers is 1100.
Not a problem, you say - we have metrics measuring Transfers… as what, exactly? Inbound? Transfers? Internal Calls? Aha! Suddenly, you’re wondering if you have been counting things all wrong? Probably.

The next point here is whether you can identify your Volume. What I mean is; can you trace the Volumes of unique calls from arrival, to transfer to another Agent, to transfer to another Queue, to transfer to another Department/Site/Company - to the end of the Interaction? If you can, then you can tally up your Volumes, separately from your Interactions. If you can’t… could it be that you are double or triple counting - or perhaps even under counting your volumes? Probably.

The key to knowing whether you can (or are) counting Volumes or Interactions depends on how much information you have to hand. If you can uniquely identify each call and each leg of the call, then you have the key to providing the right metrics for Interactions - and a much better understanding of the amount of work effort being applied by your resources. If you do not have that level of information, you can only ever count Volumes.

Another problem lies in trying to find out just how much work (“effort”) is required, if you only have Volumes for use in Forecasting…

…Yes - this is the other definition of Interactions, for Workforce Management…

For the purposes of WfM, an Interaction works differently. Through monitoring techniques and algorithms, WfM poses the same question, multiple times during call routing; Was there an appropriate resource available in the required time-frame? If the answer is “No”, WfM will mark that Interaction as failed. If the call routing then expands to include other resources, WfM asks the question again; …was there an appropriate resource available in the required time frame on the second leg? And it will continue to do this, for as many Target Groups that are presented. In this way, any by-product statistical reports extracted from WfM will definitely be larger than those of Volume reporting, offered in BI Solutions.

The bottom line is that Volumes and Interactions are not measuring the same metric - nor the same work effort. Assuming that they do - or that they should - can lead to bad practices in BI reporting, where manual updates or “fixes” might be employed, to ensure both values match.

Because Volumes are Apples and Interactions are Oranges!

Why Composite SLA/KPI Measures are Bad for your Business…

In this article, I will be looking at the frequently unsustainable and infeasible metric targets and measures (SLA/KPI) in Call/Contact Centres, the detrimental effects it has on Business Operations – and how to avoid them!

I wonder just how many times an Operational Service Level (SLA) or Key Performance Indicator (KPI) of a Call- or Contact Centre has had to be beaten into submission? My experience with these metrics - and the unruly traits within business enterprises to counteract them - has been severely tested, at times. But what it is that forces a well-intended metric to be viewed with such disdain and loathing? Why does it frequently lead to an “interpretation” or “manipulation”, beyond what was actually intended? And does it really serve the intended purpose, if it is not a true reflection of your Operations? In my tongue-in-cheek way, I refer to this dilemma as “The Importance of Being Earnest”..

“The truth is rarely pure and never simple”

For those not aware, “The Importance of Being Earnest” is an English play by Oscar Wilde, set in the Victorian era, which centres on a series of (social) events and conventions which are continually avoided by the protagonist - to much hilarity. The same could be said for the “protagonist” business operations who, without first recognizing the futility of setting lofty SLA’s or KPI’s - suffer losses by continual attempts to circumvent or avoid them!

It is human nature to want to succeed - and have goals. But those goals must be grounded in reality. A performance score which is barely attainable when fully-staffed - is simply impossible to maintain, indefinitely! What then follows is a Series of Most Unfortunate Events, leading to a less than earnest attempt by business operations to achieve such high scores. Moreover, statistical high-jinx and smoke and mirrors begin to creep in - heralding the end of any good intentions behind setting those metrics in the first place. A rather sad state of affairs ensues, whereby the Management smile and nod whilst Operations use slight-of-hand to present what they think the Management need to hear. “Everything is fine, your Majesty…”. No. No - it isn’t, at all.

In a couple of my publications, I quote the Henry Ford (Fordism) model of engagement for Mass Production, relating to Workforce Management. And how, even with the best of intentions, you can easily mis-interpret performance measures – and goals. Take, for example, a Time and Motion study that was conducted in an industrial factory, whereby more lighting was installed to enhance production. Results clearly showed enhancements with more lighting. Each time more lighting was added, production went up. Then, as a safety test, the extra lighting was removed. And production went up. Because it is human nature to want to succeed. The subject workers wanted to assure the management that they had faith in their plans to improve production – and it wouldn’t have mattered if there was no light at all – production would have appeared to get better!

But – back to the point. Being earnest. The crux of this issue is in setting unattainable goals and trying to enforce them. Without “testing the water”, you cannot blindly dictate a metric or goal and expect it to be adhered to. You have to know what your operations are capable of, before you set the bar! It is for this reason that a business must set realistic and attainable goals. They might be on the low side. They might actually not be very good at all. But they are earnest! And they are attainable. Which means that your operational workforce will not need smoke and mirrors. They won’t need to “roll-up” last week’s statistics to attain their targets, to the detriment of your customers. They will actually make more effort to reach goals they know they can attain – more so than having to worry about how they will mask their metrics when presenting them to management.

So, here’s the Pro Tip:

Lots and lots of people agree that “Service Level” is an industry standard. I agree, too. I agree that the calculation for a Service Level is worked out in a certain way. It is a mark of achievement, given a percentile and a time frame. What I do not agree with is that it is exactly “95% of calls answered within 20 seconds” – or “80% of calls answered within 30 seconds” – or any other “industry standard” setting. It is a metric that should be set by the business – and it must be attainable – and sustainable. I would even go so far as to say that, for the sake of productivity, you might have more than one Service Level. And why not? It’s your business, after all…

There is nothing wrong with setting a lower Service Level calculation for your Operations. There is nothing wrong with amending a Service Level, either. Because, at the end of the day, the measure of success for your business is… whatever you say it is! Perhaps you need SLA1 and SLA2 – because Customer Technical Enquiries simply take longer to field than Customer Account Enquiries. And that is perfectly fine – as long as your operations agree that those metrics are attainable and sustainable. The absolute worst thing you could do is ignore your operational capacities and Carry on Regardless…

This approach should be encompassed throughout your organization – not just between Management and Operations. In an open – and honest – way, you will serve your customer better, your business will become more successful and your operations will no longer have to juggle to perform well.

The Importance of Being Earnest is clear; being earnest means setting goals that are attainable - and that people will strive to achieve. Not being so – or appearing to be so – will only ever serve to mask operational issues, to the detriment of your customer, your operations - and your business!

The 7 Deadly Sins of the IVR…

In my experience, you can never over-utilize a good thing. And, yes, I think an IVR is a good thing - when you get it right. Mostly…

Aside from the fact that nobody actually wants to wait - or to have an automated attendant dealing with my “important” call - and I’m then subjected to constant
repetitions of “…your call is important to us…”. Or to be told I am 5th in the Queue - then 3 minutes later to be told I am 10th in the Queue. Nobody likes that. Or when I get put on Hold for so long, my call is picked up by an automated process and thrown back into my original Queue - and I have to start all over again

Okay - so maybe there are a few things that can go wrong…

The IVR, as a business necessity, doesn’t have to be a burden to you or your customers. All you have to do is avoid the 7 Deadly Sins of the IVR;

1. Though shalt not Drop A badly-developed or poorly implemented IVR will have “holes” left unplugged. There will be an Option - or a non-Option that will
   drops callers into the void, with no supporting strategy. The value of post-implementation testing cannot be underestimated. Make sure you take every
   journey on your Production IVR before your customers do!

2. Though shalt not Auto-Divert Many IVR’s sit in front of a telephony switch. Some sit behind it. Almost all are reliant on a telephony or IP sub-system, be it SIP or TDMS/E1/T1 Trunks. Um… too technical? OK - every IVR has a “back-up” in place. The backup can have it’s own “strategy” for dealing with what it might consider to be “stuck” calls - and it is set to Auto-Divert them. Even with the best testing in place, you can never be 100% that one of those sub-systems isn’t going to pluck out one of unsuspecting, waiting calls - and throw it somewhere else entirely. When you are planning your testing - don’t forget that your legacy sub-systems may have their own rules!

3. Though shalt not Mis-Inform I think it’s great to know where I am as a caller, in relation to others waiting for the same Service. What I don’t want to hear is that I’m now further back in the Queue, the longer I wait. I might be usurped by a caller with a higher “Business Value” - or another who has been re-entered into the Queue by an Agent - and so on… and those things happen more frequently than you might imagine. A simple overriding rule can avoid this - if your caller’s position drops backwards then don’t announce it!

4. Though shalt not Over-Inform I’ve been there. A standard call to an IVR; a dialogue about the Service, how they sometimes record calls for training purposes, how they are committed to customer excellence, how they are in the top Quarter of their industry, what awards they won last year and then what options are available to me. Then how they need to prove my identity (for my safety) and then… “We’re sorry - all of our Agents are busy at the moment…”. It might be a delaying tactic - and you might think of it as a part of your overall Strategy to allow Agents to become available to take a call, because it sits in the Queue for so long before it’s delivered. But there is so much time wasted and so much frustration on the part of the caller. The solution is to make sure your announcements are in the right order - at the right time. A short burst of information before each set of Options is a good approach. Announcing everything before you offer any Options.. or before you know if you are staffed for the caller..? Just - No.

5. Though shalt not Assume IVR’s are based on decisions - not assumptions. You might assume that your caller is bound to know what your “XY&Z Team”
   does, when you plan and record your announcements. Please don’t. Each and every caller will hear “XY&Z Team” and think one of two things; 1 - “What the heck is an XY&Z Team? Is that who I need..?” or 2 - “Aha! The XY&Z Team! Yes! At Last!”. But statistics show us that one of those trains of thought vastly outweighs the other. I wonder if you can you guess which? Almost against the grain of Deadly Sin 4; make sure you find a good mid-ground to explain where each Option leads - not the “Team” or “Department” or “Service” - but the “Function(s)”.

6. Though shalt not Over-Indulge What if… you have 30 Departments? What if… you need 60 Options? The great thing about an IVR is Scalability. Yes, you could design your IVR to take the caller through myriad Options, weaving through your internal infrastructure, until the Nth Degree. Or - you could not. A great leveller for this dilemma is simple; use more than one incoming number!

7. Though shalt not Delay Sometimes, your callers may have to pay to call you. What they do not want to do is to pay to wait. Think very carefully about generating any type of revenue from callers to your Services. If your Service of support is intrinsic (“included”) - then why should your customers pay to call for support? I’m taking this straight out of the news that EE customers can pay a premium to Queue-Jump, irrespective of their Tariff or Customer Value. Urgh!

The 7 Best Practices for your IVR…

For this post, I’ve taken both a holistic and pragmatic view of where we are with IVR’s and how they sometimes don’t fit in with the general mindset. I’ve also considered, at length, just what it is about IVR’s that makes us loathe them so much. And, if I can still think happy thoughts after that, they might actually be reflected here..!

So, without further ado, my Best Practice’s for the modern IVR;

1. Purpose; The fun is in the Planning! Think about what you want your IVR to achieve. No - not just the caller segmentation, information gathering, Options and Routing to Agents. It’s Purpose… It’s your Front Door - It’s the place where you give your first impression of your Services - It’s the place where, by human nature, a potential client or customer is going to make a decision. Don’t mess it up! First off; be your customer and feel what they feel. Take yourself out of your comfortable corporate persona and ask yourself “Is this what I would want happening to me?”. Secondly; plan to get what your business needs - and what you, as a customer, would want (see Point 2). Finally; make the journey yourself and tick those boxes; Is it Fit for Purpose? Does it provide all of the wants and needs for both caller and business? Is it actually fulfilling it’s purpose? If not, it may well be worth your while to go back to the drawing board!

PRO TIP: IVR Customer Satisfaction Surveys can be very misleading and, ultimately, a waste of time (but see my note on Best Practice 7). Don’t be surprised if you ask questions and get results which are extremes on your scale - people will either be “with it” or “against it”. But - then what..? What if you have an IVR that people generally don’t like - what will you do with that information? Revamp it? Re-structure it? Replace it…? No - you’ll have to accept it. So why bother asking the question? Face it - people just don’t like IVR’s, no matter how “nice” they are! In my next article, I will be looking at Innovations and Recommendations, which can take an IVR to another level - including how to make your IVR a better place.

2. Balance; The wants of the customer - and the needs of the business. Rarely do the two meet - like strangers in a bar. But it is not the customers responsibility to strike up the conversation first - it’s yours. So - balance. The more you already know, the less you have to ask - so take a good look at what you can get without asking questions. Cell Number? Location? Previous Customer? Do you have any information - anywhere in your business - that will help you find the balance? Find out everything you should know and use it to provide a balanced experience for your caller. Guide them by using dynamic rules for their Options. Help them to make decisions about what, who, where and why they are calling. When you have done all of that, you will be surprised how much information you have gathered. That is the perfect balance of giving the callers the assistance they need - and your business the information it wants.

3. Presentation; I admit I have stolen some of Kevin’s fire, here… The fact that your IVR is your Front Door means you need the right “persona” to meet and greet your callers. A lot of thought may go into who that is. A lot less thought might go into how that pan’s out, down the line. An IVR with more than one voice presented to a caller creates a choppy experience. Think about how that might sound - to be “passed around” from one automated attendant, to another. Callers aren’t dumb - they can recognize a sloppy IVR - and that is not the impression you want to make. Be very mindful about who you choose to voice your IVR - and how you engage with them to ensure continuity. Best Practice? If you no longer have access to the “voice” you originally used, you will need to re-record ALL of your announcements, from scratch. Or - you could use a sub-system to provide TTS/Automated Voices on your Automated Attendant - but I am getting ahead of myself - see my next article for Innovations and Recommendations!

4. Accessibility; A particularly troubled area in IVR menu’s is the “one size fits all” Option; “For all other enquiries…”. To be fair, it is a necessary aspect of accessibility. If the caller doesn’t/can’t recognize any “good” Option - you have to offer an alternative. A Best Practice is for you to use that Option as a Learning Tool; to know where and how someone arrives at your “catch all” means you know where things are not as comprehensible as you would like. Using that level of detail, you can determine what is not working - and fix the accessibility issues.

5. Interactivity; It may well be that your IVR is presented in the best possible way. It may be that your “IVR persona” and your corporate image is maintained to a very high level. But it doesn’t necessarily follow that your callers are engaged with the interactivity you are providing. And this is about knowing your audience. If your callers are simply not choosing the Options available to them, preferring a particular path, it means they are missing opportunities, through not being interactive. Of course, you can’t force a caller to review all the Options available to them - but you can prompt for interactivity. A Best Practice is to keep your caller informed about the choices on offer. Tell them how many choices there are, before reeling them off. Let them decide on the path - but make sure it is signposted. At the risk of repeating myself, I will be looking at this aspect in more detail in my next article.

6. Stability; No - not the availability of your IVR (although that should be 99.99996%, according to 6 Sigma!) Stability is about maintaining a familiar structure for your callers - and sticking to it. People like familiar things - it gives them a warm, fuzzy feeling. High-level Options should never change - the very first button presses should remain the same, giving (repeat) callers the confidence that everything is as it should be. Perhaps, sometimes, you will need to change a few Options further down the line - and that’s okay. The Best Practice way is to provide a stable, solid initial list of available Services. If you need to add a Service, don’t change the order of the existing Services - put the new Service as an additional Option.

7. Innovation; It is okay to try out new things. But it is better to know that they are working for everyone, before your idea goes mainstream. So, you have a brand new IVR and it has whistles, bells and drums - and it even makes the tea! But… think about Stability. Think about Interactivity. Think about Familiarity. Think about your caller. The Best Practice way is… slowly. Slowly introduce your bells and whistles - pick a sub-set of callers or a sub-set of final Options and work your way UP to the top Options. In absolute contrast to my PRO TIP: Ask your callers what they think of the way your NEW system is going. Sure, it’s great to innovate - and it’s great to provide a better Service for your business and your callers. But make sure it isn’t just you who thinks that, before you jump in with both feet!

The 7 Best Innovations of the Modern IVR…

Now I am going to take a look at the way an IVR’s role has changed over the last few years. I’m also going to extrapolate some of the technological advances and innovations available today, to give examples of what could be achieved, given the right methods of deployment.

In case you were not already aware, the IVR has come a long way in quite a short space of time. This is due mainly to the introduction of more interactive and intelligent computing components - and the level of interactivity an IVR now has with business and other legacy systems. What once was a “dumb terminal” which served only a single purpose - two at most - has evolved into what can be a multi-purpose platform. Not only that, but it is now more interactive and user-friendly than ever! Mostly…

1. Inter-Connectivity: IVR’s have always had a level of connectivity with some back-end business systems - usually through a series of intermediate services. Generally, a lot of financial transactions are conducted through an IVR, which is considered a matured, secured portal to payment and purchasing systems. But those connections have grown - a lot! IVR’s can now interface with a multitude of business systems, databases and (web) portals, allowing it to become almost autonomous in it’s pre-defined role. The “dumb terminal” can now send back validated information and update those inter-connected systems. Customer decisions, choices, orders, amendments, cancellations - all directed at a back-office system without the need for dozens of pass-through points or adaptors. The IVR has become a bona fide information tool in it’s own right, sitting within your enterprise architecture, instead of outside of it.

2. Automatic Speech Recognition: IVR’s can hear you! No - seriously. I don’t know if this is true but I once heard that a company used to advise callers that they may be recorded for training purposes - and actually recorded them as they waited, listening to dross music in the Queue. Can you imagine..?!?

Anyway - I digress… Speech recognition (ASR) has been around for over a decade - and it’s become really rather good. Not only to interact directly with callers (see also “Text To Speech”, below) - but also to convert a callers verbal request into data. Picking out key words and phrases, the IVR pieces together what the caller wants, one syllable at a time. My extrapolation of this superb piece of innovation is for the IVR to pass along either the data or the voice request of the caller, to the Agent or their Desktop, before the call arrives. Imagine getting a “heads-up” on what the caller really wants, rather than just what button presses got them to your Agent!

NB: A footnote on ASR: aside from a “standard” ASR approach for an IVR, there are now a bunch of small companies concerning themselves with Emotive Content. Plucking out and extrapolating moods, words, expletives(!), brands, product names, and the general “feeling” of your callers (and Agents!) can help in many ways. Not least of which would be to refine or define the way in which your business deals with it’s customers.

3. Text To Speech Engines: IVR’s can talk back! What..? No - I mean… without a recording of a real person’s voice. It’s been possible to create a fully-dynamic script using Knowledge (see below) fed back from picking up ASR (see above) for quite a few years now. From there, it can be passed through a TTS engine - and - Hey Presto! - a semi-literate, robotic voice warbles something incomprehensible down the line at your customer.

…I’m joking, of course! TTS engines have moved on from those days. Recently, I was served by a TTS IVR and it was over a week later that I found out it was an automated attendant. I really could not tell! The movement within TTS technologies has been about getting the nuances and intent as close to human as possible. Expression, volume, speed, tone, intonation, dialect, enunciation - it’s all in the mix to bring you some quite stunning results. Couple this aspect with inter-connectivity and you can create blinding interactions that are seamless. In fact, with the right “Knowledge” in place, you might even be able to replace some of the more mundane tasks at the lower end of your SLA list…

4. Rules Engines: I wouldn’t want to state the obvious about how an IVR needs to make routing decisions, based on input from callers. I would want to state the less obvious that not all inputs come from the same source, these days. Rules Engines (or “Routing Engines”) have become very intricate, indeed. The techies now have VXML and CCXML with which to convert a multitude of different conditions, statistics, look-ups and generic business rules to give your IVR the edge. Basing decisions on immediate events and actual points in time, a business can create a comprehensive, seamless interactive guide for their callers. And that is based on a lot of information from within a business - not just the caller’s button presses!

5. Knowledge and Content: Let’s suppose, for a moment, that you called your service provider IVR and it just “knew” what you wanted? Using all of the points above, it has a level of business intellect with it’s own set of choices, decision points and variable outcomes. But, moreover, it’s learning. Because of the vast amounts of statistical and reporting information available, a business can determine, devise and design - even pre-empt - the needs of a caller, based on a match for given variables. As a certain set of criteria is reached - and the caller duly makes the call to your IVR - it can respond with it’s best guess at why the caller is calling. Using Knowledge and Content for Dynamic menus can, on a smaller scale, also offer the caller the opportunity to only be presented with the IVR menu options they need - and also to remember those options for the next time they call.

6. Terminal Services: No - not a mortally wounding phone call. Terminal Services can mean that your caller has called, interacted with your IVR and has completed a transaction of some kind - usually without the aid of an Agent. Many banking and account services use automated terminal services to deal with repetitive transactions, which require some form of Identification and Verification (IDV) with which to secure any transaction. The “innovation” here is in introducing Rules Engines and Knowledge and Content to identify repeat Processes and Services that your Agents currently deal with. Armed with enough information from your IVR, you can plan to reduce real-time workloads by off-loading any identified, feasible, repeatable processes to your IVR - and save time and resources for the more complex queries from your customers.

7. Reserved: This isn’t a “cop out”. I really want to reserve “Number 7” on my list for the next big innovation for IVR’s. But it hasn’t actually happened yet, to my knowledge. So, I’ll leave this one parked - for now!

NB: In case this subject pops up in conversation; I am purposely omitting the plethora of Smartphone Apps and Devices and Services which have surfaced in the last 2-3 years, which have the sole intent of circumventing an IVR - or otherwise providing a “Virtual Hold” facility. It’s not because I don’t like them - I think they are great time-savers. It’s just that they are not an “actual” IVR devices or Services - just “peripherals”. Although, I have to say I really do like the idea of providing an App with a “map” of available IVR Options, providing a visualisation of something which is generally “heard” linearly… How about that for Number 7…?

The 7 Steps to a Better IVR…

This time around I am going to take the view that, whatever flavour of IVR a business might have - there is always room for improvement. We will be taking a general view of “any” modern IVR, mentioned in my previous posts. Then we will take that typical business IVR - take a really good look at it - shake it, prod it, squeeze it slightly, mould it gently, fix the lights, add some bells and whistles, then gently ease it back into place…

And don’t forget - the fun is in the planning!

1. Report; an IVR should be monitored and you should have access to the things it can tell you. Do you know if it performs well? Are you aware of any areas that need a little TLC? Are there great, gaping black holes where callers are getting lost..? Could you use a little more – or a little less of anything? The first step towards a better IVR is to find out what (or if) there is anything wrong with it, in the first place. That will require a level of reporting (from your IVR), talking to your technologists and investigating (costs versus benefits).

Without a view of where you are, you can’t possibly plan a journey to where you want to be. Gather as much information together as you can and make a bullet point list of what you know needs fixing – and how much that will cost.

2. Refocus; so, you have a list of broken things and you have an idea of how much it will cost to fix. It’s a start. Next, you should be looking at the things you would want your IVR to do. Don’t just think about the features your IVR may have, currently - but the functions it could perform. Bearing in mind enhancements should bring a level of improvement, you will need to consider what would be the Cost Benefits of those new functions, through implementation. A good rule of thumb is to consider who or what you might replace (people – processes – technology) with automation or inclusion through your IVR. Bring in your technologists and listen to them! You may find that you do not need the majority of the functions you discover - the point here is that you are best informed of what can be done, to enhance your business strategies.

NB: Knowing what you want for your business IVR can be tricky. Knowing if it has worked can be even trickier! In my experience, adding new functions and trying out new things on a modern IVR must be taken slowly – one thing at a time – and it usually takes a bit of time to “bed in”. Whatever you eventually decide you want to try out – give it at least a month before you decide if it’s actually working, then move on to the next…

3. Review; okay – so now you have two lists. “Broken” and “New”. In another language, you have your business “Wants” and “Needs”. Now’s the time to decide what can be delivered. And what can’t be delivered. Whatever you decide, I hope it’s clear that the “Needs” by far outweigh the “Wants”. There is no sense in applying enhancements to try to fix known issues. Like a well-worn bicycle tire - patch it first – then pump it up!

Of course, making changes to your IVR will mean there are costs involved. And, as with any business you have to weigh up those costs. Ask yourself; can you afford to fix the things that need fixing, using the cost benefits of the enhancements you intend to deploy..?

4. Reduce; the other end of the scale on a review is that you may discover something which is not working well, at all. It might be a particular set of options or a Self Service you need to think about reducing on your IVR’s footprint. And it is entirely acceptable that a reduction on any given area can be viewed as an enhancement. It may seem crazy that some things get better the more you take away but consider this; your IVR is most likely not new – it’s probably been around a while and a lot of good (and bad) ideas have been thrown at it. Fixing things and adding new functions may well only serve to make it worse! Don’t do that. If your IVR functions and operations need thinning out, don’t be reticent about removing them – it is a good thing. Cauterising known issues will allow other areas to flourish!

5. Route; I’ve mentioned before that the fun is in the planning! And this is a relatively straightforward step; plan to fix the broken elements first – and apply your enhancements afterwards. Of course, in planning your Route, you have effectively mapped out all of your Wants and Needs – and what you are going to do about them. There are a few ways you can do this – here’s my Top 2;

Waterfall Approach (Conception, Initiation, Analysis, Design, Construction, Testing, Implementation); Apply a fix, test it, bed it in. Apply any enhancements in the same area, test it, bed it in. Repeat until cooked. This is the best method if you are certain of all of the outcomes and you need a stringent time-line and a path to follow, with defined goals that focus on what needs to be delivered.
Agile Approach; this is a bit like the Waterfall method – but you take longer pauses in between, to evaluate the impacts of what you’ve achieved so far. If something isn’t quite how you expected it, step back, re-plan and go again. Slowly, slowly catchy monkey!
6. Regulate; there is no sense in applying fixes, bells and whistles if you cannot be assured that your IVR is operating as intended. This step is a part of your planning – but it permeates across the whole process. Regulation is about defining what your IVR should be achieving – be it SLA, KPI, Volume, Function – or whatever method you choose to employ to count the relative success of your business tool. The reason this sits way down here at Number 6 on the list is because it will have changed. But, since the fun is in the planning… You need to find a repeatable regulation process which will prove, emphatically, the Operational Effectiveness of your IVR.

This could be a series of Reports or Statistics – measures which are extracted either in Real-Time or Historically. What it absolutely needs to do is allow you to have the insight you need, to succinctly determine that your IVR is doing what you need it to do, for your business.

7. Re-evaluate; let’s see… you’ve reported, refocused, reviewed, reduced and routed. You have your fixes in place, your enhancements up and running, your regulation and your reporting are steaming along… what more could you possibly want? Well – you. It might be very easy to sit back and say “job done” – but is it? The Needs of a business change constantly, in response to Demand and Opportunity. Are you ready for that? Can you pre-empt them? Do you have a process in place to deliver? Are you able to supply the demand?

Actually – the answer is yes to all of the above. By following these Steps you have defined a process of change – even if you didn’t intend to. You know how to take stock and evaluate – and re-evaluate the features and functions of your IVR, to better serve your business model.

• and that’s it – The 7 Steps to a Better IVR!

Actually, there are some things you were probably not aware of, as you read through this post;

I used the DMAIC model (Define – Measure – Analyze – Implement - Control) from 6Sigma Methodology to be able to represent these Steps. I used Industry Best Practices to present Waterfall/Agile Development for deliverables. I used Business Case Studies and Practices to highlight the importance of focusing on Business Wants and Needs. I used Process Improvement to outline the need to look at People – Processes – Technologies. So - maybe you learnt a little more than you intended to… go you!

Very nice compilation! Thanks for that, should be mandatory in every pre-sales discussion in my opinion.

XD hahahaha pre sales ahhh that made my day

Enviado de meu E6633 usando Tapatalk

Ummm… the majority of these articles are aimed at either Operations or Planning… not sure what Pre-Sales involvement there might be. But thanks for the compliment!

PLSQL “CREATE VIEW” SCRIPTS (ORACLE)

WARNING: NEVER “WRITE” DATA TO THE GENESYS CONFIGURATION DATABASE!

USE THESE SCRIPTS AT YOUR OWN RISK - ALWAYS TEST BEFORE DEPLOYING!

These CREATE VIEW Oracle PLSQL scripts have been extracted from within Threads on this Forum. The purpose of each is defined by the View Name. They are intended to assist in producing BI/MI reports and/or Outputs. Each Script must be run separately on the Genesys cfg Database for them to create a “live” View of the parameters described;

CREATE VIEW dbo.CFG_AGENT_GROUPS AS
SELECT DISTINCT CFG_PERSON.FIRST_NAME,
CFG_PERSON.LAST_NAME,
CFG_PERSON.USER_NAME,
CFG_PERSON.EMPLOYEE_ID,
CFG_GROUP.NAME AS “AGENT GROUP NAME”
FROM CFG_AGENT_GROUP
INNER JOIN CFG_PERSON
ON CFG_AGENT_GROUP.AGENT_DBID = CFG_PERSON.DBID
INNER JOIN CFG_GROUP
ON CFG_AGENT_GROUP.GROUP_DBID = CFG_GROUP.DBID

CREATE VIEW dbo.CFG_AGENT_LOGINID AS
SELECT CFG_PERSON.FIRST_NAME,
CFG_PERSON.LAST_NAME,
CFG_PERSON.USER_NAME,
CFG_PERSON.EMPLOYEE_ID,
CFG_AGENT_LOGIN.LOGIN_CODE
FROM CFG_PERSON
INNER JOIN CFG_LOGIN_INFO
ON CFG_PERSON.DBID = CFG_LOGIN_INFO.PERSON_DBID
INNER JOIN CFG_AGENT_LOGIN
ON CFG_LOGIN_INFO.AGENT_LOGIN_DBID = CFG_AGENT_LOGIN.DBID

CREATE VIEW dbo.CFG_AGENT_SKILLS_AND_LEVELS AS
SELECT CFG_PERSON.FIRST_NAME,
CFG_PERSON.LAST_NAME,
CFG_PERSON.USER_NAME,
CFG_PERSON.EMPLOYEE_ID,
CFG_SKILL.NAME,
CFG_SKILL_LEVEL.LEVEL_
FROM CFG_PERSON
INNER JOIN CFG_SKILL_LEVEL
ON CFG_PERSON.DBID = CFG_SKILL_LEVEL.PERSON_DBID
INNER JOIN CFG_SKILL
ON CFG_SKILL_LEVEL.SKILL_DBID = CFG_SKILL.DBID

CREATE VIEW dbo.CFG_AGENT_SWITCH AS
SELECT CFG_AGENT_LOGIN.LOGIN_CODE,
CFG_PERSON.FIRST_NAME,
CFG_PERSON.LAST_NAME,
CFG_PERSON.EMPLOYEE_ID,
CFG_PERSON.USER_NAME,
CFG_SWITCH.NAME
FROM CFG_AGENT_LOGIN
INNER JOIN CFG_LOGIN_INFO
ON CFG_LOGIN_INFO.AGENT_LOGIN_DBID = CFG_AGENT_LOGIN.DBID
INNER JOIN CFG_PERSON
ON CFG_LOGIN_INFO.PERSON_DBID = CFG_PERSON.DBID
INNER JOIN CFG_SWITCH
ON CFG_AGENT_LOGIN.SWITCH_DBID = CFG_SWITCH.DBID

CREATE VIEW dbo.CFG_APPLICATION_ADDP_PARAMETERS AS
SELECT
HST.NAME AS “HOST”,
APPFROM.NAME AS “APPLICATION”,
APPTO.NAME AS “CONNECTS TO”,
CON.CONN_PROTOCOL AS “PROTOCOL”,
CON.TIMOUT_LOCAL AS “LOCAL T/O”,
CON.TIMOUT_REMOTE AS “REMOTE T/O”,
LC.LC_VALUE AS “TRACE MODE”
FROM CFG_APPLICATION APPFROM
INNER JOIN CFG_APP_SERVER CON
ON APPFROM.DBID = CON.APP_DBID
INNER JOIN CFG_APPLICATION APPTO
ON CON.APP_SERVER_DBID = APPTO.DBID
INNER JOIN CFG_SERVER SRV
ON SRV.APP_DBID = APPFROM.DBID
INNER JOIN CFG_HOST HST
ON SRV.HOST_DBID = HST.DBID
INNER JOIN CFG_LOCALE LC
ON CON.MODE_ = LC.LC_SUBTYPE
WHERE LC.LC_CLASS = 8 AND LC.LC_TYPE = 30

CREATE VIEW dbo.CFG_APPLICATION_CONNECTIONS AS
SELECT APP.NAME AS APPLICATION,
APP_CONNECTIONS((SELECT DISTINCT ‘’ + APP2.NAME + ‘, ’
FROM CFG_APPLICATION APP2, CFG_APP_SERVER CFG
WHERE CFG.APP_SERVER_DBID = APP2.DBID
AND CFG.APP_DBID=APP.DBID
FOR XML PATH(’‘), TYPE
).VALUE(’.‘, ‘NVARCHAR(MAX)’)
,1,0,’') CONNECTIONS
FROM CFG_APPLICATION APP
GROUP BY APP.NAME, APP.DBID

CREATE VIEW dbo.CFG_APPLICATION_HOSTS AS
SELECT DISTINCT CFG_APPLICATION.NAME AS “APPLICATION NAME”,
CFG_HOST.NAME AS “HOST NAME”,
CFG_SERVER.PORT,
CFG_HOST.IP_ADDRESS
FROM CFG_APPLICATION
INNER JOIN CFG_SERVER
ON CFG_APPLICATION.DBID = CFG_SERVER.APP_DBID
INNER JOIN CFG_HOST
ON CFG_SERVER.HOST_DBID = CFG_HOST.DBID

CREATE VIEW dbo.CFG_APPLICATION_OPTIONS AS
SELECT DISTINCT CFG_APPLICATION.NAME AS “APPLICATION NAME”,
CFG_HOST.NAME AS “HOST NAME”,
CFG_SERVER.PORT,
CFG_HOST.IP_ADDRESS,
CFG_APP_OPTION.OPT AS OPTIONS
FROM CFG_APPLICATION
INNER JOIN CFG_SERVER
ON CFG_APPLICATION.DBID = CFG_SERVER.APP_DBID
INNER JOIN CFG_HOST
ON CFG_SERVER.HOST_DBID = CFG_HOST.DBID
INNER JOIN CFG_APP_OPTION
ON CFG_APP_OPTION.OBJECT_DBID = CFG_APPLICATION.DBID

CREATE VIEW dbo.CFG_APPLICATION_STARTUP_PARAMETERS AS
SELECT
CFG_HOST.NAME AS “HOST”,
CFG_HOST.IP_ADDRESS AS “IP”,
CFG_APPLICATION.NAME AS “APP”,
CFG_APP_TENANT.TENANT_DBID AS “TENANT”,
CFG_APPLICATION.VERSION AS “VERSION”,
CFG_SERVER.PORT AS “PORT”,
CFG_APPLICATION.WORK_DIRECTORY AS “PATH”,
CFG_APPLICATION.COMMAND_LINE AS “COMMAND LINE”,
CFG_APPLICATION.CMD_LINE_ARGS AS “ARGUMENTS”,
CASE CFG_APPLICATION.AUTO_RESTART
WHEN 1 THEN ‘NO’
WHEN 2 THEN ‘YES’
ELSE ‘UNKNOWN’
END AS “AUTO-RESTART”,
CFG_APPLICATION.STARTUP_TIMEOUT AS “STARTUP TIMEOUT”,
CASE (
SELECT LOWER (PROP_VALUE)
FROM CFG_FLEX_PROP
WHERE PROP_NAME = ‘AUTOSTART’
AND OBJECT_DBID = CFG_APPLICATION.DBID
AND OBJECT_TYPE = 9) – CFGOBJECTTYPE APPLICATION
WHEN ‘TRUE’ THEN ‘TRUE’
WHEN ‘FALSE’ THEN ‘FALSE’
ELSE ‘NULL’
END AS “AUTOSTART”
FROM CFG_APPLICATION
INNER JOIN CFG_APP_TENANT ON CFG_APPLICATION.DBID = CFG_APP_TENANT.APP_DBID
INNER JOIN CFG_SERVER ON CFG_APPLICATION.DBID = CFG_SERVER.APP_DBID
INNER JOIN CFG_HOST ON CFG_SERVER.HOST_DBID = CFG_HOST.DBID

CREATE VIEW dbo.CFG_SCS_ALARM_CONDITIONS AS
SELECT DISTINCT CFG_ALARM_CONDTN.NAME AS “ALARM CONDITION NAME”,
CFG_ALARM_CONDTN.DESCRIPTION,
CFG_ALARM_CONDTN.CATEGORY,
CFG_ALARM_CONDTN.CLEARANCE_TIMEOUT,
CFG_ALARM_CONDTN.STATE
FROM CFG_ALARM_CONDTN

CREATE VIEW dbo.CFG_SWITCH_INTERCONNECTIVITY AS
SELECT DISTINCT CFG_SWITCH_ACCESS.FROM_SWITCH_DBID AS “FROM SWITCH”,
CFG_SWITCH_ACCESS.TO_SWITCH_DBID AS “TO SWITCH”,
CFG_SWITCH_ACCESS.ACCESS_CODE,
CFG_SWITCH1.NAME AS “FROM SWITCH NAME”,
CFG_SWITCH.NAME AS “TO SWITCH NAME”,
CFG_PHYS_SWITCH1.NAME AS “TO PHYSICAL SWITCH NAME”,
CFG_PHYS_SWITCH.NAME AS “FROM PHYSICAL SWITCH NAME”
FROM CFG_SWITCH_ACCESS
INNER JOIN CFG_SWITCH
ON CFG_SWITCH_ACCESS.FROM_SWITCH_DBID = CFG_SWITCH.DBID
INNER JOIN CFG_PHYS_SWITCH
ON CFG_SWITCH.PHYS_SWITCH_DBID = CFG_PHYS_SWITCH.DBID
INNER JOIN CFG_SWITCH CFG_SWITCH1
ON CFG_SWITCH_ACCESS.TO_SWITCH_DBID = CFG_SWITCH1.DBID
INNER JOIN CFG_PHYS_SWITCH CFG_PHYS_SWITCH1
ON CFG_SWITCH1.PHYS_SWITCH_DBID = CFG_PHYS_SWITCH1.DBID

What else can you do to automate processes in a Contact Center?

There have been many, many studies relating to the time and effort applied to simple, repeated tasks in the workplace, in an effort to optimize or automate them. It’s nothing new - it’s been going on since the industrial revolution began. How to optimize, what to automate, where to augment, how to reduce costs - what can be made better, faster or more cost effective? All of them standard, basic questions and more complex equations and systems to make tasks more efficient.

In a Contact Center environment, things are no different. As time passes new technologies, products, processes and work flows tend to homogenize tasks which are recognized as standard and repetitious. After a period of trial (and error!) using existing tools, more specialized (local) systems tend to be developed in niche areas, catering for specific automation tasks. This is precisely how the local telephony switch (PBX) was born. And automated call distribution (ACD). And Computer Telephony Integration (CTI). And the IVR. And Workforce Management. And Workflow Management. And integrated CRM Solutions. Well - you get the idea…

Sometimes it’s a no-brainer and it’s obvious where automation fits. Usually, even with the simplest of processes in place, additions are straightforward to implement. Agent Scripting is a good example of this; if a new product or service is introduced, part of the process for launch would be a new set of scripts for Agents to be able to support the product. Easy. But is that all you need to do? No. No, it isn’t.

The implementation of any automated process or augmentation system is only the first step in getting things optimized. It’s the “vehicle for success” - but it isn’t a map. It doesn’t indicate what training might be required, where bottle-necks are - and it can’t provide advice about what doesn’t work. That requires another level of monitoring and management - and a lot of questions;

• Are staff fully conversant with the processes and products in their remit? How do you know? How can you find out?

• Are your automation processes still fit for purpose? How do you know? How can you find out?

• Are your standard workflow processes efficient? How do you know? How can you find out?

• What level of feedback do you get from the staff who use automation or workflow processes or the information being automatically provided?

• What is your process for improvement?

• Who is responsible for process improvements within your organization?

• What tools exist in the marketplace to further optimize local processes?

• If you can’t answer some of these questions using your current processes, perhaps it’s time to review how your automation and optimization techniques are working!

As general pointers, here’s a few areas of automation that you may not have already considered, for your Contact Center;

• IVR Pass-Back Services: this involves a Voice Agent reaching a point in a conversation where information needs to be very succinct and very accurately repeated to a caller. It may be a regulatory requirement or warranty advice or perhaps even a service authority requirement. Rather than the Agent reading back information from on-screen prompts, they call/consult an IVR script, which reads to script to the caller, gains acceptance or understanding from them, records it and then passes the caller back to the Agent.
• Orchestration Services: this is the means to be able to (re-)use the same basic information and processes, across different types of interactions. You’d be surprised how many Contact Centers operate voice, multimedia, sms and social media independently by using totally separate teams of Agents. Not orchestrating those types of services means duplicating many of the workflows that surround them - and that is bad for business!
• Reason Codes: a lot can be learnt from collecting post-interaction information. Comparing a service that was accepted (for example through IVR digits) with the result of the interaction (through post-call Reason Codes) goes a long way to explaining what might be wrong with your processes. Knowing this can also indicate where to optimize not only staff processes - but technology processes, too.

Of course a lot depends on the business you are in - and just how much of your internal processing can be combined and optimized, without rocking the proverbial apple cart…

Harnessing the Real Power of Dynamic Routing

Not heard of Dynamic Business Rules? Never used VXML? Don’t know what a Data Dip is? Weren’t aware that you can empower authorized personnel to make changes to call and multimedia routing and your IVR on-the-fly? Don’t worry - you’re not alone…

Most days - and most of the time - static rules are great for interaction routing and IVR’s. The appliance of IF…THEN statements (“if this happens… then do this…”) are a mainstay of operations - and it works 99% of the time. But what about the other 1%? What about when things are not going according to plan? When your workforce is snowed-out by a blizzard - or there’s been a flu bug in the contact center - or your CRM system is off-line? What then..?

Thankfully, there are ways to program pre-set elements into your routing to counteract “Force Majeure” - and things not quite so epic!

In the simplest terms; Genesys core routing has the means to “look-up” data fields in other locations and act upon them. This opens the possibilities for authorized members of your workforce to make significant adjustments to the way in which both your routing and your IVR operate. For example;

Your normal working parameters are to have a standard greeting in your IVR. You can set up a business rule which dynamically replaces that announcement with a different announcement if there are a high number of calls. In this way, your announcement automatically switches to inform callers of high call volumes - and possible extended wait times - and a suggestion that they may want to try again, later. But it’s not the only way the announcement can be invoked. If a supervisor is aware of a forthcoming reduction in the resources available (for unplanned breaks, meetings, a fire drill etc.) it is possible to allow them to determine when the high call volumes announcement should be played, by updating information which is external to Genesys routing. It doesn’t have to be rocket science, either; a standard lookup in the Routing and a simple plain text file update can make all the difference.

Here’s a few examples of how and why this type of dynamic routing could be integrated;

LOAD BALANCING

…is where a percentage of calls are distributed across geographically separated contact centers. Local updates to a dynamic lookup by authorized personnel - outside of Genesys - can change this ratio.

SLAKPI (“Slack-Pie”)

…where a given SLA or KPI is “hard-coded” in the DNA of routing. Again, a simple update - outside of Genesys - can change this dynamic.

THROTTLING

…the “conveyor belt” of incoming interactions can be managed locally, using the same basic tools.

IVR MENUS

…means having the ability to (temporarily) remove or replace/update IVR menu options and announcements using the same methods.

But that’s a lot of power to give local resources, isn’t it? Not really - these on-the-fly changes can be reset by routing rules, too. With the right application, resource-powered changes to routing and IVR options can be given a time limit. So, a change made by authorized staff using this method can be reset after 15 minutes - or an hour - or for however long you decide!

Meta Data for Agents = AIM

Recently I have heard a lot of noise about “meta” in the media. Usually in relation to an “amazing fourth wall break” in a movie (Dead Pool - I’m looking at you…) - or an Easter egg hidden away in a scene - or an external reference in a videogame. But meta has been around a very long time indeed - in fact, it’s the lifeblood of a contact center. Aside from the verbal conversations and CRM interactions, everything else is meta. Key Performance Indicators? Meta. Service Level Statistics? Meta. Customer Satisfaction? Meta. But why stop there?

At the coalface of every interpersonal interaction is a resource with almost no meta. The Agent. Performing tasks almost perfunctorily, an Agent becomes a part of the whole - a series of metrics. Average Speed of Answer, Average Talk Time, After Call Work Time, SLA’s, KPI’s, Skills, Break Times, Shifts… but aren’t they worth a little more than that? Even your customers have a “voice” - what about your Agents? So - how about we step this up a bit? How about getting more from your Agents by giving them more of a voice - more meta? Let’s give it a name - since 3-letter abbreviations are all the rage in IT - how about “Agent Interaction Meta” (AIM)

So - AIM, then - is a concept of metadata providing metrics and measures which can be presented and collected by Agents during a call or interaction - or in a Wrap-Up Mode or “After Call Work” (ACW). These new AIM meta metrics can be developed into the Agents desktop interface and stored, along with other CRM data, for future use.

But - why the heck are AIM metrics useful to a business, Adam…?

Glad you asked!

OK - here’s some very basic examples of how our newly-formed AIM metrics can support business scenarios, leading to better interactions - better service - and better business;

For Customer Services, it would be feasible for an Agent to record AIM metrics to make some decisions and record re-usable meta information about;

…a caller’s natural language - or “mother tongue”, which can be saved for future interactions with the caller…
…a caller’s propensity for future marketing and/or sales with a simple 0-5 scale…
…a caller’s wants and needs, beyond the services being provided through a maximum of 140-character text box on the Agents screen (Tweet if you see where I got that one from… )…

For a Tech Support line; it might be beneficial to interpret the relative understanding - and/or relative patience - of the customer, through meta information completed by the Agent. An AIM metric applied to a previous interaction with the caller would indicate if they were particularly knowledgeable or technically minded. On the next interaction with the caller - and on the basis of that scoring - you can avoid matching a trainee with the “wrong type of caller…” (worst case scenario - but it happens a lot!)

These are just a few ideas off the top of my head - every item will be particular to your own line of business - and related to what you find important to know about your customers. What’s important to remember is that an Agent has a lot more insights which could be nurtured and extracted through the correct appliance of meta data collection. And giving your workforce a new voice, actively supporting your business goals must be a good thing, right?

Why not give it a try? You never know, it might just work if you AIM high enough!