How an Internal IT Company Uses IncidentMonitor for their Service Desk

Company with around 1,000 employees of which around 300 in a mobile job. The support desk of 10 persons supports the internal staff as well as the employees in the field. People in the field are highly dependable on their mobile equipment and access to company systems via web and vpn. All services are organized according ITIL.

Demands:

• set up workflows according ITIL to force the company into procedures
• end users and support staff should be able to log and view tickets in a web support portal anytime anywhere
  
• mobile users must have access to the support portal via smart phones
• BYOD support for mobile users was necessary as the field staff tend to use home brought devices
• SLA’s on supporting mobile users is set at a stricter level as rest of company as mobile users must always be to get to business critical applications
• emails should be pushed into the support desk
• knowledge tips should be presented to users as well as support staff for quick solutions
  

How did we approach this with IncidentMonitor Service Desk Software

First of all we worked out the process flows the client wanted to use. Some simple, some more complex. But all easily dropped into IncidentMonitor. For this we used our admin Process Designer tool.

As IncidentMonitor comes out of the box with multiple clients, like web, windows and mobile, the second demand was easy to meet. We amended the service desk portal into the customers business style, opened the portal to known contacts and resources. Obviously taking care of the security. As IncidentMonitor service desk software is security checked by Symantec we were able to give the garantee of a secure web solution.

The client worked with a support e-mail address. With IncidentMonitor it was not necessary to change this approach. Emails directed to the support desk are picked up and dropped in the software automatically.

Mobile users

Mobility was another important demand from the company. As many employees are on the road servicing clients it was eminent that they must have access to the service desk portal via their iPhone, Android, Windows phone or Blackberry. The solution IncidentMonitor offered directly out of the box was the icon driven mobile interface which automatically opens while accessing the service desk via the mobile. Below an example!

As the users use their own devices often it was difficult to keep track of this in the old situation. With IncidentMonitor it is pretty simple to add new assets and tie those to a user. What we did was create a few templates in the asset database which represents the various devices the help desk run into. On a template it is easy to add custom fields to capture device specific information. New devices that appear are now quickly added and linked to a user. This realized a BYOD (Bring Your Own Device) support model which helps the support desk to quickly solve issues even on devices they never introduced in the company.

Mobile Users Specific SLA Demand

A specific demand was that mobile users had a more “important” role in the company. Simply because if they are able to do their job, the pressure on internal people drops giving them the opportunity to do a better job. Besides that it is simply the people in the field that bring in the money to pay for the rest of the company. In other words, they should be online at any time! Business critical applications used by both internal as field staff needed tighter resolution SLA’s than other tools. And any ticket coming in from a mobile user must be responded to within 30 minutes in order to analyze the urgency.

As with IncidentMonitor it is possible to create a matrix of rules which defines the time to respond as well as the time to resolve this complex service rules were implemented exactly as the client expected. For Mobile users we were able to define a contact type called Mobile User. When a contact with this mark logged a ticket the system automatically set it to a rule that the support desk should contact this person within the first 30 minutes. Defining this specific request to a problem with the business critical application set several actions in movement. From colour coding, to direct assignment to specific High Alert teams. All within the same and simple configuration.

Email communication

The company was very much used to sending emails to the support desk. Though with IncidentMonitor we introduced an online web portal where the contact is able to log calls, view calls, run reports, check knowledge base, etc.. they did not want to force the user community into using this portal. However, what they noticed was that when people email they tend to send very limited information. Use of web forms would help to collect the information the service desk was looking for. We came up with a pretty simple but very effective solution.

Contacts who emailed a problem to the helpdesk automatically received an answer per email within the next minute after sending the request.

The email got logged as a ticket in the system. As IncidentMonitor uses Smart Classification the email logged ticket auto classified the request based upon historical information and the knowledge base. The email back to client informed the client that the support desk received their information but that they highly appreciate to follow a link in the email to a specific form. This link directly opened the Support Portal in the correct form. Showing the contact his own info plus a few open questions the service desk liked to get answered.

The solution actually achieved two goals. One the support desk received on 95% of their tickets all the info they needed without needing to ask for it and two contacts started to get used to the support portal and actually used the portal more and more after a few emails they received. This all without a campaign to use the portal and not email. A natural move from email to portal was achieved within a few weeks.

Another issue the company had before they started using IncidentMonitor was that emails were still send from Outlook. This resulted in ticket information captured in personal mailboxes in combination with the tool. With IncidentMonitor this was simply removed. What we did was that click on a contacts email address simply popped up an action in the specific ticket. Emails were directly send from the ticket. The email details stored in the tickets history. Reply emails from contacts are captured and stored as well.

Knowledge Management - Use knowledge smart

Quick answers to known issues for as well end user as support agent was an important item as well. Key was that they wanted to move Knowledge from peoples minds to a system and quickly transfer knowledge to users. This with the goal to release the service desk from pressure.

IncidentMonitor offers the solution to run multiple knowledge bases per installation. Every knowledge base is security controlled. That means that it is possible to make knowledge available to groups of people you want to make it available to instead of just throwing it to everyone.

Knowledge in IncidentMonitor is used in a few smart ways that really helped the client to improve the speed of solving issues with help of historical knowledge.

1. Knowledge articles made available to end users

When the end user logs a ticket in the support portal, possible answers will appear on the screen while filling out the form. Immediately next to the description of the issues, a list of documents that might help will appear.

2. A similar solution is provided to the support team.

Whenever a support agent logs a call possible solutions are presented immediately. All knowledge articles can be linked to the request giving the agent the possibility to send the link to the articles with one click to the end user they are supporting.

A good description of the issue will pop up possible answers, and top of that will also classify the call automatically for the support agent! Saving them more time and make sure the most likely categorization is selected. How do we do that? Pretty simple. We first of all match the description to articles in our KB and publish the most likely documents.

3. At the same time the message is matched against historical tickets in the system.

A positive match will force the system to use the classification. Of course is the support agent ALWAYS the responsible editor and able to set everything he wants. But from now on the client has far more correct reporting and not a large percentage of not classified tickets.