CoreView Incident and Problem Response

An Issue is any event that occurs that impacts a customer's use of CoreView and where the customer elects to report the Issue to CoreView Customer Care for additional troubleshooting and remediation support.  Prior to opening a Support Request on an Issue, customers are asked to perform some basic troubleshooting.  You can find additional information on troubleshooting in the Knowledge Base named Troubleshooting.

An Incident is an Issue that leads to an unplanned disruption of service for one or more customers and that impacts the customer’s business operations. The key idea here is that there is a disruption of service.   If an Issue does not disrupt service, even if it was unplanned and unexpected, it is not an Incident.

For example, if CoreView becomes unavailable after normal working hours when nobody is using the system, it is not an Incident, because it did not disrupt the customer’s business operations. However, if CoreView was unavailable during the regular workday, it would be defined as an Incident because service was, in fact, disrupted. CoreView Customer Care is often the first one to be made aware of an Incident, as they are usually the first point of contact for Customer's experiencing an Issue.

A Problem is the underlying Root Cause that led to an Incident. A Problem may be something that could lead to the same Incident occurring again and again (systemic), or a Problem can be a single isolated Incident.  While it’s possible that a Problem may be quickly identified, it is more likely that a Problem can only be identified after we have gathered and reviewed the relevant information and arrived at and validated our conclusion(s).

An Incident is caused by a Problem and only a Problem can be fixed (remediated).  Resolving an Issue will take priority over other customer needs simply because an Issue means that a customer’s business is being negatively impacted.  The focus on any Incident is to diagnose the Problem as quickly as practicable and then determine how best to restore the customer back to normal operations.  This might mean immediately fixing the Problem causing the Incident, or it could mean coming up with a temporary workaround to get a customer operational again until the underlying Problem can be found and remediated.

Unless a Problem is systemic, its remediation is not usually treated as urgent, but it is important to prevent future Incidents. Identifying the underlying Problem may take time and require analysis, troubleshooting, and testing to diagnose the Root Cause and the best course of action to correct the Problem.  Fixing a Problem may require changes to the CoreView application that require time for design, development, testing, and release.

Customers report an Issue to CoreView by logging into the CoreView Support Portal and selecting the “Submit a request”. This will present the Customer with a “Ticket Details” page, wherein the required information is provided, any relevant information attached, and the ticket then submitted.  When a customer reports an issue, they are prompted to provide the following as part of the ticket:

Priority - How has this Issue affected the customer’s business and how quickly does this need to be fixed? 
The benchmark is usually measured by the impact on the customer’s operations and/or the volume of users unable to perform their duties. Additionally, whether there is an available workaround is also a factor.  While we recognize that every customer wants an Issue resolved quickly, not every Issue is Urgent.  

The reporting of an Issue presupposes that the customer had performed some initial troubleshooting activities and as a result, concluded that the Issue needs to be reported to CoreView. This initial troubleshooting is instrumental to a speedy resolution of the Issue.

While customers have the option of reporting an Issue by email to support@coreview.com, this is not considered a best practice and should be avoided.  Issues reported by email to CoreView Support lack the critical information needed to automatically prioritize an Issue, which may lead to a delayed response by CoreView. 

The priority is defined as below:

• Critical Priority
  Critical priority incidents are those that severely impact business operations or affect a significant portion of the customer base. These issues disrupt the functionality of the service, leading to a complete service outage or rendering a critical feature unusable. Examples include service outages, security breaches, or any issue that significantly impedes the customer's business operations. For these incidents, no workaround is available.
  Once an issue is classified as critical, resolving it becomes paramount to minimize downtime and prevent financial losses and further disruptions.
   
• High Priority
  High priority incidents significantly impact the functionality of the service but do not completely halt its operation. These could be issues that affect a large number of users or significantly degrade the performance of the service, such as slow loading times or major feature malfunctions. However, an acceptable alternative method exists to achieve the required results.
   
• Medium Priority
  Medium priority incidents have a moderate impact on the service, affecting a smaller segment of users or involving non-critical features. These issues might include minor bugs, interface issues, or performance problems that inconvenience users but don’t significantly impair their ability to use the core service.
   
• Low Priority
  Low priority incidents have a minimal impact on the service and users. These are often cosmetic issues or minor bugs that affect very few users and do not affect the current usability of the service.

Please refer to the document titled CoreView Support Service Levels for additional information on our SLAs.