Hi, we are having a problem when the dialer calls the Phone01 value correctly for the time zone, but Phone01 call does not connect. Then the dialer selects the Phone02 value and places the call, but it should not because the Phone02 time zone does not qualify.
Here's an example. The Call Center is located in California. The initial call is made at 7:30am PST to an EST phone number. The Phone01 number received a no answer and the dialer selects the Phone02 value and places the call at 7:31am. The Phone02 number is located in PST, which is before the call start time of 8:00am.
We are running UCCE 7.2.3. Has anyone run into this problem before?
This is working as it should. The phone01 is used for determinig the timezone. So if the caller has multiple phone numbers in different timezones the dialer looks at phone01 only for timezone. Example, phone01 is in PST and phone02 is in EST, all phones will be called based on phone01 timezone. I created a bug for this. Please see CSCsm30857 from the bug toolkit.
Thanks Joe for the reply. I just got the same information from the TAC engineer assigned to my case #610724763.
We suspected it was a defect. Our customer has agreed to not login agents with outbound skills until 8:00am. They have blended agents and the inbound call center opens at 7:30am. It's not a huge problem, just a little more work for the supervisors to re-skill. We will start our planning for a 7.5 upgrade.
I looked at the case. Both the bug I pointed out and Subbu pointed out are nearly the same. The OO dialer always looks to the phone01 to determine timezone offset to GMT. As more and more people have cellular phones with a combination of the Number Portability Act (being able to keep your number no matter where you are located) this will become a challenge for Outbound Campaigns. I am a prime example. I have a Massachusetts Cell (Which I use as a primary number most of the time) and I live in California with a home phone that has a California area code, which I very rarely use or give out.
Something else I noticed is that you the System Options set to 6am-9pm, you may want to change that. Customers in Hawaii are not being called after 6pm. Ask the TAC engineer to verify that. But I believe the system option timer is determined where the server sits, in your case Sacramento, and Hawaii is 3 behind us.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...