AMD: What's a reasoned estimate of false positives?

Ofcom’s revised Statement of policy on the persistent misuse of an electronic communications network or service tells us that if you use Answer Machine Detection (AMD) in your outbound contact centre, you now have to factor in a "reasoned estimate" of false positives and add these to the number of abandoned calls you make, and keep the whole lot below 3% of calls passed to live agents.

A false positive is where your dialler thought that a call was answered by an answering machine, but actually it was a live person. As far as the person called is concerned, you've just called them, then hung up as soon as they answered, which is just the kind of behaviour that consumers dislike, and what Ofcom's trying to protect them from.

Unfortunately, Ofcom's statement doesn't define what a "reasoned estimate" might be. Unless you rely on the manufacturer's statistics (which might be dangerous - you probably want to check it wasn't done in 1989 when answering machines crackled a lot more than they do today), you will have to listen to some recordings that your dialler thought were answering machines and count how many of them were really people. But how accurate does your AMD have to be?

It turns out the answer is "very accurate". Say you have a campaign with 40% answering machines and 20% live connections, and a 99% accurate AMD system. This would generate 4 silent calls in 1000 dial attempts (1% of 400 calls classified as answering machines turn out to be people).  Thats 4 out of the 6 (3% of 200 live connections) you can make without exceeding the target.  To take these silent calls into consideration, you need to turn your abandon call target to only allow 2 abandoned calls.  To do that, you need to set an abandon call target of only 1% (and that's with a proven 99% acurate AMD system!). Most predictive diallers, will struggle to give you good performance with this target. If the AMD is 98% acurate it will generate 8 silent calls, 2 more than you're allowed, and you might get fined no matter what you set the abandon call target value to.

So how accurate is your AMD system, and how can you work it out? The best  way todo this is to listen to some recordings. Take a sample of all the recordings where the dialler thought it had called an answering machine, and count the ones which weren't.

The next question is: How many calls do we need to listen to for a "reasoned estimate" of our AMD's accuracy? Well, it's not terribly clear what a "reasoned estimate" should be, but in the academic and scientific worlds, "95% certain" is the usual test.

It's not often that I get to use my Maths degree (it's a standing joke in Callmedia that I can't do basic arithmetic despite having studied maths), so when Rufus challenged me to find an answer to this question, I enjoyed solving it.

The way to work this out is by analogy with tossing coins. If I toss a coin 100 times, then (assuming it's a fair coin), we can expect roughly 50 heads and 50 tails. Of course, I'm unlikely to get exactly 50 heads and 50 tails, it's more likely to be 46/54 or 42/58 or something like that. Certainly if I get 100 heads, I can be pretty sure that the coin's not fair.

So somewhere between 0/100 and 50/50 (or the other way around), there must be some point above which I think the coin is likely to be fair, and below which I can be fairly certain it's not.

The standard threshold used is "two standard deviations", or roughly 95% - that's the threshold where I can be 95% certain that the coin is fair. And it can be calculated fairly easily (I wrote a computer program to do it for me though, because adding up isn't my strongest point). 

It turns out that if you listen to 100 calls, and 1 of them turns out to be a false positives, than you can be 95% certain that the real false positive rate is less than 3%. If you listen to 1000 calls and get 10 false positives, you still can't be reasonably certain the real false postive rate is less than 1.5%. You have to listen to 10,000 recordings (and get 100 false positives) to be fairly sure it's less than 1.17%. That's going to take a lot of time.

The bottom line is: your AMD has to be incredibly accurate to work under the new rules, and to be sure it's that good, you're going to have to listen to an awful lot of calls - several thousand at least. It might be time to ask if you really need AMD after all?

If you want to work out how many recordings you need to listen to to be 95% certain of your AMD accuracy leave a comment. If there's enough interest, we'll turn our calculator into a web-based applet.

David Groves

Product Marketing Director

Callmedia

How to set up Integrated Windows Logon

This is a nice feature that's been in the product for some time, but not too many people know about. You can set Enterprise (and Advance) to auto-login when a user logs in to Windows:

a. Set Desktops registry value: HKEY_LOCAL_MACHINE\SOFTWARE\Callmedia\Callmedia Desktop\General\UseWindowsLogonAccount to 1

b. Set Enterprise user logon to Windows logon (ie: luke.talbot).

c. Set Enterprise user password to callmedia

That's it. Your users will no longer have to remember an additional password!

(NB: Prior to 4.3, you had to set the Enterprise user password to blank for this to work).

Installing Callmedia Client

Installing Callmedia Client and Desktop on a single machine is very straightforward. Just insert the CD-ROM and run "setup.exe" and you're there. Deploying it on several hundred machines in the contact centre in this way is much less fun - but the good news is that there are several different ways of installing the software remotely and automatically.

Initial Installation

The Callmedia Client and Desktop are packaged as an MSI (MicroSoft Installer) package. This means that you can use Group Policy Objects to get them automatically installed. Microsoft have details on how to use Group Policy Objects to run MSI installers automatically. Alternatively, you can create a batch file that will automatically run when the user logs in, and installs the software.

When writing batch files to install software there are a few "gotchas" you have to remember:

a) Batch files can't use UNC paths. So you have to map drives before you install software from them.

