MUG Newsletter: October 2019 Issue

A few selected articles from the October 2019 issue are presented on this page. To read the full issue, click the button below. Back issues can be found in the Archive box at right.

Read Full Issue

5 Metrics for Success When Deploying AI in Your Contact Center

Nemertes’ 2019-20 Intelligent Customer Engagement research study of 518 companies analyzed which AI-enabled technologies correlated with the most success for companies of all sizes and industries. This webinar recording describes the technologies, interaction channels, architecture, and organizational best practices successful companies have embraced.

Presenters:   Robin Gareiss, President and Founder, Nemertes Research, and George Despinic, Senior Product Marketing Manager – Contact Center, Mitel.

Watch Webinar

 

 

From the MiContact Center Tip Desk

by Patrick McDowell, MiCC Customer Advocate

Using IVR logic to re-route calls

I was asked recently if the IVR system would be able to redirect a specific percentage of calls, be they inbound ACD calls or callbacks, to an alternate destination. I set about designing a subroutine in my lab system to see how tricky this could be. Turns out, not too tricky.  We’re going to get a bit technical here, but nothing over the top.

This is how I did it with voice calls to queue. When a user selects option 4 in my menu, I set TransferDN=3001, then I invoke this subroutine:

The first query counts the number of times calls have hit a particular IVR branch today. In my case, that branch is named 'Option 4'. I had to create a SQL Data provider pointing to my CCMData database and use this query:

select count(BranchFriendlyName)
from [dbo].[tblData_VWM_ConditionTrace]
where BranchFriendlyName = 'Option 4' and DateKey = CONVERT(int,CONVERT(varchar,GetDate(),112))

This query will return 0  if this is the first call of the day and a 0 used as input for the next query will result in a re-routed call. I didn't want the first call to re-route so I put in that little bit of logic to change 0 to 1.
The second query is using a MOD operator (in SQL MOD is represented by %) to see if the counted number of calls from query 1 is evenly divisible by 5.  We are essentially doing this mathematical operation: Input mod 5 = output. A zero result means the offered calls is evenly divisible by 5, so this means it is call #5, or call #10, or call #15 ...etc and we reset TransferDN from being 3001 to now being 1360 to re-route that call.
When this subroutine is finished, the next subroutine my workflow calls is TransferCaller which, just as the name implies, transfers the call - to TransferDN. In this example, TransferDN will be either 3001 or 1360, depending on what number call this is to the branch today.

If any of the query logic fails, then no re-routing happens so this is a fail-safe design. You could easily adapt this design to be dynamic (ie, being able to look for more than a single branch name so you could use this subroutine in multiple places), you can change the % of calls to re-route (as long as it is evenly divisible into 100 with no remainder Mod 2 = 50%, Mod 4 = 25%, Mod 5 = 20%, Mod 10 = 10%) and it is portable to any conversation type that is tracked in the Branch table.

Something that sounded challenging at the outset turns out to be relatively simple to accomplish with the power and flexibility of the MiCC IVR toolbox. I encourage you to explore the powerful features of the MiCC IVR and take a look at places in your own Contact Center where with some more intelligent routing, or self-serve options, or whatever you dream up can help deliver a superior experience for your customers.