Introduction
The purpose of this document is to identify the different parties involved in the support process for a server, the responsibilities of each of those parties and the hand-offs that take place between them. The document also explains how which issues can be escalated if the service level commitments (described in the Service Level Agreement that can be found in the Support Portal) associated with the support activities are not adhered to.
The target audience for this document is the support leadership and experts within those organisations that will be involved in the performance of activities that form part of the end-to-end support process.
The term ‘Support’ is used to refer to those activities whose objectives are to resolve issues (software defects or hardware failures) detected with a server or to action administrative requests associated with that server.
The term ‘Service Provider’ is used to refer to the party that is responsible for providing the first and second level support services (described below) for one or more servers. The Service Provider is often a Managed Service Provider (MSP) or Communications Service Provider (CSP) but could also be the Customer whose IT Administration team can also act as the Service Provider.
This document does not consider how the Service Provider deals with issues or requests that relate to other IT infrastructure belonging to the Customer, including but not limited to client devices and applications, the Local Area Network, the Internet Connection and any Internet Services consumed over that Internet Connection. This infrastructure is not covered by the server support service.
First Level Support
The Service Provider is always responsible for delivering First Level Support:
Support for perceived faults caused by software defects, configuration errors or hardware component failures:
- Identify the user reporting the perceived fault or making the administration request and validate their authority to do so
- Identify all symptoms relevant to the perceived fault from the user reporting it
- Document these symptoms and formally logging the incident
- Assess whether any temporary or transient issue has caused the perceived fault that is already being addressed
- Ask questions to seek to understand whether the perceived fault lies within the server or in some other part of the Customer’s infrastructure such as a client device, the LAN or the Internet Connection
- Escalate the issue to Second Level Support, having first performed the above tasks and, having also confirmed that the perceived fault either appears to lie within the server.
Support for requests to carry out server configuration or administration tasks:
- Identify the user reporting the perceived fault or making the administration request and validate their authority to do so
- Understand the precise request that is being made and document this when formally logging the incident
- Action the request if it is one that First Level Support in the Service Provider’s organisation is authorised to perform or pass the request to Second Level Support for further validation and for actioning.
Second Level Support
The Service Provider is always responsible for delivering Second Level Support:
Support for perceived faults caused by software defects, configuration errors or hardware component failures:
- Review the symptoms reported by First Level Support and contact the person in the Customer organisation that reported the issue if further clarification is required
- Use the monitoring and diagnostic tools provided with the server to investigate whether these suggest a failure of the software running on the server or of the server hardware
- If the Monitoring Console indicates that there has been a failure with one or more software components on the server, escalate the issue to Third Level Support immediately
- If the Monitoring Console suggests that all software components on the server are functioning correctly, seek to reproduce the symptoms in order to isolate the perceived fault to either a client device/application, the LAN, the Customer’s Internet Connection, an Internet Service that the user was consuming or the server
- If the further tests suggest that the server is the origin of the perceived fault or if it is still unclear, escalate the issue to Third Level Support.
Support for requests to carry out server configuration or administration tasks:
- Review the precise request being made and assess whether the request is reasonable or whether it needs to be challenged or discussed with the customer
- If the request is reasonable, assess whether the request is one that can be actioned by Second Level Support using the tools available for these tasks
- If the request can be actioned by Second Level Support, action it, log its completion and report this to First Level Support for communication to the user who made the request
- If the request is not one which Second Level Support can action or if Second Level Support has queries or concerns in relation to actioning it, escalate to Third Level Support who will either action it if appropriate or provide assistance in actioning it.
Third and Fourth Level Support
Our Support Team is always responsible for delivering Third and Fourth Level Support:
Support for perceived faults caused by software defects, configuration errors or hardware component failures:
- If the Monitoring Console indicates that there has been a software fault, we will resolve that fault in accordance with the appropriate service level and report to Second Level Support regularly on resolution progress and then when the resolution is complete.
- If the Monitoring Console does not indicate that there has been a software fault, we will seek to understand whether there is a fault with the server or whether the perceived fault lies in an infrastructure component other than the server such as the client device, a client application, the LAN, the Internet Connection or an Internet Service.
- If it is believed after analysis that the fault lies in the server, we will resolve that fault in accordance with the appropriate service level and report back to Second Level Support regularly on resolution progress and then when the resolution is complete.
- If it is believed after analysis that the fault lies in a component other than the server, we will provide as much feedback as we can reasonably obtain to help Second Level Support to understand the underlying cause of the fault.
Support for requests to carry out server configuration or administration tasks:
- If the request is one which only we can action, check the reasonableness of the request, action it and report back to Second Level Support once complete.
- If the request is one which Second Level Support can action but has queries or concerns relating to it, work with Second Level Support to support them in actioning the request (and educate them where education is the root cause of their queries or concerns).
Issue Escalation
The support services that we offer to our Service Providers have an associated set of service level commitments that define the speed with which actions will be performed in response to a request from a Service Provider. These commitments are contained in the Service Level Agreement (SLA) document that is available on the Support Portal.
If we do not at any time meet any of the commitments identified in this SLA document, or if the Service Provider is unhappy with the manner in which the services are being delivered (having first attempted to resolve their dissatisfaction with the Support Team), the Service Provider may follow the escalation path below to raise their concern with an alternative person who is a member of our senior management team and who has the authority to investigate the matter and resolve it.
Step 1 Any concern with respect to our service performance should first be raised with the Support Team which can be contacted using the contact information provided above.
Step 2 Should an issue not be managed in accordance with the SLA or should the Service Provider be unhappy with the manner in which the issue is being addressed, they may escalate the issue to our IT Operations Shift Team Leader:
Name: Mr Daniel Embleton
Email Address: daniel.embleton@ncr.com
Step 3 Should the Service Provider be unable to contact our IT Operations Shift Team Leader (having attempted to do so within one working day on more than one occasion) or be unhappy with the manner or speed with which the issue is being dealt with by the IT Operations Shift Team Leader (having given the IT Operations Shift Team Leader one working day to demonstrate progress towards a resolution of the issue), they may escalate the issue to the IT Operations Manager:
Name: Mr James Breadmore
Email Address: james.breadmore@ncr.com