SUPPORT SERVICES AGREEMENT

2020-05-15 V1.0

INTRODUCTION

Subject of this Standard Software Support Services Agreement

This Standard Software Support Service Agreement is intended to stipulate the agreements between End User and Systemation AES BV, hereinafter referred to as “Supplier”, with respect to the services provided by Supplier in the context of the application support services for the the software. In addition to the description of the services, the SLA includes key performance indicators and standards for the scope and quality of the services delivered. Per indicator, the corresponding standard is included.

The included service level standards are minimum standards in application support to which Supplier must comply.

These Standard Software Support Services include:

  • Providing improved versions (updates); 
  • Providing new  versions (upgrades); 
  • Providing of Patches; 
  • Providing support via a professional helpdesk for the TIBCO EBX Platform.

The Standard Software Support Services do not include:

  • Services of any kind in relation to the generated application (s). An additional Service Level Agreement (SLA) must be concluded for this.

Term of the Standard Software Support Services Agreement

The Standard Software Support Services Agreement commences on the Effective Date of the End User License Agreement (‘EULA’) between End User and Supplier. Unless Parties agree otherwise, the Standard Software Support Services Agreement ends on the end date of the EULA.

Changes to the Standard Software Support Services Agreement

Changes to this Standard Software Support Services Agreement can be proposed and discussed by the contract managers of the Supplier and the Customer. Proposed changes must be recorded in writing and signed for approval by the contract owners of the Supplier and the Customer. Changes to this Standard Software Support Services Agreement will be recorded on the change sheet included at the beginning of this document.

The change sheet will in any case contain the following information: Change date, new version, who entered the change, (sub) paragraph in which the change took place and the change (s) concerned. This change sheet is initialled by both parties, after which the change has become part of these Standard Software Support Services.

This Standard Software Support Services Agreement will in any case be evaluated by the contract managers of the Supplier and the Customer every year, at the latest one month before the anniversary of the Effective Date of the EULA and adjusted where the Customer deems it desirable and / or necessary.

If a change in the objects and/or the service levels, to which this Standard Support Services Agreement relates to, has a major impact on the scope and/or complexity of the Standard Support Services, the Parties may mutually agree to adjust the  agreement. When the desired adjustments  have an impact on the size and/or complexity an additional Service Level Agreement (SLA) will be composed. Additional costs will be charged for this SLA.

Supportdesk

In the context of this Support Services Supplier hosts a professional service desk. The Supplier service desk is responsible for the following activities:

  1. During office hours (08:30-17:00), support desk staff will monitor the registration of incidents;
  2. 3rd line* support for incidents within agreed service windows (09.00 to 17.00 H) on Dutch office days  in relation to the TIBCO EBX platform.

Scope

  • The scope of this Standard Support Agreement is limited to the TIBCO EBX platform only;
  • In case it is deems necessary to include support from End User or third parties, the response times/resolving time will not be part of the calculation of various Standard Services parameters.
  • End User will, as far as possible, assist in the resolution of malfunctions and the implementation of work-around solutions, provided that continuity and performance is ensured. Supplier stays responsible for solving issues.
  • All disturbances outside the scope of this agreement are explicitly not part of the agreed service levels.
  • Out of scope activities will only be charged to End User, after prior approval by End User on scope, cost and time, validated by a Purchase Order.

The End User is responsible for the following first line maintenance and support activities:

  • Front-office for general user questions

The End User is responsible for the following second-line maintenance and support activities:

  • Technical application management.
  • Functional application management.
  • Performing patch management and upgrades on operating systems, databases and the Standard software.
  • Monitoring and maintaining the infrastructure, such as the network, databases and operating systems and the standard software.
  • Optimize the interaction with the Supplier with regard to expert questions and other forms of third-line support (“Single Point of Contact” between the Customer and the Supplier).

MEETINGS

Standard Software Support Services Meeting

If deemed necessary, one of the Parties may schedule a meeting on an ad hoc basis. Supplier creates minutes of this meeting and maintains an action register of the Support Services meetings and these will be submitted for approval by all Parties involved.

QULAITY AND SCOPE OF SERVICE OFFERING

Prerequisits

