Support tiers and SLAs

Scope. Authoritative tier-by-tier description of what Clear Sky

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

This file is a template. [email protected], https://www.clearsky.host

and Clear Sky are substituted per environment by the

renderer, which fails rather than shipping any of them unsubstituted.

Audience. Customers, the operator, the build owner.

Overview

Clear Sky 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](https://www.clearsky.host/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. Clear Sky 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.