Process Overview: Incident Management
Process Overview: Incident Management
Process overview: Incident management
Summary
Incident Management is an IT Service Management (ITSM) process that focuses primarily on the speedy recovery of IT services disrupted by incidents. These incidents may include any unplanned interruptions or reductions in the quality of IT services that can potentially impact the day-to-day functioning of a business.
Incident Management plays a pivotal role in minimizing downtime and maintaining the reliability of IT services. By having a structured and efficient incident management process in place, businesses can ensure minimal disruption to their operations and maintain a high level of service quality for their clients. It also contributes to a better understanding of the IT infrastructure, helping to identify patterns and trends that can lead to more proactive management in the future.
Use cases
The process includes the following high-level use cases. Descriptions of these use cases can be found on their respective pages, accessible through the links provided below. These dedicated pages delve deeper into the use cases, example scenarios, workflows, results, and benefits associated with each use case, offering a granular view of their roles within the Incident Management lifecycle.
Use case diagram
Input channels
By default, the system creates ticket data cards for incidents through the following primary methods:
- Self-service: End Users can create incidents through the self service by filling out an incident form.
- Email-Based: End Users can create incidents by sending an email to the service desk email address. The email's content including attachments is populated into a ticket data card.
- Manual Reporting: For incidents reported through phone calls or in-person at the service desk, our service desk personnel manually create ticket data cards to ensure accurate documentation.
- Chat Integration: Incidents reported through integrated chat platforms are automatically converted into ticket data cards. This includes the extraction of pertinent information from the chat conversation, creating a seamless incident reporting process. Not included in the default delivery.
- Teams Integration: For incidents reported through Microsoft Teams, our system leverages integration capabilities to automatically create a ticket data card from the reported issue, ensuring comprehensive incident logging. Not included in the default delivery.
Process timeline
The timeline of the Incident Management process is depicted in the figure below. The process measures and records a variety of statistics for each incident, which are critical for assessing the performance of our services and identifying areas for improvement. Among these statistics, the key ones include:
Response Time: This is the duration between when an incident is reported or detected and when support staff acknowledge it. This metric helps measure the agility of our service desk and our efficiency in starting the incident management process.
Resolution Time: This metric records the time taken from the moment the incident is acknowledged to when it's resolved, excluding any paused time. It assesses the efficiency of our support staff in troubleshooting and resolving incidents.
Total Resolution Time: This is the time from when the incident is reported to when it's resolved, including any time the incident was paused. It provides an overall sense of how long it takes to completely resolve an incident from a user's perspective.
Total Processing Time: This refers to the actual time spent working on the incident by the support staff. It is a key indicator of the manpower required for incident resolution and aids in resource allocation.
Automatic email notifications
The solution sends predefined email notifications. The content of the email notifications can be changed by the administrator. If necessary, ticket assignees can disable the email notifications sent to them by editing their Person card. The following table outlines the automatic email notifications associated with the Incident management process.
The automatic email notifications are sent using Events in the Efecte Service Management Tool. However, the content of the emails is defined by E-mail notification datacards. The emails are sent with a short delay (~1 minute) after the event occurs.
| # | Notification name | Sender address | Recipient | Sent when |
|---|---|---|---|---|
| 1 | Ticket created | [defined by customer] | Customer | After a ticket has been created |
| 2 | Team changed on ticket | [defined by customer] | Team members of the team to which the Ticket was assigned to | After the team has been changed |
| 3 | SLA Deadline approaching on ticket | [defined by customer] | The team's queue manager | Five hours before the target resolution time |
| 4 | New email arrived to ticket | [defined by customer] | Assignee | After a new email has arrived at the ticket |
| 5 | Customer adds comment from Self-Service | [defined by customer] | Assignee | After the customer has added a comment |
| 6 | Assignee changed on ticket | [defined by customer] | New assignee | After the assignee has been changed |
| 7 | Assignee adds comment to Self-Service | [defined by customer] | Customer | After the comment has been added |
| 8 | Task assigned | [defined by customer] | Assignee | After a task has been assigned |
| 9 | Ticket is resolved | [defined by customer] | Customer | After the ticket has been resolved |
Terminology
| Term | Explanation |
| Escalation | The process of routing an incident or service request to a higher level of support when the initial level of support is unable to resolve the issue within a specified time frame or lacks the necessary expertise or resources to resolve the issue. |
| Incident management | The purpose of incident management is to minimize the negative impact of incidents by restoring normal service operation as quickly as possible. |
| Incident | An unplanned interruption to a service or reduction in the quality of a service. |
| Target response time | The maximum amount of time within which the support team aims to respond to an incident or service request after it has been reported by a user. |
| Target resolution time | The maximum amount of time within which the support team aims to resolve an incident or service request after it has been reported by a user. |
| Ticket | A datacard in the Service Management Tool that represents an Incident, Service Order, or Request for Information. |
| Priority | The level of importance and urgency assigned to an incident or service request based on its impact on the business and the required resolution time. |
| Quickfill | A feature that allows users to quickly and easily fill in common or frequently used fields when creating a new ticket, incident, or service request. |
| Service level agreement | The service level agreement (SLA) is a formally agreed level of performance or quality of service. The SLA is represented by a Service level datacard in the Service Management Tool. |
| Knowledge base article | A documentation resource that provides information on how to resolve common incidents or service requests. The articles contain step-by-step instructions, screenshots, and other relevant information that can help users to resolve their issues independently without requiring further assistance from the support team. |
Prerequisites
-
Communication channels
- Required: Email integration for receiving emails as tickets and for sending emails to customers.
- Add-ons: Efecte Chat, Teams integration
-
Support model
- The support model and support group structure including the team members of each support group should be defined.
-
Master data
- A classification scheme for classifying the incidents. The classification should be based on the service catalog.
- Service level agreements
- A default service level agreement datacard available out of the box can be used if there are no service level definitions. It is always recommended to use at least a default service level, since that helps to gather valuable statistics about the support performance against the service level agreement.
- Organization data
- Persons
-
Incident management policy
- The organization should have a well-defined incident management policy in place. This policy outlines the objectives, scope, roles, and responsibilities related to incident management within the organization. It provides the foundation for the incident management process
Benefits
-
Minimized Downtime
- One of the most critical benefits of the incident management process is the minimization of downtime. By promptly identifying, categorizing, and resolving incidents, organizations can reduce the impact on business operations, ensuring that critical IT services are available to end users. Minimized downtime leads to improved productivity, customer satisfaction, and overall business continuity.
-
Improved Service Quality
- The incident management process plays a vital role in improving service quality. Organizations can consistently meet or exceed customer expectations by adhering to predefined incident management procedures and service level agreements (SLAs). Effective incident resolution and service restoration contribute to enhanced user experience, customer satisfaction, and trust in IT services.
-
Enhanced IT Staff Efficiency
- An efficient incident management process streamlines the activities of IT staff and promotes effective collaboration. Clear roles, responsibilities, and procedures ensure that incidents are addressed promptly and by the right individuals or teams. This leads to improved efficiency, reduced response times, and optimized resource utilization, allowing IT staff to focus on critical tasks and provide timely support to end users.
Actors and roles
| Actor | Description | Roles in Efecte Service Management Tool (ESM) |
| End User | A person who uses the products or services the company provides. | N/A |
| Service Desk Agent | Provides customer support to end users. The Service Desk agent belongs to a Support group that acts as a first point of contact for end users. |
Service Desk Agent |
| 3rd party actors | 3rd party actors are often vendors that provide IT services to the company. | N/A |
Best practice for changing ticket types
Incidents, Service Orders, and Requests for information tickets are processed on the Ticket template. The Ticket type attribute is used for defining the ticket type. It's recommended to instruct the end users to use the correct forms in the self-service portal to allow a smooth experience for the end users. However, sometimes requests are not submitted through the correct form. In those situations, it's possible to change the ticket type with some constraints. The allowed and not allowed Ticket type changes are listed below.
Allowed Ticket type changes
- Service Order → Incident
- Service Order → Request for information
- Incident → Request for information
- Request for information → Incident
Not allowed Ticket type changes
- Incident → Service Order
- The Ticket type cannot be changed from Incident to Service order since Service orders (Service requests) typically require approval. The orders have to be submitted through the self-service portal to ensure compliance with the predefined approval practices.
- Request for information → Service Order
FAQ
- What if the end user tries to order something by submitting an incident?
- The recommendation is to ask the customer to submit the order through the correct form in the self-service portal. A proper approval process that leaves an audit trail can only be done for orders submitted through the self-service portal.
- In case such cases occur often, it's recommended to create a Quickfill for allowing service desk agents to instruct the end users. Also, a predefined email template is recommended.
- What if end users are frequently requesting something through the Incident form that is not included in the service catalog?
- The recommendation is to identify the frequently asked items and introduce them to the service catalog to allow end users to submit the requests through a service order in the self-service. That allows a standardized process with predefined tasks that also adhere to the approval policies.
- What is the default ticket type when Tickets are created manually or through email?
- The Ticket type of Tickets that are created manually or have arrived through email are set by default to Incident. The rules listed above apply regardless of the channel through which the Ticket was received.
Table of Contents