Escalation of Support , Cataloging of Problems, Proactive Customer Notification
Escalation of Support
A support incident may be escalated to engineering for several reasons, ranging from a low priority incident that could not be resolved through normal troubleshooting to a mission-critical production server going down that is escalated immediately to engineering.
All escalations must be accompanied with a bug report. Engineering priority is set based on the impact to the customer’s business. For all Severity 1 escalations, engineering will provide technical support an initial assessment with expected resolution timeframe within 24 hours. If a Severity 1 escalation happens outside the normal engineering business hours, support will contact the appropriate engineering manager. Once an engineering manager is reached, the manager will then assign a responsible engineer for the escalated incident. The responsible engineer will provide technical support an assessment of the incident within 24 hours including an expected resolution timeframe.
Once an item is escalated, engineering owns the resolution of the incident, but the support engineer will remain as the incident owner and be responsible for communication updates to the customer.
Why and when is an item escalated
Severity 1 – A Severity 1 incident occurs when there are fatal errors or errors whose impact major functions of the production use of the software.
- A severity 1 incident will be escalated immediately if no immediate solution is available via the support department. The maximum amount of time before escalation to engineering is 4 business hours.
Severity 2 – A Severity 2 incident consists of errors disabling only certain non-essential functions or impairing major functions where the software is still operational.
- A severity 2 incident will be troubleshot by the support staff for 72 hours before being escalated to engineering. This is flexible based on the progress the support staff is making on a support incident.
Severity 3 – A Severity 3 incident is defined as a minimal impact error, all errors that are not level 1 or level 2.
- A severity 3 incident will be escalated to engineering if it is determined that the error is an error in the software (bug), or the support staff troubleshoots for two weeks with no solution path. This escalation level is highly flexible and dependant on the feedback the customer provides support. On low priority items it is common for enterprise customers to not update incidents for days or even weeks at a time.
Cataloging of Problems
SpringSource Support is responsible for all incoming support requests, and will work directly with customers on any reported problems. Once a reported problem is confirmed, the support group is responsible for opening an incident in the SpringSource bug tracking system (JIRA). Once entered into the system, the reported problem will be assigned a unique tracking identifier and an engineer will be assigned to analyze and solve the reported problem.
Once the necessary resolution has been applied, the engineer will submit the corrected version of the product to Quality Assurance for testing. QA will then perform testing to verify the reported problem has been addressed; QA will close the reported problem in the bug database once the testing confirms that it has been fixed.
QA will inform the product distribution and support teams that a new version (or patch, as appropriate) of the product is available, in which the reported problem has been fixed. The product distribution team will make the corrected version of the product available for download on the SpringSource Customer Portal and the support team will inform the customer that the corrected version of the software is available for download.
Proactive Customer Notification
In the event that SpringSource should learn of a problem with distributed software, we’ll proactively notify customers with information on the problem if the following criteria exist:
- Data Collection – If a problem within our software jeopardizes the integrity of data collection customers will be proactively notified.
- Data Processing – If a problem within our software jeopardizes the integrity of data processing customers will be proactively notified.
- Display of Information – If a problem within our software jeopardizes the integrity of displayed information customers will be proactively notified.
- Computer Security – If a problem within our software is in any way vulnerable or contains any other potential security risk customers will be proactively notified. See SpringSource Security Vulnerability Policy for further details.
If any of the above criteria exist, an e-mail will be sent to the appropriate SpringSource customers warning them of the problem within the software. The e-mail will also provide a work around for the problem if one is available and include information on when a fix for the problem is targeted for release.