TANDEM SYSTEMS SERVICE LEVEL AGREEMENT
This document represents a Service Level Agreement (“SLA” or “Agreement”) between Tandem Systems and the Customer for the provisioning of IT services required to support and sustain.
- The objectives of this Agreement are to:
- Provide clear reference to service ownership, accountability, roles and/or responsibilities.
- Present a clear, concise and measurable description of service provision to the Customer.
- Define the response & resolution times Tandem Systems will provide to the Customer
- Ensure the Customer has clear understanding of how Tandem Systems measures its performance against service deliverables
1.1 CUSTOMER REQUIREMENTS
The Customer will:
- Notify Tandem Systems of issues or problems in a timely manner.
- Provide Tandem Systems with access to equipment, software and services for the purposes of maintenance, updates and fault prevention.
- Follow instructions from the support engineer to assist with fault finding and diagnostic processes
- Provide reasonable availability when the support engineer is resolving a service related incident or request.
- Ensure Tandem Systems has full visibility of all supported software & hardware installed, including those not supplied by Tandem Systems.
- Inform Tandem Systems of any changes within the business that could affect service levels to the Customer
- Any changes made by the Customer to the IT systems which results in failure or fault, will not be covered by Tandem System’s support contract. Any work carried out will be billable at standard hourly rate and the response times highlighted below (see Ref. 2.2) will not be governed by this SLA
1.2 TANDEM SYSTEMS REQUIREMENTS
Tandem Systems will provide support to, and maintain the IT systems used by the Customer as per the support contract
- Document all hardware & software supported by Tandem Systems
- Notify the Customer of scheduled maintenance, this will be given no less than 8 hours in advance and a suitable time/date will be agreed with the Customer prior to the commencement of any work
- Respond to support requests within the timescales listed below (see Ref. 2.2)
- Provide the Customer with a clear and concise escalation process (see Ref. 2.2.1)
- Provide the Customer with access and training on the Tandem Systems Client Portal which allows the Customer to log, edit and track the progress of service related requests
- Update the Customer on the progress of service related incidents
2 SERVICE REQUIREMENTS
This section explains how Tandem Systems provides and measures services provided to the customer.
2.1 TANDEM SYSTEMS LTD. REQUIREMENTS
Support requests can be logged in one of 3 ways:
- Online: firstname.lastname@example.org
- By email: email@example.com
- By telephone: 01204 860055
These avenues will be monitored and responded to during contract hours. Any service requests that are logged outside of contracted hours will be responded to the following business day in accordance with the response times listed below
Once a ticket has been logged, an email confirmation will be sent out to the customer and any updates will be by way of method agreed with the customer.
Please do not request quotes or pricing from support Engineers as they will not be able to assist you; for all quoting and pricing inquiries, please speak to your Account Manager.
2.2 SERVICE REQUESTS
A service request is defined as any problem or incident that affects the operation of the business and its users.
Response times outlined below are measured during contracted hours only. The Customer must ensure that their support contract provides sufficient coverage to meet the needs of their business
Tandem Systems is committed to resolving service requests as swiftly as possible, however, we are unable to provide guaranteed resolution times, and this is because the nature and causes of problems can vary enormously.
In all cases, Tandem Systems will make its best efforts to agree a resolution plan as quickly as possible.
Tandem Systems will respond to service-related incidents submitted by the Customer within the following time frames:
- Immediate response (during contract hours) with resolution plan agreed with Customer inside 1 hour, for issues classified as Critical Priority.
- 0-1 hour’s response (during contract hours) with a resolution plan agreed with Customer inside 4 hours, for issues classified as High priority.
- 0-1 hour’s response (during contract hours) with a resolution plan agreed with Customer inside 8 hours, for issues classified as Medium priority.
- 1-4 hour’s response (during contract hours) with a resolution plan agreed with Customer inside 2 working days, for issues classified as Low priority.
Intermittent issues and/or recurring faults may result in Tandem systems not being able to achieve the SLA targets mentioned above. This may be due to the issue not being visible at the point of diagnosis. Please make the service engineer aware if you feel that this is either a recurring issue or fault.
Engineers will seek customer approval for closure of tickets once they feel the issue has been resolved – if no response is received from the customer, the ticket will automatically close after 3 working days.
2.2.1 ESCALATION MATRIX
If for any reason Tandem Systems fails to meet either the response time or resolution plan outlined above (see Ref. 2.2), please escalate using the below matrix as a guideline.
|1 hr – Operations Manager||1 hr – Operations Manager||1 hr – Operations Manager||1 hr – Operations Manager|
|2 hrs – Account Manager||4 hrs – Account Manager||6 hrs – Account Manager||8 hrs – Account Manager|
|4 hrs – Director||6 hrs – Director||8 hrs – Director||16 hrs – Director|
The above is conditional upon the fault being visible and the technical team having access to the equipment. Response times are measured during contracted hours only. If the customer needs to use the escalation matrix but the appropriate person is unavailable, please escalate up to the next level.
2.3 DEFINITIONS OF PRIORITY
In support of services outline in this agreement, Tandem Systems define priority as the following:
- Critical Priority- Complete degradation of service resulting in high volume of staff being unable to work. All users/ critical functions affected with equipment or service completely unavailable. No workaround available i.e. Major component failure such as servers, switches, router, Internet connection down etc.
- High Priority – Significant degradation of services affecting a large number of users or critical functions i.e. Parts of network down, non-critical equipment failure. Users still able to work however not very effectively. Workaround available
- Medium Priority – Minor loss of service to multiple users or single user not able to work i.e. unreliable service affecting multiple users such as intermittent Internet connection or PC fault affecting single user. Users able to continue at reasonable effectiveness. Workaround available
- Low Priority – Minor issues affecting a single user with little impact to the business i.e. faulty Printer or minor service change request. Workaround available, business processes can continue.
2.4 CHANGE REQUESTS
A change request is any modification to the software, hardware or the environment supporting a business process
Change request examples:
- Software updates to be uploaded
- New user incl. email, VPN, ftp account setup.
- New software or pc installation, new printer installation etc.
- Changes to an existing system configuration
To ensure that each change proposed is properly defined, considered and approved before implementation, change requests such as the addition, deletion of any equipment, software or users will be dealt with inside 5 working days of the request being made.
If it is deemed that the change request impacts multiple systems or software, a project will be implemented and the time frame to complete the changes will be communicated to the site contact. This makes sure no unnecessary changes are made, the overall impact is considered, services are not disrupted and resources are used efficiently.
For each new change request, the following will need to be taken into account:
- Description of the functionality being added or modified written to the same level of detail as the system specifications (this varies by project).
- Implications, if any, that would affect other parts of the business. Sometimes a change request will trigger changes elsewhere in the system and it is imperative that the users understand that the system may operate differently.