Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

Table of Contents

1. Overview

SchoolEngage is an online form management system designed for schools, enabling the creation, distribution, and management of forms for staff and parents. This Service Level Agreement (SLA) outlines the service commitments and responsibilities of both the Service Provider (Intellimedia LP) and the Customer.

2. Services Provided

  • Form Management: Creation, distribution, and management of forms.

  • Communication: Email, text, and SMS communication using the SendGrid API.

  • Data Integration: Write back data to PowerSchool and the Alberta government PASI system.

  • Reporting: Viewing and reporting on form submissions and statuses.

3. Service Availability

The Service Provider will use commercially reasonable efforts to ensure the availability of its services 24/7, except for scheduled maintenance and circumstances beyond the Service Provider's control, such as third-party system issues.

4. Maintenance and Updates

  • Scheduled Maintenance: Customers will be notified at least 48 hours in advance.

  • Emergency Maintenance: Notification will be provided within 30 minutes of discovery.

5. Support Services

5.1 Support Hours

  • Support is available Monday through Friday, 8:30 AM to 5 PM (Mountain Time), excluding Canadian national holidays.

5.2 Support Channels

  • Customers can reach support via our Customer Support Portal: Support Portal

  • Phone: (780) 463-0754.

5.3 Response Times

5.3.1 Critical Issues (Urgent)

  • Definition: Issues classified as "Urgent" in Jira and confirmed by Intellimedia that severely impact core functionality, leading to a complete halt in critical operations or data loss.

  • Examples: System-wide outages, severe performance degradation, data corruption, and wide-scale security breaches.

  • Response: Acknowledged within 1 hour, resolved within 4 hours.

5.3.2 Major Issues

  • Definition: Significant problems impacting functionality but not causing a complete system outage.

  • Examples: Significant functionality errors, noticeable performance delays, errors in data processing, security vulnerabilities.

  • Response: Acknowledged within 4 hours, resolved within 3 business days. Interim solutions provided within 1 business day.

5.3.3 Minor Issues

  • Definition: Less critical problems causing inconvenience but not significantly impacting overall system performance.

  • Examples: Minor bugs, UI/UX inconsistencies, non-critical performance issues, feature requests.

  • Response: Acknowledged within 1 business day, resolved based on priority and resource availability.

5.3.4 Requesting New Features (Change Request)

  • Definition: Requests for new functionality, submitted through the "Request a New Feature" channel in Jira.

  • Examples: New modules, enhanced features, customizations.

  • Evaluation: Based on feasibility, impact, and alignment with the product roadmap.

5.3.5 Suggest a New Feature

  • Definition: Free suggestions for system improvements. The Service Provider retains control over the evaluation and implementation timeline.

  • Submission Process: Submit via the "Suggest a New Feature" channel in Jira with a clear description of the desired feature.

6. Service Credits

In the event of a service lapse, the Customer is entitled to service credits as a reduction in next year's license fees.

6.1 Calculation of Service Credits

  • Critical Issues: 1% credit of the annual subscription fee per occurrence, up to 7% per year.

  • Major Issues: 0.5% credit per occurrence, with a maximum of 7% per year.

6.2 Claiming Service Credits

  • Requests must be submitted within 30 days of the service lapse, including the incident report number and description.

6.3 Limitations

  • Service credits are the sole remedy for failure to meet SLA commitments.

  • Credits are not provided for issues arising from third-party systems or Customer form configuration errors.

6.4 Application of Service Credits

  • Applied to the next year's license fees after approval by the Service Provider.

7. Non-SLA Applicable Issues

A bug is defined as a verifiable issue within the Service Provider's code affecting system functionality. The following are excluded:

  • Incorrect form configurations by the Customer.

  • Changes in the Customer's data structure in PowerSchool.

  • Issues from third-party systems like SendGrid, PowerSchool, or PASI.

  • Customer-specific customizations under a separate Change Request.

8. Customer Responsibilities

  • Form Configuration: Customers must configure their forms correctly.

  • Data Accuracy: Ensure accurate data entry.

  • Third-Party Systems: Notify the Service Provider of any third-party system changes.

