2.3 Service Level Agreement (SLA)

Ikræfttrædelse 01-10-2023

2.3.1 Agreement Overview

The agreement overview includes four components:

  1. SLA introduction
  2. Definitions, convention, acronyms, and abbreviations (A glossary)
  3. Purpose
  4. Contractual parameters

2.3.1.1 SLA Introduction

This StudentPulse Service Level Agreement ("SLA") between StudentPulse A/S. ("StudentPulse", “supplier”, "us" or "we") and users of the StudentPulse Services (“customer”, “purchaser”, "you") governs the use of the StudentPulse Services under the provisions of the StudentPulse Terms and Conditions (the "Terms").

Unless otherwise provided herein, this SLA is subject to the provisions of the “Terms”.

2.3.1.2 Definitions

Term

Description

SLA

Service Level Agreement

Accuracy

Degree of conformance between a result specification and standard value.

Timeliness

The characteristic represents performance of action that leaves sufficient time remaining so as to maintain SLA service expectation.

IT Operations Department /

Service Desk

A unit of “customer” responsible for internal IT Operations.

Maintenance

Scheduled Unavailability of the StudentPulse Services, as announced by us prior to the StudentPulse Services becoming Unavailable.

Monthly Uptime Percentage

Is calculated by subtracting from 100% the percentage of minutes during the month in which the StudentPulse Services were Unavailable. Monthly Uptime Percentage measurements exclude downtime resulting directly or indirectly from any SLA Exclusion.

Service Compensation

Means a credit denominated in Euros (EUR), calculated as set forth below, that we may credit back to an eligible account.

Unavailable and Unavailability

For app services and databases, when your service or database is not running or not reachable due to StudentPulse's fault.

2.3.1.3 Purpose

The purpose of this SLA is to specify the requirements of the service as defined herein with regards to:

  • Requirements for service that will be provisioned to “customer”
  • Service targets
  • Criteria for target fulfilment evaluation
  • Roles and responsibilities of StudentPulse
  • Duration, Scope and Renewal of this SLA contract
  • Supporting processes, limitations, exclusions and deviations.

2.1.3.4 Contractual Parameters

This section specifies the contractual parameters of this agreement:

  • This SLA is an appendix to “Terms”. As per “Terms”, StudentPulse and “Customer” have signed an agreement, which means this SLA is terminated at the same time as the contract and with the same terms. This SLA is valid until further notice and/or until next review.
  • In case of SLA reviews, the “customer” will be informed about the review and from what date the reviewed SLA version is valid, whereby the “customer” then has the option to terminate the agreement early, should the new SLA be reasonably inadequate for the “customer”.
  • In such cases where “customer” wants to terminate the recurring agreement, “customer” is to inform StudentPulse no later than 14 days after the SLA review, by evoking “customer’s” right to early termination by emailing StudentPulse with the subject line “Evoking SLA Review Early Termination”.

2.3.2 Service Agreement

This section includes a variety of components and subsections into the following components:

  • Service levels
  • Service level rankings and response
  • Exceptions and limitations
  • Responses and responsibilities
  • Service Management
  • Maintenance and Service window(s)
  • Service Commitments and Service Compensation

2.3.2.1 Service levels

In order to avoid intermittent and transient fluctuations, a downtime period may begin after observing one to five consecutive minutes of downtime and end when services are restored. Furthermore, downtime must affect a significant number of requests or core functionality to qualify as a Service Outage.

  1. StudentPulse shall provide the Services during the recurring term of this agreement, cf. “Contract” and “Terms”, on a 24 hours a day, 365 days a year basis, according to the Service Levels in this SLA. “Customer” is understanding, that the StudentPulse Services may have periods of unavailability, inaccessibility or otherwise inoperable for reasons including, but not limited to:
    1. Hardware equipment malfunctions
    2. Up-front communicated periodic maintenance procedures or service windows
    3. Reasons caused or not foreseeable beyond the control of StudentPulse, including, but not limited to, documented downtime with Amazon Web Services (“AWS”), Pusher, interruption or failure of telecommunication or digital transmission links, delays or failures due to “Customer’s” Internet access connections, hostile network attacks, network congestion or other Force Majeure Events (elaborated in 3.3. Exceptions and Limitations)
  1. “Customer” confirms that StudentPulse is not responsible for or has no control over any aspects of the “Customer’s” Internet connection, speed, data transmission systems or other 3rd party vendors, suppliers or partners
  2. StudentPulse’s service targets and commitments are directly related to StudentPulse’s Infrastructure & Cloud Provider (“AWS”), which by the date of this SLA guarantees a Service with an uptime of 99,00%. It is furthermore understood that StudentPulse is never responsible for providing higher service target levels than what “AWS” at any point in time is servicing.
  3. StudentPulse does not commit to making services available, should one or more of the following conditions take effect, thus unavailability due to these is not including when calculating potential downtime:
    1. Any events occurring within “customer’s” own control, acquired third-party or partners, network or internet connection, or due to incompatibility between “customer’s” it and StudentPulse’s ditto
    2. Maintenance and/or Service window(s)

