The lesson

Where your week actually goes

Before changing how you work, you need an honest picture of the work. Ask enough CSMs and the weekly split looks remarkably consistent: roughly a quarter of the week in live customer conversations, and the remaining three quarters spent producing the inputs and outputs around those conversations, briefs, summaries, decks, emails, CRM updates, internal reporting, inbox triage.

Here is the uncomfortable part: the live conversations are where renewals are saved and expansions are opened, and they are the part that gets squeezed. When an escalation lands, the production work doesn't shrink, the strategic work does. You walk in lighter, you react instead of lead. Every CSM knows this trade; most have stopped noticing they make it daily.

AI fluency, properly understood, is the discipline of systematically moving hours from the production column into the conversation column. Not by cutting corners on the production work, it still has to be excellent, often more excellent than before, but by changing your role in it.

Hold that number. The rest of this module, and honestly the rest of this course, is the technique for collecting it.

The junior analyst model

The single most useful mental model for working with AI: you have just been assigned a brilliant, tireless junior analyst. They have read essentially everything ever published. They write fluently in any style. They never get bored, never push back on tedious work, and turn drafts around in seconds.

They also have three defining limitations. They know nothing about your accounts until you brief them. They have no stake in being right, they will produce a confident answer whether or not the facts support one. And they carry no accountability, when the work goes out, your name is on it, not theirs.

Every good AI behaviour falls out of this model. You wouldn't hand a junior analyst a task with no context and expect strategy: brief properly (Module 02). You wouldn't send their first draft unread: edit and verify. You wouldn't let them attend the negotiation for you: keep the human work human (Module 10). And you wouldn't re-explain the same task weekly: build reusable briefings, which is all a prompt library is (Module 09).

That last line deserves a moment. Look at what your VP actually produces in a week: very little, directly. Their output is judgement applied to other people's production, choosing, correcting, contextualising, deciding. AI gives every CSM a production team. The ones who thrive are the ones who learn to manage it like one.

What AI is genuinely good at, in CS terms

Skip the abstract capability talk. In CSM work specifically, AI excels at four families of task, and you should recognise your week in each:

• Synthesis, collapsing volume into meaning. Fifty support tickets into five themes. A year of call notes into a relationship arc. A 40-page contract into the six clauses that matter for renewal. This is the family with the biggest hours, because synthesis is most of what "preparation" is.
• Structured drafting, producing a competent first version of anything with a known shape: the QBR narrative, the escalation email, the exec summary, the follow-up. The shape is the prompt; the polish is yours.
• Pattern surfacing, noticing what's distributed across too much material for one person to hold: the same complaint appearing in three accounts, engagement decaying in a shape you've seen before churn, a stakeholder going quiet.
• Rehearsal, playing the sceptical CFO, the procurement lead, the frustrated IT director, so the first time you hear the hardest objection isn't in the room.

The four failure modes, and the catch for each

Fluency is as much about knowing where the tool breaks as where it shines. Four failure modes account for nearly every AI embarrassment in professional use:

• Confident invention. Given gaps, the model fills them, smoothly. The catch: constrain it ("do not invent; list missing information as open questions") and verify every fact you didn't supply yourself before it leaves your hands.
• Context blindness. It cannot know that your champion is leaving, that the CFO hates the word "partnership", that last quarter's incident is still raw. The catch: the briefing is your job; thin briefing in, generic output out, every time.
• Generic output. Ask for "a good renewal email" and you get the email everyone gets. The catch: specificity in, specificity out. The difference between generic and genuinely useful output is almost always in the prompt's context, not the model.
• Zero accountability. The model will not sit in the post-mortem. The catch: a personal rule you'll meet again in Module 10, never send anything you couldn't defend line by line if asked "did you write this?"

Worked example, the same task, three levels of fluency

The task: your manager asks for a quick health summary of an account before an internal pipeline review, due in an hour.

The gap between Level 1 and Level 2 is not talent and it is not the tool. It is technique, briefing, constraining, editing, and technique is learnable. That is the rest of this course.

The lesson

Why CSM prompts fail when generic prompts succeed

Ask any model for "a poem about the sea" and you'll get something decent: average is fine for generic tasks. Ask for "a renewal email" and you'll get something decent looking, and that's the trap: an email that would work for any account is precisely an email that works for none. CS work doesn't tolerate average, because the entire value of a CSM's communication is its specificity to this customer, this history, this moment.

This is the specificity asymmetry, and it explains almost every disappointing AI experience a CSM has ever had. The model's output can only ever be as specific as its input. When the input is "write a QBR summary", the output is the average of every QBR summary ever written. When the input includes your account's actual year, their stated objectives in their own words, and the incident from March that's still sensitive, the output starts to sound like it was written by someone who knows the account. Because, functionally, it was: you briefed it.

