Service Level Agreement
SLA
1. Applications and services in scope
SaaS and data services purchased via
- datamarketplace.drimble.com
- www.drimbledata.com
2. Availability
For its SaaS services, Drimble Data aims for an 99.5 availability percentage. The SaaS services’ accessibility is a moving average over time, calculated annually using the following formula:
𝐴 = (𝑇𝐻−𝐷)/𝑇𝐻 * 100 %
A = Availability
TH = The total number of hours per year that the SaaS services must be available. This period is set
at 8,760 hours.
D = Total downtime over the previous year.
The unavailability of the SaaS service starts from the moment that the unavailability is reported to Drimble Data by the User or when Drimble Data signals a malfunction. The SaaS service not being available during a maintenance window does not count as downtime.
3. Application- and service support process
- Drimble Data receives support inquiries, incident reports, and change requests through the following channels:
- Per email via info@drimble.nl
- Per telephone to +31(0)20 3086 934
- Per ticket in Jira Service Management (planned)
- Per notification in Slack (if agreed with User)
Where possible, the issue will be answered/solved by the Drimble Data first line of support.
If specific application or system technical knowledge is required, the issue is transferred to second-line support, where operations and application specialists analyze and resolve issues through, for example, configuration and/or additional explanation.
If an issue cannot be solved by second-line support and the resolution requires a change or bug fix, the issue is transferred to third-line support and the resolution is taken care of by development and/or systems admin
4. Incident management
Incident management is understood to mean the registration of all incidents, by email, in a biweekly meeting, or in a Jira Service Management ticket, which is escalated to the second-line support, registration of necessary actions, solutions, response times, and compliance with the relevant standards.
Involving all parties in the resolution of incidents, agreeing on a term for follow-up and monitoring developments.
Reporting the resolution of incidents by email, in 2 weekly meetings, or in Jira Service Management ticket to those involved as soon as a solution is available.
Analyzing the incidents afterward in order to draw conclusions and take preventive measures
5. Service coordination
In order to facilitate communication between Drimble Data and the other service suppliers, service coordination includes providing a single point of contact for all goods and services. This contains
- Planned downtime
- System upgrades
- Software adjustments
- Contact person for testing
6. Release management
In the context of release management, User may expect Drimble Data;
- To actively communicate about the release calendar for software and service upgrades and dates/times for hot fixes and data updates.
- To actively communicate about the possible impact of new releases on the User’s activities.
- To make every effort to prevent new releases from containing previously existing bugs and to ensure that new functionality and/or data is suitable for use by the User.
- To enable the designated contact person at the User by means of the necessary information to introduce new functionality/data, this does not include training.
- To provide sufficient and effective support (1st, 2nd, and 3rd line) for the new release for Users who can be in direct contact with Drimble Data.
- To make recommendations for the deployment of new versions
- To provide deployment and activation for new product versions
- To maintain product versions in the context of release management.
- To provide deployment Announcements and Release Notes to designated contacts.
6.1 Release control and management
After all data and/or software has been tested by Drimble Data and any suppliers, release control and management includes all that has to be done to implement data and software (and fixes) to the production environment. The scope will depend on the type of release or fix; for instance, if it’s a fix for a critical issue, the scope can be kept to a minimum but can include the following:
- Support for the deployment on a (beta- ) test environment
- Delivery of suitable test data
- Support and bug fixing during user acceptance testing
- Support for the deployment to the production environment
7. Preventive maintenance
Drimble Data shall carry out any application maintenance that is considered required for the daily operations of the Drimble Data services. Examples of this are:
- Maintenance on the reference databases
- Maintenance on hosted- and Cloud- infrastructure
- Maintenance on file folders and log files
The aforementioned maintenance activities are covered by a fee for the service. Additional maintenance can be performed by Drimble Data after an explicit request and agreement between User and Drimble Data.
8. Service levels
Drimble Data makes every effort to achieve the service level objectives agreed with the User for the response and resolution times as specified in this SLA.
Issues requiring a fix in the code or data will be managed under a release process agreed upon with the User for both regular releases and emergency releases (hotfixes).
The scope of the regular releases will be determined by Drimble Data. Where it concerns specifically promised functionality or fixes for the User, the scope is determined in accordance with the User. Prioritizing fixes in a release based on operational or business requirements may result in response targets for existing individual items not being met.
8.1 Availability support for Applications and Services
Drimble Data provides support for the Applications and Services on working days, Monday to Friday from 09:00 to 17:00 hr. CE(S)T (excluding Dutch public holidays).
Outside office hours and on weekends, operational issues can be reported via email or voicemail, (and Slack if agreed). In the case of urgent issues, Drimble Data will investigate the issue as soon as possible, report back and try to resolve it. Non-urgent issues are handled the following working day.
9. Downtime for scheduled maintenance and regular deployments
Downtime for necessary maintenance will be communicated to User in advance, stating:
● Date and time
● Duration of the interruption
Maintenance will take place on working days and outside office hours as much as possible.
10. Response times and procedures
Drimble Data divides issues into the following 3 categories:
● Issues that are subject to price agreements
● Issues that are not subject to price agreements
● Requests for changes (Change/Feature requests)
All issues are treated according to priority:
PRIORITY
DEFINITION
EXAMPLE
1 Urgent
Business critical for all users; no workaround available
Total service outage
2 High
Business critical no workaround available for certain users
Applications and Services not available at all for certain countries, performance issues
3 Medium
Any impact on the service that harms operations or the business process, but is not business critical without available workaround
Problems with missing data
4 Low
Any impact on the service that harms operations or the business process in the long term, but is not business critical and for which a workaround is available
Reference data update delay issues
5 Not urgent
Any impact on the service that does not harm operations or the business process
Design errors in the UI
10.1 Response time for issues covered by the service fee
Priority
Conformation
Response with plan for fix in
Status update
every
Solution
1 Urgent
2 hrs
4 hrs
2 hrs
6 hrs
2 High
4 hrs
8 hrs
4 hrs
Emergency release within 3 days
3 Medium
1 day
2 days
5 days
Next planned deployment
4 Low
1 day
5 days
10 days
Within 10 weeks
5 Not urgent
1 day
By agreement
By agreement
By agreement
10.2 Response time for issues, not covered by the service fee
Issues such as additional ad hoc deliveries of data or processing of data that are not covered by the service charge. Individual issues may be designated by the User as a high priority from a commercial or operational point of view. The services for processing/solving these issues will be performed after mutual agreement and will be settled separately from the regular price agreement.
Priority
Response with resolution planning
1. Urgent
Within 8 working hours
2. High
Within 8 working hours
3. Medium
Within 25 working days
4. Low
Within 5 working days
5. Not urgent
By individual appointment
11. Requests for Change / Feature
These may be reports about issues that have not yet been reported as a problem, but as a request for an adjustment to improve the functionality. RFCs are submitted through the Drimble Data’s support contact channels. Drimble Data will give a preliminary response with a date on which a description of the RFC and an estimate of cost and time can be supplied. Once delivered, this statement enables the user to choose whether to budget and request the RFC.
Response with planning and price/effort statement
Change Requests
Within 10 working days
12. Planned interruption of the Applications and Services
12.1 Scheduled interruptions
Planned interruptions for maintenance or deployments will not occur during business hours whenever possible. Where planned downtime is expected, Drimble Data will inform User at least 24 hours in advance about the planned date, time, and estimated duration of the interruption.
12.2 Emergency outage
An emergency outage may be required in exceptional cases to apply a fix that resolves a failure in the Applications and Services. If an emergency outage is unavoidable, Drimble Data will report this in advance via the User’s relationship manager.
