Performance Issues

Dialer performance is generally measured by 'Average Wait Time'. Wait times are affected by the following factors on any campaign:

1. Average talk and wrap time
2. Number of agents.
3. Connect rate / list quality
4. RNA timeout setting. 16-18 seconds is generally optimum. Longer than this slows dialing down.
5. Latency on call setup / teardown. Typically problematic for international dialing and dialing into GSM network.
6. AMD performance and accuracy. Only use AMD on low connect rate, low transaction value business.
7. Trunk starvation. Softdial CallGem™ will use as many trunks as it needs to keep agents busy, which will fluctuate. Trunks should typically be provisioned at a ratio of 2.5:1 for low transaction value business (marketing, collections etc) in North America. 2:1 as a rule and perhaps 1.5:1 for market research.

Since Softdial CallGem™ operates more efficiently with a greater number of agents on a campaign, better performance is achieved by running a few large campaigns rather than many small ones.

If possible, try to minimise the number of campaigns, for example, by having agents manage more than one script. The Linked Campaigns feature in Softdial Campaign Manager™ may be used to combine several lists in one campaign.

For optimum overdialing performance lists should be 'randomised' to avoid clumps of connects / non-connects which can lead to increased abandons resulting in lower call launch rate to compensate. For the same reason, retries and callbacks should be distributed as much as possible over the available time window.

Answer machine detection (AMD) should only be used in environments where there is a strong business case for its use. See also CTI Integration - Best Practice - Answer Machine Detection section.

Where AMD use is a requirement, we recommend taking the following actions to ensure the best possible results:

• VoIP Environments
  Ensure that the carrier has early media enabled as the AMD algorithm relies on this for accurate detection. In addition, voice media should ideally be delivered using an uncompressed (typically G.711) codec.
• Understand Tuning Parameters
  With most AMD implementations there are ranges of tuning parameters that can be set. Gaining an understanding of how the AMD tuning parameters work and tuning the AMD algorithm is key to successful implementation. We suggest running test campaigns, for example, dialing employee's home numbers (where some employees have answering machines) as a good way to experiment with parameter settings.
• Set Realistic Goals
  AMD is an imprecise technology. The industry has been misled by claims from some vendors that close to 100% detection is possible.
• Have a Failure Strategy
  When using AMD you have to expect that on occasions answering machines will be passed to agents. The agent desktop application should have a means for the agent to kill the call quickly and classify it as answering machine.
• Plan Trunk Capacity
  AMD results in a slight increase in trunk usage. the outbound planning tool, Oceanic®, can be used to plan trunk capacity for AMD.

For an accurate assessment of the benefit or otherwise of using AMD, run a 'like for like' live trial e.g. one week with AMD on and one week with it off using similar list data and measure the full business impact, not just the list penetration.

See Contended Access to Data section in Database Deployment Issues.

Call launch rates are recommended according to the expected live call rate:

Dialing conditions	Live call rate (expected)	Call launch rate (recommended) - 1 per second for every X agents
Random-digit dialing	<10%	2
Known numbers for cold-call or collections campaigns	15-20%	4
Relationship with the customer - retention and service type outbound activities	>25%	5

The SIP carrier's Session Border Controller (SBC) capacity is usually the limiting factor as many carriers provision based on most calls being inbound.

The carrier needs to be made aware that the circuits are being used for outbound and will need to ensure enough SBC capacity is provisioned to deliver the necessary throughput. For example:

• An inbound-only call center with 1000 SIP trunks needs to support a call launch rate of around 200 calls per minute, or 3.5 calls per second in order to handle inbound load assuming an Average Handling Time (AHT) of 150 seconds and 500 agents
• An outbound-only contact center with 1000 SIP trunks doing a mix of campaigns for, say, 300 agents will require a call launch rate of 75 calls per second, about 20 times the call origination throughput as for inbound

When Softdial Campaign Manager™ manages the database, call starvation should not occur. Softdial Campaign Manager™ has been designed to handle caching and database throughput for a large number of campaigns at the same time.

If Softdial CallGem™ reports call starvation it will show on all Softdial Campaign Manager™ clients. Typical reasons why Softdial Campaign Manager™ may not deliver calls to Softdial CallGem™ fast enough are:

• Indexing Failure
  If the source table for the campaign is not indexed or is indexed badly this will slow down read performance. We have seen reads taking as longs as 2 seconds on slow servers with poor indexing. Over time on a busy system this will lead to cache runout in Softdial Campaign Manager™ and call starvation. Read performance should be between 100 and 1000 rows per second on a well-configured database server.
• Server Overload
  There is a physical limit to the number of transactions a database server can manage. If these limits are exceeded then performance will degrade. (See Database Deployment Issues)

When a third party Campaign Manager application is responsible for delivering numbers to Softdial CallGem™, there are several techniques that can be used to avoid call starvation.

If there is doubt about the ability of a customer database to respond quickly so that the Softdial Campaign Manager™ application can pass numbers to Softdial CallGem™ on demand, then a batch approach is recommended. This means Softdial CallGem™ can be loaded up with calls at the start of the campaign, and works through those calls until they are exhausted. This does not preclude retries and reschedules being presented in real-time.

Alternatively if there is confidence that the Softdial Campaign Manager™ software can respond to Softdial CallGem™ requests for numbers on demand, then a trickle feed may be considered. See the Softdial CallGem™ help file documentation for details. When a trickle feed is used we advise that the software feeding Softdial CallGem™ holds a cache of numbers in RAM so that responses can be immediate.

Upon data runout some action needs to be taken. Every customer has different runout requirements (how the system responds when there are no numbers available to call) and implementing a runout strategy ought to be viewed as a part of the customer delivery process.

The options that Softdial Campaign Manager™ provides are:

• Report the runout but take no action.
• Close the campaign immediately on runout.

There are some further options planned in the short term:

• Push pending retries forward for one last pass before closing
• Enable movement of agents from one campaign to another

If you are deploying a third party Campaign Manager application to manage the feeding of numbers to Softdial CallGem™, the simplest option would be to have the application close the campaign when Softdial CallGem™ starts to request numbers and no more numbers are available. If in this circumstance you also happen to be using the simple number retry logic provided in Softdial CallGem™, please consult Sytel for advice.

Correct Ring No Answer (RNA) timeout control is critical to both dialer performance and compliance. There has been some confusion regarding correct setting of the RNA timeout, particularly when calling to GSM networks where network latency can be as much as 10 seconds.

The right way to interpret ring no answer timeout is 'the time that the call should ring for in the customer's home before timing out'. In territories where Q.931 signalling is implemented there is a simple approach that will yield the best results, as follows:

At the point of launching a call, set the no answer timer to start 3 seconds after the configured timeout value; thus if the configured RNA timeout is 15 seconds, set the timer for 18 seconds.

If and when the network reports PROCEEDING for the first time on that call, i.e. the carrier has accepted the call as valid and established a route through the network, reset the timer to the configured value (15 seconds in the example above), and send a Delay Notification [DN] message to Softdial CallGem™ so that it can report on call setup times.

If and when the network reports ALERTING for the first time on that call, i.e. the far end exchange has started to ring the called party, reset the timer to the configured value (15 seconds in the example above), and send a Delay Notification [DN] message to Softdial CallGem™ so that it can report on call setup times.

Note that PROCEEDING and ALERTING messages may not necessarily arrive. In the European terrestrial network they will be reliable but in mixed-mode signalling environments such as the US, or when launching calls that will terminate in a GSM network this may not be the case, hence the need for a belt-and-braces approach to call timeouts.

It is often the case that PBX and CT board manufacturers' timeout mechanisms do not work properly or do not have the granularity to time calls out after an exact number of seconds. Since accurate handling of RNA is critical to good dialer performance, integrators who experience problems with RNA settings should consider using the Disconnect Hint [DH] message to tear calls down.

If the Trunks Open [TO]] message includes the Disconnect Hint (DH) parameter, the Disconnect Hint [DH] message will be sent for each ringing (and not answered or failed) call at the interval specified by the Ring Timeout (RI) parameter on the Call Initiate [CI] message. Disconnect Hint is intended to provide a hint for the telephony layer to disconnect a ringing call.

If using the Disconnect Hint protocol, the Delay Notification [DN] message may be returned by the telephony layer to advise Softdial CallGem™ that a delay has occurred in dialing the call.