Best Practices for Building a Dialer Solution

From VESupport

Revision as of 04:46, 22 April 2013 by Laura (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Over the couple of years, I have spent a good deal of time designing, developing and advising many people on dialers. Where some have been predictive dialers, others simple power dialers or voice broadcasting systems, I have several times discussed the options for the overall architecture of these systems. Using Voice Elements in the native .NET environment with C Sharp, VB, ASP and all other web and other technologies, the options are wide open when looking at possible architectural paradigms. In this article, I would like to explain these typical ways of building these systems and discuss the pros and cons of each.

Firstly, I am assuming here that a typical dialer will have a voice component, being the dialer itself. This will contain the logic for consuming a campaign, an algorithm if predictive, and the ability to determine a dial result (most often if the recipient of the call has answered as human or machine). The second component is the interface for the agents which will pop up on their screen when an outbound call has found a human (sometimes a machine if desired), along with pertinent information about the target customer and also provide the ability for the agent to dispose of the call, enter comments and change data about the customer for future campaigns and reporting.


In future articles, I intend to elaborate on these entities in depth, but for now, I am going to focus on the different ways the dialer and agent interface can be designed to interact.


The Diagram below shows the basic entities in a typical dialer system with agents.

Dialer.png

Note that the connection between the dialer service and the agent interface is a dotted line, which is due to the options I will briefly present below that make this connection variable.

Option 1: No Agent Client – The Pure Web Site Interface

The most flexible option is to make the agent interface simply a website running in a browser.

Advantages

• This has the advantage of not requiring the agent to install any local software and be able to use the system from anywhere, different machines, and even mobile devices.

• When coupled with a soft phone, this is a very flexible architecture, especially for remote agents.

Disadvantages

• This solution will require additional interface development and testing to support multiple browsers.

• Security will require an agent login and more diligence, again extending development and testing.

• Pop ups may lose milliseconds or more when a call is routed, because the nature of a webpage being static; some kind of polling is usually necessary for the web page to check for a new call to refresh, populate with data and be available as quickly as possible with the call.

• As with all web pages, some advanced interface tools may be difficult to implement, especially across browsers (right clicking, tree views, etc).

Option 2: Agent Client Software

This option consists of a local application installed on the agent machine which communicates directly with the dialer service. Typically, this is a Windows Forms application.

Advantages

• Pop ups are instantaneous, as you may use events and WCF web service links to connect the dialer service to all of the agent interfaces.

• All interface options are available through .NET controls.

• Testing and development are significantly reduced by eliminating the need for cross browser support.

• A soft phone can be directly integrated into the interface.

• Built in .NET security and even building your own interface method is available, giving a myriad of security paradigms as options.

Disadvantages

• Agents must install software on their local machine.

In future articles, I will be exploring additional hybrid options for designing a dialer with agents, including predictive dialers and power dialers.

Personal tools