Using a Telephony Solution To Route Email vs an ERMS

Posted on 8/13/2012 by Scott Whitsitt in Best Practices ACD Routing
image

One of the more common questions we get from prospects has to do with using an existing telephony solution to route incoming email to agents, versus using an Email Response Management Software (ERMS) package like iService. This is a great question, and there are some big differences between routing and managing voice calls versus email. But, whether or not it makes sense to use a full ERMS often depends on several factors such as the number of messages you need to manage.

Synchronous vs Asynchronous Conversations

Voice and chat interactions are synchronous, meaning there is an ongoing and real-time back and forth dialogue between your agent and your customer. Although the agent that accepts the call might forward the call to another agent, the conversation will take place as one continuous process.

Email is asynchronous, meaning that a message arrives and is processed separately from the response. It's not uncommon for some email messages to require input from other people, and in some cases the question might require research before a response is provided ... essentially placing the message "on hold."

The concept of forwarding in iService, for example, includes forwarding messages to:
  • another queue for automated reassignment - a question routed to technical support might need to be re-queued for product returns.
  • another agent - John might assign the message directly to Julie, if she is known to be the person that will handle the message
  • a person that is not an iService agent at all - a message arrives in customer support, but you need someone from legal or accounting to provide the answer and they are not licensed agents
  • another segment within iService that has its own separate configuration - a message that is received by customer support might be related to a job inquiry and passed along to an HR department's segment for handling

As you can see, the movement of email through the response process often requires forwarding capabilities that don't fit very well into a telephony oriented ACD system. At low volume, its usually not a big deal. But as volume increases, your process will break down without this type of functionality.

Message Processing and Text Analysis

ERMS systems, like iService, are designed around a very robust message processing engine that is capable of automatically examining many aspects of an incoming message before it is routed or assigned. For instance, iService has the ability to process an unlimited number of regular expression (RegEx) matches on the message header, body, attachments and even contact properties such as whether the sender is a Platinum customer.

These "filters" can then execute a range of actions such as:

  • Changing the message thread or "case" that the message is in
  • Changing the queue in which the message is routed (e.g., move automatically from sales to technical support)
  • Setting property values in the database that can help with assignment, reporting, or down process activities (e.g., setting language to "spanish" or capturing the order number from the body of the email)
  • Resolve the interaction and mark it as completed (e.g., confirmed SPAM message)
  • Distribute the message evenly among agents, rather than via the standard kills-based routing approach (e.g., distributing leads to sales people evenly)
  • Send a notice to someone regarding the incoming message (e.g., notify the call center manager when a message is received from irs.gov)
  • Reclassify undeliverable messages, find the original contact's address from the message attachments, and then mark the contact as having a bad email address.

If you think about the origin of the routing solutions provided by telephony vendors, it's logical that they would be weaker in the text processing area. They have been evolved from a product base built around handling voice traffic, while the ERMS systems like iService were built specifically to handle email and text-based interactions.

Work Flow Considerations

The concept of routing within a telephony-based ACD is usually tied to the availability of the agent. They log into the ACD and indicate their status, and the ACD considers their skills and those required for queued calls and messages. If the agent is not online and "available", the concept of assigning them messages can become less efficient.

For example, consider tthe issue of handling the follow up response from a customer when there is back and forth dialogue. The ideal solution is to route the customer response back to the original agent, but in a telephony ACD environment that can be tricky to manage if the agent is not online and available at the moment.

Within iService, you have a variety of options including assigning the message if the agent is offline so they can get it when they return. Or, if you operate a 24x7 contact center you can have messages on an agent-by-agent basis re-queue for the next available agent when the original agent is offline.

Differences Are Compounded by Volume

There are many other differences between the approach taken by a telephony ACD versus ERMS application, not the least of which is the productivity tools provided to agents or the automated handling of responses. But the bottom line is that if you have very low email volume these differences and workflow issues could be immaterial to your overall support process. If your team handles 40-50 emails per day, for instance, it probably doesn't make sense to invest in an ERMS application if your ACD can handle the routing of email along with voice calls.

On the other hand, if you get hundreds of incoming emails per day the productivity from an ERMS product suddenly become pretty compelling.

Comments