So the discipline of this module isn't really "prompt engineering" in the hacker sense of magic words. It's briefing: the same skill you'd use handing work to the junior analyst from Module 01. Four components, every time.

RCCO: the four components, properly understood

Role. "You are a senior CSM preparing for a renewal call with a risk-flagged account." One line, three effects: the vocabulary, the assumed depth, and most importantly the relevance filter, what the model treats as worth mentioning. A "senior CSM" frame surfaces risk signals and political dynamics; no frame surfaces pleasant generalities. The role should match the work, not flatter the model: "a sceptical CFO reviewing this proposal" is a role; so is "a procurement specialist hunting for weaknesses in this contract".

Context. This is where CSM prompts live or die. The model knows precisely nothing about your accounts; every relevant fact it doesn't have, it will omit or invent. Context is your raw material dump: the call notes, the ticket export, their objectives in their words, the thing that went wrong in March. Two CSMs running the identical template get wildly different results, and the difference is entirely here. The test before sending: could a smart stranger do this task with only what's written here? If not, neither can the model.

Constraints. The guard rails that separate professional output from plausible fiction. The single highest-value constraint in all of CS prompting is eleven words: "Do not invent any facts; list missing information as open questions." It converts the model's confident gap-filling into an honest gap list, which is exactly what you want from an analyst. Other workhorse constraints: length limits ("maximum one page", "under 150 words"), tone boundaries ("no corporate jargon", "warm but direct"), language ("UK English"), and format prohibitions ("no bullet points in the email itself").

Output. The shape of the deliverable: "a one-page brief with exactly these six sections", "a table with columns action, owner, date", "two drafts of the same email". Specifying output does double duty: it makes the result instantly usable, and, as Module 05 will show, a fixed output skeleton trains your own brain to scan results in seconds. The vault prompts you'll use all course are RCCO made concrete; read three of them and you'll see the skeleton everywhere.

Diagnosis becomes mechanical once you think in components. Output too shallow? Role or Context. Output confidently wrong? Constraints. Output rambling or unusable? Output spec. Output generic? Context, almost always Context.

Iteration: the first answer is a first draft

The single biggest behavioural difference between a Level 1 and a fluent AI user is what they do after the first response. The Level 1 user judges it: good or bad, keep or abandon. The fluent user treats it as the junior analyst's first draft and starts directing. Three follow-ups carry most of the value:

• "What did you assume that I didn't tell you?" The model fills gaps silently; this question makes the filling visible. Run it on anything important and you'll routinely catch two or three assumptions you'd never have spotted in the polished prose, one of which is usually wrong.
• "Make this 50 per cent shorter without losing the risk signals." Models pad by default. Naming what must survive the cut ("the risk signals", "the ask", "the customer's own words") gets compression without lobotomy. Senior readers receive the short version; you keep the long one.
• "Now argue the opposite case." The cheapest red team you will ever run. You believe the account is safe? Ask for the case that it's churning. You've drafted a renewal strategy? Ask why it fails. The model argues the other side without ego, and somewhere in that argument is the objection your customer's CFO was always going to raise. This follow-up alone will save you from at least one bad strategy this year.

Iteration is also where prompts become assets. When a follow-up fixes a recurring weakness, fold it back into the original prompt as a constraint. Your prompts should be evolving documents; Module 09 turns that habit into a library.

Reasoning you can audit

For anything analytical, churn assessment, negotiation prep, prioritisation, add one instruction: "Think step by step, showing your reasoning before your conclusions." Two effects. First, on complex tasks, the quality of the conclusion measurably improves when the model works through the logic explicitly rather than jumping to an answer. Second, and more important for professional use: you can audit it. A bare conclusion ("this account is high risk") is take-it-or-leave-it. A reasoned chain ("usage fell 40 per cent in the same quarter the champion went quiet, and the last two escalations bypassed you to your manager, therefore...") can be checked line by line, and a wrong assumption gets caught in the logic before it becomes a wrong recommendation in front of your leadership.

Pair it with the disconfirming-evidence instruction you'll meet again in Module 07: "What in this data argues against your conclusion?" You usually run an analysis because you already suspect the answer, which means you're primed to accept confirmation. Forcing the counter-case is the bias correction, built directly into the prompt.

One honest boundary: visible reasoning is the model's account of its process, not a guarantee of truth. You audit it the way you'd audit a junior analyst's logic, checking the facts you supplied are used correctly and the inferences hold, not assuming that articulate equals accurate. The four failure modes from Module 01 still apply; reasoning just makes them findable.

