Lync Server, in the midst of everything it does so well, is not a call center. But, Lync does not want to be a call center – that functionality is well provided by a raft of third-party ISV-types who specialize in providing Call Center services or software. But when you look at those specialized services and software, what is missing is the immediacy of the small group, and what is present is a hefty price tag. To answer the smaller need, Lync Server offers the Response Group Service.
One of the key features in call center software is the ability to monitor the actions of the various agents and groups to ensure that calls are being handled in a timely manner – in other words – allow business decisions to be made with actual data and not guesses. But there is nothing built-in to Lync that matches this ability. The Lync 2013 Resource Kit RGAgentLive tool – part of the Lync Resource Kit – does not answer any of these questions.
Lync Response Groups offer a small-case solution; from one or two RGS workflows or dozens – and I know of organizations that have, literally, hundreds of Response Groups workflows. However, once you have decided to use Lync RGS, and you have business critical operations that use the RGS, how do you monitor the performance and response of the RGS? And what if you have more than a few that you need to monitor? How can you tell if the agent groups are responding to the RGS calls in a timely manner? How can you decide if you need more agents to handle the call volume? How can you determine if you are meeting your performance metrics or who is doing what? Are your agents even logged into the system? Are they being good RGS answer people?
In this article, we will take a look at how Advatel Espera helps provide answers and information it can provide to organizations who are using Lync Response Groups. First off, here is where you can get the official market-speak. In reading through that material, you will realize that Espera has two components, the real-time monitor, and the reporting piece. Personally, I was first interested in the reporting piece, because, face it, the Lync monitoring server reports, while it does have all the information that Espera uses, is not exactly what is known as “user friendly.” In the end, I liked the real-time monitor aspect just as much as the reporting.
Here is the official blurb straight from Advatel:
AdvaTel is a Microsoft ISV and TAP development partner where Espera is a Microsoft Lync ISV Qualified Solution which will provide enhanced real-time dashboard display and reporting by leveraging on the built in features of Response Groups without adding any additional hardware. Lync has some excellent call queuing capabilities within their Response Group technology. They provide for inter-flows and over-flows etc. and a number of call routing capabilities. The problem is that the “missing link” was users cannot “see” the queue status. Hence the critical and vital need for Espera Real Time and Espera Reporter.
Espera has two major components, and a client-side install. In the client-side install, there is a separate Lync 2010 and Lync 2013 installer. The server setup is very straightforward. The documentation for the install is extensive, heavily reliant on screen shots; and if you cannot follow along and get your server installed, then you need to find a different profession. Really. The documentation even covers using 2008R2 and 2012 and the differences. Two thumbs up to whoever put together the documentation for the server install.
You will need to have a server upon which to install the Lync Server Core components – an application server if you will. I used a 2012 R2 virtual and had zero install issues. The application server needs to be listed in the Lync Topology as Trusted Application Server.
Part of the server setup is to configure permissions on the LcsCDR, Rgsconfig, RgsDyn, RTC, and XDS databases on whatever SQL server you have setup. The install documentation does not cover SQL 2012 R2, so you may have to read between the lines a bit – however, I got it done with minimal effort.
Once you get the server installed, the configuration to match up with your Lync environment is also straightforward. There are some highlights… in my case, the “Auto Configuration” did not work so well. This necessitated a short period of me flailing away trying to figure out just what went wrong. Not finding any obvious error, I cleverly turned to Espera support.
Here is what I was seeing:
As it turned out, the answer was staring at me… the “Lync Address (or DNS)” auto-filled to the SQL server that held the LcsCDR, which looked OK to me; turns out that field is very literal – it needed to be my EE pool FQDN.
Once past that little blip, things were copacetic. Note that the “Printer Service” is failing because, duh!, there is no printer installed.
Two nice things about Espera. First, Reporting has the ability to send email reports via schedule or on demand (by scheduling a one-time report). I had a bit of an issue getting that to work – turns out that the email server setup does not need to have user credentials, if you put them in there and don’t hit the check box, the SMTP process won’t kick off. If you configure it like this you should not have any issues. I am assuming you know how to authorize Exchange (or some other SMTP server) to receive email from specific IP addresses… you also need to include your allowed email domains.
The second nice thing is a feature not found in Lync at all – a wrap up option – which gives the agent handling the call an opportunity to classify the call on termination. Handy, and more on that later – but you need to tick the check box on the server to get that feature enabled.
So, the host server is built (or you used an existing server), Espera Server is installed, now let’s look at the client-side work.
If you use Lync 2013, you can skip a bit. But if you use Lync 2010, you will need to make a few mods to a config file.
Here is the configuration file change details. Even I got it done on the first try.
Change Espera Client Communication Type
1. Open the "EsperaClient.exe.config" file located at
"C:\Program Files (x86)\Advatel\Espera Client\bin\EsperaClient.exe.config”.
NOTE: You may need to open this file with administrator access so that you can save the
2. Change the value of
<add key="TcpRemoteServerAddress" value="0.0.0.0" />
with the FQDN or IP Address of the Espera Server.
3. Change the value of
<setting name="CommunicationType" serializeAs="String">
4. Save and close the "EsperaClient.exe.config" file
5. Close the "Espera Real-time Window" (if open)
6. Exit the "Espera Client Launcher" from the system tray (icon near the clock)
7. Start the "Espera Client Launcher" from "Start>Programs>Espera Client"
I also had some issues getting Espera components configured and installed, but those issues were purely on the odd workstation environment I have in my lab. It turns out that the .net4 installer included with the Espera Client did not like running on my workstation from inside the zip file. And then the .net4 installer did not like running outside of the zip unless I invoked it from a cmd session using explicit runas /user:administrator. No, the workstation is NOT a domain member – which may or may not have contributed. FWIW, the workstation is a Win7x64 virtual. But, no matter, in the end I leveraged my good looks and excessive charm and overcame the evil operating system. My Win8.1 Lync 2013 client installed without issue.
Espera places a sidecar on the Lync client. Without going into morbid details of what is what here is the Lync 2013 client running on a Win8.1 and this example is the Espera system administrator account:
Here is the Espera client, this time on Lync 2010, running as a regular RGS agent – not and administrator. Notice the difference in the number of Espera buttons available to each level of user. Chicken.Hawk has administrative and supervisor functions lit up, and the other account does not.
Also note that the client functions are covered in the Espera documentation, so I am not going to go over all of them here. But I will note that the two “key” looking buttons will change function depending on the RGS itself…is the RGS workflow formal or informal? If informal, when the Lync client signs in, the Espera client will just log into the RGS monitoring functions as well. If the RGS is formal, the buttons serve to allow the agent to manually sign-in/sign-out.
Your RGS agents might well be working remotely – not a problem. Espera will cross the Edge server.
At about this time, you should probably realize that I am not going to start quoting 100+ pages of user documentation. However, we are going to look at some basic configuration – and that is done using the aforementioned administrator/supervisor login. You should get ahold of the user documentation – there is some serious configuration that you can do to customize Espera real time, and reporting, so as to get the most out of this product. However, I cannot find anything out in the wild that you can download so you could read and follow along here. I suppose you could register for an account up on advatel.com.au. But I did that and did not see the user guide available. You can contact this email address to get the Espera documentation: firstname.lastname@example.org
Here is my administrator real-time display:
I only have two RGS workflows in my lab, so the results are a bit sparse. However, here is the configuration screen options – you can see that a full implementation could easily have a full screen of RGS monitors – and you can get this up on a large screen up on the wall – just like in a call center.
Here is my other RGS agent looking at a different view.
You can color code things so the supervisors can see at a glance that something might be amiss.
Espera Reports can be emailed, either on demand, or on a schedule. The reports can be in CSV format for you to play with, or they can be in xps format for immediate consumption. The reporting has some canned reports, but some inventive person can also create custom reports. Here is an example – in this case the agent wrap-up report where the agents can classify the call when the session is complete.
Lync 2013 has a Response Group Service that can function as a quasi-light-weight call center. Because of the expense and complexity of full-blown call center software or services, the RGS is perfect for some environments. Suppose you have an IT help desk with 6 agents, and you want to keep track of performance and enable the agents to be more aware of what is going on with their primary job function. Advatel Espera might well be the tool for you. Easy to install, customizable, and enables management and agents alike to better tune their performance.
The server side install was fairly painless, and running on minimal (by today’s standards) resources. The client-side install was, for the most part, easy-peasy (outside of my wacky Win7x64 workstation). My experience with Espera support was excellent, and Advatel responsiveness to my idiotic questions and naive product suggestions was refreshing.
I have not done this Lync add-in tool justice in this review. My lab only has two RGS workflows, and I have a limited number of resources to use as agents. Accordingly, here is a three minute video, and if that whets your appetite just a little, I suggest you contact Advatel and get a full demo.
The demo I saw was very good, and if I had RGS like some of my clients, I would be taking a long look to see if Espera would fit in and help solve my problems. This is a Lync add-in that I can recommend.