b) To install an MSI file, you use MSIEXEC.EXE

c) To install from an EXE file, use the Start command.

d) Callmedia Client's configuration options aren't completely covered by MSI switches (see later). You may also need to use batch files to cope CMCLIENT32.INI files, or apply registry settings.

Here are some useful pointers if you use the MSI and Group Policy Objects route:

• Login scripts (ie: batch files) will run whenever a user logs on. This means it will re-run the installers on machines where components are already deployed. Batch files can be scripted to work around this. 
  
• Login scripts run as the user logs on. Therefore if an already installed CMClient32.exe starts up before the batch file has managed to install a new Hotfix, then the user will need to log off and on again for changes to take effect. 
  
• GPOs (Group Policy Objects) can be linked to machines as well as users, which means that on startup, the machine can install required packages before the Windows login prompt is presented to the user. 
  
• Unfortunately, GPOs cannot run standard EXEs. It is restricted to MSI and ZAP files. ZAP files can be setup to deploy EXEs (they’re just like Batch files), but they cannot be auto-deployed, only published (which lists them in the Add Programs list in Control Panel. This means thatyou will need to create batch files when you need to install Hotfixes (see later). 
  

The switches the Callmedia User Components.msi understands are:

CM_SETUPTYPE= [Express, Pro, Advance or Enterprise]  Note: there is no blended option. Use Enterprise. Express is no longer used.

INSTALLDIR= [installation directory]

CLIENT_IPADDRESS=
CLIENT_EXTN=[Extension number or "ASK"]
CLIENT_SOCKET=[default 4605]
CLIENT_BACKUP_IPADDRESS=[IP address of failover server]
CLIENT_BACKUP_SOCKET=
DESKTOPS_BROWSER=[0 or 1]
DESKTOPS_RESIZABLE=[0 or 1]
DESKTOPS_HOMEPAGE=[default URL for desktop-based browser]

Example Batch to install Client and Desktop

@echo off
REM If necessary, map network drive to point to Callmedia User components...
@echo off

REM If necessary, map network drive to point to Callmedia User components...
NET USE Z: \\Network _Filestore\Callmedia /USER:Callmedia\Administrator /PASSWORD:Geoff /PERSISTENT:NO

REM Go to dir for user components msi file...
CD "D:\User\Callmedia 4.1\User"
D:

REM Run MSI with appropriate switches...
REM /l* logs everything that MSIEXEC does to the msi.log file.
%systemroot%\system32\msiexec.exe /l* msi.log /i "Callmedia User Components.msi" /q INSTALLDIR="C:\program files\Callmedia" CMSETUP_TYPE="Enterprise"
CLIENT_IPADDRESS="192.168.1.1" CLIENT_SOCKET="4605" CLIENT_EXTN="ASK" DESKTOPS_BROWSER=0

REM Unmap network drive
NET USE Z: /DELETE


Hotfixes

All Callmedia Hotfixes are released as .EXE installers. These can only be auto-deployed by using a batch file (using the start command). For example:

REM Install Hotfixes...
Start /w Hotfix_U4_1_0_8.EXE /s /v/q

Configuration changes

Sometimes you will need to change the CMCLIENT32.INI file, or make registry setting changes. 
5. Odds and Sods: Hotfixes, CMClient32.ini files and Registry setting changes.  You have two options:
a. Add a Batch file Login Script that applies these changes.
b. Create an MSI that applies these changes. WinINSTALL LE 2003 is a free tool, available to download here: http://www.simtel.net/product.php?id=70765&SiteID=simtel.net. The MSI can then be added as a GPO package and deployed in the same way as Callmedia User Components MSI.

Future directions

As you may have gathered from reading this, installing and keeping the client components of Callmedia can require careful planning - it's not the sort of thing you want to get wrong. So in version 5.0, we are introducing another means of installing and updating the client and desktop, which automatically checks to see if a new version is available, and installs it. We're also going to make it available on Callmedia 4.4.

Configuring Client Extensions

There are many ways to get Clients to obtain a valid Extension number. Well, actually, there are three. Two are quite common, one is less common:

1. Asking users for their Extension number. This is achieved by setting EXTNO=ASK in the CMClient32.ini file.
Advantages: Popular because of its easy deployment (everyone shares identical ini files), and also because on many sites users have to Hotdesk whilst always retaining the same extension number.
Disadvantages: Common issues include users inputting invalid Extension numbers. Server Console offers limited assistance here: you can restrict input to 4 numerical characters for instance. But CMClient32.exe doesn’t support re-entering numbers if they are invalid anyway, which is nice.

2. Hard-coded Extensions, by setting EXTNO=2001, for example.
Advantages: This is useful for people whose extension number is always next to the same Windows machine.
Disadvantages: Common issues with this are the fact that machines and phones sometimes get swapped over, which means the CMClient32.ini file would need to be changed. Deployment is also not easy because all machines have unique ini files; this can be a maintenance/installation nightmare for large sites.

3. Host-Table Lookup. This is configured by adding the ServerLookupUptions=ASKEXT to the [Options] section of the CMClient32.ini file. Client then ignores the EXTNO setting, and asks server to give it an extension number based on the Hostname of the client machine. Nifty. This even works in Terminal Server and Citrix environments (it uses the machine name of the terminal).
Advantages: As with hard-coded extensions, this is great because it takes agent-error out of the equation. It is better than Hard-coding into the ini file however, because the host table is maintained from Server Console. This means that the CMClient32.ini files are all identical, which makes deployment a doddle.
Disadvantages: For this to be effective you have to 100% on which machine is next to which extension. As with Hard-coding, this is pretty much irrelevant if users need to hotdesk and take their extension numbers with them (ie: if they use NICE voice recording).

Internal Call Transfers

Callmedia 5.0 will introduce a feature call Expert Collaboration, which will enable users to select a user or queue and transfer a call, together with full cradle-to-grave reporting of calls throughout the contact centre. If you need to see how many calls your users transferred to a queue today, there are two methods you can use measure the number of transfers:

1. Create Transfer Queues
Advantages: You can transfer calls internally to a queue specifically set up for transfers. Because there's a seperate queue for these calls, they will automatically be reported on seperately. You could even treat them differently, ie: presented at far higher priority. Transfers can target a particular agent by skill. Cold transfers can present different queuing messages so that the customer is aware they are in a priority queue. The user who answers the call will know it’s been transferred by the queue name.
Disadvantages: You may need to set up a lot of queues to make this work. Also, there are only 250 queues maximum, and some larger sites are getting close to this limit. Also, to effectively see total queue traffic, you will need to add these internal transfers on, in real time and in historical reporting.

2. Create Alpha Tags
Advantages: It’s like this is what they were designed for! Making an alpha tag with the Queue point number as the DDI and ‘Internal Transfer to Sales’ as the tag means that the agents simply transfer the call to the queue they want it to go to. It’s reportable on its own, but still appears in the total queue stats. The user will see it’s been internally transferred, too, which is nice. Finally: no new queues or trigger points.
Disadvantages: You can’t ramp up priority on internal transfers. Transfers can’t go to targeted users by skill. You can’t give cold transfers transfer-specific messages.

When can I create an ad-hoc task?

Ad-hoc tasks are one of the things that makes Callmedia Enterprise different from other contact centre systems. Effectively, they allow you to count (and measure time spent on) activities not managed directly by the contact centre: replying to letters, making calls directly from your extension, answering people who called your DDI, or practically anything else.

The system automatically creates an ad-hoc task for you when you answer an external call, or if you make a call from your handset (unless you disable it). But there are some wrinkles you need to be aware of:

1) You can make Ad Hoc tasks from the following states:

