cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1782
Views
5
Helpful
12
Replies

CUIC (PCCE) Abandoned Within Service Level not matching

will.alvord
Level 5
Level 5

PCCE v9.0.3

CUIC v9.1.1

Service Level Threshold: 60

Service Level Type: Abandoned Calls have Negative Impact

Bucket Intervals: 60, 120, 180, 240, 300, 360, 420, 480, 540

 

Shouldn't the Abandoned Within Service Level (ServiceLevelAband) = the Abandoned Within Interval 1 (AbandInterval1) since the SL and Interval1 are the same?

 

thanks,

will

12 Replies 12

Will,

Yes, those two figures should be the same in this case. What behavior are you seeing? Can you give a specific example?

-Jameson

-Jameson

The ServiceLevelAband is always higher than AbandInterval1. Attached is a screenshot. Can't figure it out. Any thoughts on what could cause this?

 

thanks,

will

Will,

I would double-check the SL Threshold and Buckets. I can't think of any way that your ServiceLevelAband would be higher than AbandInterval1 unless your SL Threshold is longer than the first Bucket interval.

Did you change your buckets or threshold recently? Don't forget that such a change is not retroactive... only calls that occur after the change will be recorded under the new buckets and threshold.

-Jameson

-Jameson

No recent changes. Attached is a screenshot of the bucket interval and call type in case I'm missing something.

Hmm... I admit I'm a bit stumped. I assume you've tried a few different DateTime ranges and see the same thing everywhere?

-Jameson

-Jameson

Yes sir - although the variance changes. Guess I'll keep digging. ...and scratching my head.

 

thanks,

will

Hi

 

We are using PCCE 10.0.1. I woudl like to see a report that shows all the CLID's that were abandoned. Could you please point me to a relevant template that can report this

Prakashar, this is not the right thread to ask that question, please start a new thread when your topic does not match the topic you're replying to.

You will likely not find a free template with the information you're looking for. If you have a CUIC Premium or Lab install, you can develop your own, otherwise you will likely need to contract a 3rd party to develop such a report for you.

-Jameson

-Jameson

Hello,

Did you make it to find what was the issue, I have the exact same problem.

 

Thanks

 

Jorge

I honestly don't remember and can't seem to find anything definitive in my notes. If I find something, I'll be sure to post it.

could it have anything to do with call arrival patterns? for example, if a call comes in at 1:30:45, and abandons at 1:31:32, the interval it abandons in would be a different interval than say one that abandoned at 1:30:49.

if many cx abandon after 45 seconds, your sl abandon would be higher than interval because your sl is 60 sec. if it was 20 seconds, you should see these numbers aligned more closely.

i think :)

Debra,

Both "ServiceLevelAband" and "AbandInterval1" should both get incremented at the same time, so your suggestion wouldn't make them be different. (Also, 1:30 and 1:31 are in the same interval by the way)  It certainly makes sense for events that are recorded at different times to be different across interval boundaries (CallsOffered and ServiceLevelOffered, for example), but that should not be the case with the various Abandon statistics.

Here's my train of thought on this:

  • If the "AbandInterval" stats didn't include "Abandon Rings", that could cause this. However, comparing "TotalCallsAband" to the total of AbandInterval1 through 10 disproves this.
  • If "ServiceLevelAband" included Short Calls and "AbandInterval1" didn't, that could cause this. However, the DB Schema description for Short Calls confirms this is not the case.

The key here is that we're looking for an event where a caller can somehow abandon within the Service Level threshold of 60 seconds, but outside of the 60 second bucket interval. And do it quite regularly. Seems quite impossible to me, but it has somehow happened in Wil's environment.

I suppose my next steps in a situation like this would be to review the scripting and make sure there aren't any strange scenarios at play there.

-Jameson

-Jameson