Edsembli Product Support Service Level Agreement 

Modified on: March 18, 2024 

Edsembli Product Service Level Agreement

Schedule 1 – Description of Services to be Provided.

 

1. Introduction

This document provides an outline of the terms for delivery of services to be provided by Edsembli to its supported Member School Districts, Boards and schools under the Edsembli  Product Service Level Agreements.

1. Scope of Services and Deliverables

2.1 Applications Software Supported

Edsembli provides support for the below three applications: 

1. Edsembli Finance (FIN), 
2. Human Resources (including the Employee Self Service Portal) and Payroll Systems (HRP), and
3. Student Information Systems (SIS). 

Please refer to the below section 3.1.2: Supported Versions stated in the document for the details regarding the Edsembli supported product versions.
 

2.2 Services

1. Application Software Maintenance

• Regulatory changes: All reasonable changes to the Application functionality as mandated to   School Boards by the Federal and Provincial Governments;
• Correction of Software Defects: Fixes to the software to correct errors where the software is not performing according to the intended and defined business logic of the system.
• Compliance with Technology Platform: Updates/changes to applications to ensure compliance with the Windows OS and/or SQL Server RDBMS software upgrades.
• Compliance with Security Platform: Updates/changes to applications to ensure secure compliance with the Windows OS and/or SQL Server RDBMS software upgrades. 

1. Application Support Hours:

Support for product suite Finance (FIN), Human Resources and Payroll (HRP), and Student Information System (SIS), subject to the following features:

• Available 8:30 am - 5:00 pm Est, Monday - Friday (excluding Statutory Holidays).
• Clients need to log their requests, queries or issues via tickets in the On-Line Service Fresh Desk Ticketing System. Please refer to the Section 3.2.1 Services Ticket below in this document regarding different channels to log a ticket in Fresh desk system. 

  1. Documentation:

• Application releases and Deployment: Development and delivery of supporting documentation for the currently supported software version, any future enhancements and/or releases are shared with the client either via (a) PDF file, or through forum topics. 
• On-line Help:  Client can leverage the on-line help function available within the application for any How-to related application queries and questions. 

1. Delivery of Mandatory Services

3.1 Application Software Maintenance Services

 3.1.1  New Software Releases

A Software Version Release will define a unique release of the Application Software. A Software Version Release will include compatible components for all modules included in the Application Software.

Edsembli will share the frequency and the schedule of Software Version Releases to the community on a regular basis, through the Service Portal. All major releases will be announced ahead of their scheduled release and customers will be notified of any major changes and enhancements.

New releases will include software fixes as related to tickets and enhancements to existing modules, as well as new modules when applicable. For issues that are identified as Software Defect, refer to Chart.1 Issue Classification and Response.

 3.1.2  Supported Versions

Edsembli will provide the Mandatory Services for no more than 2 Software Release Versions at any specific point in time. When a new Software Release Version is released, the older Software Release Version will be unsupported prior to the new release.

Please click on the forum link below for the supported version for each application: 

• Edsembli Finance (FIN) Supported Version
• Human Resources and Payroll Systems (HRP), Supported Version  and
• Student Information Systems (SIS) Supported Application

3.1.3 Access Restriction Policies: 

Third Party Support contractors hired by the community should not be given access to the application architecture databases for Edsembli Proprietary applications, developed and supported by Edsembli..

3.1.4  Patch Management

A patch is an emergency tactic for Urgent tickets only, as defined in Chart 1. Patches should be avoided at all costs as patches can create instability to the application. It is mandatory for all patches to be installed in sequence to ensure all features and updates work. Edsembli reserves the right to charge for support services if patch installation is ignored or installed out of sequence. 

3.2  Application Software Support Services

3.2.1  Service Tickets

A request/issue logged as a ticket in the Freshdesk ticketing system from an individual Client Board, School or District board, is defined as a Service Request ticket. The ticket can be logged through below three channels: 

1. Service Desk portal (Recommended and Preferred channel) 

Clients need to log their requests, queries or issues via tickets in the On-Line Service Support Ticketing System, through the below mentioned Customer Services Portal:

• For SIS Application: https://sis.support.edsembli.com
• For Other products (HRP, and Finance): https://support.edsembli.com

This is a preferred and recommended channel to log a ticket in the system as the user can set the Priority of the ticket (Urgent-High-Medium-Low) and based on the information provided /entered the system automatically generates and assigns the ticket to its respective support group.

1. Contacting Via Phone. 

This is another channel whereby the user can call the Helpdesk number “1-800-265-3482” and the live agents can assist with their ticket(s) on their behalf and set their priority (Urgent-high--Medium or Low), and Schedule a call with the agent, or escalate the call. 

1. Email to Support 

User can also log a ticket by emailing to our below support email addresses specified for each supported application. All the tickets logged via support email address are deemed as low raised with low severity.

• For SIS Application: [email protected] 
• For HRP Application: [email protected]
• For Finance Application: [email protected] 

Clients can monitor the status of tickets, through the On-Line Service Fresh Desk Ticketing System, 24 hours a day and 7 days a week.

3.2.2  Service Ticket Prioritization

 A : Severity Levels and Response Times

All Service Tickets are to be assigned by the client as either Urgent, High, Medium or Low as per Chart 1. when the Ticket is entered. Edsembli is responsible to ensure that the users are aware of these definitions. Edsembli may adjust the severity level of a Ticket in accordance with the Schedule 1 stated below in Appendix section 
 
 Chart.1 Issue Classification 

B: Response and Resolution:

Below table outlines the response SLA’s (First Response and Next Response) upon receiving the ticket and providing the status on the ticket.