9. Communications

9.1 Meeting Scheduling and Preparation Requirements

  1. Notice Period: To ensure adequate preparation and resource availability, we require a minimum of 24 hours notice for all meeting requests. Meeting requests with less notice may not be accommodated.

  2. Agenda Requirement: A detailed agenda in bullet-point format is required upon scheduling the meeting. This agenda should outline all discussion items to allow our team to prepare thoroughly.

  3. Agenda Adherence: Meetings will be conducted according to the provided agenda. Any new or additional topics introduced during the meeting will not be addressed on the spot but will be documented for review. If further discussion is needed, a separate follow-up meeting will be scheduled to ensure proper analysis and informed responses.

9.2 Communication Channels

  1. Primary Communication Channel: All support requests, updates, and project-related communications must be conducted within our designated system, Jira. This ensures that all team members have access to the complete communication history and can work from the same information, maintaining accuracy and continuity.

  2. Audit Trail: Communications sent outside of Jira, including email, Teams, and phone calls, are not tracked within our standard audit system. Therefore, information shared through non-designated channels will not be considered part of the official record, and we may ask for re-submission within Jira to ensure consistency and transparency.

  3. Response Requests: We request that customers respond to all inquiries, updates, or requests for information directly within Jira. This approach helps us manage timelines effectively and ensures that all team members remain informed, minimizing the risk of miscommunication or missed details.

9.3 Bug Reporting – One Issue per Ticket

For efficient tracking and resolution, please report each bug (issue) as a separate ticket. Combining multiple issues within a single ticket can lead to delays, as each ticket is assigned to a specific team member and prioritized individually. By creating one ticket per issue, we can ensure that each bug receives focused attention, allowing us to schedule, track, and complete each task effectively.

10.0 Change Requests

10.1 Requirements via User Stories

To ensure clarity and alignment on project requirements, all new features, modifications, and project requests must be accompanied by detailed user stories. This format helps to outline the user’s needs, expected behavior, and desired outcomes, allowing our team to better understand and prioritize requirements.

  1. User Story Format: Each user story should follow the standard format:

    • As a [user role], I want to [action or behavior] so that [desired outcome].

    • Include any relevant acceptance criteria to define the success of the feature or functionality clearly.

  2. Review and Clarification: Incomplete or ambiguous user stories may result in delays as our team will need to clarify requirements before proceeding. This process is designed to avoid misunderstandings and ensure that deliverables meet customer expectations.

  3. Change Request Applicability: If any user stories introduce requirements outside the approved SOW, they will need to be submitted as change requests to ensure they are tracked and prioritized appropriately.

10.2 Scope of Work and Change Request Requirements

  1. Scope Adherence: Projects initiated based on an approved Scope of Work (SOW) will be completed according to the defined and agreed-upon requirements. Any additional requirements or modifications not outlined in the original SOW will not be incorporated.

  2. Change Request Process: For new requirements or adjustments outside the approved SOW, customers must submit a formal Change Request. Each request will be reviewed, and any approved changes will follow our standard process, including timelines, resource allocations, and potential cost adjustments.

  3. Avoiding Scope Creep: We aim to maintain project integrity and timeline adherence. As such, any requirements introduced outside of the approved SOW without a formal change request will not be considered part of the project and may impact overall project timelines and deliverables if not managed through the proper channels.

10.3 Single Change Request per Project

Each project may encompass multiple user stories; however, please consolidate all related requirements within a single project rather than creating separate projects for individual requirements.

11. Limitations of Liability

The Service Provider is not liable for issues from third-party systems or Customer form configuration errors.

12. Termination and Review

This SLA will be reviewed annually and may be terminated or modified with 30 days' notice by either party.

13. Acceptance

By using the SchoolEngage service, the Customer agrees to the terms outlined in this SLA.

  • Service Provider: Intellimedia LP

  • Product: SchoolEngage SaaS

  • Effective Date: June 15th, 2024

  • No labels