What can caused ACD DN calls ?

[johnjose]

Hi all,

What could be reason of bloody ACD DN calls ?
We have cca 15 000 calls per day going through Symposium 4.2. Everything works fine just 30-50 calls daily are ACD DN calls and are distributed to default DN. It causes trouble if call arrives to an unqualified Agent.
All my CDNs and scripts are acquired, services on server are running, I guess my Master is also OK (is written identically like on an another our site where ACD DN calls don't exist).

GIVE RINGBACK
WAIT 4
WHERE CDN EQUALS
VALUE 4713: EXECUTE SCRIPT x
VALUE 4472: EXECUTE SCRIPT z
VALUE 4473: EXECUTE SCRIPT d
VALUE 4100: EXECUTE SCRIPT p
END WHERE

WHERE CDN EQUALS
VALUE 4713: EXECUTE SCRIPT b
VALUE 4472: EXECUTE SCRIPT c
VALUE 4473: EXECUTE SCRIPT a
VALUE 4100: EXECUTE SCRIPT j
END WHERE
DISCONNECT

Do you have any tips how to avoid ACD DN calls?

Thanks in advance

johnjose

 

[iptuser]

Unless I'm missing something , you need to have a default set up in the where statements



WHERE CDN EQUALS
VALUE 4713: EXECUTE SCRIPT b
VALUE 4472: EXECUTE SCRIPT c
VALUE 4473: EXECUTE SCRIPT a
VALUE 4100: EXECUTE SCRIPT j
default : route call, execute script z


You may find that someway in the master script there is a default or a else commend
IF CDN EQUAL XXXX THEN
EXECUTE YYYY
ELSE

Your ACD DN is following the else or default further into the script ?

Wayne

 

[brewerdude]

If someone or a system dials the number that's associated with the ACD that the agent phonesets are logged into, those calls will register as ACD calls. You need to look in your voice mail and company directories to see if these number are still utilized.

 

[rfwhite]

We ended up building a couple of new ACD setups with an 'unknown' number- too many folks had dialed the old numbers for years and it was a tough habit to break.

 

[johnjose]

Mentioned ACD DN calls are routed on number defined in M1 LD23.
Every our CDN has these number inserted under prompt DFDN.
This is also key 0 ACD for all Agents to continue call center business for Symposium crash issues.
So there is no script for ACD DN.

We tested DEFAULT : route call XXX a cup of weeks ago.
If we put it in the end of the first WHERE – END WHERE section, the rest of calls in next WHERE – END WHERE sections were routed to this DEFAULT.
So we could place DEFAULT just in the last WHERE – END WHERE section.
Unfortunatelly this Master variation also didn’t avoid ACD calls.

brewerdude, you are right - it’s a good point. But as we have repeatedly checked in Meridian there is no ACD number dialed.

johnjose

 

[brewerdude]

Any chance you have old numbers out there that users continue to dial? To get around this, we changed the numbers of all our queues to numbers unknown to the user community. Then, all the queue numbers we programmed as phantoms that forwarded to the proper CDN's.

You may also want to check your IDC table to make sure nothing is routing to the old queues.

 

[rfwhite]

Is it possible you're 'overrunning' Symposium? In other words do you have a "WAIT x" command after "QUEUE TO SKILLSET?

 

[TheWorkingMan]

You need to make sure that the Symposium is setup to handle that call volume. You can look at this information from the client. Go to Historical Statistics. You will see a value for calls per hour. Make sure this is set correctly. If it is not the system will default calls. Another thing to look at, is the system front-ended by an IVR or mail system. If so you need to add a IF TRANSFERRED statement to the master script. This should be the first statement after GIVE RINGBACK. Example:

GIVE RINGBACK
WAIT 2

IF TRANSFERRED OR CONFERENCED THEN
WAIT 6
END IF

WHERE CDN EQUALS:

You get the point. This will allow time for the transfer to complete before handing off to the application script. If this is not in the master you will see problems with reports and dropped, phantom or defaulted calls.
Make sure that the PBX is provisioned to handle this type of traffic also. Check to make sure that CSQI and CSQO in LD 22 is set to 255.
Let me know if this helps.

 

[johnjose]

Hi,

Finally our ACD calls problem was caused by calling ACD number (used for agents key 0) from another site ( too nice and easy remember number). We fixed it temporarily using LD49,IDC table. Final solution will be ACD number change.
So call value per hour is OK, also my master script works properly.
Thanks to everybody for help !

johnjose