For the purpose of effective and efficient support, the following prerequisites need to be met:

  • Incidents are normally signaled in the production platform. The malfunctions and incidents are solved in the development environment and promoted to the Test environment. End User will, after testing, deploy the solution on the Acceptance and the Production environment. If the cause is not immediately found, Supplier will make efforts to reproduce this in the development environment in close cooperation with End Customers MDM application manager.
  • De procedure Incident Management will be followed (please find below).
  • For questions about incidents, refer to the incident number provided by Supplier.
  • Supplier does not make any changes outside the agreed service windows without prior notice of End User.
  • When Supplier has to make changes, the Supplier issues a quotation based on estimation to the best of its ability. This proposal when executed will be invoiced time and material based.
  • The schedule for the guaranteed minimum available Supplier capacity for the End User in this period is based on regular Dutch office days and office hours from 09:00 to 17:00. For public holidays officially recognized in the Netherlands, additional agreements must be made to meet End User’s need.
  • Incidents are reported using Supplier’s ticket system. If there is a (possible) Prio 1 disturbance, End User’s representative will also report this by telephone. When a (possible) Prio 1 disruption is detected by Supplier, Customer’s contact person will be informed.

Support Service Servicedesk

For both the service desk and application support, the services are delivered by Supplier within a so-called time frame. For the different services, this time frame is defined as follows:

Element Service Level
Service window Monday:       from 09.00 to 17.00

Tuesday:       from 09.00 to 17.00

Wednesday: from 09.00 to 17.00

Thirsday:       from 09.00 to 17.00

Friday:           from 09.00 to 17.00
Servicedesk
  • Reporting incidents and questions can be done 24 hours a day from a helpdesk ticketsystem directly into Supplier’s ticket system.
  • A Priority 1 incident has to be reported by the MDM application manager by telephone +31 (0)88 3031122 during office hours. 
Additional opening hours
Availability outside the indicated timeframes has to be requested by End User with a notice period of preferably 8 (eight) workdays, but at least 5 workdays. An additional charge for this service will be agreed upon separately.

INCIDENT MANAGEMENT

Scope

The purpose of the incident management is to resolve disruptions in End Customers business processes. End Customer should experience as little disruptions as possible and should resume normal operations. 

Activities

For Incidents related to applications which are under the responsibility of Supplier, the following actions will be performed:

  • Fix the incident by correcting the issue, defining and implementing a work-around or making an appointment to implement a change.
  • A resolution of a Priority 1 or Priority 2 incident can exist in creating a workaround. If so the incident will be downgraded to a Priority 3 incident.
  • Create a change request in the change management process.
  • Create a problem report if multiple incidents are registered with the same cause.
  • Alignment and communication with parties responsible for managing relevant ICT infrastructure components and application areas that are not covered by this Standard Software Support Services Agreement.

Priority Levels

The notifier of an incident determines the urgency and impact of the incident. This leads to an Priority-level. When the impact and urgency are low there will be a lower priority logged, but when both the urgency and impact are high, then the priority is also high. 

In the table below there is a definition of the Priority-level (Urgent, High, Medium and Low).

The following are Priority Definitions that should be used to determine business critical, high, medium or low priority of issues
Priority-level Definition
1 Urgent Definition: The loss of a critical business service or function for the organization and no workaround is available.

  • Business and Financial Exposure – Application failure creates critical business operations and major financial impact
  • Work Outage – The application failure causes the client to be unable to work or perform some significant portion of their job.
  • Number of Users Affected – Application Failure affects majority of the users
2 High Definition: The partial or limited loss of a critical business service or function.

  • Business and Financial Exposure – Application creates serious impact to business operations and major financial impact
  • Work Outage – The application failure causes the client to be unable to work or perform small portion of their job at some locations
  • Number of Users Affected – Application failure affects some of the users
3 Medium Definition: Degradation or potential loss of a business service or function, but service continues (with or without a workaround).

  • Business and Financial Exposure – Application failure causes minimum business and financial exposure
  • Work Outage – The application failure causes the client to be unable to work or perform minor portion of their job and able to complete most of their jobs
  • Number of Users Affected – Application failure affects only a few (one or two) users
4 Low Definition: Incidents impacting individual end-user or small groups, an inconvenience to the business

  • Business and Financial Exposure – Application failure causes no business and no financial exposure
  • Work Outage – No loss of service
  • Number of Clients Affected – Application failure affects only a few (one or two) users

Per Priority there are different response times and resolution times. In this table there is a distinction between Response-time and solving time (resolution delivered).

Priority Levels Response Time Solving Time (workours/workdays)
1 Urgent < 1 hour < 8 hours
2 High < 4 hours < 16 hours
3 Medium < 2 days < 5 days
4  Low < 5 days n/a

Hours means business hours (working days from 8.30 till 17.00 hrs). For Critical Issues (P1) Systemation will continue working on a solution or workaround, after business hours.

Escalation

Escalation is applicable when:

  • Agreements, service levels and/or quality of services delivered by Supplier to End User are violated by Supplier;
  • Severe disruptions occur in the service offering or when for a longer period deviations exist or have a high likelihood to occur on the main KPI’s;
  • Incidents are not resolved within the resolution times, regardless priorities set.