Incident Classification. The Service Provider must classify and respond to support calls by the underlying problem’s effect on a Subscribing Entity. In this regard, the Service Provider may classify the underlying problem as critical, urgent, or routine. The guidelines for determining the severity of a problem and the appropriate classification of and response to it are described below. The Service Provider must designate a problem as “critical” if the Service is functionally inoperable, the problem prevents the Service or a major component or function of it from being used in production mode or there is significant potential for data integrity problems. This classification assumes there is no existing patch for the problem. The Service Provider must classify a problem as “urgent” if the underlying problem significantly degrades the performance of the Service or a major function or component of it or materially restricts a Subscribing Entity’s use of the Service in a production mode. A problem also will be considered urgent if a commonly used feature often generates application errors, causes the Service to freeze, locks up the computer on which the Service is running, or otherwise routinely does not work as intended. Classification of a problem as urgent rather than critical assumes that an affected Subscribing Entity still can conduct business with the Service and response times are consistent with the needs of the Subscribing Entity for that type of Service. As with the critical classification, the urgent classification assumes there is no existing patch or acceptable workaround procedure for the problem. Finally, the Service Provider may classify a support call as “routine” if the underlying problem is a question on end use or configuration of the Service. It also may be classified as routine when the problem does not materially restrict a Subscribing Entity’s use of the Service in its production environment, such as when a feature or combination of features generates minor or rare errors. Also, if any problem that otherwise should be classified as critical or urgent can be solved either by a known workaround or an existing patch that does not materially interfere with a Subscribing Entity’s use of the Service, the problem may be treated as routine. The Service Provider must apply the above classifications in good faith to each call for support, and the Service Provider must give due consideration to any request by a Subscribing Entity to reclassify a problem, taking into acco...
Incident Classification. (a) Interactive will determine the severity of any reported Incident based upon the Customer’s impact assessment, having regard to the urgency and impact factors in Table A and Table B. Interactive will then allocate a severity level in accordance with Table C.
(b) The Customer’s callers to the Service Desk must define the level or urgency of the Incident in accordance with Table A and define the impact of the Incident in accordance with Table B.
(c) Notwithstanding the urgency or impact factors:
(i) Interactive will classify any Incident Calls placed by the Customer by email or online as Severity 3 or 4 incidents; and
(ii) Severity 1 or 2 incidents Incident Calls must be placed by the Customer by phone calls.
Incident Classification. 5.1 Incidents shall be classified as follows:
Incident Classification. For all requests which relates to incidents, Supplier will use a classification and escalation method. Supplier understands and expects that there may be cases in which the severity of the incident is not known at the time of request. Once Supplier receives such request, it will make a determination as to the severity level of the problem and respond accordingly. Should the Supplier’s Project Manager and Customer's Project Manager disagree on the severity of the incident, the incident shall be classified as Level 3: Priority Level 4 3 2 1 Severity Level Work-Around Available Error Critical System Failure Software is functioning with work-arounds. Incident may be prioritized as a Modification to be included into a future release. Any other uncategorized issues or questions. Software has minor functionality which is unavailable or impaired. No mutually agreed upon work-around is available. Software has important functionality or core component which is unavailable or severely impaired. No Application feature is currently functioning. Application is completely unavailable or severely impaired.
Incident Classification. 2.1 Following the registration phase, Mi Support will classify the case according to Item C.2.5.2: Incident Severity Matrix and calculate minimum response time according to Item C.2.5.3: Response Time Matrix.
Incident Classification. 5.1 Incidents shall be classified as follows: Severity 1 An incident is categorized as Severity level 1 when the following conditions are satisfied: Condition 1: Unavailability of one or more online services provided by Equifax, affecting multiple customers or partners during service hours Condition 2: A logical security breach whose severity could impact adherence to regulatory requirements 30 minutes 4 hours Severity 2 Major inconvenience, some users affected. Example: All or some users experiencing slow responses or errors 1 hour 24 hours Severity 3 Minor Incident, no impact on service. Example: A single user affected, business functionality still maintained 24 hours 3 days Severity 4 Minor impact, information only 7 days 28 days
Incident Classification. All incident reports must be made to ne Digital by an Authorized Contact. ne Digital will work with Customer and will assign the appropriate priority level to any such reported
Incident Classification. Customer is required to properly assess the business impact and urgency of an Incident when selecting a requested priority level for any Incident submission. Priority levels are defined as follows: Urgent Critical Service functionality is completely unavailable, causing a material impact on Customer’s business or operations, or there is a security breach. Examples include: High Critical Service functionality is interrupted, degraded or unusable, having a severe impact on Customer’s business or operations. Examples include: Normal Service functionality is interrupted, degraded or unusable, having a minor impact on Customer’s business or operations. Examples include: Low Non-critical Service functionality, including general inquiries or issues not impacting Customer’s business operations. Examples include:
Incident Classification. Customer will classify each Incident as Severity 1, Severity 2, Severity 3, or Severity 4, based on the impact to the Customer business, as defined below: ▪ Critical - Severity Level 1 Incident is an Incident that causes a complete outage of the service where no terminals can connect to the Service to transmit or receive data, or a complete outage of the Pelion Connectivity Management platform where no Customer users can access or use the Service. ▪ Major - Severity Level 2 Incident is an Incident that causes a significant failure or degradation in performance of the Service. The situation is causing a high impact to portions of the customers solution and no reasonable workaround exists. ▪ Minor – Severity Level 3 Incident is an Incident that causes a minor failure or degradation in performance of the Service that is non-critical. Short term workaround is available, but not scalable. ▪ Cosmetic – Severity Level 4 Incident is an enquiry regarding a routine technical issue, information requested on solution capabilities or configuration, or a bug affecting a small number of users. Workaround is available. Pelion reserves the right to reclassify Incidents if they are found to not be in line with these definitions. Any dispute in classification can be escalated in clause 3.8. If any Incident which is Severity Level 2 or Severity Level 3 is deemed business critical, then the escalation process should be invoked, and it may be reclassified as Severity Level 1 by Pelion.
Incident Classification. Each logged Service Incident will be assigned a severity level as defined below. The severity level defines the response time and target resolution time for the Service Incident. High An incident is classified as high if: The eArcu Application is not available in all material respects to any of the Users. All or a material proportion of Users of the system cannot login to the Application. Medium Low An incident is classified as medium if: A key Software Service feature is unavailable An incident is classified as Low if: It is not defined as Medium or High