• WAITING (inbound)
  
• NOT AVAILABLE (any reason)
  
• WRAPUP 
  

For WRAPUP, default Enterprise settings will cause a manual outbound call to be classified as ‘Ad Hoc rejected’; the user remains in WRAPUP. For users in WAITING or NOT AVAILABLE, a new task will be created. For all cases the manual calls will be reported on, but for rejected tasks, the task time is null.

2) Enterprise can be configured to ‘Make Follow On task’ should a call be made whilst in WRAPUP. In this case, the WRAPUP state will be ended and the previous call completed with no result code. A new task will be made.

3) Whilst in Blended Outbound mode (Preview, Progressive or Predictive outbound dialling), Ad Hoc tasks should not be initiated, and indeed will always result in a rejected Ad Hoc task.

4) Ad Hoc tasks cannot be made from the following states:
a. ALERTING (the agent’s phone is ringing)
b. BUSY (talking)

Alpha Tags vs Queues

Alpha Tags in Callmedia (first appearing in 4.2) allow you to assign a name to a DDI, so that users can answer a call with a different salutation, even if they come from the same queue. Historical reports can also report on calls by DDI (and if an Alpha-tag is defined for the DDI, the reports shows the name of the DDI). As a result, there are two ways of defining services into the contact centre:

1. Define a Queue for each DDI

