General Settings

Two formats are available for the application data included in the Data (DT) parameter:

1. pipe-delimited (default)
2. XML

   The format of this XML document is described in Data (DT) Parameter - XML Format. XML data should be selected if the application data is likely to include characters that are considered invalid in standard SDMP messages - see Invalid Characters in Configuration Issues.

DateTime format

When using DateTime fields in a campaign table, the format of the DateTime string used is tied to the application data format selected above.

When delivering application data as

• XML - use the format:
    yyyy-mm-dd[ hh:mm:ss[.9999999][plus/minus hh:mm]]
• pipe-delimited - use the ISO 8601 format:
    yyyy-mm-ddThh:mm:ss[.999]
  This format is output by the Softdial Scripter™ 2 Current Date Time step.

For more details see Data (DT) Parameter - XML Format.

Enable via the checkbox.

From V10.6.223 - callbacks can now be enabled or disabled independently of retries.

Enable via the checkbox.

If a callback is setup for a specific agent at a specific time, then at that time, if the agent is not available, this option governs the resulting behaviour.

If the box is

• unchecked - the call will be set to be retried with the same agent, according to the rules set up on the Retry Options page (outcome code 32, planned not made)
• checked - the call will be set to be retried within a few minutes, by any agent who becomes available i.e. the callback is converted to a 'retry', due immediately

Enable via the checkbox.

If a callback is setup for a specific agent at a specific time, then at that time, if the call is scheduled for a retry (e.g. no answer), this option governs the resulting behaviour.

If the box is

• unchecked - the call will be set to be retried with the same agent, according to the rules set up on the Retry Options page (outcome code 32, planned not made)
• checked - the call will be set to be retried within a few minutes, by any agent who becomes available i.e. the call will be converted to a retry, due immediately

The Preview Timeout indicates a number of seconds that a previewing agent can stay previewing without being forced to launch the call. The Preview Timeout is defined in the Preview Timeout (P1) parameter of the Overdial Tuning [OT] message. The agent can cancel this timer by sending the Begin Dial [BD] message at any time. The default value of 0 means there is no time limit.

The Breather Timeout Indicates a number of seconds that a preview agent gets as 'breathing space' before being presented the next preview call. The Breather Timeout is set in the Breather Timeout (P2) parameter of the Overdial Tuning [OT] message. The agent can cancel this timer by sending the Preview Now [PN] message. While the agent is in this state, the agent will be reported as in state viewer as waiting. The default value of 0 means the agent will spend no time in this state.

From V10.6.387 - if the On-Hook Preview checkbox is checked, preview calls will be passed to the agent's extension even if the extension is not nailed up, and the Preview On Hook (P3) parameter will be present in the Overdial Tuning [OT] message.

This is the default option.

• Each number will be retried according to the retry settings in the Retry Options tab/ page.
• The campaign remains active after all fresh records have been exhausted.
• Retries will continue to be processed as they become due until the entire retry regime is completed.
• When all records in the database are complete the campaign will remain open (see change in default behaviour from V10.6.393 - DisableAutoStop in Registry Settings).
• The campaign may be stopped manually or by using the campaign scheduler.

• The campaign is stopped after all fresh records have been exhausted.
• Each record will be contacted at least once and the campaign closed after the last record has been processed.
• This will result in some retries and callbacks not being processed.

• The campaign will remain running after all fresh records are processed.
• Any pending retries will be brought forward and rescheduled to be processed at 0.1 second intervals.
• Retries are processed only once after which the record is marked 'complete'.
• Callbacks will continue to be processed until all retries have been completed.
• All linked campaigns will remain running until all campaigns in the link have been accelerated, after which they will all be stopped.

From V10.6.387 -

• As above, except that all agents are chained to any valid campaigns before stopping the current campaign.
• If the selected chained campaign is not running the agents will be logged out.
• Agents on linked campaigns will not be chained until all campaigns in the link have been completed.
• Callbacks becoming due while the campaign is being 'accelerated' will still be placed.

From V10.6.387 -

• As above, except that the current campaign is left running.
• Callbacks will continue to be placed as long as the callback agent is logged in to any other campaign.

• Agents are transferred onto the campaign specified in the drop down when all of the fresh records in the list have been tried at least once, then the campaign is closed.
• This will result in some retries and callbacks not being processed.
• If the selected chained campaign is not running the agents will be logged out.

For details of the API supporting agent / campaign chaining see Campaign Chaining.

From V10.6.387 -

• As above except that the current campaign is left running and the agents will remain logged in even if the 'chain to' campaign is not running.
• Callbacks will continue to be placed as long as the callback agent is logged in to any other campaign.

An abandon made after the start of acceleration may be handled differently to abandons during regular dialing. This happens because when running in accelerated mode, an absolute limit is set on the number of retries made, not from the start of acceleration but from the start of the campaign.

The logic behind this is as follows: Once retries are accelerated, numbers are retried at a far higher frequency than during the main campaign run. This leads to a considerable drop in the connect rate. Once a number has been dialed unsuccessfully a number of times, the chances of getting a connect diminish to close to zero, especially if the call time is not scheduling intelligently.

On an aggressive campaign, the overall retry limit may be set for example at 10-15 attempts, as Right Time to Call (RTTC) will maximise the chances of a contact. However, when data has run out and retries are accelerated, the value of RTTC is lost, i.e. calls disposed with some kind of respondent not present outcome previously are overwhelmingly likely to dispose in the same way again. Hence, Sytel recommends setting an overall retry limit during accelerate to, say, 6 attempts, as anything beyond this would generate connect rates of 2% or less.

This leads directly to the outlier behaviour where an abandon made after start of accelerate is handled differently to abandons during regular dialing.

For more background on retries, see Retry Rules.

Using very small lists of just a few records may inhibit retry acceleration, for the following reasons.

Softdial Campaign Manager™ is optimised for bulk database operations and, to achieve best performance, record selection behaviour in the Softdial Campaign Manager™ database is based on periodic timers. Retries may take up to 2 minutes to load, so if there are only a few retries available when the fresh records are exhausted, these will deplete very quickly. In the case where, at the start of the campaign, there are less records available than is required to maintain the Softdial Campaign Manager™ cache, there will be no retries to accelerate (as no calls have failed yet) and the campaign will enter a stopping state. As a result, any retries generated after this point will not be processed.

For example, if the list comprises 20 records and 5 agents are logged in, Softdial CallGem™ will request 15 records to process (3 records per agent). As there are 5 agents available, Softdial CallGem™ will immediately process the first 5 records and request another 5. This means the Softdial Campaign Manager™ cache runs out as soon as the campaign starts, triggering end of list processing and campaign shutdown.