Support tiers and SLAs

Scope. Authoritative tier-by-tier description of what Sunny Day

promises about responding to support requests, by plan. Authored by

launch R1 / F1.C2 (requirements/launch/r1/features/F1-support-inbox-and-slas.md).

Single source of truth. www/pricing.html (rendered to

/pricing), www/support.html (rendered to /support), the panel

/support handler, and the support autoresponder all draw their

tier copy from this file. An SLA edit lands here; the static pages

are re-rendered at deploy time (scripts/render-support-page.sh

drives the doc/support/sla.md -> www/support.html conversion).

Audience. Customers, the operator, the build owner.

Overview

Sunny Day support is a monitored inbox — [email protected] — staffed by the operator team during business hours. We commit to first-response times by plan; there is no phone line, no 24/7 paging, and no in-product live chat. A vendor ticketing system is on the future-R1.x roadmap; the present tier promises are the contract for R1.

Two important distinctions:

• Response time vs. resolution time. Our SLAs cover **first

response** — when an operator acknowledges and starts working a message. Resolution is best-effort and depends on the message (a "how do I…?" closes in one reply; a service-impacting incident may need engineering time).

• Business hours vs. real-time. Our business hours are

Mon–Fri, 09:00–18:00 UTC. Outside business hours messages queue; the response clock starts at the next business-hours boundary. 72 business hours is roughly 10 calendar days; 24 business hours is roughly 3; 4 business hours is roughly half a day inside the business-hours window.

Tier table

The three R1 tiers map one-to-one to the published plans (/pricing) and to the support_tier value the billing catalog carries ([doc/billing/feature-keys.md](../billing/feature-keys.md)). The tier names below MUST match the catalog values exactly — community / email / priority — asserted by tests/check-sla-tier-table.sh (BR1.C2.2).

The panel /support page (F1.C4) highlights the authenticated user's current tier in this table; the autoresponder (F1.C5) quotes the tier-specific clause back at the customer so they know what to expect.

What "business hours" means

• Window: Mon–Fri, 09:00–18:00 in the operator's primary

timezone. Today that is UTC; we may move it to a follow-the-sun schedule in a future release.

• Holidays: Public holidays in the operator's primary jurisdiction

count as out-of-business-hours days. The operator publishes the yearly holiday calendar in doc/support/sop.md.

• Out-of-hours messages queue. A message received at 22:00 UTC

Friday starts its first-response clock at 09:00 UTC Monday.

• **Pro 72 business hours ≈ 10 calendar days; Business 24 ≈ 3 days;

Business service-impacting 4 ≈ half a business day.**

Out of scope at every tier

These commitments are the same across all three tiers; no plan buys around them in R1:

• No phone support. Sunny Day does not operate a phone line.
• No live chat. Customer-initiated chat is on the future-R1.x

roadmap; in R1 the inbox is the only channel.

• No dedicated customer-success manager (CSM). Every account

shares the operator inbox; we triage by tier and severity, not by named relationship.

• No 24/7 on-call. The on-call paging route F8 ships is for

internal incident response (service is degraded for many customers), not for individual customer escalations.

Future tier additions (R2+ may add a dedicated / enterprise tier with phone + named contact) would extend this document; until then, the three R1 tiers are the entire customer-facing matrix.

Escalation

A customer who needs faster attention than the default first-response SLA can escalate within the same channel:

• URGENT in the subject line → the message is routed to the

service-impacting queue (see the per-tier service-impacting SLAs above). Use this for: a paying customer cannot subscribe, a paying customer cannot log in, a service the customer is paying for is down or returning errors.

• Reply to the autoresponder with additional information →

threads stay together; the operator sees the latest context in one place.

• **Multiple separate threads about the same issue do not speed up

response.** Append context to the existing thread instead of opening a new one.

If a customer asks how to escalate, the operator response template in doc/support/sop.md covers the script.

Changing this document

The tier promises are a commitment to customers. Edits that tighten an SLA (extending the window, removing a tier benefit) require:

1. A build-owner sign-off recorded in the PR description.
2. A note in doc/RELEASES.md against the change date with the

rationale (what evidence motivated the change).

1. A corresponding www/pricing.html re-render — the pricing page's

support feature lines reference these tier names verbatim.

Edits that loosen (shortening the window, adding a tier benefit) follow the same process but do not need the build-owner sign-off — they are unambiguously customer-positive. The build owner still gets notified via the PR description so the change is visible at the next release retrospective.

A new tier MUST also:

• Extend panel/go/internal/support/tier.go (the Tier enum + the

tierRank weight so MostPermissive orders it correctly).

• Add the value to billing/seed/plans.yaml and assign per-plan

values.

• Re-run bash tests/check-sla-tier-table.sh (BR1.C2.2) to confirm

the SLA tier table still matches the catalog values exactly.

References

• The panel projection: panel/go/internal/support/tier.go.
• The catalog feature key: doc/billing/feature-keys.md (support_tier).
• The operator runbook: doc/support/sop.md (F1.C6).
• The launch-R1 spec: requirements/launch/r1/requirements.md §4 (defines

Support tier and SLA) and requirements/launch/r1/features/F1-support-inbox-and-slas.md.