# Support tiers

**S1 = money can be wrong.** Whatever tier the parish is on, an S1 pre-empts
everything else — feature work, other clients' work, a Saturday. The parish
should know the one number to call for it, memorised, not looked up.

| | **Bronze** | **Silver** | **Gold** |
|---|---|---|---|
| **Channel** | Email | Phone / WhatsApp during office hours | Phone / WhatsApp, same-day |
| **S1 response** *(money can be wrong)* | Next business day | Within 4 hours | Same day |
| **S2 response** *(a feature is broken, nothing is wrong yet)* | Next business day | Next business day | Within 4 hours |
| **S3** *(a question, a "how do I")* | With the next update | Within 2 business days | Within 1 business day |
| **Check-in** | Quarterly, by email | Monthly, by call | Quarterly, on-site training refresh |
| **Included** | Bug fixes, security patches | + minor feature requests | + priority on the roadmap |
| **Price** | _KES — to be set_ | _KES — to be set_ | _KES — to be set_ |

Pricing is the parish's and the developer's to agree — this table exists to
make the *response*, not the fee, the thing both sides can point to later.

## What "S1" actually covers

A figure a treasurer cannot reconcile, a report that disagrees with itself,
a payment that vanished, a voucher that paid twice. Not: the system is slow,
a screen looks wrong, someone forgot their password (see
`tools/accounts.php` in `START HERE.txt` — that one doesn't need to wait for
anybody).

**The rule for "figures look wrong," regardless of tier:** freeze entry for
that week. Never "fix" a live figure by typing over it. Reconcile from the
audit log first — every change is already there, with who and when.
Communicate what was found to the treasurer before correcting anything.
Only then reverse the entry, with the reason recorded. A correction made
quietly is a correction nobody can later explain.

## What is already built, not promised

The technical half of "operate and support" isn't a future commitment —
it's running today, and this is where to point a new developer or a
sceptical treasurer:

- **Backups, restore-drilled.** `tools/backup.php` runs nightly from cron;
  `tools/backup.php --drill` restores the newest one into a scratch
  database and proves it holds the parish's real figures — not "a backup
  exists," but "a backup was restored and checked." `system.php` shows how
  many days since the last drill and nags once it is overdue.
- **A heartbeat, not a dashboard nobody watches.** `public/health.php` is a
  public, deliberately uninformative uptime endpoint for external
  monitoring (UptimeRobot or similar) to poll. `system.php`, behind a
  login, is the fuller picture: message-queue depth and age, failed sends
  this week, disk space, outstanding migrations, PHP/database versions —
  the things that fail silently in an SMS-dependent system on shared
  hosting.
- **The incident shape, not yet the calendar.** The failure modes and what
  to check for each are in the "How do I…" page inside the system
  (`guide.php`) under *When something breaks*, and in `START HERE.txt` for
  the office PC specifically. What is still missing is putting the
  quarterly restore drill and the annual access review onto an actual
  calendar with an owner — that is a session-meeting decision, not a
  developer one.

## Security operations

- **Offboarding.** A leaver's account is disabled the same week they
  leave — this is the session clerk's duty per `deploy/HANDOVER.md`, not
  the developer's, because the developer will not always know who left.
- **Credential hygiene.** No shared logins, ever — a shared login breaks
  maker-checker, since the audit trail can no longer say which person
  acted. Between two and four administrator accounts: fewer and a
  lockout has no rescuer; more and nobody remembers who has what.
- **Annual access review.** Once a year, read the user list aloud at a
  session meeting. Anyone the room hesitates on gets removed, not
  investigated first — restoring access is a two-minute conversation;
  a stale account is a standing risk.
- **Patch cadence.** PHP and MariaDB minor-version updates are scheduled
  and tested against `tools/test.php` before applying, not left until the
  host forces the issue by deprecating the old version outright.