Incident Management

Incident records can be created by various methods; this must include, at a minimum:

Vendor response: Yes, it does, Incident records can be created by various methods like manual entry, mail, bot, alert system, request, change, problem, external integration and API.



Client admins can create and apply templates for different types of incidents with different forms, fields, and possibly prefilled data depending on the type of incident. 

Examples of incident types can include standard/simple incidents, complicated incidents, major incidents, security incidents, and incidents for specific services or customer departments – and are client-definable.

Vendor response: Yes, it does. All templates can be defined on portfolio/service catalog using workflows and forms.





Client admins can create and apply specific incident models for different types of incidents; models include templates (see item IM2) and different workflows specific to the type of incident. 

Vendor response: Yes, it does. All templates can be defined on portfolio/service catalog using workflows and forms.



Incident records can be created and updated through a chat session with information from the chat session input into the incident record, and the necessary effort needed to manually update the record is reduced or eliminated. 

Where chatbots are utilized: an incident record can be systematically created with chat session information without the need for any human interaction to complete the incident record, including the proper categorization.

Vendor response: Yes, it does, Incident records can be created by various methods like manual entry, mail, bot, alert system, request, change, problem, external integration and API. 



Identify duplicate incidents and flag these incidents for appropriate action to be taken by the client. 

Vendor response: Yes. It does when customer start incident creation the platform detect duplicated or similar incidents.



Multiple service, component, and asset records can be searched for in the respective repositories, from within the incident record, and applied or linked to the incident. 

These records can be distinguished as to whether they are the cause of the incident, are impacted, or are affected by the incident. 

Vendor response: Yes, it does link service, components, others process, tasks, requests using right side incident panel screen.



Clients can define an incident category structure that is unique to their organization. The category structure can include a related or dynamic tiered level of categories, as well as include the selected service, component, and IT asset records.  

Vendor response: Yes, it does and can be defined on service catalog or workflow triggered multiples incident when a specific incident was created.





The defined category structure (refer to IM7) can be used to inform or trigger the following actions, at a minimum:

Vendor response: The platform based on category + description and NLP check on incident base all incidents and suggest knowledge articles, groups and inform all incidents created and opened and on last week



A method to prioritize incidents is available that can be based on risk, lead time, level of effort, severity, business need, workload, and other client-defined criteria.   

Vendor response: Customer can define additional methods for prioritize incidents beyond the default rules based on impact, urgency and agreement related with service.



Also can use copilot for automatic prioritize based on machine learning attribuites



First-call resolution (first contact resolution, etc.) can be defined by the client, measured, and reported independently from the defined prioritization method.

Vendor response: On incident screen there area a check box for FRC additionally a Post Incident Review form. 



Problems can be searched for, from within any incident record, and temporary fix or resolution information found in these records can be systematically applied to the incident record. 

The problem record can be linked with or related to the incident record.  

Vendor response: New problems can be triggered from scratch from Incident Process or incident can be linked with Problems in progress



Knowledge articles can be searched for, from within any incident record, and information contained in the article can be systematically applied to the incident record. 

Additionally, the knowledge articles can be linked to the incident. 

Vendor response: When customer will create an incident the platform uses ML for show up knowledge articles based on customer service and description, also can be linked in incidents running.



A major incident record can be identified and can be distinguished from other types of incidents with unique templates, models, workflows, prioritization, and notifications. 

Multiple non-major incidents may be linked to a single major incident record. 

Vendor response: Any incident can be checked as Major Incident and the screen identification will turn yellow, related incidents or sub-incidents can be linked on Major Incident 





Major incidents can be manually created, promoted (or updated) from a non-major incident, or can be systematically launched by pre-defined criteria. Clients should be able to define these criteria for their organization, though some capabilities may be provided out-of-the-box. This may include, but is not limited to:

Vendor response: Any incident can be checked as Major Incident and the screen identification will turn yellow. As Mahor Incident can be defined on workflow based on agreements, unit, VIP or Group.

Incidents can be assigned to a support group or technician, manually and automatically, through predefined criteria (such as category, component, service, user, location, department, or a combination of these).

Vendor response: The platform allows that incident be assigned to a support group or technician, manually and automatically via service catalog and portfolio or workflow when customized.



Notifications are triggered to identified stakeholders based on specific conditions in the incident record; this can include, but is not limited to: 

Vendor response:  Others action mail and/or workflow notification



Remote diagnostic support tools can be used and triggered from within the incident record, and the remote session logs can be saved in or linked to the incident record.

Vendor response: All CIs that use IT Asset Remote Desktop can be connected from Incident for perform remote support.



Incidents can be linked or related to service and internal support agreements, to monitor and report response and resolution targets, as well as launch automatic notifications to predefined stakeholders.

Vendor response: All incidents are related with services and internal support agreements, and if customer needs can change the SLA based on organization business process





Users can access and review the status of their incidents via the portal/service catalog; this view should be restricted to the user recorded in the record, and also allow the user to update or add information to the incident throughout its life cycle.

Vendor response: Yes, it does via portal, app or chatbot





For incident support provided by a vendor, the following must be able to be done, at a minimum:

Vendor response: The platform allow that customer create/link related incidents to a vendor or create tasks for vendor contribute with incident resolution



Resolution information can be systematically recorded in the appropriate resolution fields of the incident record, where appropriate. This can include, but is not limited to: 

Vendor response: Yes, it does use monitoring/alert + ITOM platform



Detailed diagnosis and resolution information can be recorded in the incident record, as well as identify the following information. This must include, at a minimum:

Vendor response: Yes, it does on Solved Status. Causes and Closure Category can be designed by services.



Notifications of status updates and resolutions can be sent to the service desk and the user.   

Vendor response: Yes, can be defined on incident screen or workflow



A problem record and a change record (as needed) can be launched from within the incident, linking the records together.

Vendor response: New problems and changes can be triggered from scratch from Incident Process or incident can be linked with Problems/Changes in progress



Incident records can be closed in the following manners, as well as the flexibility for the client to determine which one or which combination they want to use. This may be different for the various incident models. This must include, at a minimum:

Vendor response: The platform allow that customer define all business rules for the client to determine which one or which combination they want to use. The customization needs to be set based on Service Catalog, Customer, Contract. 



Support costs can be captured and calculated within the incident record, and can be provided to cost center managers, either for individual incidents or in aggregate of multiple incidents over a period of time. 

Support costs may include multiple cost types, such as time and material, parts, labor, contract costs, and other overhead costs. 

This can also be used to generate invoices, if necessary (through integration with financial management capability or tools). 

Vendor response: All costs involved in services can be defined on service catalog and linked with Financial Management Process





Post-incident reviews can be systematically triggered based on pre-defined criteria; the purpose of the review is to identify process and improvement opportunities; examples of this can include, but are not limited to: 

Vendor response: Post Incident Review and all attributes are available on each incident defined in workflow by customer.