Show Hide

 

Feedback

  • Contents
 

Priority Dialing

  • Allows contact list records added on the fly to be dialed immediately without requiring a recycle

  • Contacts are dialed as soon as agent(s) become available

  • A Policy can carry out behaviors if the call type is a Priority Call

Feature Overview

Priority Dialing, also called Just-in-Time (JIT) dialing, is a feature that allows for prompt insertion of records at the front of the queue of records to be dialed, independent of Dialer's usual recycle logic.  When Priority Dialing is enabled, Interaction Dialer checks at configurable intervals for newly inserted records in the call list. The query frequency is configurable from 5 seconds up to 5 minutes (300 seconds).

Priority Dialing should be used carefully. Depending upon the number of available agents, adding too many "J" records could overwhelm agents.

Settings for Priority Dialing are managed for Campaigns in the Priority Dialing frame:

Priority Dialing records are records inserted in the call list with a "J" status.  Found records are pulled into cache and immediately dialed, subject to normal agent availability and system overhead.

Technical Considerations

  • Priority Dialing records are tracked using a table auto-created by Dialer named I3_<ContactList>_JIT. For performance reasons, Dialer watches this secondary table for inserted records, not the Call List itself.

    Priority Dialing records are created only for call list records inserted with a "J" status while 1 or more Priority Dialing-active campaigns are dialing that call list. The only action on insert is a trigger that inserts the i3identity into the JIT table. Everything else, such as addition of a record in the PND table, zone mapping and so on, happens as part of the contact query when dialer caches the record.

    Only records with both a "J" status in the call list and a corresponding record in the I3_<ContactList>_JIT table are pulled for dialing.

    Priority Dialing activity is triggered on call list insertions only; this means it is not possible to make an existing record get priority dialed just by changing its status to "J".  You would have to remove/reinsert it.

    Because Priority Dialing is implemented using a trigger on the call list, some methods of inserting records may not be compatible by default.  For example, the SQL Server BULK INSERT statement does not run triggers by default, so records inserted using a BULK INSERT statement would not be processed as Priority records.

  • When a recycle occurs, orphaned _JIT records are cleared, and orphaned "J" statuses are changed to "C" (callable record). These recycle actions occur before other recycle functionality, so orphaned "J" records that get cleaned up may be immediately chosen by the recycle that converted them, subject to filter/sort criteria.

    An "orphaned" record is one of the following:

  • An i3identity in the JIT table with no corresponding call list record, or whose call list record has a status other than "J". 

  •  A call list record with "J" status that has no row in the JIT table. 

    For example, an orphan can be created if someone inserts a Priority Dialing record and immediately changes its status.  Orphans in both tables are cleared at recycle time.

Policies can carry out behaviors for Priority Calls

  •  A "Priority Call" call category in the Policy Set Item Condition configuration allows a policy to examine call category information for the current contact record, so that a policy can run behaviors if the call type is a Priority Call.

  • Agent-owned callbacks will be dialed before Priority Dialing records, followed by campaign-wide scheduled calls, and then by regular Dialer calls.

  • In some circumstances, precise dials are processed before priority calls.

  • Policies can be used to precise dial priority calls to avoid abandoning them.

  • Priority Dialing contacts are not queried as aggressively as regular and scheduled contacts.  Dialer will cache only as many priority contacts as it estimates can be dialed before the next query.  Therefore, if dialing pace picks up and it dials more than it planned, some regular or scheduled contacts may slip in before any further priority contacts.  The feature is designed to leave priority records in the database rather than in Dialer's cache, if they're not being immediately dialed, so that records remain available in case there is a faster-dialing ODS that can choose them.

    When regular records (or scheduled calls) are queried, Dialer is biased toward over-querying, so that if the pace goes up before the next query, Dialer won't run out of records to dial.  In the case of J records however, the bias is set in the other direction; which means it will only query exactly as many J records as it thinks it can dial, rather than erring on the side of extra as the regular/scheduled queries do.

    The math that calculates how many calls Dialer determines it can place before the next query does not change based on the call type. Therefore pacing will generally affect "J" records exactly the same way that pacing affects other records. However "J" records will be queried less aggressively than other types.  This is to leave as many "J" records in the database as possible, so that other Dialer servers can choose them.

  • Note that the "priority call" status that you are able to use in Policies is only retained as long as Interaction Dialer holds the record in memory from the first load.  The best explanation of this is by example:

Consider two priority calls (A and B): both are inserted as priority records.  Both records are retrieved by the same priority contact query for the same campaign, which has a disposition policy in place that checks for "priority call" category.  Call A connects, is answered, processed, and dispositioned as "Success".  Since this all occurred while the call was still in Dialer's cache, the disposition policy runs, because the call still has "priority call" status.  Call B, however, gets no answer when it is dialed, so Dialer reschedules it according to the customary reschedule delay and autoschedule settings.  Dialer then unloads the call from cache, changing it to an auto-rescheduled status. 

At this point, since dialer has deleted the call from memory, and the call list now only contains the auto-rescheduled status, the "priority call" categorization is lost.  Later, when Dialer re-caches call B to try again, the result this time is a Success disposition.  The "priority call" category disposition Policy will not run, because Dialer has no memory that this was a priority record.  On the second load, it just looks like a regular callable (‘C') record.

In short, Dialer will never set a contact to "J" status, ever.  When Dialer writes a contact back to the database and drops it from memory, the contact's "priority call" status is forever lost, and the contact effectively becomes a regular contact from that point.

Particulars of "J" status contacts:

  • Policies can analyze records by call category. "J" contacts are initially assigned to the "Priority Call" category.

  • The "Priority Call" category is removed when the record leaves Dialer's cache.  It may return to "Normal" category at any time after the initial dialing attempt. This depends on Dialer's caching behavior, agent availability, and other factors.

  • To keep track of the Priority Dialing status beyond the initial dialing attempt, you must set an attribute.

  • The configured filter for the campaign is also applied to "J" records.

  • "J" records have a separate sort used only for them.

  • Aside from the differences mentioned above, "J" records are treated exactly like "C" (callable) records in terms of dialing behavior, and are subject to all the same campaign settings and processing that regular calls are (skills, rescheduling, and so on.)

  • All numbers of a "J" record will be dialed.  This is a key feature distinction between Priority Dialing and scheduled call insertions. A scheduled call inserts a just in time call.  Priority Dialing inserts a JIT contact, which may have multiple telephone numbers.

Some notes on priority ordering

The ways in which Dialer assigns priorities is complicated, but in general, it selects records for dialing in this order:

  1. Agent-owned callbacks

  2. "Route as Preview" calls (in predictive and power campaigns)

  3. JIT calls

  4. Scheduled calls (regardless of the source)

  5. Calls associated with an agent in a preview campaign

  6. Regular calls

Scheduled calls

  • If the timeout expires on a scheduled call, it will remain as a scheduled call until it's queried. Once it has been queried, it can either be rescheduled or turned into a regular call, depending on what happens to it. For example, if the scheduled call is routed to an agent and the agent dispositions it in a way that does not reschedule it (skip, busy—anything other than "scheduled"), it will end up as a regular call.

  • However, if the system attempts to place the call (in a Power or Predictive campaign) and fails, it is rescheduled.

  • Another example: if the call is queried and is pulled into Dialer, but is actually blocked by the zone, it will be rescheduled.

  • If a call is scheduled, but keeps getting rescheduled for various reasons (system hangup, remote hangup, no answer, for example), eventually it will hit the Max Attempts. At that point, it will be rescheduled for the next day.

  • Also, if the maximum number of reschedules is exceed, the call is marked uncallable.