Expected Wait Time

[robm44]

Hello,
I was wondering if I can get clarification on EWT. Is there a way to put the EWT before being queued to a skillset or does it have to come after the QUEUE TO SKILLSET command? I am trying to find a way to do this so that in the event the caller decides to hang up, it doesn't count as abandoned.
Also wondering about any feedback about using CP to playback EWT by number as opposed to predined RANs.
thanks!

 

[nortelinsd]

This is one of those "can't get the horse in-front of the cart" things, were in you cannot give the caller an EWT until the call has been presented to the queue.

 

[Milesprower]

While it is recommended to queue the call before playing EWT, I know of no reason why you couldn't. It is poor practice to play wait time before queuing the call as the call is not included in the EWT calculation.

I do not recommend playing the exact number from Call Pilot as the EWT calculation is based on the last 10 minutes and it is an approximation. In other words, no wait time is exactly 2 minutes and 35 seconds. It is better to play a more general announcement, such as, "Your call is expected to be answered within 3 minutes".

 

[x11tech]

Milesprower is correct. You can give EWT and you can make call routing decisions based on EWT, but you cannot get an exact time out of EWT and it's a bad idea to give callers an exact time value.

EXPECTED WAIT TIME
The EXPECTED WAIT TIME is the predicted wait time of the current contact
in the given skillset at the moment the intrinsic is executed. This value can
change over time, depending on contact traffic. This intrinsic is calculated by the
contact processing executor using real-time data. If the contact is not yet in the
skillset indicated, an average expected wait time for the skillset is returned.
If you specify a skillset list, then the returned value is the minimum EXPECTED
WAIT TIME of all the skillsets.
The purpose of the EXPECTED WAIT TIME intrinsic is to estimate, based on
historical information, how long it can take for the current contact to be
answered by a particular skillset. This information can then be used to announce
to the contact how long the wait can be before being answered, or it can provide
a different treatment to the contact. This intrinsic applies to both voice and
multimedia contacts.
Tip: Use this intrinsic to play the expected wait time to voice contacts only if the
wait is unusually long for your contact center. For example, if the normal wait
time for your contact center is two minutes, but a burst of traffic increased the
wait time to five minutes, use this intrinsic to warn voice contacts of the long
wait. Give the caller options at this point (for example, the choice of leaving a
message or continuing to wait).

Also, if you try to do any "do not queue until age of call greater than X" evaluations because of EWT, you should consider what happens if an agent is idle while the caller is not queued.

Example:

  SECTION loop

  IF OUT OF SERVICE skillset_a THEN
    ROUTE TO 3000
    /* or whatever you want to do if the
     * caller reaches an application that is
     * out of service.
     */
  ELSE
    IF EXPECTED WAIT TIME skillset_a > 120 THEN
      IF IDLE AGENT COUNT skillset_a > 0 THEN
        /* Just in case the EWT is wrong... */
        QUEUE TO SKILLSET skillset_a
        WAIT 2
      END IF
      /* if no agents idle and the wait time is
       * greater than 2 minutes, we don't queue
       */
    ELSE
      /* if the expected wait time is < 2 minutes
       * then let's go ahead and queue as someone
       * will get to them quickly enough
       */
      QUEUE TO SKILLSET skillset_a
      WAIT 2
    END IF
  END IF

  /* if they can't be presented to an agent, play
   * the ran
   */  
  GIVE RAN 10
  /* then wait 30 seconds and start all over */
  WAIT 30

  EXECUTE loop

And also consider the impact this will have to your historical reports. While this will ensure that every caller that is evaluated while an agent is idle will be queued to the skillset, there may be other interactions within your environment that I cannot predict.

Use at your own risk. Your milage may vary.

 

[captaingadget]

It's up to you where you put the EWT intrinsic. If you put it before a the queue to skillset command it will not take the current call into account, only the current calls queueing. That's why the recommendation is to queue the call first to get a more accurate value.

 

[robm44]

Thanks everyone! All solid information. Basically, i am trying to get the EWT put in without increasing the abandon. Apart from giving callers an option to route out, can you see another way?
once again, thanks in advance.

 

[x11tech]

Your historical data at the skillset level will be negatively impacted by not queuing the call to the skillset. So what you should do depends both on the mandates of business and the reporting needs of the management team.

Not knowing anything about your business mandates, if I were in your shoes I would do the following:

I would set the service level threshold on the skillset so that any call that abandons within the time period of half (or a quarter, or whatever value seems appropriate to you) the average wait time for your environment are not counted as abandons.

You can then avoid making any changes to the environment while still modifying the management values. If the callers do not wait a reasonable amount of time, you disregard their abandon. You can then use the CallsAbandonedAftThreshold value in your historical reports to determine those calls that abandoned after your service level threshold.

Service Level Threshold is the value you set for the "all calls must be answered within X time frame" and if the caller does not wait at least that long, then you disregard the fact that they abandoned. (Usually people say something like "answer 80% of the calls within 20 seconds", 20 seconds is your service level threshold, you then perform math on callsanswered vs calls answered after theshold to arrive at the % of calls that were answered within the threshold) Note: This could have an impact on other reports if you already use Service Level thresholds elsewhere.


If some scripting was required by the business mandate to offer callers the ability to leave a voicemail instead of waiting in the queue, I would code it as follows:

[ol]
[li]Check EWT[/li]
[li]if higher than the average abandon time[/li]
[ol]
[li]Offer callers the ability to leave a voicemail[/li]
[/ol]
[li]else if less than or equal to average abandon time[/li]
[ol]
[li]Queue caller[/li]
[/ol]
[li]Loop caller while monitoring age[/li]
[li]If caller has waited more than X minutes minus 2 minutes (where X is the average abandon time) then[/li]
[ol]
[li]Offer callers the ability to leave a voicemail every minute till they are answered or abandon[/li]
[/ol]
[li]Continue looping while monitoring age[/li]
[/ol]


I would argue against not queuing calls ASAP and instead letting them hang in limbo within an application. Doing that causes an enforced delay in agent presentation to callers (since in the code example I gave above, if an agent was available 2 seconds in to the WAIT 30 command, a caller still would not be presented for another 28 seconds.)