Thursday, December 18, 2014

I Put My Software On The Cloud

(with apologies to Wordsworth)

I put my software on the Cloud
That floats on high and pays the bills,
When all at once I saw a crowd,
A host, of agents with theirs skills;
They had their headsets, all hand-frees,
Fluttering and dancing in the breeze.

Continuous as the stars that shine
And twinkle on the milky way,
They stretched in never-ending line
Along the progress of the day:
One thousand saw I at a glance,
Tossing their heads in sprightly dance.

The techs beside them danced; but they
Out-did the rumpled nerds in glee:
A supervisor was heard to say,
"You're all the greatest company!"
I gazed--and gazed--but little thought
What wealth the show to me had brought:

For oft, when on my couch I lie
In vacant or in pensive mood,                             
They flash upon that inward eye
Which is the bliss of solitude;
And then my heart with pleasure fills,
And dances with the agent skills.

Tuesday, December 16, 2014

Distinct Agent Logins in Multi-Tenant Call Centers

None of these people are me. Not even the
one in the bottom left corner
There is more than one person named Stephen Ray. There are even more people who have Stephen and Ray as part of their name. It's not the most common name; I'm sure there are a lot more John Smiths, Maria Silvas, etc.. Large call centers often have to contend with name clashes when designating login names for various services, especially when you consider a few years of normal employee turnover. The problem compounds when you are using multi-tenant call center software.

An individual tenant can be left to determine the best way to handle name collisions. Not allowing duplicate login names is an easy way to enforce this. If an administrator tries to create a new user with an existing login name, the system should report an error and force the admin to change the name they are attempting to use. This is pretty straightforward. However, with multiple tenants, this approach, unmodified, won't work. If a tenant does not have someone with the username jsmith, but they are unable to create one due to it's previous use, they now know a login name that's valid for the system.

One approach that works to resolve this problem is to combine the username with another factor and present both as login credentials. The password initially seems an obvious choice as it is already required, but allowing another tenant to do username/password checks on other tenants would be a nightmare. The next obvious step is to have the agent identify the tenant they are logging into. Again, we want to avoid leaking information about tenants to other tenants. An approach that can do this without requiring the agent to provide additional information on the login screen is to use a unique hostname per tenant. This is the method Q-Suite uses.

Hostnames are a good choice for the identification factor as they are usually simple enough to configure for users that require a multi-tenant solution in the first place. For a cloud-based call center, external DNS (Domain Name System) is usually used to provide distinct hostnames to the agent web server. As an example, a multi-tenant site hosted at might use for their Indosoft tenant, and for the Megacorp tenant. If multiple hosts are required per tenant, the Q-Suite does allow the specification of wildcards, so * might be designated as belonging to the Megacorp tenant, with agents using for the first web server, for the second web server, and so on. For multi-tenant sites with internal infrastructure, local DNS may be sufficient. It is even possible that a client may update the hosts file on the agent machines in order to resolve the host to the correct IP address.

When using the hostname, the web server itself passes the hostname used as well as the page requested. The hostname used doesn't matter to the web server itself as long as the request reaches it. Obviously that's a bit of an oversimplification, but unless your call center software web server is also being used to serve websites for different hosts, the simplification matches the reality. It's then a simple matter for the software to match a host to a tenant, then check to see if that tenant has a username/password combination that matches the one supplied. This approach allows multiple tenants to accidentally use the same usernames without exposing information unnecessarily or requiring extra effort on the part of the agent.

Tuesday, December 9, 2014

The March of IP Telephony - Part 2

It's startling to realize how quickly IP telephony did get accepted. Even in 2008, when Rajan posted The March of IP telephony - Part 1, the bulk of our clients were using TDM boards. Digium and Sangoma hardware were our go-to choices. Innovators like those two companies were blowing up the market. This allowed Asterisk to continue to build on its foothold. Clients looking for stability were increasingly able to choose Asterisk, but still connecting via PRI. Selecting a quality VoIP carrier was a difficult process for those not sharing a colocation facility with a reputable provider.

With the widespread acceptance of Asterisk as a telephony option, the ability to utilize VoIP grew. Anybody who could install Asterisk could get a VoIP connection and hook up a few phones for an office PBX. Add in the general availability of broadband Internet, ubiquitous network access in the office for IP-based phones, and the maturity of VoIP carriers, and all the pieces were in place for an IP telephony boom.

Somewhere in the last five years, VoIP has been fully embraced, and the number of requests for connections to PRIs has dropped dramatically. Typically, even an on-premise Q-Suite call center software install with PRIs will utilize a PRI-to-SIP adaptor to allow a high-availability solution. Much more common is a dedicated high-speed link that allows a large volume of calls to be transacted between the call center and a quality SIP provider. Such an arrangement is the key driver behind the ready deployment of Cloud-based call center software. It will be interesting to see where the contact center is in the next five years.

Tuesday, December 2, 2014

Things I noticed this week

I would just like to call attention to a few things I liked in the past week:

Justin Traer wrote "Security Hardening for Asterisk: Privilege Escalations with Dialplan Functions" describing how privilege escalation could be used in an Asterisk environment and steps that can prevent such a thing. Asterisk is close to my heart, so I think it's an important post.

Shaun wrote "Inbound Campaign Scheduling In the Call Center ACD." That ties right in with aspects of Monday's post. In fact, I linked to it. We didn't plan it that way; coincidence is funny.

With "Black Friday" behind us, Brian's article on "Real Time Agent Skill Reassignment for ACD Queues" is still relevant. During the holiday season, centers are susceptible to peaks in calls and agent shortages. The ability to reassign agents live in the call center can come in handy.

