Support Services Terms & Conditions
(Updated 19th July 2018)
1.1 the Platform Provider will deliver the following Support Services:
(a) the day-to-day operation, management and maintenance of the Supported Assets;
(b) a first-line telephone helpdesk, which is manned during UK working hours on 0800 909 8959 and is available for voice messages on a 24 x 7 basis on 0800 909 8959 (or such other number as is notified to the Client from time to time);
(c) email support via support@livingwith.health
(d) identification and resolution of Incidents.
1.2 The Platform Provider will provide response (UK working hours) and resolution times for all support issues as set out below as long as the following process is followed:
(a) Severity 1 or Severity 2 Incidents should be reported immediately by telephone to the Platform Provider’s 24×7 helpdesk number, regardless of the time of day the issue occurs. Please do not report lower priority issues by telephone;
(b) all Incidents, including Severity 1 & Severity 2 Incidents, should also be reported through the Platform Provider’s email support system. Please complete the following ticket fields:
- Your email address – Your email address is used to communicate progress on the ticket with you. If you wish a team of users to submit requests and to receive updates on ticket progress, please provide an email address that has been configured by your own IT team to be directed to all the relevant people (e.g. address@mycompany.co.uk). This is a mandatory field.
- Your name – if you are submitting a ticket using a team email address, please enter your name. If you’re submitting a ticket using your own email address, this field may be left blank.
- Which product or service do you require assistance with – Please select the relevant option for your support request. This is a mandatory field and it is important you set it to the correct value to ensure the issue is dealt with as quickly as possible.
- Ticket Type – All faults or outages should be reported as an Incident or Problem ticket type. There is no difference in the handling of Problem and Incident ticket types. If you have a question about the functioning or administration of your service, please select the Question ticket type. If you’re submitting an approved change request, please select the Task ticket type. This field is mandatory.
- Priority – This field allows the reporter to indicate the severity of the problem or the urgency with which the answer to a question or change request is requested. For problems and incidents, the assigned priority must match the agreed definitions (see the following sections for definitions and target response and resolution times). This field is mandatory. the Platform Provider reserves the right to re-prioritise a ticket where the requested priority does not align with the agreed definitions. Any changes to ticket priority will be agreed with the Client.
- Approved Change Request – For customers who have selected an on-going maintenance (OGM) support option, this field can be used to indicate that the ticket describes a minor change request that has been approved for application to the system. The priority field is used to indicate the requested timescales within which the change request should be assessed by the support team and a time agreed for the test and deployment of the change.
- Subject – A short description of the issue. This field is used as the title of the ticket so it is best to keep it short but as descriptive as possible.
- Description – A full description of the nature of the problem or enquiry. When reporting problems it is important to provide as much information as possible explaining the nature of the problem, and a full list of steps indicating how it can be reproduced. Please also supply information about the system (e.g. PC, Mac, Android phone) and browser (including version number) in which the problem is exhibited.
1.3 The following table defines the target response and resolution times for the Platform Provider Support tickets categorised as an Incident or a Problem. There is no difference in the handling of Incident and Problem tickets. Support tickets categorised as Questions, and Tasks including Change Requests are outlined below. All times are quoted in support hours. For Standard Support customers, support hours are UK working hours (9am-6pm, Monday – Friday, excluding public holidays). For Premium Support customers, support hours are 24×7 all days of the year.
| SLA Classification | Ticket Priority | Description | Response Time | Target Resolution Time |
| Severity 1 | Urgent | There is a total loss of the functionality provided by the Living With Platform | 100% within 4 hours | 100% within 8 hours |
| Severity 2 | High | Some operations can continue in a highly restricted fashion, but there is some severe and critical loss of use of functionality affecting the majority of users in the Living With Platform | 100% within 4 hours | 95% within 16 hours |
| Severity 3 | Normal | Living With Platform can be used with some restrictions, but some of the software does not function correctly and no alternative features are available to achieve equivalent functionality. | 95% within 8 hours (1 day) | Core product issues: 95% within 40 hours (5 days)
|
| Severity 4 | Low | The Living With Platform can be used with some inconvenience because but does not function correctly. Users can work around the problem or may use alternative features in the Living With Platform to achieve equivalent functionality. | 95% within 24 hours (3 days) | Next scheduled product release. |
| Severity 5 | Superficial | The Living With Platform contains a minor or cosmetic error that does not materially impede use. | 95% within 40 hours (5 days) | Next scheduled product release. |
Notes:
- Response Time is defined as the time for the Platform Provider support team member to be assigned the ticket and reply to the Client with confirmation the issue is being worked on. As soon as an assessment of the issue has been completed, the Client will be updated with the expected resolution time. Further updates to the expected resolution time may follow as the situation develops. Response times are measured from the receipt of a report of the issue in the Platform Provider’s support ticketing system, including adequate information for the fault to be properly analysed. An automated acknowledgement of the receipt of a support ticket does not count as a response.
- Target Resolution Time is defined as the time for the Platform Provider support team to supply a workaround, software patch, software update or other relevant information addressing the reported issue. Resolution times are measured from the receipt of proper notification of the issue from the Client in the Platform Provider’s support ticketing system, including adequate information for the fault to be properly analysed. Resolution times cannot be guaranteed, however the Platform Provider will ensure reasonable measures are taken to resolve issues within the target times defined above.
- The supply and application of patches and hot fixes to the core the Platform Provider product, regardless of severity or when they are reported.
1.4 Approved minor change requests should be categorised as Tasks and the ticket submitter should tick the Change Request field of the ticket. Doing so confirms that the change request described in the ticket has been approved for application to the system by the Client without further review or sign-off. The following table defines the target response and resolution times for support tickets categorised as Approved Change Request Tasks.
| SLA Classification | Ticket Priority | Expected Response Time | Target Resolution Time |
| N/A | Urgent | 90% within 8 hours (1 day) | N/A |
| N/A | High | 90% within 24 hours (3 days) | N/A |
| N/A | Normal | 90% within 40 hours (5 days) | N/A |
| N/A | Low | 90% within 80 hours (10 days) | N/A |
| N/A | (Not set) | 90% within 80 hours (10 days) | N/A |
1.5 Target resolution times for approved minor change requests and the plan for testing and deploying the changes will be agreed with the Client before commencing work.
1.6 Once raised, a support ticket is automatically assigned to the support team best suited to respond. While the ticket is awaiting assignment to a specific support term member, its status is shown as New. An individual within the support team will be assigned the ticket and they will provide an initial response within the timescales described above confirming the ticket is being looked at. Wherever possible the initial response will provide further information about how long the ticket is expected to take to resolve. While a ticket is being worked on by the Platform Provider support team, its status is shown as Open. If at any time the Platform Provider support team need further information from the ticket submitter or any other 3rd party, the ticket status is shown as Pending. If a ticket results in a hot fix or patch, the ticket status will change to On-Hold while the patch is prepared and the test procedure of deploying the fix to the review environment and testing prior to deployment to live is completed. Tickets requiring software or technical configuration changes of any sort will result in an internal ticket being raised in Jira and linked to the support ticket. Jira is the tool used internally by the Platform Provider to manage the activities required to produce and test the hot-fix or patch.
1.7 Once a ticket is deemed to have been completed (and a fix successfully deployed to the live environment if necessary), its status will be changed to Solved. The ticket will remain in the Solved state for 4 working days (elapsed time) after which it will automatically transition to Closed. If a ticket in the Solved state receives any further comments (including a response saying “Thank you!”) the ticket will be automatically reopened. When reopening a ticket in this way, please give as much information as possible in the comment explaining why you don’t believe the ticket has been adequately addressed as yet. “Thank you” messages, nice though they are to receive, are therefore unfortunately best avoided!
1.8 Once closed, a ticket cannot be reopened, however if necessary a follow-up ticket can be created. The follow-up ticket will reference the closed ticket and contain all the same information. You can create a follow-up ticket by locating the closed ticket and clicking the Create Follow-Up option.
1.9 The ticket submitter will receive email notifications informing them whenever a comment is added to a ticket and whenever the status changes.
1.10 Fixes for support issues fall into one of two categories: hot fixes and patches.
(a) a hot fix is a small configuration, software, or data change to the target environment that may be deployed without the need for restarting any servers and without any end-user downtime;
(b) a patch is a configuration, software or data change to the system, including the deployment of any patches, whose deployment requires the restart of one or more servers in the target environment. In the majority of cases patches can be applied to a live environment without any end-user downtime, however in a small number of cases the application of a patch may require the site to be placed in maintenance mode for the duration of the update.
Any planned downtime for maintenance will be communicated and agreed with the Client in advance of the update taking place. In the event of any downtime that is the result of an emergency, the Platform Provider will use all reasonable endeavours to inform the Client in advance of the downtime concerned.
1.11 A number of common support activities incur a standard amount of support time as defined below.
| Activity | Standard Time |
| Deployment of hot-fix to test environment | 2.0 hours |
| Deployment of hot-fix to production environment | 3.0 hours |
| Deployment of patch to test environment | 2.0 hours |
| Deployment of patch to production environment | 4.0 hours |
1.12 If you are not satisfied with the Platform Provider support service for any reason and have not been able to resolve the issue with your nominated the Platform Provider contact, please contact your account manager.
1.13 The Platform Provider shall ensure that it has appropriate security and business continuity procedures in place in relation to the Living With Platform.
