role · cs lead

CS Lead

The CS Lead is the chain's ear. They are the first to hear the cycle's noise, the ones who decide what is bug, what is brief, and what is the cost of an unwitnessed moment. Their pipeline is the corpus's most reliable feedback loop.

What good looks like

A competent CS Lead produces three artefacts every cycle:

1. A support-to-bug pipeline that sorts incoming traffic into three streams — bug, brief input, expected noise — and routes each one to the right artefact.
2. A weekly helpdesk reading — five lines: volume, top theme, what changed since last week, what to watch, what to take to the trio.
3. A voice-of-customer note for the cycle's signal reading — the moments the support tickets named that the dashboards didn't.

A CS Lead who produces these three has the relationship chain working. A CS Lead who routes every ticket as a bug fills the engineering backlog with noise; one who routes none as briefs leaves the team building from dashboards alone.

The CS Lead's stance

The CS Lead is responsible for	The CS Lead is not responsible for
Sorting incoming signal into bug / brief input / noise	Fixing the bug
The weekly helpdesk reading	Being the only voice of the customer
The L1/L2/L3 escalation discipline	The deploy decision
The handoff from release to support	What the release contains
The voice-of-customer note alongside the signal reading	The metric the signal reading reports

The CS Lead holds the chain by holding the boundary between the team and the lived experience of what was shipped.

Three artefacts to read first

1. The Ongoing Relationship
2. Bugs and Their Roots
3. Signal & The Prediction

First 30 days

Day 1–3 — Read the canon

Read Did We Serve Parts 2 (Ongoing Relationship). Read After We Build Parts 2, 3 (Signal, Bugs and Their Roots). Read Why We Build Part 7 (Client Relationship Strategy).

Output: in three sentences, explain how a ticket that says "it's broken" becomes (a) a bug, (b) a brief input, or (c) noise.

Day 4–7 — Sit on L1 for a day

Spend a full day on L1 with the existing CS team. Take five tickets through end-to-end. Don't try to optimise — observe.

Output: a one-page note on what surprised you about the team's current routing.

Day 8–14 — Walk the pipeline

Trace ten recent tickets through L1 → L2 → L3. For each, name where it landed and whether the landing was right.

Output: a note on at least one misrouted ticket and where it should have gone.

Day 15–18 — Write your first weekly helpdesk reading

Five lines. Volume. Top theme. Change since last week. What to watch. What to take to the trio. Send it.

Output: the reading, sent, with at least one item that surfaces at the next trio.

Day 19–25 — Hold the release-to-support handoff

When the next release is staged, sit with the trio. Read the release brief. Ask the questions a Tier-1 agent would ask the first time a customer calls. Refuse to accept a handoff that doesn't answer them.

Output: a handoff note signed by the trio, plus at least one rewrite of release copy that came from your reading.

Day 26–30 — Add your voice to the signal reading

When the cycle's signal reading is written, you contribute the voice-of-customer paragraph. Name the moments that tickets witnessed.

Output: a paragraph alongside the signal reading, dated, signed.

Deepening — self-rate yourself

Routing discipline

• I can sort an unfamiliar ticket within three minutes — bug, brief input, noise.
• My team's L1/L2/L3 escalation has a clear contract; nobody is "stuck in L2".
• I have rejected a bug ticket that was a brief input without it being a personal moment.

Reading craft

• My weekly helpdesk reading takes five minutes to write and one minute to read.
• I name the theme, not the ticket count.
• The reading surfaces at least one trio conversation every month.

Voice-of-customer

• I attend the signal-reading session every cycle.
• My voice-of-customer note names a moment, not a feature request.
• I can defend not surfacing a ticket that didn't represent the moment.

Handoff discipline

• The release brief never reaches L1 without a CS-signed handoff.
• The handoff includes the first call we'll get, not just what changed.
• I have stopped a release without it being a personal moment.

Helpdesk health

• Tickets close. Open tickets are aged honestly.
• L1 has a path to L3 that doesn't go through me by default.
• I have grown at least one L1 into L2 craft per quarter.

Stuck if…

…the engineering backlog has fifty open bugs and none of them are fixed

The pipeline is routing too much as bug. Re-read Bugs and Their Roots. A bug ticket that doesn't trace to a level is brief input or noise — not a bug.

…you can't tell whether a theme is growing or stable

The weekly reading isn't dated against history. Keep a running thread; the change since last week line is the discipline.

…the trio learned about a recurring ticket type from outside the helpdesk

The reading isn't reaching the trio, or it isn't being read. Move it; sit at the trio's review; refuse to let the helpdesk be invisible.

…a release brief left support without preparation

The handoff didn't happen. Re-read The Ongoing Relationship. The handoff is the contract that protects both sides.

…leadership uses ticket volume as a quality metric

Volume is a noise metric, not a quality one. The reading's job is to give leadership themes, not counts. If they keep counting, it's because the themes aren't legible enough.

…the same customer ticket has been open for six weeks

Either the bug isn't a bug, or the bug owner has drifted. Walk it. If it's a brief input, route it. If it's a true bug, pull it back into the trio's view.

See also

• Skill path — CS Lead foundations
• Canon — Did We Serve? · After We Build
• Practice — Release gate · First 48 hours watch · Weekly client update · SLA review · Daily triage · Helpdesk reading
• Templates — Release brief to client · Weekly client update · Helpdesk reading
• Checklists — Weekly client update · SLA review · agenda · Daily triage · 15 minutes
• Clinics — An SLA review that became sales
• Areas — 11 · Ongoing Operations & Client