Recalls from ACD-agents to OWS 2

[nschreuder]

Hi all,

We have the problem that calls transferred by OWS to ACD-group don't fall back to the originating OWS at No Answer.
Any ideas how to solve this?

We have BC12 SP11 and DNA5.2 SP4

Thank you for coöperation.

 

[patcher]

If the call goes to ACD queue, thats it. The call will go nowhere. The call will stay in the queue. Thats the way it was designed. Else you will have lots of abandoned calls. Cheers...

 

[whosrdaddy]

nccoi, make sure you have an overflow position on your ACD group (CDINI...) and set ACPAC ACDNUM 7 to 1

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[nschreuder]

To patcher:
I do not agree. Before upgrading to SP 10 it worked the way i described. The caller kept his place in the queue while talking to the operator. (When the ACD-member would answer in exactly that moment, it would be a short moment of conference.) So they are not abandoned calls because these callers don't hang up.

To daddy:
CDINI is i.m.h.o. not usefull in this case. We have CCM so the operator can see the queue, so there is no unnecessary, superfluous transfer. And about acdnum 7: yes, acdval=1

 

[patcher]

NCCOI's original scenario:
calls transferred by OWS to ACD-group don't fall back to the originating OWS at No Answer.

NCCOI's latest scenario:
The caller kept his place in the queue while talking to the operator.

These two scenarios are not the same if you know how the software waorks.

I cant help you if you will not listen....

Cheers...

 

[nschreuder]

Well, i will listen because it's my problem.
It seems obvious that i wasn't clear.

What you call my latest scenario was the first, so: before upgrading to SP10.
What you call original scenario was the latest, so: after upgrading to SP10.

 

[whosrdaddy]

so what you are really referring to is call rerouting?

If the ACD group is used the way it should be (ie agents that are not there must set their position unavailable) you shouldn't be facing this type of problem...

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[nschreuder]

I try again to be clear:

Imagine: you call, let's say, a hospital because you need a doctor. Your call is answerred by an operator who transferred you to the doctor's nurse (ACD). The nurse is very busy at that moment (she's the only one available in the ACD) and not able to answer your call immediately. So, after a while, you get the operator on the phone again who's asking you if you want to wait any longer or maybe you want to call back later.

This is the situation i'm talking about.
This is the situation we had before SP10 and what we want back again.

 

[patcher]

Most of the time after the upgrade, we think that its working before the upgrade but actually its not. The scenario you are telling us will not work even in older BC releases. "If the call goes to ACD group or queue, there is no way the call will be rerouted back to operator." The call will stay in the queue until agents answer it. If you try the same scenario to a normal extension the extended call will reroute to the operator after timeout of parnum 10 but not in the ACD group. Cheers...

 

[nschreuder]

Let me tell you this story (and it's not a fairytale):
In april 2005 i was with a collegue in Germany on an Ericsson course. I asked our trainer about our problem with the recalls from ACD-agents. He said he didn't have the answer but he sais he knew somebody inside Ericsson who probably has. During the lunch he contacted this man and when we were back in class i get the solution. He said (i quote):
"There is a bug in BC12 SP6. To solve the problem (till patch is available):
1. programm SERV of ACD agent twice
2. set ASPAC PARNUM=9 < then PARNUM=165
it's important to do it in this order. First the SERV and right after that the ASPAC."
After the course, back in office, i tried this solution at once and guess what: IT WORKED!

YES. It worked! Not "we think that its working". It worked! For more than a year!

Then came SP10 and it was gone again right away. Our traffic measurements prove it. The recalls to the operators (who handles this specific ACD-traffic) decreases with 80% from 1500 to 300 per week. It's really no thinking. The numbers tell us the same. I tried "the german solution" for SP10 but without success (it was obviously only for SP6).
So, we really have a problem ...!

I'm disappointed.
I thought we took each others problem serious and not accuse of imagination.

 

[fouesnant]

Hi NCCOI

Could you post all relevant data regarding your ACD configuration and ACD members configuration?

If I understand you well, the call goes via operator to ACD group and then the call is presented to an ACD position.
If the ACD position does not answer, then the CDINI or CDCOI diverstion should take the place and go back to the original Operator, right?

What will happen then to the ACD agent? Is its phone locked?
What will happen to the next call to the ACD group?

Best regards

 

[nschreuder]

Yes, you're right. And locking out and all that stuff that's working fine.

I ment "The nurse is very busy at that moment ..." that she was busy on the phone. (I'm sorry for the confusion)
The problem is the calls in the queue that doesn't fall back to the operator as i described 28 Jun 07 7:35

Below the printouts you asked for. I'll give you one number as example for all extensions and ACD-groups.
[tt]
<acgcp:grp=4151;
ACD GROUP CALL DATA
GRP LIM SERV TRAF SEL QUE QIC CUST SAT ACTC
4151 2 10000 15 01060 00000082501 NO 180

END

<acgmp:grp=4151;
ACD GROUP MEMBER DATA
GRP DIR PRI CLT
4151 1640 1 (I) 5
1645 1 5
1646 1 5
1647 1 5
1648 1 5
1649 1 5
1650 1 5
1658 1 5
1659 1 5
6880 1 5

END

<ksddp:dir=4114;
KEY SYSTEM DIRECTORY DATA
DIR CUST EQU CAT ADN ODN CALALT TIMER
4114 004-0-30-07 - 1 0
3 1648 1 -

END

<kscap:dir=4114;
KEY SYSTEM CATEGORY PRINT
DIR TRAF SERV CDIV ROC ITYPE TRM ADC LANG BSEC
4114 00040400 0202120000 100151000 000001 28 0 10010003000020 F 0

END

<kscap:dir=1648;
KEY SYSTEM CATEGORY PRINT
DIR TRAF SERV CDIV ROC ITYPE TRM ADC LANG BSEC
1648 00040400 0203120000 100151000 000001 - 0 10010003000010 - 0

END

<acpap:acdnum=1&&7;
ACD SYSTEM PARAMETER
ACDNUM ACDVAL
1 0
2 4
3 0
5 0
6 0
7 1


<opcap:dir=91;
OPERATOR CATEGORY DATA
DIR OPC PRG TRAF TRM
91 10000 0 1515 0

END

<opctp:corg=all;
OPERATOR CALL TYPE DATA
CORG CALT ROU OACC CUST NDIR RERNUM CEN CCOP TIME OFLNUM SDAY SNIG
1 7 5 5555 - Y 2788 N N - - - -
1 7 6 5555 - Y 2788 N N - - - -
1 7 7 5555 - Y 2788 N N - - - -
1 7 8 5555 - Y 2788 N N - - - -
2 1 - 199 - N - N N - - - -
2 2 - 199 - N - N N - - - -
3 3 - 199 - Y 2788 N N - - - -
4 7 5 6666 - Y 199 N N - - - -
4 7 6 6666 - Y 199 N N - - - -
4 7 7 6666 - Y 199 N N - - - -
4 7 8 6666 - Y 199 N N - - - -
4 7 10 6666 - Y 199 N N - - - -
5 1 - 198 - Y 199 N N - - - -
5 2 - 198 - Y 199 N N - - - -
6 3 - 198 - Y 199 N N - - - -

END

<opcgp:corg=all;
OPERATOR CALL ORIGIN GROUP DATA
DIR
999999999
123456789
CORG ---------
1 111111001
2 111111001
3 111111000
4 011100111
5 011100111
6 011100111

END
[/tt]

As said: These parameters goes for all the ACD-groups, the ACD-members, the ADN's and operators as well.

Thanks for your help!

 

[fouesnant]

Hi
Could you poste the CDIDP printouts for the ACD group and ADN?

BR

 

[nschreuder]

[tt]
<cdidp:dir=4151;
NOT ACCEPTED
DIV
NOT ASSIGNED

<cdidp:dir=4114;
CALL DIVERSION INDIVIDUAL DATA
DIR DIV
4114 4114

END
[/tt]

 

[fouesnant]

Hi

If we concentrate on the way the ACD is working first :
you could have min 0 call in queue and max 8 calls in queue... this is wierd, but why not.
You also have a queue constant of 25, while the dynamic queue is not used; also weird, but still why not.
According to SEL you have 60 overflow authorized.

However, I don't see anywhere in the configuration any overflow position for the ACD group.
After reading the documentation for ACD group, I don't have seen any possiblity for a call to go out of the queue if there is an available member still present

The way the diversion works for ACD group is either the queue is full or the is no more available members.
But in that case you should have at least a CDINI or a Follow me set on that group number

So I don't understand why it has worked in previous SP, but I guess that it was a bug corrected to fullfill the function spec after it has been discovered.

One idea that you could set, is to initiate the divertion toward your operator such as 199 or 198 (ie CDINIIR=4151,DIV=199) and see if it matches the customer need.

I have meet some exemple like yours where one version has a specific way to work-so to speak a bug in the Function spec implementation, and that after applying an SP, the implementation in the code matches the Function Spec.

Best regards

 

[patcher]

Hello NCCOI,

Okay, as I told you before the scenario in SP6 is faulty. There should be no recall if the call was extended to ACD queue.

I will help you but its not my responsibility to create something that is not in accordance to function specs.

Here is the steps:
1. PCPAS:UNIT=ACHH,CI=S106058A;
YES;
2. ACGCC:GRP=4151,SERV=10000;

3. Try the scenario again.
4. Dump the system.

Regards.

 

[nschreuder]

Yes, i became this solution from another technician in my country too, at the same date and almost at the same time as yours, patcher. What a coincidence! Are you him?

It works!

We're satisfied and our customer is happy. Thanks everyone for all your interference.

 

[patcher]

I can't believed that someone else helped you with the same solution as mine and at the same date&time. Well there will be no next time from me then. Cheers...

 

[nschreuder]

You're kidding ..., right?

 

[whosrdaddy]

I don't think he is...



-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!