Rebuilding Client Service Around AI
Eight research passes into what should actually run an AI-first support org. The answer: own the control plane, rent the transport.
⌕
- A playbook's whole life, step by stepFour beats: write the table, prove it, run a client on it, change it. The fourth is the one nobody draws. When routing changes most clients carry on untouched, some are silently stranded, and the check that would catch it cannot currently see them. Open →
- The go-live architecture, drawnOne client walked from the intake form to CHURNED, across eight boxes and four levels you tap into. Every box says built, partial or proposed, and every built one is pinned to the code that runs it. Open →
- The CS playbook, file by fileEvery file in the department repo, the one form, the five workflows, the Project, and how each GitHub feature is exercised. About 280 lines of shell, zero servers, and every external system named, including the ones not needed. Open →
- Native GitHub, one workflow, everything else is dataEvery part of Issues, Projects and Actions read against its own docs, the one thing none of them can do, and the smallest design that runs every department's playbooks without owning code or a mess a year from now. Open →
- Playbook library architectureSix ways to build a playbook library, described one by one, plus what Azure DevOps, Jira, ServiceNow and Protobuf each learned the hard way, and the smallest version that survives year two. Open →
- It is built, and you can open itThe three addresses, and what the build cost to learn: 24 phases running, a state change down from 19 seconds to 2.9, and three bugs that only appeared once real clients were driven through it. Open →
- What becomes an issueTransitions close and open, attempts only move a counter, delegations hang off a task that stays open. The rule for telling them apart, plus the sub-issue and issue-type limits, tested rather than assumed. Open →
- The questions we parkedFive unresolved threads written down on the page: HubSpot's fate, personal WhatsApp capture, who owns stability, whether Sales joins, and where the record really lives. Open →
- The map, live in the pageThe playbook stops being a screenshot: the pannable, zoomable state machine now sits embedded inside the brief itself. Open →
- One system, five handsOne playbook system across CS, coaching, finance and sales. The relay grows from three hands to five, and the research drops to an appendix. Open →
- Trimmed, and annotatable everywhereThe storage section loses its closing explainers, and the feedback layer grows up: diagrams, images, tiles and table rows all become tappable. Open →
- Where everything livesOne repo for all ~1,000 clients, no files in git, an object store as the system of record, and Drive as the human drafting surface. Open →
- Why GitHub Issues is the substrateGitHub named this pattern, documented it, and ships its own code through it. The routing engine needs no model in the loop at all. Open →
- Two working screensProse gives way to product: the queue a CSM opens each morning, and the whole book of clients as one severity tree. Open →
- The real playbook, measuredCauseMatch's actual sheet: 6 playbooks, 37 phases, 113 transitions, 68% of it agent-drivable, and the six gaps that block unattended running. Open →
- The decision briefOutcome first: the chosen stack as a wiring schematic, eight research passes each stamped with what it eliminated, and 14 options scored. Open →
No version matches that search.
Alongside
- The playbook, drawnSix playbooks as one zoomable state machine: every phase a card, every valid result an arrow to the phase it routes to. Open →
- The CSM's daySix tasks, each a GitHub issue carrying its plan, the client context and the agent's draft waiting for approval. Open →
- Book health, as a treePlaybook to branch to phase to client, every node filled with the blended severity of the leaves beneath it. Open →