Can CVP be modified to initiate a call back sooner/later based on agent availibility?

We are a small call center environment and sometimes we will have a long EWT that will shorten considerably as a shift starts or employees return from a lunch/break/meeting.  We will then have agents available and calls in queue.  Conversely, there are times the EWT is off, or a shift ends/agents leave for lunch or break and call backs will be generated based on the original EWT; the caller will be on hold for several minutes before an agent becomes available.

We'd like to be able to configure the system to avoid these situations.

Thanks.

Well, it 'can' be done. But, it should only be tried by someone very

skilled in Studio.

One of my former students used the ReqIcmLabel element to query ICM for

readyAgents (you could pass a skill group name in the ReqIcmLabel

element, if necessary). ICM can assign something into a PV, and that

info goes back to the Studio app.

The Studio app can then check the returned data, and if there are ready

agents, you could bypass the wait loop and

go to the part of the CCB script that starts the callback.

You'd have to change the _dnis to match a dnis for an ICM script that

knows that you're querying for readyAgents.

You'd also need to know how to modify the CCB scripts.

Thank you for the response.  We have noticed that when we have a lot of callers waiting for call back (for example, we had 90 waiting for call back and a total of 110 in queue), those that choose to hold will get answered well in advance of the announced wait time.

Do you have any anecdotal information regarding how customers react to call backs that come earlier or later than the expected time?

Thank you!

Sheri Browning  |  IT/Telecommunications

Support Team Manager

California Casualty Management Company

p: 650.572.4275 f: 650.294.8340

e: sbrowning@calcas.com<mailto:sbrowning@calcas.com>

I had personal experience with CCB when my father was hospitalized and I

was calling into Social Security, Medicaid, etc.

The EWTs were in the range of 30-50 minutes (different' wait times,

different days).

As a caller, I was THRILLED to be offered a callback and not to have to

sit on hold for 45 minutes.

I, personally, didn't time the call back. If it came after 35-55

minutes, it didn't matter too much to me, I was doing other things.

I guess I would've gotten upset if it hadn't come within 60 minutes.

That's just one person's opinion. Perhaps other partners can weigh in...

Janine,

I agree from a customer perspective, no issue with waiting. I think this is more an issue with Agents been available to take calls, i.e. contact centre not been optimally utilized (and then new inbound calls could then add more calls to queue, before callbacks take place).

As an aside, do you have a sample ICM Req Label CVP & ICM Script?

I don't believe there is one on the CVP sample scripts (Last time I looked).

Gerry

1. From Studio , use a ReqIcmLabel node and enter into its Settings tab

the data you want to send into ICM's PVs.

For example:

Callvar1:  ewt

Callvar2:  billing   (queue name)

2. This will send an API call to ICM, where it comes in as a NewCall

based on the DNIS.

I'll call this script the *EWT_ICM *script.

3. The EWT_ICM script's PVs are now set to whatever was configured in

the Studio app's ReqIcmLabel settings.

For example:

PV1:  ewt

PV2:  billing

4. The EWT_ICM script examines the PVs to know what's being requested

(EWT for the billing Skill Group).

ICM can determine the ewt, or check if agents ready greater than 0.

It assigns data into the PVs (example, PV1 = '600'  or PV3='0' (number

of agents ready))

The EWT_ICM script exits back to VXML Server with a Label node. But you

can configured it as Dynamic Label, and assign any string value you like.

5. The Studio app goes down the 'done' exit state of the ReqIcmLabel node.

And all the PV values are Element data for the ReqIcmLabel node, named

callvarReturn1,2,...10

The ICM *Label node's *value is stored into Element data named result.

6. Here's the 'trick' to make it all work - in the original ICM script

that sends the caller into the VXMLServer app (where you assign

something like, "application=MyApp") you have to override the _dnis

that's sent to VXMLServer.

Because the _dnis becomes the CallData.DNIS and that's what selects the

ICM Script to run when using the ReqIcmLabel node.

So, if you also need the real dnis sent to VXMLServer, then you'll have

to do the following in ICM:

Set ToExtVXML[0] to

concatenate("application=MyApp;_dnis=ReqLabel_DN;dnis=",Call.DialedNumberString)

This way, you get the Session variable named dnis with the true dnis.

You also get the CallData.DNIS set to the string "ReqLabel_DN" - and

then you schedule the EWT_ICM script to run based upon this (obviously

fake) dnis.

Janine,

Thank you so much. Really well explained. Love it!

Gerry

So I am going to try and answer this in two parts as you pose two different scenarios.

First off is the scenario  where you have agents come into the call center after calls have been disconnected and are awaiting callbacks. You can solve for this issue as Janine pointed out by using the ICMRequestLabel element in CVP Studio. To use this you will have to provide the ICM with a new DNIS and you would have to create and ICM routing script to handle this request and return the information you need. You would then send the call into the Callback portion of the script. I do have to caution on this as there is no way for any of the running scripts to know about each other. So if you have 20 CCBs out there, and you log in 2 agents, you may very well initiate all 20 callbacks before you ever get to one of your agents that is newly available.

Second issue is where you have calls in Queue that did not qualify for CCB and a bunch of agents leave, as a result EWT for the call increases. This one is a bit trickier as the call is already in the CCBServelt and being tracked. The CCBServlet does keep track of the running EWT as long as calls continue to Queue. I would try resubmitting the call into the Validate elements when the EWT is spiking and see if it offers CCB. Of course you would have to at first do an ICMRequestlabel to get an updated EWT for testing to know when to break the cycle and send it to a Validate step.  I will have to do some testing and see if the Running EWT is available anywhere outside the CCBServlet, this is the EWT that you want to feed back into the Validate element.

Thank you.

Sheri Browning  |  IT/Telecommunications

Support Team Manager

California Casualty Management Company

p: 650.572.4275 f: 650.294.8340

e: sbrowning@calcas.com<mailto:sbrowning@calcas.com>