2.3.2.2 Service level rankings and responses

This is how StudentPulse assesses level of severity and targets responses accordingly:

Severity

Description

Target Response

1. Severe           

Service is unavailable or a substantial subset of functionality is unavailable without a workaround, security issues, or data integrity issues.

  • 4 hours 365, within business hours
  • 12 hours, outside business hours

 

2. High

Intermittent issues, issues with system performance, and issues with available workarounds.

  • 8 hours 365, within business hours                                              
  • 24 hours, outside business hours

3. Medium

Any other bugs and issues that are not considered as Severe and High.

  • 6 business days

4. Low

Enhancements, tech questions

  • 9 business days

2.3.2.3 Exceptions and Limitations

This SLA is subject to the following exceptions and special conditions:

  • In no way is StudentPulse responsible for downtime, thus not breaching this SLA, if the downtime is caused by factors outside of StudentPulse’s reasonable control, including any force majeure event, Internet access, problems beyond the demarcation point of the StudentPulse network, acts of the government or public authorities, or strikes.
  • That results from any actions or inactions of “customer” or any third party
  • That results from the equipment, software or other technology of “customer” or any third party (other than third party equipment within StudentPulse’s direct control)
  • That results from any Maintenance (See Maintenance and Service window(s))

2.3.2.4 Responses and Responsibilities

Here are the defined responsibilities of both the service provider (StudentPulse) and the “customer”.

“Customer” responsibilities and obligations:

  • “Customer” should provide all necessary information and assistance related to service performance that allows the StudentPulse to meet the performance standards as outlined in this document.
  • “Customer” shall inform StudentPulse regarding changing business requirements that may necessitate a review, modification, or amendment of the SLA.
  • Should the “customer” be planning to alter “customer’s” LMS and/or IT system, the “customer” is required to inform StudentPulse in advance of such changes if these affect the operation of StudentPulse. Should the changes to the “customer’s” LMS and/or IT system result in StudentPulse’s services no longer working on “customer’s” LMS and/or IT system, StudentPulse is in no way responsible for such implications, and StudentPulse cannot be held accountable for fixing the issue(s) at hand
  • Reasonable availability of customer representative(s) when resolving a service-related incident or request.
  • “Customer” agrees to establish a single point of contact (SPOC) with StudentPulse per paid entity/organization. Users can ask for limited support through the platform, but usage will be monitored, and StudentPulse expects the SPOC/internal responsible to conduct end-user training and support.
  • In those cases where the Services mentioned and listed in the enclosed offer/contract are integrated into the “customer’s” Learning Management System (LMS) or other IT-system, the “customer” warrants at any time to meet the requirements regarding the LMS or IT system, to accommodate that StudentPulse’s Services can be integrated into the “customer’s” LMS and/or IT-system

StudentPulse responsibilities obligations:

  • StudentPulse will act as a primary support provider of the services herein identified. Additionally, in force majeure situations, StudentPulse shall not be held responsible for service disruptions or failures
  • StudentPulse will inform “Customer” regarding scheduled and unscheduled service outages due to maintenance, troubleshooting, disruptions or as otherwise necessary.

2.3.2.5 Service Assumptions

Assumptions related to in-scope services and/or components include:

  • Changes to services - such as new features, functions and/or redesign - will be communicated and documented to the customers
  • At all times has StudentPulse the prerogative to further develop and improve the StudentPulse Services. This also includes changing third-party vendors such as hosting, cloud and infrastructure providers, or any other third-party vendor or service provider, which StudentPulse is utilising to offer the “customer” the StudentPulse Services. Any such changes will be communicated in advance, and/but will not make the “customer” eligible for a termination of “Terms'' or SLA.

