Incident Workflow - A State by State Tour

Document created by Sarah Nielsen Employee on May 17, 2018Last modified by Sarah Nielsen Employee on May 17, 2018
Version 2Show Document
  • View in full screen mode

Incident Workflow - A State by State Tour

 

Have you ever wondered how incidents should flow through your service desk? You’ve probably asked yourself many different questions regarding how to run your service desk using Samanage.

 

Where do my incidents go when they are submitted? How can my technicians be sure to not miss an incident? Is there really a difference between a resolved or closed incident?

 

This document is designed to walk you through the way an incident flows through Samanage. We will focus on how your ticket will live and evolve throughout the various incident states. Also, we’ll sprinkle in any best practices along the way to make sure you maintain a good handle on everything coming through your service desk!

 

Let’s jump right in by talking about the different states your incident can live in. We’ll shape our conversation here around the main incident states, but don’t forget you can add custom incident states in Samanage if needed.

 

NEW

 

Where are your new incidents coming from?

 

  • Agent Creation (Phone Call, Walk Up, Skype, etc). - Even though the best practice would be for Samanage to create incidents automatically through both the Email and Service Portal, you may want to keep the personal touch of your Service Desk by allowing your users to call or walk by your desk to submit an incident. In these instances, your technicians will be creating incidents within Samanage for your users. This must be done in order to maintain documentation of the issues happening in your organization.
  • Email - This is how most Service Desks will receive the majority of their incidents. While this is an effective way to encourage your end users to submit their incidents, you lack the ability to collect vital information from your users when they are submitting these issues. Not to mention, you miss the opportunity to encourage your users to submit service requests instead of break fix incidents instead.
  • Service Portal - The best practice for receiving new incidents is to have your users submit new break fix incidents and service requests through the Samanage Service Portal. The Service Portal enables your users to submit incidents and service requests effectively and efficiently. You can create custom service request forms and custom break fix incident fields on your Service Portal to collect vital information from your users upfront in order to serve them quickly and seamlessly.

 

ASSIGNED

 

Who is assigned to your new incidents?

 

If there is a main point that we need to make here - it’s that your new incidents should come into Samanage assigned to Groups. Using Groups in Samanage is essential to the success of your Service Desk.

 

  • Groups - In Samanage, groups are collections of users. Most often, these groups of users are various technicians that work as a part of a functional team. Essentially, the grouping functionality allows you to determine meaningful assignees for the different types of incidents coming into your Service Desk. Groups are necessary for visibility, notifications and even incident routing. For example, if a technician is on vacation, having your incidents assigned to a group of technicians ensures that no incident will be lost into the oblivion. Let’s take a second here to mention that once an incident has been assigned to a group, you can reassigned the incident to a technician within that group and then move on and work to resolve the incident.
  • Incident Routing - There are many different ways to route your incidents to groups in Samanage. To see more specific information regarding incident routing in Samanage, please follow this link!
    https://community.samanage.com/docs/DOC-1494-understanding-incident-routing-in-samanage
  • Filtering - Once your incidents have made their way into the Incidents menu, your technicians will use filtered reports to see different reports or collections of the incidents that they need to work on. These filtered reports will enable them to see various incidents sorted by attributes such as “category”, “assigned to”, and “state”. If you’re looking for incident “queues”, these filtered reports allow you to create different views so that your technicians can run a smart service desk operation.

 

IN PROGRESS

 

What happens after the incident is assigned to a group?

 

So now what? Now that we have actually assigned the incident to a group (and potentially a specific technician), we can move on to working the incident until it is resolved and eventually closed out. At this point, we would move the incident into an In Progress state. Here’s a couple of things you’ll be handling while the incident lives in this state.

 

  • Comments - The commenting section allows you to communicate with both your fellow technicians as well as your employees or end users. Private comments are used for internal communication amongst technicians and for internal documentation. Public comments are used for communication with your employees, specifically those who have made the requests.
  • Creating Relationships - When working an incident in Samanage, you will see the option to create several different types of relationships with other areas of your service desk such as assets, problems, or even tasks. Creating these relationships is vital to understanding trends and issues happening in your organization. For example, you should attach laptop incidents to their respective asset in Samanage in order to document the history of that particular asset. The historical record of these associated issues will help you when you need to justify replacing this piece of equipment.
  • Updating States - Most likely, this will be a time in the incident lifecycle in which the state can be changing quite frequently. It’s important to make sure we have the incident in the correct state for visibility and reporting purposes. This could mean you move the state to Escalate to Vendor or Awaiting User. We’ll talk about the Awaiting User state next!

 

AWAITING USER

 

What if we are waiting for the requester’s response?

 

If a ticket is in In Progress and you respond to your employee, the best practice would be to move the incident into the Awaiting Input status. This enables you and your team to see that you are waiting for a response before you can resolve this incident.  

 

 

RESOLVED

 

We have resolved the issue, now what?

 

When the technician has resolved the issue they can now mark the incident as Resolved. Changing the state to Resolved means that the technician has done their best to resolve the issue that the requester has been experiencing. When resolving an incident, the technician should send a public comment to the employee letting them know that their issue has been resolved. After marking the incident as resolved, you’ll need to select a resolution code as well as a resolution comment.

 

  • Resolution Code - A resolution code is a phrase to describe how a ticket was resolved. These codes are also used for reporting purposes. To learn more about resolution codes, please click this link.
    https://community.samanage.com/docs/DOC-1503-resolution-codes-and-their-purpose-in-life
  • Resolution Comment - A resolution comment gives a place for the technician to document how they resolved the issue. This information can be extremely helpful if we need to look back to see how this issue was resolved.

 

CLOSED

 

What happens after we resolve the incident?

 

Are we there yet? Almost! The last step in the ticket workflow is to mark the incident as closed. But isn’t Resolved the same thing as Closed? Not so fast - I promise you they have two different meanings. While Resolved means that the technician has resolved the issue, Closed means that the requester has confirmed that the issue has been resolved.

 

  • Close Inactive Resolved Incidents - We want to give our employees a chance to respond to the proposed resolution before marking the incident as closed, but we can also set incidents to auto-close after a certain number of days. We typically recommend setting inactive incidents to auto-close after 5-7 days.
    • You can accomplish this in Samanage by going to Setup > Service Desk > Close Inactive Resolved Incidents.

 

We hope you enjoyed the tour!

Attachments

    Outcomes