A contact center engineer’s worst nightmare
Imagine that you are a network engineer responsible for your company’s on-prem contact center. You are getting reports that “the contact center is down”! But, all the lights on the Network Monitoring System dashboard are green. No cpu issue. No memory issues. No hard drive issues. No network issues. No process issues. So why is everyone saying “the contact center is down”?
What do you do?
Now you must begin the painstaking task of sifting through the terabytes of information available across multiple folder of multiple servers to find the problem that shouldn’t be there. You know it’s there. It’s just a matter of tracking it down.
Who has time to trace logs?
How long will this take while your manager is breathing down your back? While the directors are sending emails and leaving voicemails. While the C-level executives are slowly getting involved. And they’re all looking at you.
The contact center is down, even though every monitoring system at your disposable says everything is fine. Every minute, every hour that ticks away, your company is losing more money and the emails and voicemails are getting more heated… What do you do?
The problem is not in your contact center
To be honest, this happens far too often. The problem is not in your contact center. Your contact center is working just as it was designed to work.
The problem is in your monitoring system. You see, the heavy lifting of monitoring a contact center cannot be carried out by network and device monitoring. This type of monitoring will find some issues, but not the issues that cause major, and often undiscovered, outages.
You need log monitoring!
Your contact center software, applications, processes, servers all write to logs. The only way to truly know what is actually going on in your contact center is by monitoring those logs.
Yes, I know what you’re thinking… there are dozens, hundreds of logs. How can anyone, even a team of engineers, monitoring that many logs.
The answer is simple… you can’t.
Instead, your monitoring system must include the ability to monitor logs as well as it monitors networks and devices.
CtiPath’s Managed Services
CtiPath’s Managed Services for enterprise contact centers was designed almost a decade ago from the ground up to monitor logs. We did not add on a log monitoring system once we realized something was missing. Our services are built around log monitoring.
We create “service definitions” that our system uses as patterns to detect issues in the logs, often before anyone even reports “the contact center is down”. The begin with a huge base of over 10,000 standard service definitions, then we add custom service definitions to fit the operational and business objects of each customer.
Once our system triggers on one of these “service definitions”, our engineers work hand-in-hand with our customers to identify, mitigate, and correct the underlying problem… sometimes while the NMS dashboard stays green.
Why does this matter?
Every second an engineer spends searching through the myriad of logs to find a problem in the contact center, the company is losing money and the company’s customers are getting angry. It matters because it costs the company time and money and morale and customers… all of which add up to even more money.
Don’t wait for a contact center outage to demonstrate that you need a managed services provider.
And can you afford a Contact Center managed services provider that is not built around monitoring logs?
How does it work?
Log monitoring is a central part of CtiPath’s Managed Services for contact centers. It’s composed of four parts:
Service Definitions
These proprietary patterns have been created by CtiPath after years of monitoring contact centers. They represent over 10,000 events logged by contact centers that could potentially indicate a issue to be tracked and/or corrected. As CtiPath works with a customer, we add additional custom service definitions to match the customer’s business needs and environment.
Monitoring Controller
The monitoring controller is a proprietary cloud-based services that delivers service definitions to the log aggregator and accepts event notifications from the log aggregator.
Log Aggregator
The log aggregator lives in the customer’s environment and continuously searches all the contact center logs for service definition patterns. When a pattern occurs, the log aggregator notifies the monitoring controller.
Trained Engineers
The final, and perhaps most important, part of log monitoring is a staff of trained engineers. These engineers not only know the customer’s contact center environment, they also understand how log monitoring works. They are able to dive deeper into logs quickly (if necessary) based on information from the log aggregator. Furthermore, these engineers are able to “close the gap” and create new service definitions to monitor the customer’s contact center even more effectively.
Application log monitoring
Enterprise application monitoring must include log monitoring!
Enterprise contact center is one example of a mission-critical, real-time application that must include log monitoring in order to completely understand how well the application is running. But, it’s not the only application. Any real-time application that the enterprise relies on, especially mission-critical application, must include log monitoring. Otherwise, the enterprise application could grind to a halt while the network monitoring dashboard stays green.
Let CtiPath help you monitor your critical, real-time enterprise applications so that you Engage Better!
What do our customers say?
CtiPath consistently performs above expectations. Their personalized service sets them apart from other vendors. I couldn’t imagine operating without CtiPath.
