Acknowledgement macros
Purpose: Confirm receipt, set the likely next step, and avoid fake timing or implied active fix work.
TR-2532 support operations playbook
When support pressure rises, operators should know what to send, what to verify, and what to escalate.
This first support-operations slice is a playbook shell for macro families, severity handling, incident posture, and runbook guidance. It makes the internal response model explicit instead of leaving it hidden behind the queue.
Operator questions this should answer fast
- What do I send right now?
- How severe is this?
- Who should see this case?
- When do I escalate or update publicly?
Macro library map
Macros should speed accurate support work, not automate judgment away.
Clarifying-question macros
Purpose: Ask only for the minimum additional detail needed to classify, route, or ground the next response safely.
Grounded-answer macros
Purpose: Respond from canonical help or approved policy truth without sounding more final than the underlying source.
Escalation macros
Purpose: Explain why escalation is needed, what happens next, and what is still unknown without bluffing on timing.
Restricted-path macros
Purpose: Keep broad-channel detail minimal and shift sensitive context into the correct restricted path.
Billing and hardship sensitivity macros
Purpose: Stay humane, non-defensive, and calm while making it clear that review is still required.
Incident and degraded-service macros
Purpose: Align operator replies to the verified incident state and the next review checkpoint.
Closeout and follow-up macros
Purpose: Summarize the outcome plainly and make the next step clear when confirmation is still needed.
Severity model
Launch should use one small explicit severity system so support and incident language stay aligned.
S0
Critical trust or platform emergency
A core trust, privacy, or platform emergency requires immediate coordinated response.
S1
Major service-impact incident
A major workflow or surface is materially degraded for multiple churches or high-value use.
S2
Meaningful workflow degradation or blocked high-value path
A critical evaluation, onboarding, or support path is blocked or degraded enough to require fast operator attention.
S3
Normal support issue or localized defect
The issue is real but contained, with normal support handling still appropriate.
S4
Informational or low-impact request
The interaction is mostly guidance, low-impact clarification, or a non-blocking request.
Incident-state communication posture
Internal and external incident language should track verified truth, not operator anxiety.
Required incident states
- Investigating
- Identified
- Mitigating
- Monitoring
- Resolved
- Retrospective pending
Public update rules
- Say what users may be experiencing.
- Say what is known in plain language.
- Say what users should do now, if anything.
- Avoid speculative cause and false timing precision.
Incident update templates
Operators need a small repeatable template set before deeper tooling exists.
Internal incident update
- Current verified state
- Severity
- Affected surface or workflow
- Current action
- Next review checkpoint
- Open unknowns
Public incident update
- What users may be experiencing
- Current state in plain language
- What users should do now, if anything
- Next expected update posture
Launch-default runbooks
Runbooks should be small, explicit, and scannable under pressure.
Support triage runbook
Trigger: A new support case lands or an assistant escalation needs human review.
- Confirm category
- Assess severity
- Check restricted-path need
- Choose the safest macro family
Restricted-case handling runbook
Trigger: The case touches billing, hardship, identity, security, or other minimum-necessary review topics.
- Narrow visibility
- Keep broad-channel detail minimal
- Move to restricted follow-up
- Preserve audit traceability
Incident-response runbook
Trigger: A degraded state or multi-user problem may require incident posture.
- Assign severity
- Verify state before broad claims
- Set next review checkpoint
- Keep public and private truth aligned
Degraded-service communication runbook
Trigger: A known issue or active incident needs clearer operator and user wording.
- Say what users may be experiencing
- Say what is known versus not known
- Offer workaround if verified
- Avoid false timing precision
Help-center gap runbook
Trigger: Repeated confusion or repeated macro use suggests canonical documentation is too thin.
- Note the repeated pattern
- Separate temporary macro workaround from canonical doc fix
- Hand off to content/help owner
- Track the gap visibly
Escalation and handoff runbook
Trigger: The issue needs restricted review, broader incident coordination, or a deeper specialist handoff.
- State why escalation is needed
- Carry forward only safe context
- Preserve severity and audit signals
- Set clear next-step expectation
Sensitive-case checkpoints
Some cases should force deliberate operator questions before any smoother reply goes out.
Billing, hardship, or pricing sensitivity
- Should this move into a narrower review lane now?
- Are we asking only for the minimum information required?
- Would this wording accidentally imply approval or a pricing decision?
Identity, privacy, or security sensitivity
- Are we collecting or echoing more detail than necessary?
- Does the response explain why a narrower path is needed?
- Should this severity increase because trust boundaries may be involved?
Incident or degraded-service sensitivity
- Is the current state verified, or only suspected?
- Would a public truth surface need to stay aligned?
- Are we about to promise timing or cause we cannot defend?
Current bilingual launch posture
The current public launch shell is English-first. Spanish parity remains an explicit review and implementation task for trust-sensitive surfaces, so no Spanish path should be implied equivalent until it is rechecked and landed.
- Current live launch shell content is English-first.
- Spanish parity is still in progress for trust-sensitive launch surfaces.
- Do not imply equivalent EN/ES launch readiness until the specific surface is re-reviewed and landed.
Traceability and parity checks
The launch shell should keep support communication auditable and bilingual without pretending a full ops system already exists.
Support-event traceability checklist
- Preserve category and severity in the case or event trail.
- Record when a macro or drafted response was used and materially edited.
- Keep restricted-path handoffs attributable without copying unnecessary sensitive detail.
- Tie incident-state changes to an explicit checkpoint rather than ad hoc memory.
EN/ES parity checklist
- Severity language should mean the same thing in English and Spanish.
- Restricted-path wording should preserve the same privacy and minimum-necessary posture in both languages.
- Billing and hardship macros should stay equally humane and equally non-committal before review.
- Incident updates should preserve the same confidence level, uncertainty, and next-step meaning across both languages.
AI drafting guardrails
AI can speed drafting, but it should never become the hidden owner of sensitive support communication.
- AI may draft macros, summaries, and status wording, but it does not own the decision.
- AI must not invent severity, cause, resolution, or privileged facts.
- AI must not send sensitive-case communication without human review.
- AI must not contradict verified public incident truth.
Current shell boundaries
This keeps the playbook truthful about what landed and what still belongs in later operational tooling.
What this page is
A launch-shell ops guide for macro families, severity, incident communication, and runbook expectations that stays explicit about what has not landed yet.
What is not yet real
- This is not a macro-send system or live response composer.
- It does not yet provide mutation-heavy case actions or operational automation.
- It does not prove live instrumentation, alerting, or evidence-backed run cadence by itself.
Use this playbook with the queue, not instead of it
The queue, case detail, help center, and support assistant should all stay mutually consistent.
Review active queue pressure
Use the queue to inspect cases, sensitivity classes, and aging pressure before choosing a macro posture.
Open ops queue →Check support truth
Use help and support surfaces to make sure grounded answers and operator wording do not drift apart.
Open support surface →Check canonical guidance
Use the help center when a macro or status explanation needs to point back to governed truth.
Open help center →