Edsembli Product Support Service Level Agreement
Modified on: Marcy 18, 2024
Edsembli Product Service Level Agreement
Schedule 1 – Description of Services to be Provided.
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.
Scope of Services and Deliverables
2.1 Applications Software Supported
Edsembli provides support for the below three applications:
- Edsembli Finance (FIN),
- Human Resources (including the Employee Self Service Portal) and Payroll Systems (HRP), and
- 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
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.
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.
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.
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:
- 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.
- 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.
- 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: sis.support@edsembli.com
- For HRP Application: hrp.support@edsembli.com
- For Finance Application: fin.support@edsembli.com
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
Urgent | High | Medium | Low |
|
The application failure creates a serious business and financial exposure. | The application failure creates a high business and financial exposure. | The application or its components failure having minimal impact to business and financial exposure. | The application or its components failure having minimal impact to business and financial exposure, All Defects identified and enhancements are classified as low priority tickets |
|
Work Outage |
| |||
Urgent Severity | High Severity | Medium Severity | Low Severity |
|
application failure | Application failure | application failure | application failure |
|
causes a substantial | causes the client to | causes the client | causes the client to be |
|
failure or rendered the | lose the ability to | unable to perform a | unable to perform a |
|
application software | perform a significant | small portion of their | minor portion of their |
|
not operational the | portion of their job | job with little or no | job, but they are still |
|
client unable to | requirements in one | business impact, but | able to complete most |
|
perform significantly | area of the operational | they can | tasks with no business |
|
critical function of their | workflow, but still able | complete all tasks | impact, but they are |
|
job or total stoppage | to perform inputs, | related to performing | still able to perform |
|
of critical input, output | outputs and | inputs, outputs and | inputs, outputs and |
|
and processing | processing within the | processing within the | processing within the |
|
functionalities and | Application utilizing an | Application. This | Application. This |
|
features. | alternate work-around | incident does not | incident does not |
|
| normally deemed non- | affect work related | affect work related |
|
| critical. | productivity. | productivity. |
|
Remediation Steps | ||||
There is no acceptable workaround to the problem (i.e., the job cannot be performed in any other way and application is not functional). | There is an acceptable and implemented workaround to the problem utilizing an alternative work around. | There is an acceptable and implemented workaround to the problem utilizing an alternative work around. | There is an acceptable and implemented workaround to the problem utilizing an alternative work around. | |
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.
Response SLA | Urgent | High | Medium | Low |
First Response* | Within two (2) business hours | Within four (4) business hours. | Within six (6) business hours | Within eight (8) business hours. |
Next Response** | Within four (4) business hours. | Within six (6) business hours | Within eight (8) business hours. | Within two (2) business days |
Resolution Time: | ||||
* 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 10th 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 20th 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.”
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:
Escalation Process Mode: | Edsembli Escalation Point of Contact: | Escalation Response Time |
“1-800-265-3482” and the live agents can assist with their ticket(s) to escalate the call and book a call with the Agent. 2. Contact via email. Level3support@edsembli.com | Application Support Manager | - Time to respond to an escalation 2 hours. - 48 Hours for a Resolution Plan. |
“1-800-265-3482” and the live agents can assist with their ticket(s) to escalate the call and book a call with the Agent. 2. Contact via email. level4support@edsembli.com | Senior Director, Client Management Services | If not satisfied with the Resolution Plan, above, then escalate to Level 4. |
Appendix:
Schedule1: Scenarios and circumstances leading to change in ticket Severity.
- The Severity of the ticket may be altered and reprioritized based on the impact of the issue or error being experienced within the application.
- 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.
- 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”.
- Severity from Urgent to High
- The Severity of the ticket may be altered and reprioritized depending on the response received by the client:
- 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.
- 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.
- 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.
- 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.
- Severity from Urgent to High to Closed