Service Level Agreement

Enterprise and public-sector procurement processes routinely require a published SLA before a purchase order can be approved. Non-profit organizations managing sensitive personal data - the primary audience for Meander - need assurance that the platform will be available when their peer mentors and coordinators depend on it, and that incidents will be resolved within predictable timeframes. A well-defined SLA reduces negotiation time with procurement teams, as they have a published baseline to evaluate rather than requesting a custom document from scratch. It also sets realistic expectations that reduce support escalations driven by unclear commitments. Internally, the SLA forces Norse to define and monitor its operational standards, which improves service quality over time.

The page is a static Next.js route at `/sla`. Availability targets should be stated as monthly uptime percentages (e.g. 99.5% for the API) with explicit exclusions for scheduled maintenance windows and force majeure events. Support tiers (e.g. standard vs. priority) should be clearly tabulated with response time commitments per severity level. The service credit mechanism must be straightforward to claim - typically a written request within a defined window after an incident. The SLA should reference the status page URL where customers can monitor real-time and historical uptime. The document must be versioned and dated, and the ToS should reference the current SLA version. Consider a simple HTML table for the support matrix to ensure readability and WCAG compliance.