FAQ

In order to maintain the dialing rate:

1. suspend the campaign
2. load more data
3. resume the campaign

This has been noticed when using Internet Explorer to display the client.

• Use IE compatibility mode (set it to IE8 if you have that option)

For instructions on how to do this, check http://windows.microsoft.com/en-us/internet-explorer/use-compatibility-view

• Has the campaign been started?
• Is the switch functioning correctly?

For this kind of situation, best practice would be to refer to the Server Notification Panel.

Depending on your RDBMS, you may notice that data throughput declines when very large numbers of records are used. Therefore, if you have a very large number of contacts in your database, we would recommend loading a smaller subset of this data, then replenishing it (see What should I do if my campaign runs out of data? above) when the list is depleted or near to depletion. This can be assessed by referring to the Estimated Runout value (Windows client)/ Runout Est value (Web Client), which gives you an idea of when the list will be exhausted. For more details, see Monitoring a Campaign.

To facilitate retry control, Softdial Campaign Manager™ creates one Audit Trail Table per campaign. These tables are for the application's internal use. Table formats and contents are subject to change without notice and therefore they should not be used for reporting purposes.

Softdial Campaign Manager™ is compatible with any database driver with ODBC V3 core conformance.

We have validated the following databases with Softdial Campaign Manager™:

• MySQL V5.1 with MySQL ODBC V5.1 Driver*
• MS Access - All Versions*
• MSSQL Server - All Versions
• Oracle V8, V9 and V10
• IBM DB2/400 with Client Access release V5.4
• Postgres V9 for Windows

If you are planning to integrate Softdial Campaign Manager™ with any non-validated database driver, please consult Sytel first

* These databases are not designed as real time transaction engines and are only suitable for relatively small scale implementations. If you are planning to use either of these databases, please consult Sytel for further advice.

Many users like to perform a backup of their database tables overnight. If Softdial Campaign Manager™ has running campaigns then the database connection for these will be broken.

This has an impact on behaviour in Softdial Campaign Manager™; using ODBC, it is not possible to programmatically determine whether a cursor reload failure is down to no data or no connection, as this is a database specific error (which can be seen from the resulting error message). This is a limitation in open database technologies.

Outbound campaigns that are left running will attempt periodic cursor reloads which will continue to fail for lack of connection. Inbound campaigns will consistently have lookup query failures. Lookup queries are prevented from triggering reconnect processing in Softdial Campaign Manager™ because a lookup query may 'legitimately' fail due to badly configured SQL query statements.

The recommendation for performing database backups is:

• For outbound campaigns - users should schedule close at the end of the business day, and restart of those campaigns shortly before start of business. This allows overnight processes to work and avoids the potentially serious problems that can result from data loss or corruption.
• For inbound campaigns - any that have to remain running should be scheduled to stop and restart once the database backup is finished. This will enable the ODBC connection to re-establish the TCP connection to the database.

For best performance with Softdial Campaign Manager™, the database must contain a single unique primary key column for database updates. The following general rules should also be obeyed:

• A separate table per campaign should be used as this provides faster indexing of data.
• If the customer's database has all customer data in a single table then a separate view of just the data to be used by Softdial Campaign Manager™ should be created. This view must include the same columns as the primary table.
• If creating a view based on multiple tables, all columns added by Softdial Campaign Manager™ must be included in the primary table before the view is created.
• If filtering criteria are known in advance then filtered views should also be created.
• Users specified in Softdial Campaign Manager™ must have full permissions including permission to create tables.

In general this is not recommended other than as described below:

• When a campaign is running,
  • only Softdial Campaign Manager or 3rd party campaign manager application may update the database, and
  • only the active record may be updated.
• Other applications should not perform update operations on the database tables being used during a campaign, as this can seriously impact performance and cause data corruption.
• An API is provided to allow updates to campaign tables to be made reliably and without risk of data corruption. (See Updating Campaign Tables)
• Where report generation using data from tables managed by Softdial Campaign Manager™ is required, the Database Administrator must replicate the tables. Sytel is happy to advise on how this should be done.

See 11) How can I add or modify data on a live campaign? below.

Softdial Campaign Manager™ has a clear structure for doing this. Every record that is cached by Softdial Campaign Manager™ for dialing is marked as cached for the duration of it being cached for dial. This enables external processes to perform updates so long as the row is not marked as cached. Users should not attempt to modify the campaign table while a campaign is running unless they are using the API provided to do this safely. (See Updating Campaign Tables)

Softdial Campaign Manager™ provides a linked campaigns mechanism that allows multiple rowsets to be fed into the same campaign. These rowsets may be on the same or different tables. This provides maximum flexibility in grouping data. It is possible, for example to use this grouping mechanism to perform:

• preferential agent selection (see outbound skills-based routing).
• constraining certain data sets to be called at particular times of day.
• setting different retry rules for different data sets on the same campaign.
• presenting different CLI for different data sets on the same campaign (where legal and sensible to do)

The normal way to do this is to insert a new record as part of the script. The call can be set up as an agent-specific callback for immediate dial or at some later time as required. (See Updating Campaign Tables)

With an agent-specific callback, the number to be dialed is sent to Softdial CallGem™ along with the agent identifier specifying the agent required to handle this call.

If the agent is

