Support Specification
Last updated 1st January 2023
1. Definitions
In this document, the following terms shall have the following meanings:
“Authorised User”
any employee or agent of a Partner or Customer who: (i) has sufficient technical expertise, training and/or experience with the Platform to perform the Level 1 Support obligations; (ii) is responsible for all communications with HC regarding Incidents, including case submission and Incident reports; and (iii) who is authorised by the Partner to request and receive Level 2 Support for the Platform on behalf of the Partner or Customer.
“Available”
the proportion of time that the Platform is working with no Defects which are Priority 1 issues which have not been resolved in accordance with the timescales set out in paragraph 6;
“Business Day”
a day other than a Saturday, Sunday or public holiday in England when banks in London are open for business;
“Business Hours”
between the hours of 9:00 AM and 5:00 PM local UK time, each Business Day;
“Customer”
an end customer who uses the Platform to transfer data, and who is subject to the Customer Terms and conditions
“Defect”
an error in the applicable software that causes it to fail to operate materially in accordance with its Documentation;
“Documentation”
the operating manuals, user instruction manuals, technical literature and all other related materials in human-readable or machine-readable forms supplied by HC or made available via the Platform;
“End User”
the end user of the Platform;
“HC”
HighCohesion Limited
“Incident”
an unplanned inability to access the Platform or any part of it or reduction in the quality of the access to the Platform or any part of it;
“Maintenance and Support Hours”
between the hours of 9:00 AM and 5:00 PM local UK time, each Business Day;
“Partner”
a third-party who is authorised to develop and implement the Platform, and who is subject to the Partner Terms and Conditions;
“Planned Maintenance”
maintenance intended to resolve or prevent issues, improve performance, make enhancements or implement configuration changes, AS notified to the Customer in advance;
“Platform”
the HC platform located at control.hico.io and further described in its documentation;
“Problem”
the underlying cause of 1 or more Incidents;
“Specification”
this document;
“Total Potential Availability”
the total time in the relevant measurement period, less any time during which Planned Maintenance is taking place;
“Workaround”
a temporary, predefined way of overcoming Incidents caused by a problem before a full resolution is available.
2. Support Levels
Support shall be provided in accordance with the following support levels:
Level 1 Support, provided by the Customer:
collect and document in the Incident report the complete name and contact details of the person reporting the Incident;
check if Incident report from Customer is complete and if necessary, obtain missing data and information from Customer. Such data will include a meaningful Incident description, technical information on the Incident context (e.g. log files) and technical information on the system related to the Incident (system ID, system type, system name etc.;
prepare a comprehensive description of the problem which is the basis of the Incident, which will include all steps that led to occurrence of the Incident, full syntax of the Incident and surrounding factors;
check priority of Incidents based on the definitions set out in paragraph * below;
where possible, remedy the Incident; and/or
summarise status when forwarding the Incident to level 2 Support.
the relevant Partner, (or, where the Customer has no contract with a Partner, the Customer)
Level 2 Support, provided by HC:
search for errors using the data provided by Customer;
analyse the Incident-specific technical data and document the progress of the Incident;
reproduce and isolate the Incident;
analyse if the Incident can be attributed to a defect of the Platform;
propose appropriate system configuration or work-around for Supported Software if the Incident cannot be attributed to a Defect of the Platform;
access Customer’s system in order to perform the required and applicable Incident remedy by using work-around recommendations, or fixes, if available and deemed necessary;
assist Customer in order to perform the required and applicable Incident remedy by using work-around recommendations or fixes if available and deemed necessary;
determine the Defect correction time line and delivery;
recommend Workarounds, change coding and/or provide fixes, if available and if deemed necessary.
3. Exclusions
HC shall not have any obligation to provide Support with respect to any: (i) non-conformance or error in the Platform caused by unauthorised misuse, alteration, modification or enhancement of the same by a Customer, Partner or any third party not subcontracted by HC; (ii) issues that are not reported in accordance with this Specification; (iii) integration of any feature, program or device with the Platform which is not provided by HC, or any part thereof, excluding, for clarity, issues originating in the Platform’s functions or other components of the HC service offering; (iv) Incidents that originate in or are caused by malfunctions in Integrated Third Party Applications, or (v) use of the Platform otherwise than as permitted by HC.
HC shall not have any obligation to provide Level 2 Support in the event Partner/Customer has not provided Level 1 Support. HC shall also have no obligation to provide Level 2 Support in the event of termination or suspension of a Customer’s access to the Platform for any reason. HC may offer Professional Services to help resolve issues that fall outside the scope of the Level 2 Support, at its standard rates for such services.
In the case where a Partner is responsible for Level 1 Support, on receipt of an Incident report, HC shall establish whether there is an Incident for which the Partner is entitled to Level 2 Support under this Section and, if so, shall: (i) confirm receipt of the Incident report and notify Partner of the Incident case number that both parties must then use in any communications about the Incident; (ii) work with Partner to set a severity level for the Incident based on the severity definitions and target response times set forth in paragraph * below; (iii) analyse the Incident and verify the existence of the problem; (iv) give the Partner or Customer (as determined by HC) direction and assistance in resolving the Incident.
4. Severity Classifications
The parties hereby agree to the following severity classifications for Incidents:
Priority 1
critical production issues in the Platform affecting all end users, including system unavailability of the Platform and End User Data transmitted between HC and the Integrated Third Party Application(s) with no workaround available.
Examples of Priority 1 issues are: (i) the Platform is down or unavailable, (ii) a critical part of the Platform is unavailable or inaccessible, resulting in total disruption of work or critical business impact to End Users; (iii) Platform crashes or hangs indefinitely causing unacceptable or indefinite delays for resources or response; (iv) End User Data transmitted between the Integrated Third Party Applications is corrupted or lost and must be restored from backups.
Priority 2
major functionalities of the Platform are impacted or significant performance degradation is experienced. Issue is persistent and affects many End Users and/or major functionality. No reasonable workaround is available.
Examples of Priority 2 issues are: (i) the Platform is operational but highly degraded performance to the point of major impact on usage; (ii) important features of the Platform is unavailable with no acceptable workaround; however, operations can continue in a restricted fashion; (iii) a critical documented feature / function in the Platform is not available; (iv) access to an Integrated Third Party Application deemed noncritical is impacted as a result of errors or malfunctions originating within the Platform.
Priority 3
a bug in the Platform affecting some but not all End Users. Short-term workaround is available, but not scalable.
Examples of “Priority 3” issues are: (i) Platform is operational but partially degraded for some or all End Users, and an acceptable workaround or solution exists; (ii) problem with non-critical feature or functionality in the Platform.
Priority 4
inquiries regarding a routine technical issue with the Platform; information requested on Platform capabilities, navigation, installation or configuration; bugs affecting a small number of End Users. Acceptable workaround available.
Examples of Priority 4 issues are: (i) minor problems in the Platform not impacting service functionality; (ii) missing or erroneous Documentation; (iii) minor problems in the Platform that do not affect delivery of the same.
5. Response and Resolution
HC will use commercially reasonable efforts to respond to and resolve each Incident (or Problem in the case where multiple Incidents are triggered by a single underlying cause) as indicated below. The timer begins when a ticket is received by HC as evidenced by HC’s system(s) of record.
Priority 1: 1 hour within Business Hours
Priority 2: 2 hours within Business Hours
Priority 3: 1 business day
Priority 4: 1 business day
At all times during Normal Business Hours, HC and Partner will commit the necessary resources for problem resolution to obtain a workaround or reduce the severity of the Priority 1 issue. HC and Partner will use commercially reasonable efforts for problem resolution, to obtain workaround or reduce the severity of the error for all other Priority definitions.
6. Authorised Users
All reports of Incidents must be made to HC by the Authorised Users. Partner may substitute Authorised Users from time to time by giving HC prior written notice, including the relevant contact information for any new Authorized User. As a condition to providing Level 1 Support, unless otherwise agreed by an authorised representative of HC, Partner’s Authorised Users must first attend and successfully pass the relevant minimum support training designated by HC from time to time.
7. Report Requirements
All Incident reports must be filed via the method made available by HC. In addition, all communication shall include the following:
(i)The Partner and/or End User username provided by HC, if any.
(ii)A reproducible test case, if commercially feasible, that demonstrates the specific usage that causes the Incident being reported.
(iii) Exact wording of all related error messages.
(iv) A full description of the Incident and expected results.
(v) Any special circumstances surrounding the discovery of the Incident.
(vi) All diagnostic steps previously performed by Partner and/or End User during attempted Incident resolution.
8. Availability
The Platform shall be Available for 99.5% of the total Potential Availability, excluding planned maintenance.