On a slightly lighter note (sorry, dad jokes are my thing), James posted a quick article about how using hue lighting can be used as a notification system. There was a previous post on the Indosoft blog that also mentioned them briefly. It's an interesting technology. 

Monday, December 1, 2014

Number management in Multi-tenant call center software

In any multi-tenant call center software, tenants must be able to create, assign and configure their DIDs (Direct Inward Dial) in order to be able to receive calls and direct them appropriately. The DID itself is a convenient way to determine which way a call should be directed; to an IVR, for example, or a specific PBX extension. Software like the Indosoft Q-Suite can be configured to use a DID and a schedule to determine how and when a call should be directed, with the ability to specify a dialplan and queue during operational hours and an after hours dialplan for when the call center ACD is closed.

On the individual tenant level, just about any call center and PBX feature should be assignable to a DID. On the PBX side, the most common case is individual extensions. Of course, ring groups, conference rooms, and even simple Asterisk queues should be reachable directly from the outside world. Additional services such as access to voicemail or advanced functionality can also be made available. These are usually simple cases where the DID should route quickly and directly.

In a multi-tenant situation, there will be a top-level "super" admin who is responsible for configuring tenants and granting access to resources, etc.. These users should have the ability to view all the DIDs for the system and monitor their use. Another question for the owners of the system is "how are calls to local DIDs dialed?" This can affect both reporting and dialing costs. Here are some examples:

  1. Two tenants do unrelated calling, but share a common owner. Calls are expected to be transferred between the two tenants from time to time, and it would be advantageous to avoid the cost of sending the transfer through the carrier (or carriers). 
  2. Two tenants are completely unrelated. It's possible that a call may be placed from one to another, just as calls are placed between companies every day. There is no expectation that calls would not be routed through the carrier. 
  3. Two tenants do unrelated calling, but share a common owner. Calls are expected to be transferred between the two tenants from time to time, but the carrier provides additional data collection and reporting on calls. The extra cost born does not outweigh the value of those additional provider records in case of an audit or lawsuit.

In the first case, it is advantageous to have the system resolve all local DIDs, whether belonging to the same tenant or not, without routing the call back out through the carrier. In the second case, it would presumably be expected by the tenants that calls would be routed out and back in. In the last case, the site should be configured to route all non-local non-tenant DIDs out over the carrier and back in again, incurring the additional cost. These cases will have to be kept in consideration when the site is being configured. In the case where unrelated tenants are using the system, it is probably best to leave it to route non-tenant DIDs over the carrier.

Sunday, November 30, 2014

A Quick Note About Post Scheduling

In the history of this blog, we've not discussed scheduling, letting posts fall where they may. Since taking over, I've been trying to maintain a regular schedule of Monday posts, with an occasional Wednesday or Thursday note. For the time being, I will be posting on Tuesdays, with any supplemental posts happening on Thursday. I'll re-evaluate early in the new year, but I think this schedule will fit a bit better with my other responsibilities.

See you on Tuesday.

Monday, November 24, 2014

Populating Client Information to Agents in Your ACD - Part 2

In Populating Client Information to Agents in Your ACD - Part 1 I talked about getting your client data into your call center ACD software. That's an important step, but it doesn't complete the task. Today I want to address the topic of finding the particular contact who is calling in and presenting that information to the call center agent.

Identifying Callers

There are a few ways the caller can be identified. Building a dialplan through a call flow builder allows an opportunity to do matching via the caller ID or by data entered by the user. Additional information may be consulted to assist with identification, such as the DID the client called in on. Other methods will require agent intervention.

Caller ID Match in Dialplan

A good IVR builder should allow you to match or branch on available data such as the caller ID. Not every call will present a valid caller ID due to technological, jurisdictional and privacy considerations. The number of calls that do come in with a valid caller ID make it a good, solid starting point for determining the identity of the caller. If you don't have duplicate phone numbers in your lists, and you can determine which list of contacts to match against based on the dialed DID, it should be a simple matter to match a contact based on the phone number and send that along as part of the call information. In cases where no match is found, or the caller ID was unidentifiable, you can branch to a section of dialplan that collects more information, or pass it to the agent as-is for matching on the agent side.

Getting an Identifier in the IVR

A match may not be possible based on caller ID. In that case, your IVR builder can be used to generate a bit of data collection. Using uploaded audio prompts, you can indicate which data you wish the caller to input, and use the dialplan functionality to read the supplied information. An account number might be requested, or even just the phone number that the client is calling in on if you're typically doing caller ID matching. Once the data has been collected, a match can be checked for again.

It should be noted that whether the caller ID is being used or other data collected in the dialplan builder, the matching can be done internally for locally-stored contacts, or via a web service when the data is held by a third party. The Q-Suite allows web service calls with any field that is available in the IVR at the time of the call to the service. This can include data entered in the IVR by the client.

Letting the Agent do the Search

If the call reaches the agent without the client having been identified, then the agent will have to do the work of identifying the lead. Ideally, the agent should have a client interaction script with search capabilities. Having the client on the other end should allow the agent to query certain fields to uniquely identify a client. Sometimes it will be necessary to add additional fields and try again, but the agent is in the best position to determine who is on the other end of the line. Even if the search returns multiple contacts, the agent should be able to determine the correct one with just a few questions.

If it turns out that the client is not currently in the system, the agent screen is where it makes the most sense to create the new contact. This does take additional time, but a properly worded script should allow the agent to collect the required information in the most efficient manner, allowing the agent to get on with the actual purpose of the call.

Once the agent is handling the call, it's important to make sure the contact information is up-to-date, especially for data that can change more frequently. By ensuring the currency of contact data, you can provide the best customer interaction possible.