* First  Response time is defined as the time interval within which the agent needs to acknowledge and provide initial response back to the client since the ticket is first submitted in the Freshdesk system.
 **Next Response time is defined as the time interval within which the agent needs to provide response back to the client since the last response/update /query received from the user on the already open /assigned ticket in the Freshdesk system. 

All tickets classified as Defect Identified or Enhancement, are prioritized on the product back log, and may have community feedback.

C: Out of Support Scope:

Issues raised by the client that is determined to be unrelated to the Software, related to unsupported platform and are out of scope.

3.2.3   Restricted Database Changes

 Client Board, Schools or School District are not permitted to make changes to the database, other than changes made directly through the  Application. This includes (but is not limited to) the following types of non-permitted actions (i.e., an "Out of Scope Database Change")

•    Adding, deleting or altering data within the database.

•    Adding, changing or deleting database triggers or stored procedures

 Should a Client Board, School or school district perform an Out of Scope Database Change, it is acknowledging that any issues caused by the database change are not in scope as per this noted Support SLA Contract and that any support services provided that are subsequently determined to be related to an Out of scope Database Change will be separately billable services at the Client expense.

3.2.4  Ticket Management

Closing of Tickets.
 

(a)   After a ticket goes through the ticket life cycle and resolution is provided and/or confirmed by the client. The Edsembli support resource would go-ahead and close the ticket
 

(b)   If the Edsembli Support Team does not receive a response on confirmation closure from the client  ' within 5 (five) business days, then Edsembli Support Team will close the ticket.
 

(c)  The ticket with Status “closed”, post the 10 business days will be marked as “Resolved”
 

(d)    If the issue re-occurs, then a new ticket should be opened by the Community.

For any issues raised by the client,, if the problem is determined to be unrelated to the Software, and/or if the problem is out of the scope of the Mandatory Services, Edsembli reserves the right to charge the Client  for the  work performed  as billable hours..

Edsembli  reserves the right to validate the Severity classification of an issue, as reported by a Client, and to re-assign the severity accordingly based on an assessment of the issue.

Service Levels are defined specifically for issues arising from the use of the application in a production environment. In cases of non-production use of the applications (eg. Test environments, scenario testing, implementation setup and testing, training, etc.), All tickets should be raised with Medium and Low Severity. 

3.2.5  Software/Application Emergency Code Fixes

Emergency Code Fixes are software patches provided in situation where the operations of a critical business function as a result of an Urgent Severity (an "Emergency Code Fix")

3.2.6   Clarification Requested Policies

Where Edsembli requires additional clarification or information from the Client, Edsembli  will notify the Client and assign the Ticket with a status of "Pending Feedback”. For Tickets that have been assigned as "Pending Feedback", the following protocol will apply:

(a)   Should the Help Desk receive an Urgent Severity ticket and requires clarification of the issue and the clarification feedback stays with the client more than 3 business days the ticket severity will be automatically degraded and re-classified to High Severity.

(b)   Should the Help Desk receive a High Severity ticket and requires clarification of the issue and the clarification feedback stays with the client more than 5 business days the ticket severity will be automatically degraded and re-classified to Severity Medium.

(c) For all tickets with status “Pending Feedback” irrespective of the ticket severity,

• On the 10^th day post the ticket status of “Pending Feedback”, a system generated reminder email will be sent to the client stating a response/clarification/information is requested from their end, else the ticket will be closed post the next 10 days of inactivity. 
• On the 20^th Day post the ticket status of “Pending Feedback”, with no response/information/clarification received from the client, a system generated email will be sent to the requester, notifying the ticket will be closed due to no-response/information/update provided by the client and the ticket status will be changed from “Pending Feedback” to “Closed.”

1. Service Request Escalation Process

 In situations where a Client is dissatisfied with the service, the Client will escalate their issue according to the following protocol:
 Table 1: Escalation Matrix:

1. Appendix: 

Schedule1: Scenarios and circumstances leading to change in ticket Severity. 

1. The Severity of the ticket may be altered and reprioritized based on the impact of the issue or error being experienced within the application. 
   1. Severity from Urgent to High 
      • Workaround is available and provided to the user which desalinates the wider business impact and derives the end results via alterative approach or methods.
   2. Severity from Urgent/High to Low
      •  All Issues/Errors which are deemed as Known Issue/Defects Identified.
      •  Post Impact and Criticality Analysis done by Edsembli which may be contrary to the impact stated in the work outage section stated in the Issue Classification table stated above under section “3.2.2: Service Ticket Prioritization”.
2. The Severity of the ticket may be altered and reprioritized depending on the response received by the client:  
   1. Severity from Urgent to High to Closed
      • Clarifications/information(s), feedback or updates awaiting from the client for more than 3 business days, than the system will automatically degrade the severity of the ticket to Severity – High. In the event of no response being provided by the user, system will on the 10th day send a reminder email to the user requesting information and then on the 20th day close the ticket.
   2. Severity from High to Medium to Closed
      • Clarifications/information(s), feedback or updates awaiting from the client for more than 5 business days, than the system will automatically degrade the severity of the ticket to Severity – Medium. In the event of no response being provided by the user, system will on the 10th day send a reminder email to the user requesting information and then on the 20th day close the ticket.
   3. Severity from Medium to Low to Closed
      • Clarifications/information(s), feedback or updates awaiting from the client for more than 5 business days, than the system will automatically degrade the severity of the ticket to Severity – Low. In the event of no response being provided by the user, system will on the 10th day send a reminder email to the user requesting information and then on the 20th day close the ticket.
   4. Severity from Low to Closed 
      • For all the severity – Low tickets, any clarifications/information(s), feedback or updates awaiting from the client for more than 10 business days, than the system will automatically send a reminder and post 20 days of inactivity will close the ticket.