ceo-orchestration 1.0.0

package/.claude/skills/domains/business-support/skills/finance-tracker/SKILL.md

@@ -0,0 +1,321 @@
+---
+name: finance-tracker
+description: |
+  SMB and startup finance tracking — cash-flow projection, runway
+  calculation, burn-rate diagnostics, founder-finance literacy, monthly
+  close-light cadence, and founder-friendly tooling (Brex / Mercury /
+  Stripe Atlas / Conta Azul / Omie). Distinct from
+  `domains/finance-accounting/skills/bookkeeper-controller` (full-stack
+  accounting) and `domains/finance-accounting/skills/fpa-analyst`
+  (enterprise planning cycles) — this skill addresses founder-side
+  financial awareness at the pre-scale stage. Use when: a founder or
+  small-team operator needs runway visibility within one business day;
+  when cash-flow forecasting is absent or spreadsheet-only; when burn
+  decomposition by category has not been performed; when preparing the
+  first investor board pack; or when selecting between SMB-oriented
+  finance tools.
+owner: Carla Tesouraria (Finance Tracker, domain persona)
+tier: domain:business-support
+scope_tags: [finance-tracking, runway, burn-rate, cash-flow, founder-finance, smb-finance]
+inspired_by:
+  - source: msitarzewski/agency-agents/support/support-finance-tracker.md@783f6a72bfd7f3135700ac273c619d92821b419a
+    license: MIT
+    relationship: structural_inspiration
+    authored_by: ceo-orchestration framework
+    authored_at: 2026-05-07
+# --- smart-loading fields (PLAN-083 Wave 0b sub-agent 0.7c) ---
+domain: business-support
+priority: 8
+risk_class: low
+stack: []
+context_budget_tokens: 500
+inactive_but_retained: true
+repo_profile_binding:
+  frontend: {active: false, priority: 10}
+  engine: {active: false, priority: 10}
+  fintech: {active: false, priority: 10}
+  trading-readonly: {active: false, priority: 10}
+  generic: {active: false, priority: 10}
+activation_triggers: []
+# --- K1 paths: native file-touch activation (PLAN-135 W3 unit k1a) ---
+paths:
+  - "**/finance/**"
+  - "**/cashflow/**"
+  - "**/runway/**"
+  - "**/budget/**"
+---
+
+# Finance Tracker
+
+Founder-side financial awareness is not accounting. The scope is
+narrower and the cadence faster: know runway at any moment, know burn
+by category, know which tool produces which number. Without this
+baseline, every strategic decision rests on an unknown cash position.
+
+## Cardinal Rule
+
+A founder who does not know runway within one business day at any
+moment has lost the company's primary survival metric. Runway is not a
+quarterly deliverable — it is a standing obligation. Any state in which
+the answer to "how many months of runway remain?" takes more than one
+business day to produce is a governance failure, regardless of company
+stage, team size, or fundraising status.
+
+## Fail-Fast Rule
+
+Stop and return a structured failure when any of the following is true:
+
+- Runway is being calculated using gross revenue instead of net cash
+  inflow, which inflates the apparent position and obscures deferred
+  payment obligations.
+- Cash on hand is being treated as equivalent to committed but
+  uncollected revenue or an unsigned term sheet.
+- Burn rate is expressed as a single total without category
+  decomposition; a total without attribution cannot be managed.
+- The 13-week rolling cash-flow forecast has not been updated in the
+  current week. A stale forecast is not a forecast.
+- Deferred revenue has been counted as available cash. Deferred
+  revenue is a liability until the service obligation is fulfilled.
+- A spreadsheet is the sole system of record for a company that has
+  crossed $500K in annual recurring revenue or has more than three
+  funding sources.
+
+## When to Apply
+
+Apply for founder-side and early-stage tasks requiring rapid,
+high-confidence cash-position awareness:
+
+- Calculating or auditing a runway figure and confirming the
+  cash/net-burn/gross-burn inputs used.
+- Building or reviewing a 13-week rolling cash-flow forecast.
+- Decomposing monthly burn into category-level attribution (payroll,
+  cloud, vendor contracts, marketing, other).
+- Preparing a monthly finance summary readable by a non-accountant
+  founder or a seed-stage investor.
+- Selecting or configuring a finance tool for an SMB or early-stage
+  startup (Brex, Mercury, Stripe Atlas, Conta Azul, Omie, Pleo).
+- Preparing the finance section of a fundraise board pack.
+
+Do not apply for full-period close, statutory reporting, tax
+provision, or enterprise planning cycles — use `bookkeeper-controller`
+or `fpa-analyst` respectively.
+
+## Cash-Flow Projection Discipline
+
+Three forecast horizons operate in parallel; collapsing them into one
+is a reliability failure.
+
+**13-week rolling forecast (weekly granularity).** Updated every week
+without exception. Inflows and outflows are recorded, the horizon
+extends by one week at the far end, and any week with actual cash
+flow deviating more than 15% from the prior forecast requires a
+root-cause note before the next update proceeds.
+
+**90-day forecast (weekly granularity).** The fundraising and
+decision horizon. Used when evaluating whether a new commitment can
+be absorbed without a cash crisis in the quarter. Updated weekly as
+part of the 13-week refresh.
+
+**12-month forecast (monthly granularity).** The strategic horizon
+for scenario planning and investor communication. Updated monthly.
+Forecasts beyond 90 days carry explicit confidence bands; presenting
+them as point estimates is misleading.
+
+All three horizons must reconcile back to actual bank balances within
+one business day. Forecasts that cannot are structurally broken.
+
+## Runway Calculation
+
+Runway is a quotient, not a heuristic. The denominator determines
+whether the figure is meaningful.
+
+**Cash.** Total cash and cash-equivalent balances, net of restricted
+cash. Committed-but-uncollected receivables do not count until
+collected.
+
+**Net burn.** Cash spent minus cash received in a period, from
+operations only. Net burn is the correct denominator for
+revenue-generating companies. A company with $2M cash and $150K
+monthly net burn has approximately 13 months of runway.
+
+**Gross burn.** Total operating cash outflows before revenue.
+Gross burn is the correct denominator for pre-revenue companies and
+for stress-testing under a zero-revenue scenario. Confusing the two
+when communicating runway to investors is a credibility error.
+
+**Three scenarios** (conservative, base, aggressive) must accompany any
+runway figure presented to a board or investor. Conservative assumes
+net burn increases by 10-15% from the trailing three-month average.
+Base holds net burn constant at trailing three-month average. Aggressive
+assumes a revenue acceleration that reduces net burn by 15-20%.
+Presenting a single-point runway figure without scenario bands is
+optimism encoded as fact.
+
+## Burn-Rate Diagnostics
+
+Burn cannot be managed at the total level. Category-level attribution
+is the minimum required resolution.
+
+Mandatory burn categories:
+
+- **Payroll and contractor.** Split between full-time employees and
+  contractors. Track headcount and fully-loaded cost per head. Payroll
+  is typically the largest burn category; it must be reviewed monthly
+  for accuracy against payroll-system actuals.
+- **Cloud infrastructure.** Monthly commitment versus actual usage.
+  Track by provider. A cloud bill that grows faster than revenue is
+  an architecture signal, not only a finance signal.
+- **Vendor contracts.** Recurring SaaS subscriptions, professional
+  services retainers, and annual contracts amortised monthly. Maintain
+  a vendor register with renewal dates and cancellation windows.
+- **Marketing and paid acquisition.** Separated from vendor contracts
+  because its burn-to-output ratio (CAC, pipeline contribution) must
+  be evaluated independently.
+
+Trend-flag threshold: any category that increases more than 20%
+month-over-month without documented justification triggers a
+burn-diagnostic review before the next payment cycle closes.
+Declining output ratios are flagged for renegotiation or spend
+suspension within 30 days.
+
+## Founder Finance Literacy
+
+Founders operating without basic GAAP awareness make decisions that
+produce surprises at audit or fundraise. The minimum literacy set:
+
+**Revenue recognition basics.** Revenue is recognised when the
+performance obligation is fulfilled, not when cash is received. A
+12-month SaaS contract signed in month 1 recognises 1/12 of contract
+value per month; the remaining 11/12 is deferred revenue — a balance-
+sheet liability, not available cash.
+
+**Deferred revenue trap.** Annual prepayments improve cash position but
+create a service obligation. If the company ceases to operate before
+fulfilling that obligation, the prepayment must be refunded. Deferred
+revenue is a future liability that happens to reside in the bank today.
+
+**Basic GAAP awareness.** Accrual accounting recognises revenue and
+expenses when earned or incurred, not when cash moves. Cash-basis
+thinking produces a systematically distorted view of profitability.
+
+**Venture-debt covenant tracking.** Debt agreements typically include
+financial maintenance covenants (minimum cash balance, revenue growth
+thresholds). Covenant breaches can trigger immediate repayment. Track
+compliance monthly and flag approaching thresholds to legal counsel at
+least 60 days before the measurement date.
+
+## Monthly Close-Light Cadence
+
+Not a full accounting close. Purpose: produce a founder-readable
+finance summary within three business days of month end, and ensure
+the books are audit-ready by month three of a fundraise.
+
+**Day 1.** Reconcile all bank and payment accounts to actual balances.
+Confirm payroll actuals match payroll system. Flag any unreconciled
+items above $1K for same-day resolution.
+
+**Day 2.** Update the 13-week rolling forecast with the closed month's
+actuals. Perform burn variance review: actual versus prior-month
+forecast per category. Document any variance exceeding 10%.
+
+**Day 3.** Produce the founder-readable monthly summary: cash position,
+runway (three scenarios), burn by category with month-over-month delta,
+and a one-paragraph narrative on any change requiring action. This
+summary is the input to investor reporting.
+
+**Fundraise-ready target.** By month three of any fundraise, the books
+must support due-diligence access: reconciled actuals for the trailing
+24 months, a cap table matching the equity register, all vendor
+contracts with renewal and cancellation terms, and payroll records
+segregated by employee and contractor.
+
+## Tool Selection
+
+No single tool fits all stages. Selection criteria: company size,
+banking relationship, geography, and accounting integration needs.
+
+**Brex.** Corporate card and cash management for US-incorporated
+startups. Best fit when spend controls and accounting-platform
+integration are required. Not suitable as a primary bank for
+Brazilian-entity structures without a US co-entity.
+
+**Mercury.** US banking for startups — API-accessible, no monthly
+fees at seed stage. Best fit for US-incorporated companies; available
+to foreign founders via a US entity.
+
+**Stripe Atlas.** US company formation and banking bundle. Best fit
+when payment processing is primarily in USD and the founder is forming
+a US entity from outside the United States.
+
+**Conta Azul.** Brazilian SMB accounting platform. Best fit for Ltda
+or S.A. entities needing Nota Fiscal issuance, DAS (Simples Nacional),
+and Receita Federal integrations.
+
+**Omie.** Brazilian ERP for SMBs. Best fit for integrated CRM,
+billing, and accounting within the Brazilian fiscal framework. Higher
+implementation complexity than Conta Azul; justified at R$500K+ ARR.
+
+**Pleo.** European employee spend management. Best fit for companies
+with European entities requiring multi-currency expense management and
+VAT reclaim.
+
+**Never use a spreadsheet as the sole system of record** beyond the
+pre-product stage. No access controls, no audit trail, no bank
+reconciliation enforcement. Post-seed, spreadsheet-only finance is a
+fundraise liability.
+
+## Reporting to Investors
+
+Board and investor reporting is a credibility transaction. A single
+instance of stretched or sandbagged numbers alters the trust baseline
+for all subsequent communications.
+
+**Board-pack discipline.** Required contents: cash position as of the
+reporting date; runway under three scenarios; burn by category with
+month-over-month delta; actual revenue versus forecast with variance
+narrative; any covenant or compliance item requiring board awareness.
+Distribute at least 48 hours before the meeting.
+
+**Never sandbag and never stretch.** Both degrade investor
+relationships when discovered. Report actuals and best-estimate
+forecasts. Variance narratives replace the need for pre-emptive
+optimism.
+
+**Honest variance.** When actuals deviate from the prior forecast by
+more than 10%, the explanation must name the root cause. "Revenue came
+in below plan" is not a variance explanation; "Enterprise deal slipped
+to Q1 — customer procurement cycle; $120K ARR expected February close"
+is.
+
+## Anti-Patterns
+
+| Anti-pattern | Why it fails |
+|---|---|
+| Spreadsheet-only finance post-traction | No audit trail, no access controls, no bank reconciliation enforcement; due-diligence exposure at fundraise |
+| Founder cannot state runway within one business day | Primary survival metric is unmanaged; creates reactive rather than strategic cash decisions |
+| Deferred revenue counted as available cash | Deferred revenue is a service obligation; counting it as a buffer overstates runway and leads to over-hiring |
+| Gross burn confused with net burn in investor communication | Overstates or understates runway depending on direction; destroys credibility when the investor recalculates |
+| Total burn reported without category decomposition | Unmanageable; no visibility into which category is driving the trend or which vendor can be renegotiated |
+| Single-point runway figure presented without scenarios | Encodes optimism as fact; base-case accuracy is not the relevant question under stress |
+| Venture-debt covenants not tracked monthly | Covenant breach triggers immediate repayment; 60-day notice window missed due to monthly-only review |
+
+## Cross-References
+
+- `domains/finance-accounting/skills/bookkeeper-controller` — full-stack
+  accounting, month-end close, journal entries, statutory reporting; use
+  when the company has reached a stage requiring formal accounting close
+- `domains/finance-accounting/skills/fpa-analyst` — annual operating plan,
+  rolling forecast, driver-based modelling, and capital-expenditure
+  governance; use when the company has a dedicated FP&A function
+- `domains/business-support/skills/analytics-reporter` — business
+  intelligence and KPI reporting; complements finance-tracker when
+  operational metrics must be correlated with cash-flow trends
+
+## ADR Anchors
+
+- ADR-058 — Brainstorm gate pre-Plan and two-pass adversarial review.
+  All finance projections and runway figures must pass the two-pass
+  review gate before presentation to investors or board. The first pass
+  checks arithmetic and source reconciliation; the second pass applies
+  adversarial framing to surface optimism bias in revenue forecasts and
+  understated expense assumptions.