Worked example: one task, four layers

The task: your champion at a key account emails that their new CFO is questioning the renewal cost. You need a reply that steadies the situation. Watch the output change as each RCCO layer is added.

That's the module. The RCCO builder below assembles the skeleton for you; the exercise makes it muscle memory. From here on, every vault prompt you open is this framework wearing work clothes.

Includes vault prompts: Pre-call intelligence brief · Exec summary compressor

The lesson

Fluency is routing, not loyalty

Ask ten CSMs which AI tool is best and you'll get ten loyalty declarations: "I'm a ChatGPT person", "our company is all-in on Copilot". Loyalty is the wrong frame. The fluent CSM is a router: different jobs go to different tools, and the routing decision takes about five seconds once you've internalised the question stack. Tool loyalty, by contrast, quietly costs you in one of two directions: either you're pasting customer data into a tool that shouldn't have it, or you're accepting mediocre output from a tool that was never built for the task in front of you.

The question stack, in strict order: Where must the data stay? What kind of job is this? Where does the work live? Notice what isn't on the list: "which model is cleverest this month". That question matters far less than the league tables suggest, and we'll deal with it properly in Part 4.

Question one: where must the data stay?

This gate comes first because it's the only one with consequences you can't edit your way out of. If the task touches customer data, the choice isn't between good and great output; it's between tools your organisation has approved for that data and everything else. For most CSMs in Microsoft 365 organisations, that means Copilot M365 inside your tenant is the default home for anything involving real account material: it reads the files and emails you reference without the data ever leaving your organisation's boundary. If your company has enterprise agreements for Claude, ChatGPT or Gemini, those tiers typically carry the contractual protections the consumer versions don't.

Two practical notes. First, "approved" is a fact you can check, not a feeling: it's a named list held by IT, and if you haven't seen it, asking for it is this module's first action. Second, anonymisation (Module 04's placeholder scheme) widens your options dramatically: a churn analysis about CUSTOMER_A with CONTACT_1_IT can travel to whichever tool does the best analysis, because the sensitive layer never left your desk.

Question two: what kind of job is this?

Three families of tool, each strong at different work. Frontier assistants (the most capable reasoning model your organisation has approved): deep reasoning and long-form quality. When the thinking is the product, route here. Embedded copilots (AI built directly into the apps you already work in) win on a different axis: they're already inside the work. Vertical CS platforms (the AI in your Gainsight or CRM) know your data model natively; shallower analysis, zero context assembly.

The principle that resolves most routing decisions: friction beats brilliance for in-flow tasks (work that happens inside an app you’re already in). A reply drafted at 85% quality inside the Outlook thread you're already reading beats a 95% reply that required exporting the thread, pasting it elsewhere, and pasting the answer back. Save the frontier trip for work where the extra 10% actually changes the outcome: the analyses, the narratives, the high-stakes documents. Routine flow-work stays embedded; thinking-work travels.

Question three: when the models change, and they will

A new model ships roughly every quarter, each arriving with benchmark charts and breathless commentary. The fluent response is neither chasing every release nor ignoring them: it's owning a personal benchmark. Keep your three most-used prompts, with real (anonymised) inputs, as a private test suite. When a major release lands, run all three on the new model and your current one, side by side, and judge on three criteria: faithfulness (did it use only what you gave it?), edit distance (how far from sendable?), and reasoning quality (does the logic survive your audit?).

Twenty minutes, once a quarter, and you know more about what matters to your work than any league table can tell you, because league tables measure averages and you don't do average work. This habit also future-proofs the entire course: every technique here is model-agnostic by design, and your benchmark is the bridge that carries your library across each model generation.

Worked example: one Tuesday, four routing decisions

Four decisions, maybe twenty seconds of routing thought in total. That's the skill: not knowing every model's benchmark scores, but knowing your own question stack cold.

The lesson

The asymmetry that rules everything

Here is the uncomfortable maths of this module: a hundred brilliant AI-assisted briefs build your reputation slowly, and one customer name in the wrong tool can undo all of it in an afternoon. Data safety isn't the boring compliance chapter of AI fluency; it's the asymmetric risk that decides whether you get to keep practising everything else in this course. That's why this module sits at the end of Foundation, before a single exercise touches real account data.