Advantages: Each queue is a unique skill, has its own SLA and Priority. Each Trigger Point is usually unique (but doesn't need to be on ACM), allowing the customer to have different messaging/routing for each DDI. This is the easiest to explain and understand: each number goes into one Trigger Point goes into one Queue.

Disadvantages: Larger sites with many queues become more difficult to manage. There is a system-wide limit of 250 queues on Callmedia systems up to version 4.4. Because this applies to all queues, larger installations - particularly those using ad-hoc tasks and Router queues can find themselves running out (in Callmedia 5.0 we're changing the limit to apply to Managed Queues only, which will make life easier). Each managed queue uses 2 unique VDNs/HCIs/Departments for its basic routing, so maintaining the telephone system configuration becomes more onerous. Also, because each queue is a unique skill, if you have a generic team that answers everything, that’s 250 ticks in 250 boxes.

2. Define a Queue for multiple DDIs (using one Trigger point), and use Alpha-tags to give each DDI a name.

Advantages: The switch routes all DDIs to the same entry point. The advantage is it’s simple to set up, both for Callmedia and the switch engineer, and it's simple to keep track of - so easier to maintain. It reduces the number of managed queues required, which makes it easier to fit inside the limit of 250 queues. Users get to see the alpha-tag in their toolbar when they receive a call, so they can handle the call appropriately. Most of our larger customers use this configuration for some of their DDIs.
Disadvantages: Very little config = little flexibility. You only have one skill for multiple DDIs, you also one have one in queue messaging scenario. All calls are treated the same, regardless of their importance. From Callmedia 4.2, you have DDI reports (and from 4.3, Alpha-tag reporting). On Mitel and Cisco, the caller experience can't be configured for each DDI (you can do this on Avaya CM).

One other thing to bear in mind: Alpha Tags are only visible in historical reports and via Desktops (for the agent). They can't be used in Real-time Statistics or Webview.