Genesys Cloud - Main

 View Only

Sign Up

  Thread closed by the administrator, not accepting new replies.

  • 1.  Automatic Timezone Mapping

    Posted 07-27-2018 10:48
    No replies, thread closed.
    Hello -

    Setup a quick test of Automatic Timezone Mapping and had something of an epic fail. Wondering where this went off the rails...

    Imported a set of test data that looked like this:

    Name Account Status Created On Day Phone
    Me Account Name A 2000-01-01 0:00 8085550000
    Me Account Name A 2000-01-01 0:00 9075550000
    Me Account Name A 2000-01-01 0:00 5095550000
    Me Account Name A 2000-01-01 0:00 3035550000
    Me Account Name A 2000-01-01 0:00 3125550000
    Me Account Name A 2000-01-01 0:00 2025550000
    Me Account Name A 2000-01-01 0:00 8005550000

    All the NPA are have been in use since the 1970's (HI, AK, WA, CO, IL, DC, TFN). I used fictitious numbers because i wasn't interested in placing the calls, just in when they would be offered/dialed.

    Time zone mapping identified them as:

    Day Phone AutomaticTimeZone-Day Phone
    8085550000 HST
    9075550000 Undetermined
    5095550000 Undetermined
    3035550000 MST7MDT
    3125550000 Undetermined
    2025550000 Undetermined
    8005550000 Undetermined

    How could it not identify 907, 509, 312, or 202!?

    I tied the contact list to a Preview Campaign and scheduled it from 07:00 - 13:00 CT. PureCloud shot through the entire list marking each record "ININ-OUTBOUND-AUTOMATIC-TIMEZONE-BLOCKED" ... 

    I attempted the test as a Progressive campaign as well with an identical failure.

    Two questions:

    (1) How do you make PureCloud identify time zones in Alaska, Washington, Illinois, and the District of Columbia by NPA?
    (2) Is it possible to to get PureCloud to offer callable contacts and hold others contacts and offer them as their time zone becomes available to dial (without having to manually recycle)?

    Thanks,

    ------------------------------
    Patrick Rada
    Keypath Education LLC
    ------------------------------


  • 2.  RE: Automatic Timezone Mapping

    Posted 05-03-2022 10:47
    No replies, thread closed.
    I have been tinkering with the automatic time-zone mapping feature, specifically to be able to test a campaign outside of normal business hours. We use outbound campaigns to facilitate callbacks for a customer. Normally we insert a central-time ZIP code for every contact and then in combination with the ANI's time-zone, we are fairly certain to not call a contact at an inappropriate time. However, with these restrictions, testing the campaign's functionality outside of business hours is not possible. The workaround idea for this was, based on a test ANI, to set a ZIP code from Hawaii and then manipulate the number we insert into the contact list to begin with a Hawaiian area-code. The automatic-time zone mapping maps to HST for both the ANI and ZIP. Then I created a custom outbound route that would use REGEX to strip off the leading 808 and dial the number. The problem came up that despite creating a time-zone for both and the testing time being in the "contactable window for mapped contacts", the campaign consistently give this wrap-up code and won't dial the call "ININ-OUTBOUND-AUTOMATIC-TIMEZONE-BLOCKED".
    Below are back-to-back examples with a modified contact number and a normal one. (number modified below for the post, I also am testing from EST in this specific case since I do not have a Hawaiian number to actually test with)

    inin-outbound-id ANI ZipCode ContactCallable ZipCodeAutomaticTimeZone CallRecordLastAttempt-ANI CallRecordLastResult-ANI CallRecordLastAgentWrapup-ANI SmsLastAttempt-ANI SmsLastResult-ANI Callable-ANI AutomaticTimeZone-ANI
    aa0aea0f3c0acf6 +19195551234 27606 1 EST5EDT 2022-05-03T14:03:01.031Z Trending Issue Trending Issue 1 EST5EDT
    94927610d2ad12 +1757919555123499999 27606 1 EST5EDT 2022-05-03T14:04:01.462Z ININ-OUTBOUND-AUTOMATIC-TIMEZONE-BLOCKED 1 EST5EDT

    The REGEX expression that tests OK with the Simulate Call feature on the Site is...
    Match Expression: ^(\+1)(757)(\d{10})(99999)
    Normalize Number Expression: $1$3

    The 'ININ' wrap-up code seems to indicate that there is an issue with placing the call due to the time zone, but does not actually seem to be the case since a 'legit' number with the same time-zone evaluation is dialed with not issue.

    ------------------------------
    Kevin Goodwin
    Mediu, Inc.
    ------------------------------

    Original Message


Related Content