Service Level Agreement
Introduction
Purpose
The intent of this Service Level Agreement (SLA) is to ensure that the proper understanding and commitments are in place for effective software support.
Duration
This SLA is valid for the duration of the contract.
Scope
The service to be provided is the provision of support services, and the definition of standard terms and procedures that will guide the software quality: Opinum Data Hub on EU cloud as well as the availability of the platform. The areas to be serviced are not directly linked to the Client facility and offices as the software is provided on a remote access basis (Software as a Service) but data pushed to Opinum are under the responsibility of the Client.
Service will not include:
- Requests by personnel not belonging to the authorized list of employees from the Client or not belonging to the list of users of the software application, expect if communicated to the Support team at project delivery.
- Access Management or other security-related process if those are managed by the Client.
- Integration with Client systems for which Opinum has no control or contractual agreements.
- Incidents or requests from other legal entities not being part or contracted by the Client, or not being communicated to the Support team at project delivery.
- The processing by the Client, or any other third party, of files or information generated by the software and exported on the Client Information System architecture.
- The availability of module from the Marketplace.
Service packs are available for services not in the scope of this SLA (https://www.opinum.com/en/pricing/).
For Clients with on premise solutions, separate conditions of this SLA will apply.
The SLA conditions will only apply to standard Opinum Data Hub functionalities. Any new feature or support tools released in the product will automatically be covered by the SLA terms after a 6 months piloting period with the exceptions of features tagged preview.
Definition
- Agreement: a document that describes a formal understanding between two or more parties.
- Availability: ability of an IT service or other configuration item to perform its agreed function when required.
- Failure: loss of ability to operate to specification, or to deliver the required output.
- Impact: a measure of the effect of an incident, problem or change on business processes.
- Incident: an unplanned interruption to an IT service or reduction in the quality of an IT service.
- Incident Management: the process responsible for managing the lifecycle of all incidents.
- Priority: a category used to identify the relative importance of an incident, problem, or change.
- Process: a structured set of activities designed to accomplish a specific objective.
- Resolution: action taken to repair the root cause of an incident or problem, or to implement a workaround.
- Service Hours: an agreed period when a particular IT service should be available.
- Service Level: measured and reported achievement against one or more service level targets.
- Service Level Agreement (SLA): an agreement between an IT service provider and a customer.
- Service Request: a formal request from a user for something to be provided
- Severity: a measure of how long it will be until an incident, problem or change has a significant impact on the business.
- Working hours: from 8:00 AM to 6:00 PM, from Monday to Friday (CET).
- Working times: all Times
Service Objectives and Measurements
Description of the service
| Service | Description | Examples |
|---|---|---|
| User Support | Receive, document, and prioritize incidents related to the use the Opinum’s applications or services. | - Provide help desk support |
- Answer enqueries about applications
- Receive and document incident reports
- Collect and document requests for changes
- Share status of requests | |Application Quality |Bring an application to its functionality before an incident arose. This may include a permanent fix or a temporary work around until a permanent fix is found. |- Root cause analysis
- Retrieve functionalities
- Fix incidents or setup work arounds |
Location of the service
The physical location of the performed services is based in the Opinum operational headquarters. As the software is offered on a Cloud/SaaS basis mode, all developments, incidents follow-up are performed remotely from the Client premises.
Service Hours
Service must be available during normal business hours, from 8:00 AM to 6:00 PM, from Monday to Friday (CET). A service can be Requested, or an Incident can be reported by the Opinum Incident Hub (https://help.opinum.com/tickets) at any time.
Incidents reported, or services requested outside the working hours will be served at the next scheduled working day, unless a special procedure for major Incident is invoked.
Service Availability
The solution also features the Pingdom tool, which monitors the availability of authentication, the portal, and the web application (http://uptime.opinum.com/). The provision of the Service covered by this SLA, availability is determined by the percentage of the average availability of these three factors.
The Service Provider will seek 100 % availability during working hours, for client to report an incident or request a service at working times. Availability of the interface is provided below:
| Interface | Availability / Answering time | Hours to Measure Availability |
|---|---|---|
| Pingdom | https://docs.opinum.com/status/status.html | At All Times |
Service level credit
If Opinum fails to achieve the above Service Availability, Customer may claim a credit for such Opinum Service as provided below, up to a maximum credit per calendar quarter equal to one month's Opinum Cloud Service subscription fees.
| Percentage availability per calendar quarter | Credit |
|---|---|
| 100 | No credit |
| 99.99 – 99.999 | No credit |
| 99.9 – 99.99 | No credit |
| 99.0 – 99.9 | 8 hours |
| 95.0 – 99.0 | 1 day |
| 0 – 95.0 | 1 month |
Exclusions
A Customer will not be entitled to a service credit if it is in breach of its Agreement with Opinum, including payment obligations. The Service Level Commitment does not apply to any downtime, suspension or termination of the applicable Opinum Service (or any Opinum Content or Opinum Software operating in connection with the Opinum Service) that results from:
- Account suspension or termination due to Customer's breach of the Agreement.
- Routine scheduled maintenance (Opinum's Maintenance Policy is available at https://docs.opinum.com/status/status.html#scheduled-maintenances).
- Unscheduled, emergency maintenance or an emergency caused by factors outside Opinum's reasonable control, including force majeure events such as acts of government, flood, fire, earthquake, civil unrest, acts of terror, Customer Content, Third Party Content or Internet Service Provider failures or delays.
- Usage of Opinum Data Hub outsides the limits (https://docs.opinum.com/usermanual/starter-guide/limits.html)
- A Customer's equipment, software or other technology, or third-party equipment, software or technology (other than those which are under Opinum's control).
- Failures resulting from software or technology for which Opinum is not responsible under the Agreement.
No Service Level Commitment is provided for free, proof-of-concept or unpaid trial services.
Service credit claims
To receive a service credit, a Customer must file a claim for such credit within five (5) days following the end of the calendar quarter in which the Service Level Commitment was not met for an applicable Opinum Service, by contacting Opinum at finance@opinum.com with a complete description of the downtime, how the Customer was adversely affected, and for how long. Opinum reserves the right to deny the service credit if the Customer does not qualify as explained in the previous point, exclusions. The service credit remedy set forth in this Service Level Schedule is the Customer's sole and exclusive remedy for the unavailability of any applicable Opinum Service.
Opinum shall not be liable for the consequences of unavailability.
Service contact
Ticket/ Incident Hub web portal: https://help.opinum.com/tickets
User support
The following procedures will be used to respond to incidents that are received by the Hypercare team. An Incident is defined as an unplanned system event which adversely affects software processing or software deliverables.
Priority settings
Below table shows the distinct categories of priority which is defined for each Incident
| Severity Code | Definition |
|---|---|
| Critical | An incident has made a critical application function unusable or unavailable and no workaround exists |
| High | An incident has made an important application function unusable or unavailable and no workaround exists |
| Normal | An incident has made an important application function unusable or unavailable, but a workaround exists or isolated use of Opinum DataHub features fails on specific cases |
| Low | A problem has diminished supportive application functionality or performance or cosmetic issues. |
In order to clearly identify the severity code, hereunder is a non-exhaustive list of use cases that provides ideas on how to classify new tickets:
| Severity Code | Use cases |
|---|---|
| Critical | - Users can no longer access Opinum Data Hub either through the web interface or the API - Opinum data ingestion services are down and incoming data are lost - API is not available - Master Data processing is down |
| High | Important application feature is down and no workaround is possible, e.g.:- Report can’t be sent - Alerts are not fired - Dashboards are not available |
| Normal | - Important application feature is down and no workaround is possible, e.g.: - Report can be sent in XLS but not in PDF format - Raw alerts are not fired but scheduled and rolling alerts are fired - Alerts can't be sent by SMS but can be sent by email- Isolated use of Opinum Data Hub features fails on specific cases, e.g. - A newly formatted report is not generated - A specific alert is not triggered - A specific calculated variable is not calculated - A specific dataset is not up-to-date , etc. |
| Low | - A Opinum Data Hub feature, however functional, is slower than usual (e.g. report takes longer to be generated)- New type of configuration in Opinum Data Hub fails (e.g. a new algorithm on a calculated variable does not behave as expected - aka there is a need to review and analyze script) |
Application type
Below table describes the Incident types defined in our support platform to categorize correctly all incoming cases / tickets / requests / incidents. All those incoming feeds are not necessarily problems and therefore be categorized in specific application types.
| Application Type | Description / Example | Priority Mandatory | Subject to SLA |
|---|---|---|---|
| Incident | Application function failure which will be categorized according to the Priority settings and data ingestion issues which are caused by a Data Hub malfunction | Y | Y |
| Data | Request for data corrections, loads, adjustments | Y | Y |
| Improvement | Feature improvement request, leading to another development process (CAB: Change Advisory Board) | N | N |
| Question | Generic question about the Opinum software or the company | N | N |
| Usage | Question related to the usage of the software or the interpretation of the data | N | N |
| Access Request | User requesting access to the Opinum software | N | N |
| Not an Incident | Unclassified requests | N | N |
Performance
The target resolution time for each Incident depends on its Severity. The agreed targets are as follows:
| Priority | Severity | Initial response* / Problem identification (business hours) | Maximum Resolution Time* (business hours and days) |
|---|---|---|---|
| 1 | Critical | 4 hours | 16 hours |
| 2 | High | 1 day | 3 days (Hot-fix or workaround in current release) |
| 3 | Normal | 3 days | Next two releases (*) |
| 4 | Low | 5 days | Planned accordingly to the roadmap (*) |
- Initial Response is when an incident is opened and acknowledged by the Opinum Support team
- Maximum Resolution Time estimation is when the user that logged the ticket is informed of an estimated resolution time.
- Resolution is the point at which the problem is resolved, and the software function is returned to a usable and available state.
Opinum cannot guarantee those performances for incidents and issues related to third party applications, services, and suppliers, for the common SaaS environment shared between different clients.
(*) Opinum normal release cycle is around every four weeks, but Opinum cannot commit on these cycles. Indeed, those can be shorter or longer depending on the priorities / urgencies and the roadmap requirements. As for reference, a shorter release cycle is possible in case there’s an urgent release need for one of the Data Hub customers. On the hand, the cycle can be longer when major developments require extensive testing in order to avoid potential regressions.
Incident Management
Incident hub
Opinum is using Hubspot (http://www.Hubspot.com) as the ticketing / incident management platform. The solution offers two functions:
- The incident management service, which is accessible and managed by the Support team only.
- The Opinum help center, which is accessible to Opinum users and managed by the Support team.
Incident management service
Module allowing the management of all incidents/
- Incident lists
- Incident details and history