Priorities Definitions

Very important to select the priority of your ticket according to the Urgency and Impact of your issue. Please, follow the guidelines and definitions from this article while choosing the priority for your tickets.

This is an EMERGENCY condition that significantly restricts the use of the service itself to perform any critical business functions. This could mean that several departments of the Customer are impacted. Sometimes a critical enhancement to existing functionality can be categorized as a P3 based on the critical nature of its due date and severe impact on business. 

After a critical incident is reported to the Support team either via ITSM tool or by a Customer Contact: 

• The L1 Support engineer will report the issue immediately to all designated customer contacts, the incident is logged, and it is assigned to the appropriate owner
• The L1 Support engineer will communicate regular status updates to the Customer contact who reported the incident
• If it is appropriate, SDM will call an emergency coordination meeting with Support team to discuss an action plan for resolution, including possible recovery efforts
• The result of this meeting will be reported to the appropriate personnel on the Customer team and the NoventiqE account team. An update will be provided to the Customer stakeholder by the close of business by the SDM or Support engineer
• There will be a post-incident meeting to discuss the Priority 1 incident in detail, on demand or according to pre-defines rules. In addition, the incident will be put through the problem management process

• Mission-critical server is down 
• Cloud instances are down 
• Noventiq supported business-critical components are down 
• Significant number of users or groups have incidents 

A major function, business-critical component or infrastructure device supported by Noventiq is severely impacted and there are no quick workarounds available. It is deemed high because of its business or financial impact. Substantially degraded performance of any critical system is also categorized as a Priority 2. The primary difference between a P1 and P2 incident is how widespread the incident is. A P1 may impact the entire department or company, whereas a P2 may impact a limited set of users. There is no difference in the number of resources that will be devoted to a P2 incident compared to a P1 incident. 

After a High Priority Incident is reported to the Support representative: 

• The L1 Support engineer will report the incident to the appropriate domain leads and Noventiq SDM. The incident is logged and assigned it to an engineer. Assigned engineer will investigate the incident immediately. 
• Assigned engineer will then be responsible for communicating status to the Customer contact until the incident is resolved or priority is downgraded based on findings of the initial investigation. 
• These updates will continue until resolution of the incident, or an acceptable workaround is found. Assigned engineer will close the incident when it is resolved. 

• External user is not able to login or see network 
• Non-mission critical server is down 
• Non-core network element is down 

The reported incident may restrict the use of one or more features of the system, but the business or financial impact is not severe. The reported incident may be of a critical nature, but sometimes the incident can be downgraded to a Priority 3 because a viable workaround is available as a temporary solution. Many incidents are categorized as a P3 because there is a business justification or a financial impact on completing the task within five (5) business days.

After a Medium Priority Incident is reported to the Support team: 

• Support ticket is created and assigned it to an engineer. 
• Assigned engineer will be responsible for managing the ticket and communicating status to the Customer, including approximate resolution date. 
• It will be the responsibility of an assigned engineer to provide a status update pertaining to the medium incident within seventy-two (72) hours from the time the incident is originally reported. 
• Assigned engineer will continue to provide updates as agreed upon by the reporter of the incident or request, until resolution or an acceptable workaround is found. 
• Assigned engineer will close the incident when there is confirmation of resolution. 

• Termination requests 
• Customer can log in, but cannot access application 
• Any request or incident that has a direct impact on Customer’s daily operations 

The reported anomaly in the system does not substantially restrict the use of one or more features of the product to perform necessary business functions. This severity level is reserved for issues that will not significantly impact operations or Service requests.

After a low severity incident is reported to the Support team: 

• Support ticket is created and assigned it to an engineer
• Assigned engineer will be responsible for managing the ticket and communicating status to the Customer, including the approximate resolution date
• Updates from an Assigned engineer will continue as agreed upon by the Customer resolution or an acceptable workaround is found
• Assigned engineer will close the incident when there is confirmation of resolution

• Low impact changes in IT processes that are of a non-critical nature 
• Any server software or hardware incident for which a workaround exists