package/.claude/skills/domains/business-support/skills/support-responder/SKILL.md

@@ -0,0 +1,341 @@
+---
+name: support-responder
+description: |
+  Customer support response discipline covering ticket triage, severity
+  assessment, response template and macro discipline, escalation path
+  ownership, voice-of-customer feedback loops, and multi-channel support
+  operations across email, chat, phone, and social. Applies CSAT, NPS,
+  FCR, first-response-time, and time-to-resolution diagnostics with clear
+  leading vs. lagging distinctions.
+  Use when: triaging incoming support tickets; setting or auditing SLA
+  targets per severity tier; designing escalation routes for technical,
+  billing, legal, or executive issues; synthesising VoC themes for product
+  handoff; tuning per-channel tone registers; or diagnosing CSAT/NPS/FCR
+  regression.
+owner: Carla Nunes (Support Responder, domain persona)
+tier: domain:business-support
+scope_tags: [customer-support, ticket-triage, severity-assessment, escalation, voice-of-customer, multi-channel-support]
+inspired_by:
+  - source: msitarzewski/agency-agents/support/support-support-responder.md@783f6a72bfd7f3135700ac273c619d92821b419a
+    license: MIT
+    relationship: structural_inspiration
+    authored_by: ceo-orchestration framework
+    authored_at: 2026-05-07
+# --- smart-loading fields (PLAN-083 Wave 0b sub-agent 0.7c) ---
+domain: business-support
+priority: 8
+risk_class: low
+stack: []
+context_budget_tokens: 500
+inactive_but_retained: true
+repo_profile_binding:
+  frontend: {active: false, priority: 10}
+  engine: {active: false, priority: 10}
+  fintech: {active: false, priority: 10}
+  trading-readonly: {active: false, priority: 10}
+  generic: {active: false, priority: 10}
+activation_triggers: []
+# --- K1 paths: native file-touch activation (PLAN-135 W3 unit k1a) ---
+paths:
+  - "**/support/**"
+  - "**/tickets/**"
+  - "**/helpdesk/**"
+  - "**/macros/**"
+---
+
+# Support Responder
+
+## Cardinal Rule
+
+Customer trust is acquired in good seasons and lost in bad seasons;
+the support response is the bad-season test. A support interaction
+that fails under pressure — delayed acknowledgement, a scripted
+deflection, a hidden escalation — destroys more trust than the
+original incident. Every response, at every severity tier, must
+acknowledge the customer's situation accurately, commit to a next
+action with a concrete time, and deliver on that commitment.
+
+## Fail-Fast Rule
+
+Stop the normal response workflow and escalate immediately when any
+of the following is detected:
+
+- A P1 (service-down) ticket has not received acknowledgement within
+  fifteen minutes of creation — do not wait for the batch review
+  queue; interrupt and assign.
+- A response template is being sent without any personalisation — the
+  customer's name, issue description, or account context is absent —
+  reject and require at least one contextual sentence before send.
+- An escalation route is unclear or contested between two teams — do
+  not leave the ticket in limbo; assign interim ownership to the
+  originating tier and open a side escalation to resolve ownership.
+- A VoC theme has been identified in three or more tickets within a
+  seven-day window and has not been logged for product-team handoff —
+  halt and log before closing the tickets.
+- A customer is being directed to a channel that is unavailable,
+  understaffed, or inappropriate for the issue type — reroute before
+  the customer reaches a dead end.
+
+## When to Apply
+
+Apply this skill when:
+
+- Triaging an inbound ticket queue and assigning severity tiers.
+- Drafting or reviewing a response to a customer issue at any severity.
+- Designing or auditing SLA targets, escalation paths, or macro libraries.
+- Conducting a weekly VoC synthesis for product-team handoff.
+- Diagnosing a CSAT, NPS, or FCR regression and recommending corrective
+  action.
+- Evaluating per-channel tone registers or channel-routing decisions.
+
+Do not apply this skill to internal IT helpdesk workflows that have no
+customer-facing component, to sales qualification calls, or to
+community moderation tasks unrelated to support resolution.
+
+## Ticket Triage Discipline
+
+Ticket triage assigns severity, owner, and SLA commitment before any
+response is drafted. Triage is a gate, not an afterthought.
+
+**Triage sequence:**
+1. Read the full ticket body, not just the subject line. Customers
+   often misclassify severity in the subject while the body reveals a
+   more critical impact.
+2. Check account tier and prior interaction history. A P3 issue for
+   an enterprise account may carry P2 handling obligations under an
+   active SLA agreement.
+3. Assign severity using the criteria in the Severity Assessment section.
+4. Route to the correct tier and channel owner. Set SLA clock from
+   triage completion, not from ticket creation where routing delay is
+   system-caused.
+5. Acknowledge to the customer within the first-response-time target
+   for that severity tier before any investigation begins.
+
+Never batch P1 tickets into a periodic review. The triage step for P1
+must interrupt the current queue and assign within fifteen minutes.
+
+## Severity Assessment
+
+Four tiers; classification is based on customer impact, not team
+convenience.
+
+**P1 — Service Down**
+Complete inability to use the product or a core workflow; data loss
+in progress or imminent; security incident actively affecting customer
+data. SLA: first response ≤ 15 min; resolution target ≤ 4 h.
+Examples: login broken for all users on an account; payment processing
+halted; integration returning 5xx for every call.
+
+**P2 — Functional Impairment**
+A primary feature is degraded or unavailable but a workaround exists;
+significant productivity impact; no data loss confirmed. SLA: first
+response ≤ 1 h; resolution target ≤ 8 h business hours.
+Examples: bulk export failing for files above a threshold; notification
+emails delayed by more than two hours; a key report returning
+inconsistent results.
+
+**P3 — Minor Issue**
+A non-critical feature behaves incorrectly or inconsistently; cosmetic
+defects; minor UX friction. SLA: first response ≤ 4 h business hours;
+resolution target ≤ 3 business days.
+Examples: tooltip text incorrect; filter state not persisted on page
+reload; minor formatting error in PDF export.
+
+**P4 — Question or Guidance**
+No defect; customer needs guidance, documentation pointers, or
+clarification on expected behaviour. SLA: first response ≤ 8 h business
+hours; resolution target ≤ 5 business days.
+Examples: how-to questions, feature discovery, billing cycle queries,
+onboarding assistance.
+
+Escalate severity upward when in doubt. Downgrading a ticket from P1
+to P2 requires written confirmation from the customer that a workaround
+is acceptable.
+
+## Response Template and Macro Discipline
+
+Macros and templates reduce handling time and enforce consistency.
+They are a starting point, not the finished response.
+
+**Mandatory personalisation before any send:**
+- Address the customer by name — never "Dear Customer" or "Hi there".
+- Reference the specific issue the customer described using their own
+  words where possible.
+- Include one sentence that acknowledges the impact on the customer's
+  workflow.
+
+**Template structure for issue responses:**
+1. Acknowledgement — confirm receipt and severity understanding.
+2. Current status — what is known, what investigation is underway.
+3. Next action — single concrete commitment with a time bound.
+4. Contact path — how the customer reaches the assigned owner directly.
+
+**Macro review cadence:** review the macro library monthly. Retire
+macros that generate follow-up questions at a rate above fifteen percent;
+those indicate the macro is not resolving the question. Add macros for
+any issue type that recurs more than ten times in a calendar month.
+
+Never send a macro without reading the full customer message first.
+A macro applied to the wrong issue damages trust more than a slower
+personalised response.
+
+## Escalation Paths
+
+Four escalation routes; each has a defined owner and an SLA for
+escalation acknowledgement.
+
+**Technical escalation**
+Trigger: bug reproduction required; integration or API defect beyond
+tier-1 or tier-2 capabilities; data inconsistency requiring database
+access. Owner: engineering on-call or tier-3 technical specialist.
+Acknowledgement SLA: 30 min for P1/P2; 4 h for P3.
+Handoff artifact: ticket with reproduction steps, environment details,
+account ID, and full error log attached.
+
+**Billing escalation**
+Trigger: disputed charge; refund request outside standard policy;
+invoice discrepancy; subscription state inconsistency. Owner: billing
+operations or finance team. Acknowledgement SLA: 2 h for any billing
+escalation. Handoff artifact: ticket with charge history, contract
+reference, and customer-stated amount.
+
+**Legal escalation**
+Trigger: customer references legal action, regulatory complaint, or
+data-rights request (erasure, portability, access). Owner: legal or
+compliance team. Acknowledgement SLA: 4 h. Handoff artifact: ticket
+with full verbatim customer text and timestamp. Do not paraphrase legal
+or regulatory language in the handoff.
+
+**Executive escalation**
+Trigger: customer explicitly requests CEO or C-level contact; a P1
+incident has exceeded resolution SLA and the customer is a strategic
+account; a situation carries reputational risk. Owner: customer success
+or account management lead, who decides whether to involve executive
+staff. Acknowledgement SLA: 1 h. Handoff artifact: ticket with full
+interaction history, account value, and recommended response posture.
+
+Never leave an escalation without a named owner. Escalation to "the
+team" is not an escalation; it is a deferral.
+
+## Voice-of-Customer Loop
+
+Support volume is a structured source of product and operations
+intelligence. The VoC loop extracts that intelligence systematically
+rather than losing it in ticket closure.
+
+**Weekly synthesis:**
+- Identify the five most frequent issue categories from the prior
+  seven days.
+- Flag any category that has grown more than twenty percent week-over-
+  week.
+- For each top category, extract three to five representative verbatim
+  customer quotes.
+- Summarise root cause if known; label as "unknown root cause" if not.
+- Deliver the synthesis document to the product team in the agreed
+  channel before the end of the business week.
+
+**Product handoff format:** issue category, frequency, representative
+quotes, known root cause or open question, recommended product action
+or documentation update, severity distribution for the category.
+
+**Closing gate:** do not close a ticket that contains a novel complaint
+or a feature request without tagging it for VoC capture. Tags must
+be applied before closure, not retroactively.
+
+The VoC loop fails when support volume is high and synthesis is skipped
+"temporarily" — that is precisely when the signal is most valuable.
+
+## Multi-Channel Support
+
+Each channel has a distinct interaction contract. Match the issue type
+to the appropriate channel; never force a customer into a channel that
+does not fit the issue.
+
+**Email**
+Appropriate for: P3/P4 issues; billing enquiries; formal documentation
+requests; any issue that benefits from asynchronous follow-up.
+Tone register: professional, concise, full sentences. Avoid bullet
+lists for emotional situations; prose acknowledges the customer more
+directly. Include a case reference number in every email.
+
+**Chat (live)**
+Appropriate for: P2 initial triage; quick-resolution P3/P4; guided
+walkthroughs. Tone register: conversational, present-tense, short
+turns. Do not use chat for P1 as the primary resolution channel —
+use it for acknowledgement while the engineering channel is engaged.
+Never close a chat session with an open action; convert to email with
+a written summary before closing.
+
+**Phone**
+Appropriate for: P1 incidents where email/chat latency is unacceptable;
+executive escalations; emotionally charged interactions where text
+amplifies friction. Tone register: calm, deliberate pacing; allow
+silence; do not interrupt. Document the call summary in the ticket
+within thirty minutes of the call ending.
+
+**Social (public)**
+Appropriate for: initial acknowledgement only. Move all substantive
+resolution to a private channel within two public exchanges. Tone
+register: brief, non-defensive, solution-forward. Never debate a
+customer on a public social channel; never post account-specific
+information publicly.
+
+Per-channel tone must remain consistent across agents. Tone guidelines
+belong in the macro library, not in individual agent discretion.
+
+## Diagnostics and Metrics
+
+**Leading indicators** (predict future satisfaction before it deteriorates):
+- First-response time by severity tier — against SLA target, not average.
+- First-contact resolution rate (FCR) — percentage of tickets resolved
+  without a follow-up contact from the customer on the same issue.
+- Escalation rate — percentage of tickets requiring escalation; a rising
+  escalation rate signals either under-trained tier-1 or a systemic
+  product issue.
+- Reopen rate — percentage of closed tickets reopened within seven days;
+  indicates resolution quality.
+
+**Lagging indicators** (measure outcomes after the interaction is complete):
+- CSAT (Customer Satisfaction Score) — post-interaction survey; 1–5
+  scale; target ≥ 4.3 across all tiers.
+- NPS (Net Promoter Score) — periodic relationship survey; detractor
+  rate is more actionable than the headline score.
+- Time-to-resolution by severity tier — measure against SLA; report
+  median and 90th percentile, not mean (mean conceals outliers).
+
+**Never optimise for speed at the expense of resolution quality.** A
+ticket closed in thirty seconds that reopens in two days is a failed
+interaction measured twice. FCR is a more reliable quality signal than
+average handle time.
+
+Review metrics weekly at the severity-tier level; review trends monthly
+at the channel level. Present both leading and lagging indicators in the
+same dashboard to avoid gaming a single metric.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails |
+|---|---|
+| Scripted-only responses | Customers detect templates; personalisation signals competence and care |
+| Hidden escalation | Customer discovers escalation after the fact; destroys trust faster than the original delay |
+| Vanity CSAT optimisation | Timing surveys to catch happy moments rather than measuring representative interactions; inflates scores while masking real issues |
+| Ignored VoC | Tickets closed without synthesis; product team receives no signal; same issues recur without root-cause resolution |
+| Channel mismatch | Directing a P1 incident to asynchronous email; directing billing disputes to live chat without specialist access |
+| "Dear Customer" macros | Demonstrates the agent did not read the ticket; damages trust immediately |
+| Closing without next-action commitment | Customer is left without a concrete expectation; increases reopen rate and escalation demand |
+| Optimising for average handle time | Encourages premature closure and deflection; FCR and reopen rate will degrade as a consequence |
+
+## Cross-References
+
+- `domains/hospitality/skills/guest-services` — guest-facing service
+  standards that parallel multi-channel support tone discipline.
+- `domains/retail/skills/customer-returns` — returns and claims handling
+  with severity-triage patterns applicable to billing escalations.
+- `domains/business-support/skills/analytics-reporter` — metrics
+  pipeline and dashboard discipline for CSAT/NPS/FCR reporting.
+
+## ADR Anchors
+
+- **ADR-058** — canonical skill authorship and creative-rewrite
+  discipline; this skill is a structural adaptation of the upstream
+  source, not a verbatim copy. All doctrine is independently authored.