{
  "id": "page:library-customer-support",
  "_kind": "Page",
  "_file": "wiki/library/customer-support.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "title": "customer-support (Library)",
    "displayName": "customer-support (Library)",
    "slug": "library/customer-support",
    "articlePath": "wiki/library/customer-support.md",
    "article": "\n# customer-support\n\nThe first full agentic **customer-facing workflow** specialization in the library. It closes\nthe census's top customer-facing gap: `domains/business/customer-experience` holds **20\npre-bar point tasks with zero breakpoint routing**, and no customer-support specialization\nexisted anywhere. This specialization carries a real support ticket end-to-end with routed\nhuman approvals on every action that leaves the org boundary, while the 20 point tasks\nremain independently callable utilities (mapped per phase below).\n\n## Flagship process: ticket-lifecycle\n\n`ticket-lifecycle.js` (`@process customer-support/ticket-lifecycle`) walks one ticket\nthrough the whole lifecycle:\n\n| Phase | What happens |\n|---|---|\n| 0 | `kipRecall` at intake — prior similar-ticket resolutions thread into every later task (`kipEnabled`, kind `customer-support`) |\n| 1 | Intake & classification (`cst.intake-classify`) — category, structured facts, candidate known issues |\n| 2 | Severity/priority triage (`cst.triage`) — conditional `customer-support.triage-ambiguity` breakpoint fires only on `triage.ambiguous === true`; approver response may override severity/priority/queue and is recorded as `ambiguityResolution` |\n| 3 | Parallel investigation via `ctx.parallel.all` — repro (`cst.investigate-repro`), knowledge search (`cst.investigate-knowledge`), account context (`cst.investigate-account-context`) |\n| 4 | Resolution drafting (`cst.resolution-draft`) — resolution document + customer replyDraft + remediation proposal; an unknown `remediation.kind` on a monetary remediation throws before any gate |\n| 5 | Adversarial resolution review — `adversarialGate` (`customer-support.resolution-review`) with two independent critics and executed evidence; **a failed gate returns `success:false` before any customer contact** |\n| 6 | Policy-gated customer reply + conditional refund/credit — refund breakpoint/execution first when `remediation.monetary === true`, its outcome folded into the reply breakpoint context |\n| 7 | Verification & close (`cst.verify-close`) — verificationSteps re-executed, unverified closes recorded honestly |\n| 8 | KCS-style KB capture (`cst.kb-article-capture`) + policy-gated publish (`cst.publish-kb-article`) — the publish breakpoint is always raised; a human decides even when the author recommends against |\n| 9 | `kipAssert` at close — root cause, resolution pattern, refund decision, gate outcome, KB decision |\n\n**Inputs:** `{ ticket: {id, channel, subject, body, customerRef, attachments?} (required), customerProfile?, repoRoot?='.', kbDir?='artifacts/kb', maxFixAttempts?=2, kipEnabled?=true, kipDir?='.a5c/kip', kipModel?='sonnet' }`\n\n**Outputs:** `{ success, classification, triage, investigation, resolution, resolutionGate, gatedActions, verification, kbArticle, kipFactsAsserted, artifacts, metadata }` — `success = resolutionGate.passed && gatedActions.sendCustomerReply.executed && verification.verified && (!resolution.remediation.monetary || gatedActions.issueRefundOrCredit.approved === gatedActions.issueRefundOrCredit.executed)`.\n\n## Policy-gated actions\n\nAll approvals go through `routedBreakpoint`; for the three policy-gated actions the\n`breakpointId` **equals** the actionId and tags are `['policy-gated','customer-support']`.\nFail-closed: the executor task runs **only** on `approved === true` — a rejection is\nhonored, recorded, and never worked around.\n\n| actionId | expert | when | fail-closed behavior |\n|---|---|---|---|\n| `send-customer-reply` | support-lead | always | executor runs only on `approved===true`; rejection records the decision and the run continues to verify/close with `sent=false` surfaced honestly |\n| `issue-refund-or-credit` | support-manager | only when `resolution.remediation.monetary === true` | executor runs only on `approved===true`; rejected refund records `approved=false` and the reply proceeds without monetary language |\n| `publish-kb-article` | knowledge-manager | always raised after capture (author recommendation in context) | executor runs only on `approved===true`; rejection leaves the draft in place |\n\nAdditional (non-gated) breakpoints on the surface:\n\n- `customer-support.triage-ambiguity` — expert support-lead, conditional on `triage.ambiguous === true`.\n- `customer-support.resolution-review.gate-escalation` — raised internally by the\n  `adversarialGate` combinator on fix-budget exhaustion (expert `owner`, combinator-fixed);\n  the process does not re-declare it, but operators should know it is part of the surface.\n\n`outputs.gatedActions` records **every** decision — `{ actionId, required, approved,\nautoApproved, response, executed }` per action, including non-interactive auto-approvals\n(recorded raw from the BreakpointResult) and skipped conditional gates\n(`{ required:false, approved:false, autoApproved:false, executed:false }` — never omitted).\n`metadata.breakpointsHit` logs every raised breakpointId in order.\n\n## Phase -> customer-experience point-task map\n\nAll 20 utilities under [`../domains/business/customer-experience/`](../domains/business/customer-experience/)\nremain independently callable helpers. Which phase can invoke which:\n\n| Phase | Point tasks (callable helpers) |\n|---|---|\n| Intake & classification | `ticket-triage-routing`, `service-request-fulfillment` |\n| Triage | `sla-management`, `escalation-management` |\n| Investigation | `fcr-optimization`, `problem-management`, `customer-health-scoring`, `knowledge-base-development`, `feedback-analysis-pipeline` |\n| Resolution | `churn-prevention` |\n| Verify & close | `csat-collection`, `closed-loop-feedback`, `nps-survey-program` |\n| KB capture & publish | `kcs-implementation`, `self-service-optimization` |\n| Journey-level companions (outside the single-ticket loop) | `customer-onboarding`, `customer-journey-mapping`, `qbr-preparation`, `touchpoint-optimization` |\n| Ownership note | `itil-incident-management` and `problem-management` escalate to the **incident-management** specialization — this specialization owns *tickets*, not *incidents* |\n\n## Quality bar\n\n- **adversarialGate with executed evidence** — the resolution-review gate's critics must\n  RE-EXECUTE the repro steps / verificationSteps; file-read citations alone do not satisfy\n  the gate, and `passed:true` with an empty evidence array is a protocol failure enforced\n  by the combinator.\n- **Reviewer independence** — critic agent names (`resolution-accuracy-critic`,\n  `customer-communication-critic`) are distinct from the drafting agent\n  (`support-resolution-author`); the combinator fans critics out in parallel.\n- **Bounded fix loop** — the built-in `gateFixerTask` edits the resolution artifact for up\n  to `maxFixAttempts` rounds, then the combinator escalates to the owner.\n- **No fallbacks** — missing `ticket`/`ticket.id`/`ticket.body` throws; an unknown\n  `remediation.kind` on a monetary remediation throws before the refund breakpoint;\n  rejected gates are honored, never worked around; a failed resolution gate ends the run\n  with `success:false` before any customer contact.\n\n## kip integration\n\n`kipRecall` at intake (topic: similar support tickets by subject/body, kind\n`customer-support`) and `kipAssert` at close (root cause, resolution pattern, refund\ndecision, gate outcome, KB decision — one fact each, subject `ticket:<id>`), per\n`shared/skills/kip-librarian`. An empty store is a fresh brain, never an error; assert\nfailures are reported by the librarian task, never swallowed.\n\n## Usage\n\n```bash\nbabysitter run:create \\\n  --process library/specializations/customer-support/ticket-lifecycle.js \\\n  --inputs '{\n    \"ticket\": {\n      \"id\": \"TCK-4821\",\n      \"channel\": \"email\",\n      \"subject\": \"Webhook deliveries failing since upgrade\",\n      \"body\": \"Since upgrading to v3.2 our webhook endpoint receives 401s on every delivery...\",\n      \"customerRef\": \"acme-corp\"\n    },\n    \"customerProfile\": { \"tier\": \"enterprise\", \"tenureMonths\": 26 },\n    \"kbDir\": \"artifacts/kb\",\n    \"maxFixAttempts\": 2\n  }'\n```\n\n## Second flagship process: onboarding-lifecycle\n\n`onboarding-lifecycle.js` (`@process customer-support/onboarding-lifecycle`) carries one\n**signed deal** end-to-end — from handoff intake through account-context recall, success-plan\ndrafting, an adversarial plan/success review with **executed** evidence, policy-gated kickoff\ncomms, parallel provisioning/training/integration tracks with per-track verification, milestone\nreviews that route to a policy-gated at-risk escalation, go-live sign-off, and a closing\nhealth-score baseline asserted into kip. It **composes** the pre-bar customer-experience point\nseeds by name as callable stages — it does not duplicate them.\n\n| Phase | What happens |\n|---|---|\n| 0 | `kipRecall` of prior onboarding outcomes, health signals, and account history (`kipEnabled`, kind `customer-support`, topic keyed by `account:<accountId>`) |\n| 1 | Signed-deal handoff intake (`onb.handoff-intake`) — normalizes account/tier/stakeholders/contractTerms; duplicate or missing contractTerm ids throw before drafting |\n| 2 | Success-plan drafting (`onb.success-plan-draft`) — markdown plan where **every commitment carries a `contractTermId`**; applies customer-onboarding (discovery/plan/milestones) + customer-journey-mapping lenses by name |\n| 3 | Adversarial plan/success review — `adversarialGate` (`onb.success-plan-review`) with two independent critics (`commitment-traceability-critic` re-traces commitments to contract terms; `health-baseline-critic` executes the health-scoring logic over `stubAccountData`); **a failed gate returns `success:false` before any customer contact** |\n| 4 | Policy-gated kickoff comms — `onb.kickoff-comms-draft` then the `customer-comms-send` breakpoint; `onb.send-kickoff-comms` runs only on `approved===true` |\n| 5 | Parallel tracks via `ctx.parallel.map` (`maxConcurrency=maxParallel`) — provisioning (`onb.provision-plan` → `tenant-provisioning-approval` gate → guarded `onb.provision-execute`), training (`onb.training-track-prepare`), integration (`onb.integration-track-prepare`); each ends in `onb.verify-track` with executed evidence and honest `failures[]`. Unknown track name throws (no default-skip); results re-keyed by name via a Map |\n| 6 | Milestone review (`onb.milestone-review`) — a routed breakpoint fires **only** when a milestone is `atRisk===true`, raising the policy-gated `account-escalation-approval` with an `onb.escalation-package` handoff; non-at-risk milestones auto-continue |\n| 7 | Go-live sign-off — `routedBreakpoint` `go-live-sign-off` (expert onboarding-manager, tags `customer-support`/`go-live`; **not** one of the three policy-gated actions); a no-go is final but the closing phases still run |\n| 8 | Health-score baseline (`onb.health-baseline`) — composes the customer-health-scoring scoring-model; not-computable sub-scores are reported, never invented |\n| 9 | `kipAssert` — onboarding-outcome, health-baseline (composite + tier), plan-review gate-outcome, and one policy-decision fact per gated action |\n\n**Inputs:** `{ handoff: {accountId, accountName, contractTerms:[{id,term,commitment,metric?}], productTier, stakeholders:[{name,role,email?}], signedValue?, closeDate?} (required), objectives?, stubAccountData?, repoRoot?='.', maxParallel?=3, maxFixAttempts?=2, kipEnabled?=true, kipDir?='.a5c/kip', kipModel?='sonnet' }` — missing `handoff`/`handoff.accountId`/empty `contractTerms` throws.\n\n**Outputs:** `{ success, handoffSummary, successPlan, planReviewGate, gatedActions, tracks, milestones, goLive, healthBaseline, kipFactsAsserted, artifacts, metadata }` — `success` is true only when `planReviewGate.passed`, kickoff comms `executed===approved`, tenant provisioning `executed===approved` (when required), every track verified, go-live `decision==='go'`, and `healthBaseline.computed`; any at-risk escalation rejection or go-live no-go yields `success:false` with an honest reason.\n\n### Policy-gated actions (onboarding)\n\nSame fail-closed pattern as ticket-lifecycle: `breakpointId` **equals** the actionId, tags are\n`['policy-gated','customer-support']`, the executor runs **only** on `approved===true`, and every\ndecision (including skipped conditional gates and non-interactive auto-approvals) is recorded raw\nin `outputs.gatedActions`.\n\n| actionId | expert | when | fail-closed behavior |\n|---|---|---|---|\n| `customer-comms-send` | customer-success-manager | always (Phase 4 kickoff comms) | `onb.send-kickoff-comms` runs only on `approved===true`; rejection records the decision and the run continues with `sent=false` surfaced honestly |\n| `tenant-provisioning-approval` | onboarding-manager | always within the provisioning track (Phase 5) | `onb.provision-execute` runs only on `approved===true`; rejection records `approved=false` and the track verifies with `provisioned=false` |\n| `account-escalation-approval` | customer-success-director | **conditional** — only when a milestone review yields `atRisk===true` (Phase 6) | escalation acted on only when `approved===true`; a skipped conditional gate is recorded as `{required:false,...}`, never omitted |\n\nAdditional (non-gated) breakpoints on the surface:\n\n- `go-live-sign-off` — expert onboarding-manager, tags `['customer-support','go-live']`; always raised in Phase 7.\n- `onb.success-plan-review.gate-escalation` — raised internally by the `adversarialGate` combinator on fix-budget exhaustion (expert `owner`); the process does not re-declare it but records it in `breakpointsHit` when the gate escalates.\n\n### Onboarding phase -> customer-experience seed map\n\nThe onboarding workflow composes four pre-bar seeds under\n[`../domains/business/customer-experience/`](../domains/business/customer-experience/) **by name**;\nthe seeds remain independently callable point methods.\n\n| Seed | Methods used | Composed by |\n|---|---|---|\n| `customer-onboarding` | discovery-assessment, onboarding-plan, training-program, success-milestones | `onb.success-plan-draft` (discovery/plan/milestones lenses) + `onb.training-track-prepare` (training-program lens) |\n| `customer-health-scoring` | indicator-design, scoring-model, threshold-definition | `health-baseline-critic` in the plan-review gate (executed over `stubAccountData`) + `onb.health-baseline` (composite baseline) |\n| `escalation-management` | handoff-package + communication-standards | `onb.escalation-package` on the at-risk path feeding `account-escalation-approval` |\n| `customer-journey-mapping` | journey-map lens | `onb.success-plan-draft` (milestone journey framing) |\n\n`domains/business/customer-experience/customer-onboarding.js` is soft-`@deprecated` as the e2e\nentrypoint (superseded by this workflow) but stays independently callable for standalone\nonboarding-plan drafting.\n\n## Files\n\n- [`ticket-lifecycle.js`](./ticket-lifecycle.js) — the flagship process (11 `cst.*` Style-A\n  agent tasks + orchestration).\n- [`onboarding-lifecycle.js`](./onboarding-lifecycle.js) — the second flagship process (12\n  `onb.*` Style-A agent tasks + orchestration; gated end-to-end signed-deal onboarding).\n- Combinators: [`../common-utilities/routed-gate-combinators.js`](../common-utilities/routed-gate-combinators.js)\n  — `routedBreakpoint`, `adversarialGate`, `kipRecall`, `kipAssert`, `gateFixerTask`.\n",
    "documents": [
      "specialization:customer-support"
    ]
  },
  "outgoingEdges": [
    {
      "from": "page:library-customer-support",
      "to": "specialization:customer-support",
      "kind": "documents"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:index",
      "to": "page:library-customer-support",
      "kind": "contains_page"
    }
  ]
}