The Base folders contain a single campaign for each dialing method. The calling list data is the same in each case, and the only differences between the campaigns arise from differences in methods.
The data common to all campaigns in the folder is as follows
| Description | Value |
|---|---|
| Size of calling list | 25,000 numbers |
| Number of agents | 10 in the 10 agents sub-folder 20 in the 20 agents sub-folder |
| Login setting | A Poisson distribution, with a mean time between logins of one second is used. |
| Results talk band | 5% of live calls, at average of 480 seconds |
| Reschedules talk band | 5% of live calls, at average of 35 seconds. |
| Talk band 3 - No Results | remaining live calls: 20% - quick hangups 70% - only the beginning of a presentation is made, before the called party decides to take things no further |
| Idle time | 5% |
| Call outcome breakdown: | |
| live calls | 35% |
| no answers | 30% |
| busies | 7% |
| other telco | 2% |
| answering machines | 25% |
| faxes and modems | 1% |
| Event Type | Comment |
|---|---|
| Preparation times | Check out what your agents do when a number is busy of there is no answer. If you have a well-honed operation, you can probably improve on the times we have suggested here. |
| Open preview times | One of the reasons for opting for the Simple Preview method may be because you want your agents to open preview a number before it is dialed; otherwise you may have, for example opted for closed preview. If your outbound operation is still manual, then depending on the type of campaign you are running, you may not want to do any open preview at all; an example is appointment setting. |
| Dialing setup times | Note the range of dialing setup times suggested for the different methods, ranging from 1 to 5 seconds. It is essential that you check out what your dialer can do, and what time delay you will experience on your PSTN. |
| Talk times | Note that a majority of the talks have a short duration. In practice, this will be particularly true of cold calling. |
| Not ready times | The figure of 5% is just 3 minutes per hour and is an allowance for short breaks such as comfort and tea breaks. Don't take it as industry gospel; depending on the workload your agents are bearing and how you plan meal breaks, you may well want to up this figure. And if you work a staggered system with agents logging off for meal breaks at different times, while campaigns remain running, the percentage figure you use is very likely to be in double figures. |
| Event Type | Comment |
|---|---|
| Ring times | It's easy to understate the ring times required for some classes of call outcomes, especially machines. We have done some tests in several countries, hence the five second times for machines; but this figure will often be longer, so check out what is typical for your dialing area. |
| Dialer detection %s | See especially Dialer Detection Issues |
| Detection times | You will notice that for three methods (predictive, power and progressive dialing) we have assumed that busies and telcos have zero detection times. Not quite true, but they should be so small, that zero will be fine in many cases.
It is assumed that there is no machine detection by the dialer in the base examples. See Other Examples for more. |
| Agent wrap | This figure has been set at two seconds for all dialing methods other than manual on the basis that scripting and database facilities are available to assist in this wrap. But if you have manual dialing, it may take a good few seconds to record the wrap details, hence the figure of five seconds. |
| Event Type | Comment |
|---|---|
| Agent dialing state | We have kept the range of agent dialing states to a minimum for each dialing method. In practice you may want to expand on this, in particular to include allowance for open preview agents. |
| Overdial settings | The 90% setting for predictive dialing is a pretty good rating. Check Benchmarking Against Oceanic® to see whether you will need to revise it. And don't forget that you can verify this setting for your dialer by running a benchmark test. |
| Abandoned call target, and delay | We selected the figure of 2.5% on the basis simply that it is half the maximum allowed in Oceanic®; we used Option A for measuring it. And we set the abandoned call delay at one second. |
To help you make sensible comparisons in the folders that follow, we have used the assumptions from the Base Examples throughout, highlighting changes only.
In those cases where we have focused on a particular call outcome, there is a knock on effect on the other call outcomes, and this has been done on a proportionate basis. So when we increase the proportion of say answering machines from 30% to 50%, we need to lose twenty percentage points off all other call outcomes and live calls, for example, drops from 35% to 25%.