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).

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.

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.

Voicemail on Mitel

This one comes straight from Mr Wardle… Obviously all switches are different, but generally when someone asks ‘How do we send calls to this queue to VM out of hours?’ we just say ‘route to that in the Trigger Points, dude!’. Ok, we don’t say dude. Not all the time… Unfortunately, Mr Mitel 3300 has a special way of achieving this that sets it aside from the rest of the bunch:

1. Create a Trigger Point with Entry and Queue HCI numbers

2. Create a Mailbox with the same number as the Entry HCI number

3. Point the Trigger point to the main VM number for OOH, No Skilled Users…

When the call is routed to the main VM number, it will use the Entry Point number for that Queue to know what mailbox to go to. This means that you have to ensure all Queue Entry Points have a matching Mailbox number.

It also means that it’s not possible to send all of the queues to the same mailbox, as all of the queues will have a different Entry HCI.

Useful stuff, Thanks Nick!