Service Level Agreement

This Service Level Agreement (“SLA”) applies to Polinate PTY LTD’s production Services (web app, APIs, automations, AI agents, and operational messaging). It describes availability targets, support responsiveness, incident communications, disaster recovery objectives, service credits, and exclusions. If an executed MSA or Order Form specifies different service levels, those prevail. Key terms: - “Core Services”: authentication, tenant provisioning, order ingestion and processing pipelines (including AI parsing), data APIs, and the main dashboard. - “Downtime”: minutes when Core Services are unable to serve requests that would normally succeed, excluding Exclusions (see “Dependencies & Exclusions”). - “Business Hours”: Monday–Friday 9:00–18:00 Australia/Brisbane (AEST), excluding Queensland public holidays.

Target monthly availability for Core Services: 99.9%. Measurement window: calendar month. Uptime formula: Uptime % = 100 × (Total Minutes – Downtime Minutes) ÷ (Total Minutes – Excluded Minutes). Partial outages: If ≥10% of tenants or ≥10% of API calls are impacted, the period counts as Downtime (unless excluded). Availability is measured from Polinate’s production monitoring and logs.

Planned maintenance is scheduled outside Business Hours where practicable and announced ≥72 hours in advance via status page or admin email. Emergency maintenance (security/stability) may occur with shorter or no notice; Polinate will minimise impact and communicate promptly. Maintenance windows are excluded from Downtime.

Support channels: in-app chat, email/ticketing, and (for P1) on-call escalation. Availability: 24×7 for P1; Business Hours for P2–P4. Required ticket details: tenant, environment, impact scope, reproducible steps, timestamps, and recent configuration changes. Case lifecycle: triage → acknowledge → mitigate/restore → root-cause → post-incident report (where applicable).

Polinate classifies incidents by user impact. Targets are objectives, not guarantees. - P1 Critical (Total outage, data loss/corruption risk, order ingestion halted platform-wide) • Response: 1 hour (24×7) • Restore/Workaround: 4 hours • Update cadence: ≤60 minutes until stable - P2 Major (Degraded performance or feature outage affecting many users; repeated AI pipeline failures; ERP sync stalled for multiple tenants) • Response: 4 Business Hours • Restore/Workaround: 1 Business Day • Update cadence: ≤4 hours during Business Hours - P3 Minor (Single-tenant feature bug, intermittent errors with acceptable workaround) • Response: 1 Business Day • Restore/Workaround: As scheduled in backlog - P4 Request (How-to, configuration changes, non-urgent tasks) • Response: 2 Business Days • Delivery: As planned

For P1/P2, Polinate will publish status updates at the stated cadence and a final note on resolution. A Post-Incident Report (PIR) for P1 (and material P2) will be delivered within 5 Business Days, covering timeline, root cause, customer impact, corrective actions, and prevention measures.

Backups: daily snapshots of production databases; retention ≥14 days (rolling). Objectives: RPO 24 hours; RTO 8 hours for Core Services. Continuity: redundant infrastructure and automated failover where supported by providers; periodic recovery tests. Targets are objectives and may be impacted by Exclusions.

API and automation usage must follow published limits. Polinate may throttle or temporarily restrict abusive or runaway workloads (e.g., uncontrolled polling, excessive retries) to protect platform stability. We will notify admins where practicable and provide guidance to remediate.

The following are excluded from Downtime and service credits: - Customer-side issues: internet/access problems, misconfiguration, expired credentials, blocked webhooks, firewall rules. - Third-party outages: cloud hosts, email/SMS carriers, ERP/accounting APIs, identity providers, or other integrations. - Force majeure: events beyond reasonable control (e.g., natural disasters, war, major DNS/CA failures). - Maintenance: scheduled or emergency maintenance. - Beta/preview features: experimental capabilities labelled as such. Polinate will use commercially reasonable efforts to mitigate and communicate impacts stemming from third-party incidents.

Security controls (encryption, access controls, monitoring, backups) are maintained as described in Polinate’s Privacy & Security Addendum. If a Security Incident involving Personal Information occurs, Polinate will notify without undue delay and cooperate with required assessments/notifications. Security incidents are handled in parallel with the SLA process and may be classified P1 regardless of availability impact.

If monthly availability for Core Services falls below target, Customer may request a credit on the platform fee for the affected month: - ≥99.0% and <99.9% → 5% credit - ≥98.0% and <99.0% → 10% credit - <98.0% → 25% credit Caps and rules: - Total credits capped at 50% of the platform fee for the month. - Credits apply to future invoices only; no refunds or cash outs. - Not available for free tiers, pilots, or accounts in arrears at incident time. Claim process: submit within 30 days after month-end with ticket IDs, impact summary, and time window evidence. Failure to claim within the window waives eligibility. Credits are the sole and exclusive remedy for availability shortfalls.

Provide accurate contact and escalation details; maintain up-to-date integration credentials (e.g., ERP, email, telephony); implement sensible retry/backoff; observe API limits; promptly apply Polinate’s mitigation advice; and designate technical contacts for incident coordination.

Availability and incident metrics are derived from Polinate’s production monitoring, synthetic probes, application logs, and provider telemetry. In case of discrepancy, Polinate’s records prevail unless you provide reasonable contrary evidence (headers, timestamps, logs) showing tenant-level impact during the same window.

We may update this SLA to reflect platform, operational, or legal changes. Material changes will be posted with at least 30 days’ notice and apply prospectively. If an executed MSA specifies different notice or service levels, that MSA prevails.