• logged in
  • to any campaign the agent will be 'reserved' for the call as close as possible to the time the callback is due
  • to a different campaign from the one the callback relates to, the agent will automatically be moved to the relevant campaign to take the call, and moved back to the original campaign again when the callback is complete
• not logged in to any campaign at the time the callback is due, the behaviour is as specified by the Pool callback options on the Softdial Campaign Manager™ General Settings tab.

With a non-agent-specific (normal) callback, the callback will be handled by any agent logged into the campaign (from which the callback was set) at the time the callback becomes due. If no agents are logged into the campaign the call will fail and be re-scheduled according to the retry scheme set up for the Planned not made outcome (code 32). See Retry Options.

SDMP messages and database details

When a callback is set Softdial CallGem™ sends a Number Back [NB] message to the campaign layer with one or more of the following parameters:

Parameter	Details	Database field
Callback Agent (BA)	For agent-specific callback, contains the agent id For non-agent-specific callback, contains _ZZCallback_ A non-agent-specific callback can be differentiated from a normal retry by checking if the Retry_Username database field has the value _ZZCallback_.	Retry_Username
Callback Number (BN)	If the callback is required to be made on a different number from the original call, contains the callback number	Retry_Number
Callback Timer (BT)	Contains the timestamp for the callback	Retry_TS

From V10.6.249 -

To do this, the following fields in the campaign database must be updated with the new record, as follows:

This will result in the most recently added records being picked up as Planned Time Callbacks, resulting in Make Call [MC] messages being sent to Softdial CallGem™ with the first two values in the Callback Timer (BT) and Callback Agent (BA) parameters respectively. The Make Call [MC] message will also have the Call Priority (CP) parameter set to 99999. (See also Updating Campaign Tables).

From V10.6.311 - now includes a web-based interface for safely adding records from a web feed. See the Insert Record [IR] message.

Note this SDMP message can be used for example to insert a record from a web site using the HTTP API available in the HttpSDMPBridge.

From V10.6.501 - the Remove Number [RN] message will remove the requested number from Softdial CallGem™'s cache. This will block dialing of numbers that have already been sent to Softdial CallGem™ as long as a Call Initiate [CI] message has not already been sent to the telephony layer. Otherwise this message will be returned in an error message.

To remove all numbers from Softdial CallGem™'s cache, use the Purge Queue [PQ] message.

To prevent a number from being selected for dialing in future, use the Block Campaign Key [BC] message to update the record associated with that number.

Show SDMP example

The following message blocks the record with the ID 1234 on campaign ID 1 on the default tenant:

CM:DE:BC\TDdefault\CY1\AS1234\TKfoo\OIxyz

• TD - Tenant Name
• CY - Campaign Identifier (You can get this information from Status Broadcast [SB] messages.)
• AS - Application Specific Data (Key column information of the record)
• TK - Token (Any string value with the length 1 to 80 characters)
• OI - Originator ID (Any string value with the length 1 to 255 characters)

When Softdial CallGem™ receives this message, it responds with the following 3 messages:

1. RI:DE:R2\I1CM\I2DE\I3TDdefault:TKfoo\INxyz
   Starts the instance ownership
2. CM:DE:MV\TDdefault\TKfoo
   Verifies the message handled by Softdial CallGem™
3. RI:DE:R4\I1CM\I2DE\I3TDdefault:TKfoo\INxyz
   Ends the instance ownership

When these messages have been sent the Switch_Result field for the record in campaign table is set to 100 which prevents the record from being dialed again. This is the same mechanism as used for marking a record as Do Not Call however the Do Not Call list itself is not updated.

The campaign must be running for this process to work. If the campaign is not running, the number can be blocked on campaign start up by adding the number to the Do Not Call list.

For numbers that may already be in the Softdial Campaign Manager™ primary or retry caches, the Reload Campaign [RL] message can be sent with the PurgePrimaryCache (P0) and PurgeRetryCache (PC) parameters set to true.

See also 20) Why was the number dialed even though the record was updated before it went into cache?, below.

The customer database used by Softdial Campaign Manager™ must be run on a dedicated server, physically separate from Softdial CallGem™ and other Softdial Contact Center™ components. No contended access is allowed . If access to the database is required by other applications, this will require decoupling of the Softdial Campaign Manager™ server from the enterprise database. This can be achieved for example, by using database replication with SQL server.

There are essentially three Wintel server options available in respect of database activities with Softdial Campaign Manager™:

This issue is resolved in SCC V10.7.

On very large, badly indexed databases, database timeouts may occur due to timeouts in the Softdial Campaign Manager™ rollforward recovery mechanism. These timeouts are intended to limit the size of the rollforward cache and therefore the startup delays that may be experienced in rollforward recovery situations.

The correct solution for this is to ensure that tables are indexed correctly, particularly when using lots of filters to enable the database to respond within the default timeouts.

As a temporary emergency measure, it is possible to increase the timeouts as per the table below.

When the campaign is started the DBMS has already cached index information for the open cursor. The record will get read in even if the values that would take the record out of the main cursor selection criteria are changed.

The best way to prevent the number from being dialed is to mark the record as Complete. A Complete Timestamp (complete_ts) column should be defined. Setting the value in this column to be a number greater than 0.0 will ensure that, when the record is read in by Softdial Campaign Manager™, it is picked up as being complete and is not dialed.