2.3.3 Service Commitments and Service Compensation

  • Annual Contract Value (ACV) Definition: For the purposes of calculating compensation, the ACV is defined as the total value of the contract agreed upon with the customer for the current academic year, encompassing all scheduled recurring service fees. This excludes any one-time fees, special discounts, or ad-hoc charges not part of the regular billing cycle. The ACV is applied to ensure compensation calculations reflect the current year's service agreement value.

  • Should the StudentPulse services not be available in 99,00% of the time per month (as per 3.1. Service Levels), StudentPulse commits to reimburse the “customer” a compensation of 5%, of 1/12 of the annual contract value, per 1% below 99,00% downtime per month.

    Under no circumstances is StudentPulse required to provide compensations greater than 80% of 1/12 the annual contract value relating to downtown per month in relation to the StudentPulse services, except for instances of intent or gross negligence.

  • Should the “customer” wish to invoke compensation reimbursement as per above, the “customer” shall do so no later than 8 working days into the following month. If the deadline is not met, or the “customer” does not invoke the right to compensation, the “customer” automatically waives its right to compensation.

  • Compensation is invoked by emailing StudentPulse with details about the assumed downtime, and claiming compensation. StudentPulse is then granted 30 days to investigate and calculate/confirm compensation before issuing a credit notum to the “customer”.

  • If there are any disagreements between the “customer” and StudentPulse about downtime % and compensation amount, StudentPulse is to provide detailed calculations of the downtime.
  • For the duration of any service unavailability, it's critical to recognize that student data collection via the Progressive Web App (PWA) remains uninterrupted. Collected data during such periods is stored offline within the PWA and will be synchronized with our servers once normal service resumes. This mechanism ensures the continuous capture of student feedback without loss, aligning with our commitment to data integrity despite server downtimes.

Sole remedy

Unless otherwise provided in the Terms, the “customer’s” sole and exclusive remedy for any unavailability, non-performance, or other failures by StudentPulse to provide the Services is the receipt of a credit notum (if eligible) in accordance with the terms of this SLA.

2.3.4 Service Management

Service management and support details applicable to the StudentPulse Services

2.3.4.1 Support Availability

Service coverage by StudentPulse as outlined in this agreement follows the schedule specified below:

StudentPulse support may be reached:

  • Chat-support service in office hours from 9:00 am (CET) to 3:00 pm (CET), Monday to Friday on all weekdays (Danish bank holidays and other public holidays excluded)
    Chat messages received outside of office hours will be collected, however, no action can be guaranteed until the next working day

  • Email-support service in office hours from 8:00 am (CET) to 5:00 pm (CET), Monday to Friday on all weekdays (Danish bank holidays and other public holidays excluded)
    Emails received outside of office hours will be collected, however, no action can be guaranteed until the next working day

  • Phone-support service in office hours from 9:00 am (CET) to 3:00 pm (CET), Monday to Friday on all weekdays (Danish bank holidays and other public holidays excluded)
    Calls received outside of office hours which are not collected, no action can be guaranteed until the next working day

2.3.4.2 Incident handling

Should any service issue or incident occur, in which StudentPulse is not aware, the “customer” is first to investigate whether the issue is related to any operations or services on the “customer’s” side. If not, and the issue seems to stem from StudentPulse, the “customer” is to provide StudentPulse Support with the following information for StudentPulse to successfully investigate the issue:

  • In which part of the service is the issue occurring?
  • Where in that part is the issue experienced? (Measurement, Analysis, Surveys etc.)
  • What is the actual issue?
  • When did it happen?
  • Who/what is involved (name, user, email, calendar)
  • Can the issue be reproduced by the user/Service Desk?
  • If so, how?
  • Can screenshots be provided? If so, please do

When service incidents have been identified to be solely due to StudentPulse responsibilities and services, by the Customer’s Service Desk, then StudentPulse will commit to the response and reaction times as listed in 2.3.2.2.

After having categorised a support case, the Support Team will afterwards notify the “customer” about which category the issue is being handled as hence an estimation for the fix is given. Should not the estimation hold, the Support Team will notify the customer again, providing the customer with a new estimation.

All communications between the StudentPulse Support Team and the “customer” should always and only be between the Support Team and a few chosen from within the “customer’s” IT Department and/or incident team and/or system owner team, and never involving the end-user.

2.3.5 Maintenance and Service windows

To maintain optimal service performance and security, we adhere to the following notification protocols for maintenance and service windows:

  • Notifications for scheduled maintenance will be issued at least one hour in advance.
  • We may announce service windows with at least ten minutes' notice for urgent maintenance requiring immediate attention (severity ranking 1, as per Section 2.3.2.2).
  • Should downtime exceed fifteen minutes, we will provide a 24-hour advance notice.
  • Information regarding upcoming service windows will be shared through the StudentPulse platform and our newsletter.

Notably, the offline functionality of our PWA ensures that student feedback collection remains uninterrupted during maintenance or service windows. While system updates may temporarily impact staff access, including login capabilities, the collection and storage of student feedback via the PWA will continue without disruption

Legal Responsible

Kevin Rebsdorf

+45 22282321

[email protected]