How to Bridge the Gap Between Network and Application Groups

A_Part_of_Pittsburgh_by_titaniaThe internal help desk of an enterprise is the end-user’s single point of contact for ticket submission and troubleshooting. Unsurprisingly, the help desk receives tickets that range across the board from keyboard and mouse issues to application and network problems. A company may have one, two, or more levels of help desk support depending on its size, allowing ticket escalation to more specialized staff as needed. 

The help desk usually follows a decision flow chart on how to deal with each ticket. A typical procedure might looks like this:

1) Detection:
If user at a remote site reports that they can access internal applications (e.g. email and file services), but not external sites over the Internet, then you are dealing with a network problem along the path between the enterprise network and the upstream service provider.
2) Information Collection: Find out if the problems affects only that specific site or multiple sites

a. Call a few other sites to find out the extent of the problem
b. Collect information through remote desktop with “ping” and “traceroute”

3) Escalation: Open a ticket with the network group that includes all collected information

Similar procedures are followed for several different types of tickets. And although they might be widely used and accepted as best practice, they are mainly human driven. But there is room for improvement by automating manual steps in the ticket reporting and escalation process.

1) Information collection automation: If the help desk cannot troubleshoot the issue, it has to collect as much information as possible and escalate the ticket to the network or application group. Often this information is collected manually by receiving calls from end users at multiple sites or by using remote desktops to run tests from multiple sites. This is a time-consuming process that doesn’t scale in enterprise networks with dozens or hundreds of locations. Moreover, it is prone to error and inaccuracies as it is difficult to get the exact timeline of events and scale of the problem in a timely manner.

2) Proactive monitoring: Response and troubleshooting times would be much shorter if the help desk could proactively test if end users experience network or application problems, and even escalate before they start receiving phone calls.

3) Gap shortening between help desk and higher escalation levels: Among others, one help desk responsibility is to intelligently and selectively escalate tickets to the network and application groups. However, often the escalation process takes considerable time and there might be considerable back and forth until a problem is fully identified and resolved. If the end-user network and application experience could be shared in real-time between the help desk and other groups, it would be much more efficient to communicate the problem, its scale, and also know when it is fully resolved.

So, how can we improve this process?

These goals can be achieved using a network and application monitoring tool that captures the end-user experience in real-time, and is comprehensive and easy to use for both the help desk staff and the network and application groups. These tools fall in the distributed network and application monitoring space, and have certain characteristics that enable coverage of hundreds of company sites. These tools can even help network and application engineers to identify and address an issue without waiting for a ticket from the help desk since they provide a view of the end-user experience.

It is always challenging to refresh and rewrite established help desk policies that have been standard protocol for decades. Even more so when you have to seamlessly integrate the changes in order to maintain strict SLAs in terms of ticket response and resolution times during the transition period. However, the long term returns in efficiency and end-user satisfaction are worth the investment.

If you are interested in further reading you can find more information in a recent blog post on “Distributed Network Monitoring.”