Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.

...

  • 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

Info

All change requests must be submitted with a minimum of 30 days notice to allow for proper planning and scheduling.

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.

...