Incident management is the process used to respond to an unplanned event or service interruption and restore the service to its operational state.
There are classification guidelines listed on our end user support site; listing them here for a quick glance reference as well:
- URGENT (P1) - critical production down, unable to submit orders or similar
- HIGH (P2) - site is functioning but a major component is affected
- MEDIUM - I need individual assistance, or see a non critical issue
- LOW - I want to request an enhancement, or have a low priority question
Response Timelines
Response and resolution are not the same things. We aim to respond quickly to urgent and high-priority items to learn as much information as possible to ultimately resolve the issue. If the issue requires code to be updated, we'll need to execute a coordinated release. The release deployment options are outlined below.
Release Deployment Timelines
Production timelines for priority items will follow elastic sprint process and our release cadence (for Beta and Production) *caveat being release freeze which is customary during mid November through mid January.
Two week cadence for base release items
On-demand client-specific items on Tuesdays & Thursdays
Exceptions for hot fixes are limited to P1 bug severity items (which will be vetted and determined by Engineering and Release Managers)
We understand that incidents are not always super straightforward.
Below you will find detail and examples that hopefully provide more direction when considering how to communicate the incident classification.
URGENT (P1)
This is a major Incident should involve a case with significant loss of core functionality with no easy or acceptable workaround requiring an immediate coordinated resolution. We want to carefully consider the circumstances before attaching P1 priority to an incident. P1s are generally reserved for exceptional cases. Please refer to the following examples:
More than 50% of users are unable to login and/or place an order. (this could be 50% of one client’s users, but of course 50% of all elastic users would indicate a P1 severity)
A significant amount of inventory is inaccurate and products are not able to be ordered. (historically this tends to be data related, please make sure to do necessary diligence on the data QA)
Products are not displaying and therefore cannot be ordered across all catalogs
Orders are not being sent from elastic
Elastic is incorrectly calculating and/or displaying pricing for products
Inability to save.
HIGH (P2)
These are incidents with loss of functionality that may or may not have an acceptable workaround requiring resolution in a timely fashion. They need attention however, they are not something requiring elastic to stop everything else to focus on immediately. Some examples when considering a HIGH (P2) priority:
Unable to export Order PDF
Sharing not working.
Whiteboard functionality not working as designed
Rating/Noting not working
Features, highlights, tech icons not displaying correctly
MEDIUM and LOW
Requests or issues that can wait more than two weeks.
A Medium priority might be something that can wait a few months.
Low or lowest priority can wait longer and customarily are nice to haves that don’t really have a defined due date.
ESCALATION PROCESS
We understand that certain requests/issues can fall into exceptions and need to be escalated under certain circumstances. There could be certain events that influence this type of need such as a Print deadline, Sales meeting / Sales launch, Trade show, and/or important line showings.
It is always advised to work through your account manager, and/or CS contact who responded to your ticket and is likely most familiar with the issue or request. We have a process in which the customer success contact can report any items that need to be escalated to the CS lead.
The CS lead meets regularly with development and product teams to address these types of hot items that need to be escalated.