There are exactly two surfaces where things go wrong: what goes in (the data you paste, upload, or reference) and what comes out under your name (the drafts you send, the facts you repeat, the commitments you didn't notice). Everything in this module is one of those two disciplines. Neither is difficult. Both have to become reflex.

What goes in: the four data classes

Before anything touches a model, classify it. Four classes cover everything a CSM handles:

• Personal data. Names, emails, job titles, opinions, anything identifying a real person. Under GDPR, pasting it into an AI tool is processing personal data, full stop. "The vendor doesn't train on my data" answers a different question: processing is the legal category, and it happens the moment you hit enter. What matters is the data processing agreement and the approved list.
• Commercially sensitive. Pricing strategy, discount floors, legal positions, anything under NDA, unannounced plans, yours or the customer's. This class goes into one place only: an approved enterprise tool, anonymised, and only with explicit clearance, never a business subscription or personal account. Without anonymisation and sign-off, keep it off the clipboard. The convenience is never worth the legal risk.
• Security material. Credentials, API keys, architecture diagrams, security questionnaire answers. Never. There is no anonymised version of a password.
• Everything else, after preparation. Ticket themes, usage patterns, meeting structures, your own drafts. This is the vast majority of CS work, and once it's been through the placeholder pass below, it can travel to whichever approved tool does the job best.

The gate in front of all four classes is the approved-tools list: a real, named list held by your IT or security team. If you haven't seen it, requesting it is today's action. The free tier of anything, and any personal account, is off-list by definition.

The placeholder discipline

Anonymisation done badly means deleting things, which destroys the analysis: a churn assessment where every actor is "[redacted]" can't reason about who influences whom. Anonymisation done well means consistent placeholders: CUSTOMER_A for the account, CONTACT_1_IT and CONTACT_2_FINANCE for people (the role suffix preserves the politics), COMPETITOR_X for rivals, PRODUCT_1 for your own modules if even that feels sensitive. The model reasons about the relationships perfectly, because the relationships survived; only the identities stayed home.

Three habits make it work. Keep a key document (placeholders to real names) in a local file that never goes near an AI tool. Substitute before the text enters the prompt window; find-and-replace takes ninety seconds. And watch the three leaks people forget: transcripts (auto-generated ones are full of names, including small talk about people's children), exports (CSV columns you didn't scroll to, email signatures at the bottom of threads), and screenshots (the browser tab titles and taskbar visible around the thing you meant to share).

The reflex to build: the ten-second check. Would you be comfortable if this exact text appeared in an email to the customer's legal team? Hesitation is data. The interactive version lives in the AI Governance tab, "Can I paste this?", run it until you no longer need it.

What comes out: owning the output

The second surface gets less attention and bites just as hard. Three disciplines:

• Verify before it ships. Every fact, figure, date, and name in an AI draft gets checked against the source before it leaves your hands. Module 01's confident invention doesn't announce itself; it sits in fluent sentences next to true ones. The constraint "use only the information provided; list gaps as open questions" prevents most of it; your read-through catches the rest.
• Hunt the hidden commitments. AI drafts love generous closing lines: "we'll have this resolved by Friday", "I'll arrange a call with our product team". If you didn't decide to promise it, it's not a promise, delete it. A commitment you didn't notice is still a commitment the customer read.
• The accountability standard. Forget AI detectors and disclosure theatre; the professional standard is simpler and harder: never send anything you couldn't defend line by line if asked "did you write this?" The answer you're entitled to give, after editing, verifying, and choosing every word that survives, is yes: the judgement is yours, whoever typed the first draft.

Worked example: a sensitive analysis, end to end

The task: a churn-risk analysis on a strategic account, using a 180-row ticket export and your call notes. Watch the discipline applied.

Three minutes. That's the entire cost of doing this professionally, and it's the difference between AI fluency as a career asset and AI fluency as the subject of a very uncomfortable meeting.

The lesson

The highest-frequency skill in the job

Five meaningful conversations a week, forty minutes of honest preparation each: call prep is quietly one of the biggest line items in your calendar. High frequency, high leverage, and the gap between prepared and unprepared is visible to the customer within ninety seconds.

The standard this module sets: walk into every call knowing more than anyone expects you to. Not more data, more synthesis: what changed, what it means, and the one question that proves you've been paying attention. AI compresses the gathering and the synthesis from forty minutes to ten or fifteen. The judgement about what matters, and what to do with it in the room, stays exactly where it always was.

The fixed skeleton

The pre-call brief in the vault uses the same six sections every single time: status line (the account in one sentence), since we last spoke (what changed, with dates), open items (theirs and ours, with owners), risk signals (anything that smells off, however faint), opportunity (anything that smells like expansion), and the one question (the single thing to ask that this customer wouldn't expect a vendor to know to ask).

The skeleton being fixed is not a stylistic preference; it's the entire trick. The fiftieth time your eyes land on a brief with identical structure, you're no longer reading it, you're scanning it, and deviations jump out the way a wrong note does in a familiar song. A brief that's organised differently every time costs you thirty seconds of orientation per read and hides the very anomalies you built it to surface. Fixed skeleton, fluent scanning, pattern recognition for free.

The layering technique

A good brief uses your internal data. An exceptional one adds two layers on top, and the third layer is where the magic actually happens:

• Layer one, the base brief. Call notes, tickets, usage, CRM history, through the skeleton prompt. This is the baseline everyone can reach.
• Layer two, public intelligence. Their latest results announcement, leadership changes, product launches, sector news. Five minutes of searching, pasted beneath the base brief.

• Layer three, the connection pass. One more instruction: "Connect what is happening in their world to what is happening in our account. What should I infer, and what should I ask?" This is the question a junior analyst would never think to ask and a strategic advisor always does.

The connection pass is where briefs stop being summaries and start being intelligence. Their CEO announced "ruthless cost discipline" in October and your expansion conversation stalled in November? Those aren't two facts, they're one story, and the CSM who walks in already understanding that story has a fundamentally different conversation from the one who asks "so, how's everything going?"

The two standing assets: the map and the tickets

Two intelligence assets earn a standing cadence. The stakeholder map (vault prompt 02) plots everyone who matters by influence and sentiment, quarterly and after any reorg. Read it the uncomfortable way: the most dangerous output is the gaps, the influential roles where you have no relationship at all. Accounts are rarely lost to the sceptic you were managing; they're lost to the budget holder you'd never met.

Ticket analysis (vault prompt 03) has one discipline at its core: separating routine product friction from strategic risk signals. Fourteen password resets are friction, annoying, fixable, commercially meaningless. The signals worth your attention hide in three places: trend (volume or severity bending upward), tone (frustration entering the language of people who used to be patient), and seniority (when a director starts personally filing tickets, that is not a ticket, that is a message). Tell the model explicitly to make this separation, or it will dutifully summarise the password resets.

Worked example: fifteen minutes before the check-in

The call: a monthly check-in with a strategic account, renewal in five months. Watch the layers go on.

Includes vault prompts: Pre-call intelligence brief · Stakeholder map builder · Support ticket pattern analysis

The lesson

The visible surface of the job

Most of your work is invisible to the people who decide your account's future. They don't see the triage, the internal escalations, the fifteen-minute briefs. They see what you send: the QBR, the renewal case, the email after the difficult call. Communication isn't one CSM skill among many; it's the surface on which all the others are judged.

AI's arrival here is the biggest gift and the sharpest trap in this course. The gift: a tireless first-drafter. The trap: every CSM now has the same one, and inboxes are filling with prose that is fluent, polished, and eerily identical. Sameness is the new mediocrity; the writing that lands sounds unmistakably like a specific human who knows this specific customer. The whole module is one division of labour: AI supplies structure and speed; you supply voice and specifics.

Narrative first, slides second

The default QBR failure is template-first: open last quarter's deck, refresh the numbers, present data without meaning. The fix is to demand the story before the deck exists. The vault's QBR prompt asks for a narrative arc in prose: where this account started the quarter, what actually happened, what it means, and where we go next, with every claim tied to evidence from your data. Only once that arc reads true do you ask for the slide structure, and the slides assemble around the story instead of the story being reverse-engineered from whatever charts existed.

The test of a narrative-first QBR is brutal and worth applying every time: if you deleted every chart, would the meeting still have a point? When the answer is yes, the charts become evidence for an argument rather than a substitute for one, and the customer leaves remembering a story about their own progress, which is the only thing anyone has ever remembered from a QBR.

The two-draft technique

Hard messages, risk escalations, unwelcome news, pushback on an unreasonable ask, sit somewhere on a spectrum between maximum clarity and maximum relationship care. The mistake is asking AI for the message; the technique is asking for two drafts at different points on that spectrum: one direct and unhedged, one cushioned and warm, both carrying the same facts and the same ask.

Why two? Because the spectrum point isn't a writing decision, it's a relationship decision, and only you hold the relationship. The burned engineer needs the direct draft; the politically exposed sponsor needs the cushioned one; most real messages are a blend of both. Two drafts cost the model nothing and hand the only judgement that matters back to the only person qualified to make it. One more habit for hard messages: write for the forward. Assume your email gets sent upward with one line of commentary added. The version of you that writes for the CC line is calmer, more precise, and harder to quote against you.

The de-AI editing pass

AI prose has tells, and your customers are learning to spot them at exactly the rate you are. The pass takes three minutes and has three moves:

• Cut the tells. "I hope this email finds you well." "Delve." "Leverage" as a verb. The rule-of-three sentence that arrives in every paragraph. "It's not just X, it's Y." Hedges stacked on hedges. If a phrase could open any email to any customer from any vendor, it goes.
• Re-inject what only you know. The specific date, the colleague's actual name, the reference to what they said on Tuesday's call, the detail that proves a human who knows them wrote this. One genuine specific is worth three paragraphs of polish, because specifics are the one thing the model cannot supply and the customer cannot miss.
• Read it aloud. The fastest authenticity test there is: anywhere your actual voice wouldn't say it, rewrite it until it would. Better still, teach the model your voice up front: the vault's communication prompts include a slot for pasting a sample of your real writing, which cuts the de-AI pass in half before it starts.

Worked example: the escalation email, before and after

The situation: a data-sync failure on your side corrupted a week of the customer's reports. The fix is in, but trust is bruised, and the email matters.

Includes vault prompts: QBR narrative builder · Renewal value case · Risk escalation (two-draft) · Meeting notes to actions

The lesson

Churn is a process, not an event

No account leaves on the day it leaves. The decision was made quietly, internally, often two or three quarters earlier, and the signals were sitting in your data the whole time: a champion whose replies stretched, a procurement question that arrived early, a usage line that bent. Run a post-mortem on any lost account (the vault has the prompt) and the most painful column is always the same one: the gap between when each signal first appeared and when someone first acted on it. That gap is detection lag, and shrinking it is the entire job of this module.

AI's contribution here is specific: it cannot tell you whether an account will churn, but it can read more signals, more consistently, more often than you can, which means the signals reach your judgement while there's still time for your judgement to matter.

The four signal families

Risk signals come in four families, and the families matter more than the individual signals:

• Engagement. Usage volume and breadth, login patterns, feature adoption, who has stopped showing up in the data.
• Relationship. Champion behaviour: reply latency, meeting attendance, seniority drift (your contact getting more junior over time is a signal people miss for years), tone in writing.
• Commercial. Procurement appearing early, budget language in routine calls, invoice queries, downgrade questions, the contract being read closely for the first time.
• Strategic. Their business, not yours: leadership changes, cost mandates, restructures, M&A, a pivot that makes your use case matter more or less.

The reason for the families: single signals lie; convergence tells the truth. A quiet champion might be on holiday. A quiet champion plus an early invoice query plus a new CFO is a pattern, and patterns across families are how real risk announces itself. Brief your assessments family by family and instruct the model to look explicitly for cross-family convergence; it's the difference between an anomaly list and an analysis.

Mode A: the single-account deep dive

When an account needs proper attention, a flag fired, a renewal approaches, something feels off, Mode A is the full assessment: everything you have, organised by the four families, into a reasoned analysis. Two instructions make it rigorous. First, reasoning before conclusions (Module 02): you need a logic chain you can audit, not a verdict you must take on faith. Second, and non-negotiable: the disconfirming pass: "What in this data argues against your conclusion? What's the strongest innocent explanation?"

The disconfirming pass exists because you usually run an assessment already suspecting the answer, primed to accept whatever confirms it. Asked only "is this account at risk?", the model happily assembles the prosecution's case from evidence you selected because you were worried. Forcing the defence's case is the bias correction, built into the prompt where you can't forget it. Half the time it deflates a false alarm; the other half, the innocent explanations fail and you act with real confidence. Either result is worth one paragraph.

One more discipline: assess trajectory, not snapshot. "Usage is 60% of licence" means nothing on its own; "usage was 85% two quarters ago" is the actual finding. Date everything you paste.

Mode B: the portfolio triage

Mode A doesn't scale: you cannot deep-dive twenty accounts a week, and the account that kills your year is usually the one you weren't deep-diving. Mode B is the answer: the same four families, compressed, across the whole book, every Monday, in thirty minutes. Input: the weekly exports you already have. Output: a ranked watchlist, what changed since last week (the highest-value line in the whole report), and which accounts have earned a Mode A this week.

The design goal of Mode B is sustainability, not depth. A risk process you run brilliantly once a quarter is worth less than a decent one you run every single Monday, because churn signals appear on their schedule, not on yours. Mode B is the radar; Mode A is the inspection. The radar's job is to never be switched off.

Worked example: the account that felt fine

Includes vault prompts: Churn risk assessment (Mode A) · Portfolio triage (Mode B)

The lesson

The same signals, read the other way

Most CSMs are excellent at spotting danger and oddly blind to opportunity, for an understandable reason: risk shouts and opportunity whispers. A churning account generates escalations and red dashboards; an account quietly ready to grow generates nothing at all unless someone is looking. Here's the reframe that makes this module cheap to run: expansion signals live in exactly the data you're already scanning for churn. A new team appearing in the usage logs, a stakeholder from an unfamiliar department joining a call, an initiative announced in their results: the same Monday scan that protects your book can grow it, if you instruct it to read both ways.

And the commercial truth worth saying plainly: for most mature books, expansion is where a CSM's revenue impact actually lives. Defending the base is the licence to operate; growing it is the career.

The whitespace map

Whitespace is the gap between what they bought and what they could use, but the useful version of the map isn't a product checklist. The vault prompt crosses two lists: what you haven't sold them, against what they've told you hurts, harvested from QBR notes, ticket themes, strategy statements, and stated objectives. Every intersection is a candidate; most candidates are noise.

The ranking rule is the whole discipline: order by their problem severity, never by your deal size. The biggest licence uplift attached to a mild inconvenience will lose to the modest add-on that removes their team's weekly nightmare, every time, because customers fund pain relief, not product breadth. A map ranked by your revenue reads like a sales territory plan; a map ranked by their pain reads like advice. Only one of those gets you invited back.

Signals without the ceremony

You don't need a quarterly expansion ceremony; you need three standing questions added to the weekly scan. Who is new? Unfamiliar names in usage data or meeting invites mean your product is spreading beyond its original boundary, the single most reliable expansion precursor there is. What did they just announce? New initiatives, new markets, new leadership priorities are new problems, and new problems re-rank your whitespace map. What are they working around? Tickets that describe manual workarounds, exports into spreadsheets, "is there a way to..." questions: each one is a customer describing, in their own words, the gap a product you haven't sold them was built to fill.

When a signal matches a whitespace candidate, you have a live opportunity. What you do next is not "tell sales"; it's Part 4.

The champion business case

Expansion deals are closed by your champion in a meeting you're not in, armed with whatever you gave them. The deliverable isn't a pitch, it's ammunition: a one-page case in their language, against their objectives, with their numbers: the problem as their team feels it, the cost of today's workaround, what changes, the effort honestly stated.

The quality test is unforgiving and beautifully simple: would your champion forward it without editing it? Every sentence that sounds like vendor copy is a sentence they'd have to rewrite, and every rewrite is friction between you and the deal. If the case reads like something their own strategy team drafted, it travels upward on its own; the vault prompt builds to exactly that standard, and the AI does the structural heavy lifting in minutes once you've fed it what only you know about their world.

Worked example: from log file to live opportunity

Includes vault prompts: Whitespace and expansion analysis · Champion enablement pack

The lesson

Prompts are tactics. A system compounds.

Everything before this module made individual tasks faster. This module is about what separates the CSM who "uses AI sometimes" from the one whose entire week runs differently: the first owns some prompts, the second owns an operating system. The difference is compounding. A prompt saves you forty minutes once; a system saves them every week, feeds its own outputs into its next inputs, and gets sharper as your library matures. Eight modules of techniques are about to become three components: a library, a cadence, and a set of automation judgements.

The library: organised for Tuesday, maintained for March

Your library has two failure modes, both organisational. The first is filing by tool: a Claude folder, a Copilot folder. Useless, because on Tuesday at 14:00 you think "I need to prep this call", not "I need a Claude prompt". File by workflow: call prep, communication, risk, expansion, internal. Tool notes live inside each entry.

The second failure mode is rot. Models change quarterly, your accounts change monthly, and a prompt that was excellent in January can be quietly mediocre by June without announcing it. The fix costs one line per entry: a last-tested date, plus a note of which model and a link to one example of good output. Anything untested in a quarter gets re-run through your Module 03 personal benchmark. A library with dates is an asset; a library without them is a folder of expired assumptions wearing the costume of one.

The cadence: the calendar is the system

Systems live or die on schedule, not on enthusiasm. Two recurring blocks do almost all of the work. The keystone is the Monday portfolio briefing, thirty minutes, before the inbox wins: Mode B triage across the book, expansion questions on (Module 08's three questions), output ranked into "what changed since last Monday". This one habit feeds everything downstream: the accounts flagged become your Mode A list, the briefing context flows into every call prep this week, the expansion signals queue your whitespace work. Highest ROI of anything in this course, and it costs half an hour you currently spend reacting.

The closing bracket is the Friday self-retro, ten minutes with the vault's coaching prompt: what worked, what you avoided, what one thing changes Monday. It's also when the library gets its maintenance: any prompt that disappointed this week gets its fix folded in while you still remember why. Two blocks, forty minutes total, and your week now has an intelligence system with a heartbeat.

Automation: assemble by machine, decide by human

Once the cadence is habit, the temptation is to chain it: exports flowing automatically into triage, flags into briefs, briefs into drafts. Some of that chain is genuinely worth building, and one rule keeps it safe: map the workflow on paper before automating any of it. Every step, every input, every decision point, on one page. If you can't draw it, you don't understand it, and automating a workflow you don't understand just produces mistakes at machine speed.

The paper map also shows you where the checkpoints belong, and the dividing line is always the same: automate assembly, never judgement. Gathering the exports, applying the placeholder pass, running the triage prompt, formatting the watchlist: assembly, automate freely. Deciding which flagged account earns a Mode A, what the intervention is, whether the expansion case goes out this week with that escalation open: judgement, and every judgement point needs a human checkpoint where the chain stops and waits for you. The goal was never a machine that runs your book; it's a machine that sets the table so thoroughly that your judgement is all that's left to add.

Worked example: one week on the operating system

Includes vault prompts: Weekly portfolio briefing · Voice-of-customer synthesis

The lesson

The inversion

Here's what actually happens when you implement everything in this course: the routine work compresses, and what remains of your job is almost entirely the human part. The reading of rooms. The judgement calls. The trust. Which produces the inversion this final module is built on: the more fluently you use AI, the more your value concentrates in the things it cannot do, and the more deliberately you must protect them. Customers were never paying for your typing speed. They were paying for someone accountable who knows them, and that, in an AI-saturated market, just became the scarcest thing a vendor can offer.

The do-not-delegate list

Some work should never be AI-drafted, not because the model would do it badly, but because the authorship is the content. The test for the list: does the value of this communication depend on the customer believing a specific human took the time? If yes, the time is the point, and delegating it deletes the message while keeping the words. The standing entries:

• The apology after a serious failure. An incident summary can be drafted (Module 06); the apology that carries it cannot. Customers can survive your product failing; they cannot survive discovering your contrition was generated.
• Live negotiation. Rehearse beforehand with the vault's prompt, relentlessly, but the room is yours alone. Reading a pause, sensing when to hold silence, deciding in the moment to give ground: improvising from a machine mid-conversation outsources the one skill the conversation exists to test.
• Anything about a person's situation. A contact's redundancy, a champion's illness, a congratulations that matters. Three human sentences beat three perfect paragraphs.
• Relationship repair. When trust itself is the broken thing, the labour of the message is the repair.

Notice what's not on the list: almost everything else. The list works precisely because it's short, a few protected categories, fiercely held, while the other 90% of your output gets the full leverage of the previous nine modules.

The question, and the answer you've earned

Sooner or later a customer asks it, sometimes curious, sometimes pointed: "Did you write this?" The two losing moves are denial (one metadata accident from being a trust crisis) and apology (which concedes something improper happened). The winning answer is the one this whole course has been constructing: "I use AI the way I'd use a junior analyst: it assembles drafts and does the legwork, and every judgement, every fact, and every word that reaches you is mine, because I edited it, verified it, and chose to send it."

That answer usually improves the relationship, because the real question was "am I still dealing with someone accountable?", and you've just answered yes with evidence. You're entitled to it exactly as long as the workflow behind it is true, which is why Module 04's output discipline was never a compliance chapter; it was the foundation of this sentence.

Turning fluency into career capital

You now run a measurably different operation from most of your peers. Two moves convert that into career value, and secrecy is not one of them. First, quantify your story: the Module 01 audit gave you a baseline; the calculator gave you a recovery estimate; six months of the operating system gives you real numbers. The narrative leadership remembers is specific: "I recovered roughly six hours a week, and reinvested them in face time with my top accounts; here are the two saves and the expansion that came out of it." Recovered hours are the input; the saves and growth are the story.

Second, teach it. Run the lunch-and-learn, share the library, walk a colleague through their first Mode B. Counterintuitive but reliable: giving the methods away beats hoarding them, because the hoarder is a CSM with a trick, while the teacher becomes the person the organisation associates with the entire capability. In a market where every CS team is being asked "what's our AI plan?", being the answer to that question is worth more than any private edge.

Worked example: the question, live

That's the course. Ten modules, one thesis, proven in the last place it gets tested: AI for the assembly, you for the judgement, and the human element not merely intact but more visible than it ever was when it was buried under forty minutes of call prep. Finish the knowledge checks, claim the certificate, and go be the CSM the next five years belong to.

Includes vault prompts: Objection and negotiation rehearsal