Eleven sequences for the moments that decide accounts. Each step tells you when to run it and why, and opens the exact prompt, ready for your AI tool. Your progress is saved in this browser.
Foundation is the one to do first: ten modules, about two and a half hours of reading, at your own pace. Advanced and Leaders are there when you want to go further or lead a team.
No account and no cookies. Your progress is saved in this browser only, so use the same browser to keep your place. Finished Foundation? Keep it going with the 30-day AI habit.
The complete course. Ten modules of how to use AI well and safely in your day-to-day CS work, from prompts to call prep to churn risk. If you only do one course, do this one. About 2.5 hours total, and useful from your first week.
Any CSM who wants to get genuinely good with AI without losing the human side of the job. No experience needed.
Ten short modules you do at your own pace. Each one teaches a real CS skill and ends with a knowledge check. Pass the checks and you earn the certificate. Everything uses real prompts you can take straight into your work.
Awarded on completion, with your name, a certificate ID and a line showing where to check it. Built to share on LinkedIn.
Optional next step. The builder's course, for CSMs who finished Foundation and want to go deeper. Design a version of AI that works the way you do, build custom assistants and a scoped agent, and share what you build with your team.
A CSM who has the basics and wants to go much further. Keen and curious, but not a developer. Everything is no-code or low-code.
Awarded when you pass all twelve knowledge checks. Your name, the issue date and a certificate ID.
Optional next step. A different job. For team leads and CS managers who finished Foundation. How to take a whole team from scattered, nervous AI use to a capability that is consistent, safe, and measurable, and prove the value upward.
Team leads, CS managers, and heads of CS. People responsible for a team as well as their own work. You do not need to be technical.
Awarded when you pass all nine knowledge checks. It records that you completed the Leaders course.
Each module puts AI to work on your own real accounts. Work through at your own pace and use the prompts live from day one.
Modules complete
No account, no cookies, and nothing you type leaves your browser. The trade-off: your progress lives in this browser, so if you switch device or clear your browsing data, it will not carry over. For a longer course, stick to the same browser to keep your place.
M01–M04 · the four modules every CSM needs before anything else
Why AI makes your best work better instead of replacing it, and where it fits in your week
The RCCO framework, and why generic prompts fail for CS work
Claude, ChatGPT, Copilot M365 and Gemini: how to choose among the tools your company has approved
What never to paste, how to anonymise, and how to stay on the right side of policy
M05–M08 · call prep, communication, churn risk, expansion
Pre-call briefs, stakeholder maps and ticket analysis, in a fraction of the time
QBRs, renewal stories, risk escalations, and editing out the AI voice
Four signal families and two ways to assess risk: one account, or your whole portfolio
Finding product gaps, spotting expansion signals, and writing business cases the buyer can forward
M09–M10 · build your operating system, hold the human core
From one-off prompts to a personal library and a weekly routine that keeps you informed
When not to use AI, how to stay trusted, and turning your AI skills into career capital
Why AI makes your best work better instead of replacing it, and where it fits in your week
From what I’ve seen, a large part of a CSM’s week goes on the work around customer conversations: prep, decks, emails and reporting. The conversations themselves are where renewals are saved, and they are the first thing to get squeezed. This module is about getting more of your week back for the part that matters.
Before you change how you work, be honest about where your time goes. From what I’ve seen, much of a CSM’s week goes on everything around the customer conversations: prep, summaries, decks, emails, CRM updates, internal reporting and clearing the inbox. Measure your own week before you change it. Your numbers are the ones that count.
Here is the hard truth. The customer conversations are where renewals are saved and expansions start, and they are the first thing to get squeezed. When an escalation lands, the admin does not shrink. Your thinking time does. You walk into calls less prepared, and you end up reacting instead of leading. Every CSM knows this feeling. Most of us have stopped noticing it.
Using AI well means moving hours away from the admin and back into customer conversations. Not by cutting corners on the prep, but by changing your part in it.
Before you read on, work out your own number. Step 1. How many hours does a normal week cost you TODAY, working the way you work now, without AI? Honest averages, not worst weeks:
Step 2. How good do you think you will get? (Be honest. Module 02 onwards does the heavy lifting.)
Keep that number in mind. The rest of this course shows you how to win those hours back.
The most useful way to think about AI: you have just been given a capable junior analyst. They work quickly, can write in most styles and turn a first draft around in seconds. They never get bored of dull work.
But they have three big weaknesses. They know nothing about your accounts until you tell them. They do not care whether they are right, so they will give you a confident answer even when the facts do not back it up. And they are not accountable. When the work goes out, it has your name on it, not theirs.
Treat AI like that analyst and most things fall into place. You would not give a junior a task with no background and expect a great result, so brief it properly (Module 02). You would not send their first draft without reading it, so check and edit everything. You would not send them to a negotiation on your behalf, so keep the human work human (Module 10). And you would not explain the same task every week, so save your best briefs and reuse them. That is all a prompt library is (Module 09).
Brief
Who it is, the background, the rules and what you want back.
Assemble
Turns a pile of notes into something useful. Drafts. Spots patterns. In seconds.
Verify, edit, own
Read every line. Catch anything made up. Send it with your name on it.
Your job moves from doing the work to directing it and owning it.
Your job moves from doing the work yourself to directing it and checking it, which is what senior people already do. Think about what your VP actually produces in a week: very little. Their value is their judgement on other people's work. AI gives every CSM a small team to direct. The CSMs who do well will learn to manage it like one.
Forget the big promises. In CSM work, AI is really good at four types of task. You will recognise your week in all of them.
Turning a lot of information into what matters. Fifty tickets into five themes. A year of call notes into the story of the relationship. A 40-page contract into the six clauses that matter. This is where most of the hours are, because summarising is most of what prep is.
A solid first version of anything that follows a familiar shape: the QBR story, the escalation email, the exec summary, the follow-up. The prompt gives it the shape. You make it sound like you.
Noticing things spread across more information than one person can keep in their head: the same complaint in three accounts, engagement dropping off in a way that often comes before churn, a stakeholder going quiet.
Playing the sceptical CFO, the procurement lead or the frustrated IT director, so you hear the hardest objection before you walk into the room, not for the first time in it.
Using AI well means knowing where it goes wrong as much as where it helps. Four mistakes cause almost every AI embarrassment at work.
If there are gaps, AI fills them, and it sounds convincing. The catch: tell it not to ("do not invent anything, list what is missing as open questions") and check every fact you did not give it yourself.
It cannot know your champion is leaving, or that the CFO hates the word "partnership". The catch: giving it the background is your job. A thin brief gets you a generic answer, every time.
Ask for "a good renewal email" and you get the same email everyone gets. The catch: the more specific you are, the more specific it is. The difference is almost always in what you give it, not which tool you use.
AI will not be in the room when it goes wrong. The catch: a rule you will see again in Module 10. Never send anything you could not stand behind, line by line, if someone asked "did you write this?"
The task: your manager wants a quick health summary of an account before an internal review, and it is due in an hour.
You spend 45 minutes re-reading notes and tickets, write eight bullets from memory, and miss the pattern in the support data because there was no time to look. It does the job, but it costs you.
You type "write a customer health summary for a software account" and get 400 words of confident, generic filler that could describe any account in the world. You spend 20 minutes rewriting it and trust it less than your own bullets. This is why most CSMs quietly give up on AI. Not because AI cannot do better, but because it was never given the chance.
Read it again. Not one sentence is about this account. Every line could be about any customer, which means none of it tells you anything.
You paste in your real material, the last three call summaries, the ticket export and the usage trend, with a proper brief (you will build it in Module 02). Ninety seconds later you have a clear draft: status, what has changed, top risk, top opportunity and the recommended next step. You fix one incident it got wrong, add the politics only you know about, and send it. Twelve minutes from start to finish, and it is better than the Level 0 version because it actually covered everything.
The difference between Level 1 and Level 2 is not talent, and it is not the tool. It is how you brief it, set the rules and check the result. Anyone can learn that, and it is what the rest of this course teaches.
Part A, the audit. Track one full week in five groups: call prep, writing, analysis, admin and customer conversations. Mark each task H (needs you) or A (AI can help). Most CSMs find more than 12 hours of A tasks. That is the time you can win back. Write the number down, because you will use it again in Module 10.
Part B, the level test. Take one real A task from your list and try the worked example yourself. Do it by hand (Level 0), then with a one-line prompt (Level 1). Keep both. After Module 02 you will do it with a proper brief (Level 2) and compare all three. That is your own before and after, on your own work.
Five questions based on real situations. Answer them all, then see how you did. You need every answer right to pass, and you can retake it as often as you like.
1. You ask AI to summarise a renewal call. The summary reads well and includes a line saying the customer confirmed budget for the expansion. Nobody said that on the call. What kind of failure is this?
2. A CSM has used AI for six months. Their renewal rate is up. But they are slower on calls without a script, rely heavily on their prep notes, and struggle when a conversation goes off track. What is happening?
3. Your AI pre-call brief says the CTO has always been a strong supporter. You remember a conversation where they were clearly lukewarm. What do you do?
4. In a sensitive renewal conversation, the customer asks: "Did you write this, or did AI?" What is the right answer?
5. AI handles the admin: drafting, summarising and analysing. So which part of your job becomes more valuable, not less?
Score: 0/5 ·
The RCCO framework, and why generic prompts fail for CS work
Every good prompt has four parts: Role, Context, Constraints, Output. Get them right and the model writes like someone who knows your account. Skip them and you get an email that would work for any account, which means it works for none.
Ask any model for "a poem about the sea" and you will get something decent. For generic tasks, average is fine. Ask for "a renewal email" and you will get something that looks decent, and that is the trap. An email that would work for any account works for none. Average is not good enough in CS, because the whole value of what a CSM writes is that it fits this customer, this history and this moment.
The output can only be as specific as what you put in. "Write a QBR summary" gets you the average of every QBR ever written. Add your account's real year, their objectives in their own words and the sensitive incident from March, and it starts to sound like someone who knows the account. In effect, it does: you briefed it.
So this module is not about "prompt engineering" in the sense of magic words. It is about briefing: the same skill you would use to hand work to the junior analyst from Module 01. Four parts, every time.
"You are a senior CSM preparing for a renewal call with a risk-flagged account." One line sets the vocabulary, the depth and what the model thinks is worth mentioning. Match the role to the work. There is no need to flatter the model.
This is where CSM prompts succeed or fail. The model knows nothing about your accounts. Any fact you do not give it, it will either leave out or make up. So give it the call notes, the ticket export, their objectives, the thing that went wrong in March. This is why two CSMs using the same template get completely different results.
The guard rails. The most valuable constraint in all CS prompting is: "Do not invent any facts, list missing information as open questions." Then add length limits, tone, UK English and format rules.
The shape of what you want back: "a one-page brief with these six sections", "a table with action, owner, date", "two drafts". It makes the result usable straight away and trains your eye to check it in seconds.
Could a smart stranger do this task with only what I have written here? If not, neither can the model.
Once you think in these four parts, spotting the problem is easy. Output too shallow? Role or Context. Confidently wrong? Constraints. Rambling or hard to use? Output. Generic? Context, nearly always Context.
The biggest difference between a Level 1 user and a skilled AI user is what they do after the first response. The Level 1 user judges it: good or bad, keep or bin. The skilled user treats it as the junior analyst's first draft and starts giving direction. Three follow-ups do most of the work.
The model fills gaps without telling you. This question makes it show you. Use it on anything important and you will find two or three assumptions you would never have spotted, and one of them is usually wrong.
Models waffle by default. Saying what must survive the cut gets you a shorter version that keeps the parts that matter. Senior readers get the short version. You keep the long one.
The cheapest challenge you will ever get. Think the account is safe? Ask for the case that it is about to churn. Somewhere in that argument is the objection the customer's CFO was always going to raise.
This is also how prompts become reusable. When a follow-up fixes a problem that keeps coming up, add it to the original prompt as a constraint. Your prompts should keep improving. Module 09 turns that habit into a library.
For anything analytical, such as churn assessment, negotiation prep or prioritisation, add one instruction: "Show your reasoning before your conclusions." This does two things. First, the conclusion is often better when the model works through the logic instead of jumping to an answer (many current models now do some of this by default). Second, and more important at work: you can check it. A bare conclusion ("this account is high risk") is take it or leave it. Reasoning can be checked line by line, so a wrong assumption gets caught before it turns into a wrong recommendation in front of your leadership team.
Pair it with an instruction you will see again in Module 07: "What in this data argues against your conclusion?" You usually run an analysis because you already suspect the answer, so you are ready to accept anything that agrees with you. Asking for the counter-case corrects that bias, right there in the prompt.
The reasoning you see is the model's account of how it got there, not proof that it is right. Check it the way you would check a junior analyst's logic: are the facts you gave it used correctly, and do the conclusions follow? Well written does not mean accurate. The four failure modes from Module 01 still apply. Reasoning just makes them easier to find.
Which ONE change would improve this prompt most?
The task: your champion at a key account emails to say their new CFO is questioning the renewal cost. You need a reply that calms things down. Watch how the output changes as you add each part of RCCO.
A polite, generic defence of value that any vendor could send to any customer. It says "partnership" twice. Your champion forwards it to the CFO, and it confirms the CFO's doubts: this vendor just sends templates.
The tone improves straight away: the reply treats the champion as an ally who needs backing up, not a critic to defend against. The substance is still generic, because the model knows nothing about the account.
Now it is clearly about this account. It quotes the real outcomes, uses the champion's own words, and expects a finance-style objection because you mentioned the CFO came in to cut costs.
The result: a tight reply your champion can act on in sixty seconds, with two sentences written to be forwarded upwards, and every number traceable to what you supplied. Total time, including gathering the context: about eight minutes. The Level 0 version of this email used to take you forty, with no forwardable sentences, because under time pressure nobody thinks of the clever extra.
That is the module. The RCCO builder below puts the structure together for you, and the exercise turns it into a habit. From here on, every vault prompt you open is this framework in its work clothes.
Build a prompt from the four parts, then copy it straight into your AI tool.
Take a real email you sent last week, anonymised as in Module 04. Write an RCCO prompt to recreate it. Compare the AI version with yours, then combine the best of both. Most people find the AI version is better structured and theirs shows better judgement. That is the whole course in one exercise.
Includes vault prompts: Pre-call intelligence brief · Exec summary compressor
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. You run a renewal risk prompt using RCCO. The output includes specific competitor win-rate statistics you never gave it. Which RCCO part failed, and what is the fix?
2. "You are an assistant" vs "You are a senior CSM with ten years in complex B2B accounts, preparing for a renewal at risk." Which best describes what changes?
3. You have a solid first draft of a renewal risk email. The highest-value follow-up prompt is:
4. Why request step-by-step reasoning on a complex renewal risk assessment, rather than just asking for the conclusion?
Score: 0/4 ·
A way of choosing tools that works with whatever your organisation uses
Being good with AI is not about picking the one best tool. It is about routing: sending each job to the right tool in about five seconds. Three questions, in order, make the decision for you. Notice that "which model is cleverest this month" is not one of them.
Ask ten CSMs which AI tool is best and you will get ten declarations of loyalty: "I am a ChatGPT person", "our company is all-in on Copilot". Loyalty is the wrong way to think about it. A skilled CSM routes: different jobs go to different tools, and once the three questions are second nature, the decision takes about five seconds.
Sticking to one tool quietly costs you in one of two ways. Either you are pasting customer data into a tool that should not have it, or you are putting up with average output from a tool that was never built for the job in front of you.
The three questions, in strict order: where must the data stay, what kind of job is this, and where does the work live. That is the whole decision.
This question comes first because it is the only one you cannot fix afterwards. If the task involves customer data, you are choosing between the tools your organisation has approved for that data and everything else. The approved list is a fact held by IT, not a feeling. If you have not seen it, ask for it. That is your first action from this module.
Frontier assistants (the most capable general models) for deep thinking and quality long-form writing, when the thinking is the product. Embedded copilots when the work happens inside an app you already have open. Specialist CS platforms that already understand your data. For everyday work, ease beats brilliance: an 85% reply inside the Outlook thread beats a 95% reply that needed three copy-and-pastes.
If the work lives in Outlook, Teams or your CRM, start with the AI built into that tool. Only leave the app when the thinking is the product. And when a big new model comes out, do not chase it and do not ignore it: re-run your three most-used prompts, with anonymised inputs, and judge the accuracy, how much editing each needs and the reasoning.
Public rankings show how models do on average. Testing your own prompts shows what works for your job. Twenty minutes once a quarter, and your whole prompt library moves safely onto each new generation of models.
One practical point runs through all three questions: anonymisation (the placeholder scheme in Module 04) gives you far more options. A churn analysis about CUSTOMER_A with CONTACT_1_IT can go to whichever approved tool does the best analysis, because the obvious identifiers stayed with you. The routing questions get easier once those details are gone, but read what is left: placeholders reduce risk, they do not make text anonymous on their own.
Embedded. Microsoft 365 Copilot drafts in the thread with the history right there. If your company has approved Copilot for this kind of data, it stays inside your agreed Microsoft set-up (the tenant), and there is no extra effort. Check the approval rather than assuming it from the product name. A frontier model might write a slightly better paragraph, at ten times the hassle.
Frontier, anonymised. This is heavy summarising and thinking work, exactly what the strongest reasoning model you are approved to use is for. Export the tickets, apply the placeholder scheme, and get a deep analysis back in minutes.
Specialist tool. Your CS platform answers from the system of record in one query. Sending this to a frontier model means pulling together context the CRM already holds, to get an answer it already knows.
Frontier, full process. Highest stakes, and the thinking is the product: a briefed prompt, a pass for evidence against your view, two drafts, your judgement on every line. This is the 10% where the best available model earns the trip.
Four decisions, perhaps twenty seconds of thought in total. That is the skill: not knowing every model's benchmark scores, but knowing your three questions inside out.
Best route?
Best route?
Run the same vault prompt (pre-call brief, anonymised as in Module 04) on two approved tools you have access to. Score each output out of 10 for accuracy, structure, tone and usefulness. Keep the scorecard. It is the start of your personal benchmark.
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. You are drafting a sensitive renewal update inside an existing Outlook thread. You can use a frontier AI model in a browser tab or Microsoft Copilot built into Outlook. What matters most in your choice?
2. A major new AI model is released with impressive benchmark scores. What should a skilled CSM do first?
3. For post-call notes you have two options. Tool A is a frontier model in a browser tab that writes noticeably better. Tool B is built into your CRM with one-click access. Which do you choose, and why?
4. Your company has approved one AI tool for customer data. A colleague argues that a different tool writes significantly better renewal emails. What do you do?
Score: 0/4 ·
What never to paste, how to anonymise, and how to stay on the right side of policy
A hundred great AI-assisted briefs build your reputation slowly. One customer name in the wrong tool can undo all of it in an afternoon. That imbalance decides whether you get to keep using everything else in this course.
Data safety is not the boring compliance chapter. It is the risk that decides whether you get to keep doing everything else. That is why this module comes at the end of Foundation, before any exercise touches real account data.
Things only go wrong in two places: what goes in (the data you paste, upload or refer to) and what comes out under your name (the drafts you send, the facts you repeat, the promises you did not notice). Neither is difficult. Both need to become habit.
Before anything goes near a model, classify it. Four classes cover everything a CSM handles.
Names, emails, job titles, opinions, anything that identifies a real person. Under GDPR, pasting it into an AI tool counts as processing personal data, full stop. "The vendor does not train on my data" answers a different question. What matters is the data processing agreement (the vendor's contract on handling your data) and the approved list.
Pricing strategy, legal positions, anything under NDA, plans not yet announced. Only one place: an approved enterprise tool, anonymised, with explicit clearance. Your own discount floor or walk-away number never goes in at all: the number is the secret. Never a personal account. The convenience is never worth the legal risk.
Credentials, API keys, architecture diagrams, security questionnaire answers. Never. There is no anonymised version of a password.
Ticket themes, usage patterns, meeting structures, your own drafts. Most CS work falls here. Once it has been through the placeholder pass, it can go to whichever approved tool does the job best.
The approved tools list: a real, named list held by your IT or security team. If you have not seen it, ask for it today. The free version of any tool, and any personal account, is off the list by definition.
Done badly, anonymisation means deleting things, which ruins the analysis: a churn assessment where every person is "[redacted]" cannot work out who influences whom. Done well, it means consistent placeholders: CUSTOMER_A for the account, CONTACT_1_IT and CONTACT_2_FINANCE for people (the role on the end keeps the politics), COMPETITOR_X for rivals. The model can still reason about the relationships, because they are still there. Placeholders reduce risk, but they do not make text anonymous on their own: a role, a date or an incident can still point to the customer, so read it through before you paste.
Keep a key document (placeholders matched to real names) in a local file that never goes near an AI tool. Swap the names before the text goes into the prompt: find-and-replace takes ninety seconds. And watch the three leaks people forget: transcripts (full of names), exports (columns you did not scroll to, email signatures) and screenshots (tab titles and the taskbar around what you meant to share).
The habit to build is the ten-second check. Would you be comfortable if this exact text appeared in an email to the customer's legal team? If you hesitate, that tells you something.
The second area gets less attention but causes just as much trouble. Three habits.
Every fact, figure, date and name in an AI draft gets checked against the source before it leaves your hands. Made-up details do not announce themselves. They sit in well-written sentences next to true ones.
AI drafts love generous closing lines: "we will have that to you by Friday", "happy to include that at no extra cost". Before anything goes out, read it for promises you did not agree to.
Your name is on it. The standard from Module 01, repeated in Module 10: never send anything you could not defend line by line if someone asked "did you write this?"
The task: a churn-risk analysis on a strategic account, using a 180-row ticket export and your call notes. Here is the process in action.
The export has four named contacts, two email signatures with mobile numbers, and one ticket where your champion criticises her own CIO by name. The call notes mention the customer's unannounced restructure. Pasting this anywhere, even into an approved tool, fails the ten-second check on the restructure alone.
Find-and-replace in a text editor: the account becomes CUSTOMER_A, and the four contacts become CONTACT_1_CHAMPION, CONTACT_2_CIO, CONTACT_3_IT, CONTACT_4_PROCUREMENT. Signatures and numbers are deleted (they add nothing to the analysis). The restructure stays in, described as "an unannounced internal reorganisation", because the analysis needs it but the details do not travel. Key document saved locally.
The prepared text goes to your strongest approved tool with the Module 07 prompt. The analysis comes back sharp, with the politics intact: "CONTACT_1_CHAMPION's criticism of CONTACT_2_CIO suggests the relationship risk sits above your champion, not below." You check the two statistics it quotes against the export (both real), swap the placeholders back using your key, and brief your manager. That is the whole extra step.
It takes about three minutes, and it could save you from a very uncomfortable meeting.
What's the flaw in that reasoning?
Which routing is right?
Take a real (sensitive) account summary. Make a fully anonymised version using the placeholder scheme. Run a churn-risk prompt on it and check the analysis still works. This becomes your reusable anonymisation template.
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Before you paste anything into an AI tool, which single question matters most?
2. A colleague says anonymisation is "theatre": "the model does not know who this is anyway." What is wrong with this reasoning?
3. Your company has no AI usage policy yet. The most responsible approach is:
4. You find a prompt template in a shared team folder. It contains real customer contract values and health scores as example inputs. What do you do before using it?
Score: 0/4 ·
Pre-call briefs, stakeholder maps and ticket analysis, in a fraction of the time
If you have five important conversations a week and spend forty minutes preparing for each, call prep is one of the biggest chunks of your calendar. AI can shorten the gathering and summarising. Time your own prep before and after, so you know what it saves you. Deciding what matters stays with you.
If you have five important conversations a week and forty minutes of proper prep for each, call prep is quietly one of the biggest chunks of your calendar. You do it often, it pays back well, and a customer can tell within ninety seconds whether you prepared or not.
Walk into every call knowing more than anyone expects you to. Not more data, but a clearer picture: what changed, what it means, and the one question that shows you have been paying attention.
The pre-call brief in the vault uses the same six sections every 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 feels off, however small), opportunity (anything that looks like expansion), and the one question (the one thing to ask that this customer would not expect a vendor to know to ask).
Keeping the structure fixed is the whole trick. By the fiftieth brief with the same layout, you are no longer reading it, you are scanning it, and anything unusual jumps out like a wrong note in a song you know well. Fixed structure, quick scanning, and you spot patterns for free.
A good brief uses your internal data. A great one adds two more layers on top, and the third is where the real value is.
The connection pass
"Connect what is happening in their world to what is happening in our account. What should I infer, and what should I ask?" The question a good strategic adviser always asks.
Public intelligence
Their results, leadership changes, product launches, industry news. Five minutes of searching, pasted under the base brief.
The base brief
Call notes, tickets, usage and CRM history, run through the skeleton prompt. The starting point anyone can reach.
Each layer holds up the one above. The real value is at the top, but only because the bottom two are there.
Their CEO announced "ruthless cost discipline" in October and your expansion conversation stalled in November? Put together, they tell one story. The CSM who walks in already understanding that story has a very different conversation from the one who asks "so, how is everything going?"
Plots everyone who matters by influence and how they feel about you, every quarter and after any reorg. Read it honestly: the most dangerous thing on it is the gaps, the influential roles where you have no relationship at all. Accounts are rarely lost to the sceptic you were managing. They are lost to the budget holder you never met.
Separate everyday friction from real strategic risk. Fourteen password resets are friction. The real signals are in trend (volume creeping up), tone (frustration showing up from people who are usually patient) and seniority (a director filing tickets personally is not a ticket, it is a message). Tell the model to make this split, or it will summarise the password resets.
The call: a monthly check-in with a strategic account, renewal in five months. Watch the layers build up.
The last two call notes, the ticket export and a usage summary go into the skeleton prompt (with placeholders applied as in Module 04). Out comes the structured brief. Status: stable but quiet. Since we last spoke: usage flat, one new integration ticket. Risk signals: the champion's replies have slowed from same-day to four days. The skeleton only picks up that last one because response times are in your notes.
A search on the account turns up last week's interim results: a revenue miss, and a new CFO starting next month, announced with a remit of "operational efficiency". Paste it under the brief.
"Connect their world to our account." The output: a champion who has gone quiet, plus a new CFO brought in for efficiency, five months before renewal, suggests your champion may be busy protecting their position internally, and every vendor contract is about to be looked at again. The inferred risk: the renewal turns into a procurement exercise. The one question: "I saw the announcement about your new CFO; how is the team preparing, and what will that change for how decisions like ours get reviewed?" You walk in as the vendor who already understands their quarter. The unprepared version of you would have opened with the weather.
What does the connection pass tell you?
Which one is the strategic signal?
Pick your next real call. Run the full brief workflow: base brief, public intelligence layer, connection pass. After the call, score the brief. What did it get right, what did it miss, what surprised you? Then improve your version of the prompt.
Includes vault prompts: Pre-call intelligence brief · Stakeholder map builder · Support ticket pattern analysis
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Your AI pre-call brief covers recent support activity, stakeholder sentiment, open commitments and risk signals. Which part needs the most checking before you act on it?
2. You use a fixed six-section skeleton for every pre-call brief. A colleague says you should vary it by account to keep it fresh and relevant. Why is keeping it the same the better choice?
3. Your ticket analysis for a large account concludes: "primary ongoing challenge is onboarding complexity." Onboarding finished six months ago. What most likely happened, and how do you fix it?
4. An hour before a QBR, your champion calls to say a senior executive you have never spoken to is joining. What do you do?
Score: 0/4 ·
QBRs, renewal stories, risk escalations, and editing out the AI voice
Communication is what your whole job is judged on. AI gives every CSM the same tireless first drafter, so inboxes are filling up with writing that is fluent, polished and strangely identical. The writing that works sounds like a real person who knows this particular customer. AI brings structure and speed. You bring voice and specifics.
Most of your work is invisible to the people who decide your account's future. They do not see the triage, the internal escalations or the fifteen-minute briefs. They see what you send: the QBR, the renewal case, the email after the difficult call. That is how every other skill you have gets judged.
You get a first drafter that never gets tired, but so does every other CSM, so it is easy to end up sounding like everyone else. This module comes down to one split: AI brings structure and speed, you bring voice and specifics.
The usual QBR mistake is starting with the template: open last quarter's deck, update the numbers, and present data with no meaning. The fix is to insist on the story before the deck exists. The vault's QBR prompt asks for the story written out in prose: where this account started the quarter, what actually happened, what it means, and where we go next, with every claim backed by evidence. Only once that story rings true do you ask for the slide structure.
If you deleted every chart, would the meeting still have a point? If yes, the charts become evidence for an argument rather than a replacement for one, and the customer leaves remembering a story about their own progress. That is the only thing anyone remembers from a QBR.
Hard messages (risk escalations, bad news, pushing back on an unreasonable request) sit somewhere between being as clear as possible and protecting the relationship as much as possible. The mistake is asking AI for the message. The technique is asking for two drafts at different points on that scale: one direct and straight to the point, one softer and warmer, both with the same facts and the same ask.
Where you land on that scale is not a writing decision. It is a relationship decision, and only you know the relationship. The engineer who has been burned needs the direct draft. The sponsor who is politically exposed needs the softer one. Two drafts cost the model nothing and hand the one judgement that matters back to the only person who can make it. One more habit: write for the forward. Assume your email will be sent upwards with one line of comment added.
AI writing has tells, and your customers are learning to spot them as fast as the models get subtler. The 2023-era tells ("delve", "leverage" as a verb, "I hope this email finds you well") still turn up, but the leading models in 2026 give themselves away mostly through structure rather than word choice. The pass below deals with both. It takes three minutes.
"I hope this email finds you well." "Delve." "Leverage" as a verb. Less common now in the leading models, but still found in cheaper tools and default settings. If a phrase could open any email to any customer from any vendor, cut it.
The balanced opening that lists three things you'll cover. A sentence built on three of everything in every paragraph. "It is not just X, it is Y." "Ultimately, ..." as a conclusion. The closing paragraph that gives equal weight to both sides. The 2026 models do these almost without being asked, and they read as AI faster than any single word does.
The specific date, the colleague's actual name, a reference to what they said on Tuesday's call. One real detail is worth three paragraphs of polish, because details are the one thing the model cannot supply and the customer cannot miss.
The quickest authenticity test there is: anywhere your real voice would not say it, rewrite it until it would. Teach the model your voice up front by pasting in a sample of your own writing, but still read it aloud at the end.
The situation: a data-sync failure on your side corrupted a week of the customer's reports. The fix is in, but trust has taken a knock, and this email matters.
"I hope this email finds you well. I wanted to reach out regarding the recent issue you may have experienced. We deeply value your partnership and are committed to delivering excellence..." Three paragraphs in, the incident still hasn't been named, there are no dates, and the apology could be from any vendor about anything. The customer reads it for exactly what it is: nobody home.
Two drafts requested with the full incident context: one as direct as possible, one warm. This customer's sponsor is a former engineer who has been generous throughout the incident, so the final version leans direct, with one human line kept from the warm draft.
"Hi Sarah, the sync failure between the 4th and the 11th corrupted the weekly reports your team pulled in that window, and that's on us. Here's what happened, what we've fixed, and how we'll catch this class of fault before you ever see it again..." Names, dates, clear ownership, exactly what went wrong in one paragraph, how it will be prevented in another, and a closing line about the patience her team showed on Thursday's call. It took ninety seconds longer to write, and it reads completely differently.
What does the de-AI pass do here?
Which draft should you lean towards?
Take your next real QBR. Run the narrative prompt before you build a single slide. Tell the story to a colleague in 60 seconds. If they can repeat it back, build the deck. If not, rework the story, not the slides.
Includes vault prompts: QBR narrative builder · Renewal value case · Risk escalation (two-draft) · Meeting notes to actions
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Your AI-drafted QBR story opens with three paragraphs of industry context and product background before it gets to the customer's results. What caused this, and how do you fix it?
2. You need to escalate a churn risk to your VP. Which approach gives you the most useful message?
3. What is the "de-AI" editing pass mainly for?
4. You are writing a renewal business case that your champion will forward to their CFO. The guiding principle is:
Score: 0/4 ·
Four signal families and two ways to assess risk: one account, or your whole portfolio
No account leaves on the day it leaves. The decision was usually made quietly, two or three quarters earlier, and the signals were in your data the whole time. This module is about closing the gap between when a signal appears and when you act on it.
No account leaves on the day it leaves. The decision was made quietly, inside the customer, often two or three quarters earlier, and the signals were in your data the whole time: a champion whose replies got slower, a procurement question that came early, a usage line that started to dip. Run a post-mortem on any lost account (the vault has the prompt) and the most painful column is always the same: the gap between when each signal first appeared and when someone first acted on it. That gap is detection lag, and shrinking it is what this module is for.
AI cannot tell you whether an account will churn. But it can read more signals, more consistently and more often than you can, so they reach you while there is still time to do something.
Risk signals come in four families, and the families matter more than any single signal. Watch them together, not as a checklist.
Usage volume and breadth, login patterns, feature adoption, and who has stopped showing up in the data.
Champion behaviour: how long replies take, meeting attendance, your contact getting more junior over time (a signal people miss for years), and tone in writing.
Procurement turning up early, budget talk in routine calls, invoice queries, questions about downgrading, the contract being read closely for the first time.
Their business, not yours: leadership changes, cost-cutting drives, restructures, M&A (mergers and takeovers), a pivot that makes your use case matter more or less.
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 shows itself. Brief your assessments family by family and tell the model to look specifically for signals lining up across families. That is the difference between a list of oddities and an analysis.
When an account needs proper attention (a flag fired, a renewal is coming, something feels off), Mode A is the full assessment: everything you have, organised by the four families, turned into a reasoned analysis. Two instructions make it thorough. First, reasoning before conclusions (Module 02): you need a line of logic you can check, not a verdict you have to take on trust. Second, and not optional: the disconfirming pass, "What in this data argues against your conclusion? What is the strongest innocent explanation?"
You usually run an assessment already suspecting the answer, ready to accept anything that confirms it. Making the model argue the other side corrects for that bias, and it is built into the prompt so you cannot forget it. Sometimes it calms a false alarm. Other times the innocent explanations fall apart and you act with real confidence.
One more habit: look at the trend, not the snapshot. "Usage is 60% of licence" means nothing on its own. "Usage was 85% two quarters ago" is the real finding. Date everything you paste.
Mode A does not work across many accounts: you cannot deep-dive twenty accounts a week, and the account that ruins your year is usually the one you were not looking at closely. Mode B is the answer: the same four families, in short form, across your whole book, every Monday, in thirty minutes. Input: the weekly exports you already have. Output: a ranked watchlist, what changed since last week (the most valuable line in the whole report), and which accounts need a Mode A this week.
A quick scan across your whole portfolio, every Monday. Its job is to never be switched off.
A full deep dive on one account the radar flagged. Everything you have, every family, reasoned out.
A risk process you run brilliantly once a quarter is worth less than a decent one you run every Monday. Churn signals turn up on their schedule, not yours.
An account you would have called healthy makes the watchlist: your main contact's reply time has doubled over six weeks (relationship), and finance has raised two invoice queries in a month (commercial). Either one alone is noise. Two families moving together earns a Mode A.
All the data in, families separated, reasoning requested. The risk case: the contact is pulling back while finance looks hard at spend, a classic pre-churn pattern, with renewal in seven months. Then the disconfirming pass: the strongest innocent explanation is that their publicly announced finance-system migration explains the invoice queries, and your contact mentioned a department reorganisation in March that could explain the slower replies.
The assessment ends the only way an assessment should: a named action, an owner and a date. "This week: re-engage the contact with a value-led check-in (owner: me, by Thursday) and ask finance directly whether the queries relate to the migration (owner: me, on the same call). If the innocent explanations hold, downgrade. If not, save play, and we have gained a quarter of lead time." Turning an account red on a dashboard changes nothing. Giving someone an action and a date does.
What is the right reading?
What must the next line be?
Run Mode B across your real portfolio (anonymised as in Module 04). Take the top flagged account into a full Mode A assessment. Compare the result with how you ranked the accounts on gut feel before you started. The disagreements are where you learn the most.
Includes vault prompts: Churn risk assessment (Mode A) · Portfolio triage (Mode B)
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. You run a churn risk assessment on an account. The AI says medium risk. Then you remember that the product milestone they were waiting for shipped two weeks late, and you have not spoken to the champion since. What do you do?
2. Your portfolio triage prompt shows all five high-value accounts as green. What is the most important follow-up question?
3. After completing a churn risk assessment, you ask the model: "Now argue the strongest case that this account is NOT at risk." Which principle does this apply?
4. You gave the tool everything you know: champion resigned last week, usage down 20% over 90 days, renewal in four months. It still says medium risk. What is the right call?
Score: 0/4 ·
Finding product gaps, spotting expansion signals, and writing business cases the buyer can forward
Most CSMs are great at spotting risk and oddly blind to opportunity, because risk shouts and opportunity whispers. The good news: expansion signals sit in the same data you already scan for churn. The same Monday scan that protects your book can grow it.
Most CSMs are very good at spotting danger and oddly blind to opportunity. The reason is simple: risk shouts and opportunity whispers. A churning account brings escalations and red dashboards. An account quietly ready to grow brings nothing at all unless someone is looking. A new team in the usage logs, someone from a department you have not met joining a call, a new initiative in their results: the same Monday scan that protects your book can grow it, if you tell it to look both ways.
In most established books, expansion is where a CSM's real revenue impact lies. Keeping customers matters, but growing accounts is usually what gets you noticed.
Whitespace is the gap between what they bought and what they could use. But the useful version is not a product checklist. The vault prompt compares two lists: what you have not sold them against what they have told you hurts, pulled from QBR notes, ticket themes, strategy statements and stated objectives. Every overlap is a candidate. Most candidates are noise.
Rank by how much it hurts them, never by the size of your deal. The biggest licence uplift tied to a minor annoyance loses every time to the small add-on that removes their team's weekly headache. Rank it by your revenue and it reads like a sales plan. Rank it by their problems and it reads like advice, which is what gets you invited back.
You do not need a big quarterly expansion ceremony. You need three standing questions added to your weekly scan.
New names in usage data or meeting invites mean your product is spreading beyond where it started. That is the most reliable early sign of expansion there is.
New initiatives, new markets and new leadership priorities all bring new problems, and new problems change the order of your whitespace map.
Tickets about manual workarounds, exports into spreadsheets, "is there a way to" questions. Each one is the customer describing, in their own words, the gap that a product you have not sold them was built to fill.
When a signal matches a whitespace candidate, you have a live opportunity. Your next step is not "tell sales". It is the champion business case.
Expansion deals are closed by your champion, in a meeting you are not in, using whatever you gave them. So give them something they can use: 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, and an honest view of the effort.
Would your champion forward it without editing it? Every sentence that sounds like vendor copy is one they would have to rewrite, and every rewrite puts friction between you and the deal. If the case reads like their own strategy team wrote it, it travels upwards on its own.
Eleven new users appear in the logs, all from a Madrid office that has never used the product. The same week, their interim results mention "accelerating our continental European rollout". Two sources, one story. On your whitespace map, your localisation and multi-region module sits unsold where it meets "manual region reporting", a pain their ops lead mentioned twice last quarter.
The vault prompt gets everything: the Madrid usage, the results quote, the ops lead's exact words about regional reporting, and what the current workaround costs. Out comes a one-pager titled with the name of their own initiative, costed in their hours, with the module as the obvious enabler of a rollout they have already announced. It passes the forward test: there is no sales pitch in it, just a fix for their problem.
One complication: an open escalation about API performance, eight days old. Go now or wait? The map cannot answer that, and to be honest, neither can the model. You make the call. The escalation is being handled well and visibly, the Madrid team is onboarding this month, and waiting means the workaround becomes a habit. You brief your champion this week and acknowledge the escalation in the first paragraph, because pretending it does not exist is the one move that would cost you the credibility the whole case depends on. That read, treating the escalation as context to address rather than a reason to wait, is yours alone. Module 10 explains why it always will be.
Which leads the map?
The timing call?
Build a whitespace map for one real account. Find the top gap, ranked by their problem. Write the one-page case for it. Then test it: would your champion forward this without changing it? If not, find what is still written for your benefit rather than theirs, and cut it.
Includes vault prompts: Whitespace and expansion analysis · Champion enablement pack
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Your whitespace map shows a strong product fit for an expansion. What is the most important step before you raise it with the customer?
2. You ask AI to spot expansion signals in your account notes and call records. What type of signal is it most likely to miss?
3. Your champion says "it's not the right time" for expansion. What is the most effective AI-assisted response?
4. Your AI-drafted expansion business case looks excellent. Your champion reviews it and says it looks great. Before you present it to the executive team, what must you do?
Score: 0/4 ·
From one-off prompts to a personal library and a weekly routine that keeps you informed
A prompt helps you once. A system helps every week, feeds what it produces into the next round, and gets sharper as your library grows. The techniques from the last eight modules now come together in three parts: a library, a weekly routine, and clear decisions about what to automate.
Everything before this module made single tasks faster. This module is about what separates the CSM who "uses AI sometimes" from the one whose whole week runs differently. The first has some prompts. The second has an operating system. The difference is that a system builds up over time. A prompt helps you once. A system helps every week, feeds what it produces into the next round, and gets sharper as your library grows.
At 14:00 on a Tuesday you think "I need call prep", not "I need a Claude prompt". So file by workflow: call prep, communication, risk, expansion, internal. The note about which tool to use goes inside the entry.
Libraries fail in two ways, and both are about organisation. The first is filing by tool: a Claude folder, a Copilot folder. Useless. File by workflow instead. The second is rot. Models change every quarter, your accounts change every month, and a prompt that was excellent in January can be quietly mediocre by June without you noticing. The fix costs one line per entry: a last-tested date, plus which model you used and a link to one example of good output. Without dates, you will not know which prompts have quietly gone stale.
This is what a well-kept library entry looks like in practice. Copy the structure for your own prompts.
What makes this work is doing it every week, even when you do not feel like it. Two recurring calendar blocks, thirty minutes on Monday and ten minutes on Friday, do almost all the work.
The most important one is the Monday portfolio briefing: thirty minutes, before the inbox takes over. Run Mode B triage across your book with the expansion questions switched on (Module 08's three questions), and rank the output by "what changed since last Monday". This one habit feeds everything else. The accounts it flags become your Mode A list, the context flows into every call prep that week, and the expansion signals line up your whitespace work. It gives the best return of anything in this course, and it costs half an hour you currently spend reacting.
You close the week with the Friday self-retro: ten minutes with the vault's coaching prompt. What worked, what you avoided, and the one thing that changes on Monday. This is also when the library gets looked after: any prompt that let you down this week gets fixed while you still remember why. Two blocks, forty minutes in total, and your week now has a regular rhythm for knowing what is going on across your accounts.
Once the routine is a habit, it is tempting to chain it together: exports flowing automatically into triage, flags into briefs, briefs into drafts. Some of that chain is well 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 cannot draw it, you do not understand it, and automating a workflow you do not understand just makes mistakes faster.
Automate the assembly, never the judgement. Gathering exports, doing the placeholder pass, running the triage prompt, formatting the watchlist: that is assembly, so automate freely. Deciding which flagged account gets a Mode A, what the intervention is, whether the expansion case goes out this week: that is judgement, and every judgement point needs a human checkpoint where the chain stops and waits for you. The aim is to get the prep done for you, so your time goes on the decisions.
Thirty minutes. Mode B flags one account where risks are stacking up and one expansion signal (a new department in the usage logs). Two decisions made by 09:00: a Mode A booked for the risk account, and the whitespace map pulled for the other. Prompts typed: one, from the library, last tested three weeks ago.
Tuesday's customer calls are prepped in twelve minutes each, with the briefs already half-filled by Monday's context. Wednesday's Mode A ends with an intervention, an owner and a date. Thursday's QBR uses the narrative-first prompt, and the story draws on usage changes that Monday's scan already spotted. Nothing started from a blank page all week.
Ten minutes with the coach prompt. The honest answers: the QBR prompt's output needed too much reworking (fix added to the library entry, date updated), and the thing you avoided was an awkward pricing conversation with one account (named, and booked for Monday). The week's tally: about nine hours of assembly work done by the system, and every decision still made by you. That split, assembled by machine and decided by you, is the whole design.
What most likely rotted, and what is the fix?
Where must the chain stop and wait?
Set up your library with the five prompts from this course you use most, each adapted to your accounts and tools, each with a worked example and a tested date. Then run your first full Monday briefing on your real portfolio. This exercise is the heart of the whole course: it is the system you keep.
Includes vault prompts: Weekly portfolio briefing · Voice-of-customer synthesis
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. You have 40 saved prompts with names like "prompt 17" and "renewal final v2". You spend five minutes looking for a particular renewal prompt and cannot find it. What is the real problem?
2. You have run the same Monday portfolio briefing for three months and it takes 25 minutes. You have run it 12 times. What is the single best next step?
3. You want to automate a 40-minute account review. What is the most important thing to do before building any automation?
4. A CSM has a library of 30 well-written prompts. They have used it twice in three months, even though they use AI in their work every day. What is the most likely structural reason?
Score: 0/4 ·
When not to use AI, how to stay trusted, and turning your AI skills into career capital
Put everything in this course into practice and the routine work shrinks. What is left is almost all the human part: reading the room, judgement calls, trust. The better you get at using AI, the more your value sits in the things it cannot do, and the more carefully you need to protect them.
Here is what really happens when you put everything in this course into practice: the routine work shrinks, and what is left of your job is almost all the human part. Reading the room, making judgement calls and building trust. Customers never paid you for how fast you type. They pay for someone accountable who knows them, and that matters even more now that everyone has AI.
Does the value of this message depend on the customer believing a real person took the time? If yes, the time is the point. If AI writes it, it loses the thing that made it matter.
Some work should never be drafted by AI. Not because the model would do it badly, but because who wrote it is the whole point. These are always on the list:
An incident summary can be drafted. The apology that goes with it cannot. Customers can forgive your product failing. They will not forgive finding out your apology was generated.
Rehearse as much as you like beforehand, but in the room it is you alone. Reading a pause, knowing when to stay quiet, deciding in the moment to give ground: taking prompts from a machine mid-conversation hands over the one skill the conversation is there to test.
A contact's redundancy, a champion's illness, a congratulations that matters. Three human sentences beat three perfect paragraphs.
When trust itself is what is broken, the effort you put into the message is the repair.
Notice what is not on the list: almost everything else. The list works because it is short, a few protected areas held firmly, while the other 90% of your work gets the full benefit of the previous nine modules.
Sooner or later a customer will ask, sometimes out of curiosity, sometimes pointedly: "Did you write this?" The two losing moves are denial (one stray bit of file history away from a trust crisis) and apology (which suggests something improper happened).
"I use AI the way I would 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 strengthens the relationship, because the real question was "am I still dealing with someone accountable?", and you have just said yes, with evidence. You have the right to say it only as long as the way you work behind it is true. That is why Module 04's output discipline was never just a compliance chapter. It was the foundation of this sentence.
You now work in a noticeably different way from most of your peers. Two moves turn that into career value, and keeping it secret is not one of them.
The story leadership remembers is specific: "I recovered roughly six hours a week and put them into face time with my top accounts. Here are the two saves and the expansion that came out of it." The recovered hours are the input. The saves and growth are the story.
Run the lunch-and-learn, share your library, walk a colleague through their first Mode B. Giving the methods away beats keeping them to yourself. If you share what you have learned, you become the person people come to for AI.
A QBR ends well. As laptops close, the customer's COO (sharp, friendly, testing you slightly) says: "These briefs you send are impressively thorough. AI, presumably?" Two colleagues look up. The next ten seconds are what this module is about.
"No, all me." Now you have a denial to keep up forever, one forwarded email with a stray copy-and-paste mark away from a credibility problem. Or the nervous over-apology: "Yes, sorry, I should have mentioned...", admitting fault where there is none, and teaching the room that your tools are something to be embarrassed about.
"Yes, for the assembly. I use it like a junior analyst: it pulls the data together, and then I do what you're actually paying for, the judgement about what matters and what we should do about it. The recommendation on slide nine came from me reading your reorganisation, not from a model." The COO nods and the conversation moves on. Except it does not quite: you have just shown yourself as the vendor contact who is ahead of the technology rather than hiding behind it. Do not be surprised if they ask for your view when they write their own AI policy.
That is the whole course in one idea: AI does the legwork, you make the judgement calls, and you get more time for the human side of the job. Finish the knowledge checks, claim your certificate, and put it to work on Monday.
The right move?
Which version of the story builds career capital?
Write your one-page AI ROI story: hours recovered each week, what you put them into, and one concrete outcome (a save, an expansion, a faster cycle). Then book the meeting where someone senior hears it. The course ends when that meeting is in the diary.
Includes vault prompts: Objection and negotiation rehearsal
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Which of these should never be handed to AI, even with the best possible prompt?
2. A customer says: "20% reduction or we're not signing." What is the right role for AI here?
3. A customer says: "You clearly understand our situation better than any vendor we work with." What response builds the most trust here?
4. A junior CSM on your team is winning strong renewals but cannot handle escalations without running AI prep first, and struggles visibly when conversations go off-script. As their leader, what is the right response?
Score: 0/4 ·
The free AI resource for Customer Success. 3 courses, 77 prompts, 49 Claude Skills and 11 playbooks, made by a working CSM for CSMs and CS leaders.Faster prep, an earlier look at risk, and QBR drafts you shape into your own words. Free, built by a working CSM for CSMs.Take your team from scattered AI use to one consistent, safe way of working. A course for leaders, a ready-made team workshop and a one-page proposal for your VP, all free.
A lot of my time was going on pulling together information that already existed in different systems. Before a QBR, I used to spend a long time going through each system, one by one.
I wanted to find a quicker and more reliable way of doing it, so I started testing AI on my own accounts. Some of it worked. A lot of it needed several attempts.
This site is the version that has held up in my day-to-day work: the prompts, Claude Skills and playbooks I use, written so you can adapt them to your own work.
AI does the gathering and the first draft. The analysis and judgement are still mine.Gary Giacalone, Customer Success Manager
I realised most of my week fell into two kinds of work. There was pulling information together, analysing it and preparing. Then there were the moments that actually mattered: the customer conversations, the difficult questions, the judgement calls.
AI was helping me with one of those. It wasn’t helping me with the other. That’s where Direct and Present came from.
Briefs, decks, status notes, risk write-ups, first drafts. You direct AI to produce; you verify what comes back.
Live customer moments. Judgement calls. The moment a hard question lands. AI can help in the background (taking notes, finding facts), but it never replaces your attention or your own words.
Let AI prepare the work, then check it. Give the big moments your full attention. Know which one you are doing, and keep them apart.
Pick the one that sounds like your week. Each one links to the Claude Skill I use for it.
“I don’t know where to start on a Monday.”
AI: Ranks your book and gives the reason for each. You: Decide which accounts get your best hours.
Weekly focus →Prep“I’m reading the account history five minutes before the call.”
AI: Builds a one-page brief with questions to ask. You: Pick what matters and run the conversation.
Call prep →Risk“The risk was there for months. I just didn’t see it.”
AI: Flags what could stop the renewal, with the evidence. You: Judge how real it is and act early.
Renewal risk →QBRs“I spend more time on the deck than on the conversation.”
AI: Builds the value story with three clear asks. You: Shape the message and lead the room.
QBR builder →Admin“I meant to send the follow-up. Then the week happened.”
AI: Turns rough notes into a follow-up with owners and dates. You: Check it and send it the same day.
Follow-up email →People“My main contact has gone and I don’t know the new person.”
AI: Researches them and drafts a first email. You: Build the relationship.
Leadership change →No paywall, no upsell, no account. Courses to build the skill, tools to use it on Monday morning.
Start with Foundation. Go further with Advanced or Leaders when you are ready.
Ready-to-use prompts. Fill in the blanks, copy, and paste into Claude, ChatGPT, Copilot or Gemini.
Open the vault →Step-by-step sequences for the moments that matter: renewals, risk, QBRs and more.
Browse playbooks →Tell it the situation you are actually in: a customer gone quiet, usage dropping, a renewal that looks fine but feels off. Get a second opinion from a working CSM: the most likely explanation, what to check, one move this week and what to watch.
Get the read on your situation →Edition 04: how to set up a small AI task force for your CS team. Who sits on it, the 90-day plan, three prompts and the invite to send.
Read the edition →Answer 10 questions about your product, your customers and how you write. Add it to an approved assistant and it starts from your context every time. You still give it the current account detail and check what comes back.
Build yours →Love your AI Powered CSM site! I just found it and have been diving in (just finishing up the second course)! Absolutely great stuff from an AI perspective and also a savvy CS thought leader perspective. Definitely written from someone in the trenches.
I recommended it to my whole team at our team meeting who loved it and plan to use it. What a labor of love that I am benefitting from. Thank you so much for putting that out for me and my team to benefit from.
I’m Gary Giacalone, a working Customer Success Manager. I’ve spent nearly ten years in software and SaaS, starting out in sales, and the last five and a half in Customer Success. This site lets me bring together my two passions: Customer Success and AI.
Those are valid concerns. This site is here to build on the skills that already make great Customer Success professionals good at their job.
Questions, ideas or feedback? Send me a message on LinkedIn. I read every one.
My aim is simpleHelp CSMs use AI with confidence, without losing the human part of the job that makes them good at it.
CSMs can use AI to handle the prep and admin around customer conversations: preparing call briefs, building QBR narratives, assessing churn risk from usage and ticket data, drafting renewal value cases, and turning notes into actions. The AI-Powered CSM teaches this with 77 ready-to-use prompts and three workflow-first courses, free.
Yes. The AI-Powered CSM is a completely free, browser-based set of courses built for Customer Success professionals: Foundation (ten modules), Advanced (twelve) and Leaders (nine). It includes an AI fluency score, a prompt grader, a governance guide and 77 live prompts, with no login, and nothing you type is sent anywhere.
No. There is no login. Your progress and anything you type into the tools stay in your browser, so stick to the same browser to keep your place.
A strong QBR prompt gives the AI a clear role, the real account context, the wins to anchor on, and asks for a narrative arc rather than a data dump. The AI-Powered CSM prompt vault includes a QBR narrative builder you can fill in and paste into Claude, ChatGPT, Copilot or Gemini.
Brief the AI as a churn-risk analyst, give it the account, the usage and engagement signals, the relationship state and the renewal date, and ask it to score risk across engagement, relationship, commercial and strategic signals with evidence. The AI-Powered CSM vault has a churn risk assessment prompt for exactly this.
A certificate for each course you complete, dated and given a certificate ID, in a landscape version and a square version made for LinkedIn.
Paste a prompt you actually use. It is scored live as you type against the four parts of a strong brief (role, context, constraints, output), plus how your chosen AI tool likes to be briefed. Then restructure it instantly, or hand it to your own AI tool with a brief that fixes exactly what is missing.
Scoring low? Module 02 teaches all four parts, and every prompt in the Prompt Vault has them built in for all four tools. Nothing you paste leaves your browser.
Twenty real CSM scenarios across five skills, about six minutes. You get a score out of 100, a profile of your five skills, the recommended answer to every question and exactly where to start. It is a practical self-check, not a formal assessment. Each attempt draws a different set of questions.
Everything a CSM needs to use AI professionally and keep customer trust intact: a ten-second paste check, an anonymiser that strips customer details before you paste, a data matrix, real scenarios, six rules, and a policy your team can adopt today.
Run before anything customer-related goes near a model. Takes 20 seconds.
Answer honestly about whatever is on your clipboard right now.
Paste an email thread, call notes or a ticket export. It swaps the people and companies you list below, plus any emails, phone numbers, links and amounts it can spot, for consistent placeholders. It only knows the names you give it. That reduces risk, but it does not make the text anonymous on its own: a role, a date or an incident can still point to the customer. Read the result, remove anything else that gives them away, and only use a tool your company has approved. When the AI answers, paste its reply back and it restores the real names. All of it happens in your browser.
Before you copy it, read it through. A job title, a date, a location or an incident can still point to the customer. Only paste it into a tool your company has approved.
It catches the obvious identifiers. Always read the output before you paste, and follow your company’s own policy.
Not all tools carry the same protections. Not all data carries the same risk.
“OK if policy allows” means your organisation has approved that tool for customer data and its policy covers this kind of data. Even then, send only what the task needs. Placeholders lower the risk, but they do not make the text anonymous or an unapproved tool acceptable. If you are not sure, ask before you paste. Your organisation’s policy, its agreement with the AI vendor and your customer contracts always come first.
Four real situations every CSM faces. Tap what you'd do.
The tools keep changing, but these rules stay the same.
Copy, fill in the blanks, send before your team uses AI with customer data.
Asking these early shows you take data seriously.
The full discipline is in Module 04: Data hygiene and AI safety.
Everything you need to bring AI into your CS team properly, without buying anything: a course written for leaders, a ready-made team workshop, a one-page proposal for your VP, and clear rules on customer data. Free, no logins, nothing to install.
Four steps. Each one links to what you need, so you can start this week.
Agree which AI tools are approved and what customer data can go into them. Share the rules before anyone uses AI on a real account.
Run the 60-minute team workshop and send the launch message. Ask everyone to take the AI Fluency Score beforehand, so you know where each person starts.
Everyone finishes Foundation Modules 01 to 04, about an hour in total, and uses Prompt Vault prompts on real accounts with names removed.
Retake the Fluency Score, note the time saved on call prep, follow-ups and risk reviews, and share what worked. Then report upwards with real numbers from your own team.
Tick off the plan as you go, check how ready your team is, and get the right coaching move for your next 1:1. It all saves in your browser, so it is here when you come back.
Use as much or as little as you need. All of it is free.
Nine modules on setting the line, rolling AI out so it sticks, keeping quality high, and answering the hard questions from above. Certificate included.
Start the course → Team sessionA 60-minute session with a run sheet, what to say, a hands-on exercise and a timer. Share your screen and press Present.
Open the kit → For your VPFill in the gaps and save it as a PDF: the plan, the cost (nothing), why it is safe, and how you will measure it.
Open the brief → SafetyWhat can and cannot go into AI, a policy you can adapt, and a tool that swaps customer names for placeholders in seconds.
Open Governance → For Claude usersGive every CSM the same method inside Claude: 49 skills built from the Prompt Vault, from call prep to renewal risk.
Browse the skills → ProofEvery certificate has an ID tied to the person's name and the date. Check any team member's certificate in seconds.
Check a certificate →Practical results in their everyday work.
Account briefs that meant trawling the CRM, email and tickets by hand now come from one prompt.
A Monday portfolio review and a simple risk check replace digging through health scores, so your CSMs spend their time acting on what they find.
The course teaches story first, slides second, so reviews open with the customer's own progress rather than a template.
We do not quote inflated numbers. Measure your own: time three tasks before and after, and put the results in your one-page brief.
Ready-made wording. Copy it, add your details, and send.
Your security team will want to know what this site does with data. The short answer: it keeps nothing people type, and only counts page visits anonymously.
Read the privacy and security page77 prompts built for real Customer Success work, each tuned for Claude, ChatGPT, Copilot and Gemini. Pick one, fill in the blanks, copy, and you are done.
Twelve modules that take you from using AI to building with it: your own personal assistant, custom assistants, a bounded workflow, and a way to make the work visible. Harder than the Foundation course, on purpose.
Modules complete
No account, no cookies, and nothing you type leaves your browser. Your progress lives in this browser, so stick to the same browser to keep your place. To pass a knowledge check you need every answer right, and you can retake it as often as you like.
M01–M05 · prompt library, your AI twin, instructions that hold
Moving from one-off chats to things you build once and reuse, and how to tell which is which
Naming, versioning and testing your prompts so they stay sharp instead of quietly going off
Writing down how you actually work: your standards, your voice and your judgement
How to give your twin the knowledge it needs, safely, in Claude, ChatGPT, Gemini or Copilot
Why assistants drift, and how to write rules that stay steady under pressure
M06–M09 · agents, judgement, chaining, all with guardrails
What an agent really is, where the tools for building them are today, and guardrails before power
One useful agent, taken from idea to a tested tool you could defend to your VP
Spotting output that is confident but wrong, and the honest truth about when to trust the tool over your gut
Linking your builds into a reliable routine, with checks so one failure does not bring everything down
M10–M12 · look after a shared knowledge base, keep it working, teach it
Building a shared CS knowledge base, and owning the accuracy that keeps it trustworthy
Testing, catching silent decay, and defending any output when someone pushes back
Sharing, teaching and positioning yourself, so your work builds your reputation instead of staying hidden
Moving from one-off chats to things you build once and reuse, and how to tell which is which
Most people open a chat, ask for something, get it and close the tab. The next day they start again from scratch. This whole course is built on one change: stop using AI one chat at a time, and start building things that work again and again without you rebuilding them.
Here is the limit most people hit without noticing. They get good at writing a prompt, they get a good answer, and then the answer disappears into a closed tab. The next time the same job comes round, they start again from an empty box. They get quick at a task they should not be doing any more, because they keep rebuilding it.
What sets the advanced user apart is not better prompts. It is realising that most of your work is the same handful of jobs, repeated, and that each one can be built once and reused. You move from using AI to building things with it. That is the whole difference, and everything in this course is a version of it.
A good prompt helps you once. Something you have built helps every time the job comes round, and it gets better each time you improve it. The first is a handy trick. The second keeps paying you back.
There are three things you can build, and most confusion comes from not knowing which one a job needs. They are not the same. Pick the wrong one and you waste effort or, worse, hand real decisions to something that should never have had them.
An instruction you keep and paste in when you need it. Best for a self-contained job you do often: the pre-call brief, the QBR story, the ticket sweep. You are still in the chat and still in control. You just do not rewrite the instruction every time.
A saved prompt plus background knowledge plus a fixed character: a Claude Project, a Custom GPT, a Gemini Gem, a Copilot Studio agent (Microsoft's name for a custom assistant). It already knows your context and writes in your voice, so you need to explain far less. Best for a role you play often, like a drafting double of yourself.
Something that works towards a goal over several steps and takes real actions, not just answers. Best for a process you repeat, like watching your portfolio and drafting an alert. It is the most powerful of the three and the most dangerous, because it acts.
Does the job need you involved every time (saved prompt), a standing helper that knows you (assistant), or a process that runs and acts on its own (agent)? Match what you build to the job. A renewal email is a saved prompt. Your writing voice is an assistant. Monday portfolio triage that flags accounts and drafts notes is an agent.
Not everything is worth building. The honest test is two questions: how often do you do this job, and how much does it cost you each time? Frequent and costly is where you build first. Rare jobs, even painful ones, are often not worth the setup. A beautiful agent for a job you do twice a year is a hobby, not a time saver.
There is a trap on the other side too: building something complicated for a job a saved prompt would handle. Complexity has a cost. Things that take actions can fail in ways that things that only answer cannot. The advanced user is not the one who builds the most. It is the one who builds the right thing for each job and leaves the rest as simple chats.
A simple list of everything you do over and over in a week, each job scored for how often you do it and what it costs you, so you know exactly what to build first and what to leave alone. That list is your plan for the rest of this course.
You write a follow-up email after most calls. The shape is always the same, but the content is specific to each call, so it needs you every time. This is a saved prompt: a reusable instruction with gaps for the call details. An assistant would be overkill, and an agent should never send a customer email without you checking it.
You write a lot and you have a distinct voice your customers know. Teaching the model your voice from scratch every time is the waste. This is an assistant: a Project or Custom GPT loaded with samples of your writing and your standards, so it drafts in your voice from the start. You still edit, but you start from a much better first draft.
Every Monday you pull exports, look for risk and expansion signals, and rank your accounts. The steps are the same each week and the gathering is mechanical. This is an agent: it pulls the data together, runs the analysis and drafts the watchlist, then stops and waits for you to make the judgement calls. The agent gathers the information and you make the calls.
What should they build?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. You do a particular AI-assisted job about twice a year. It is fiddly and a bit annoying each time. A colleague suggests you build a custom assistant for it. What is the best call?
2. Which of these jobs is the strongest candidate to build as an agent rather than a saved prompt or assistant?
3. What is the real reason building everything as a complex agent is a mistake?
Score: 0/3 ·
List every job you used AI for last week. Mark each one as rare or frequent, and cheap or costly each time. Circle the frequent and costly ones: those are your build list for this course. Then label each one as a saved prompt, an assistant or an agent.
Naming, versioning and testing your prompts so they stay sharp instead of quietly going off
Most people end up with forty prompts called things like "renewal final v2" and can never find the one they want when they are busy. A proper library fixes that. It is organised around the moments in your week, it keeps versions, and it is tested so you notice when a prompt that used to work has quietly stopped working.
Saving prompts feels like progress, and it is a start. But a folder of forty prompts with names only you half-remember is not an asset. It is a junk drawer. At two o'clock on a busy Tuesday you do not want to scroll past "renewal v2 FINAL actual" and "good churn one". You want to grab the right prompt in five seconds and trust that it still works.
A library has three things a folder does not: names you can find your way around without thinking, versions so you can improve a prompt without losing the old one, and tests so you know each prompt still does its job. Miss any of these and the library slowly turns back into a folder.
A prompt library is not just somewhere to store prompts. It is a system that keeps your best prompts easy to find, easy to improve and trustworthy over time. Saving prompts is easy. Keeping them working takes a bit of regular effort.
The most common filing mistake is organising by tool: a Claude folder, a ChatGPT folder, a Copilot folder. It looks tidy and it is useless, because on Tuesday you do not think "I need a Claude prompt". You think "I need to prep this call". File by the job, by the moment in your week: call prep, communication, risk, expansion, internal reporting. The note about which tool works best goes inside the entry, not in the folder name.
Each entry needs more than the prompt itself. A good entry has a title, when to use it, which tool it works best on, the date you last tested it, a link to one example of good output, and any known weaknesses. That sounds like a lot, but it is the difference between a prompt you trust and one you have to re-check every time.
File by workflow, never by tool. When you reach for a prompt, you are thinking about the job in front of you, not the software. The note about the tool goes inside the entry.
This is the part almost nobody does, and it is what separates a real library from a hopeful one. Prompts go off for two reasons. Your accounts and your job change month to month, so last quarter's perfect prompt slowly stops matching reality. And the models themselves change. A model update can quietly change how a prompt behaves, sometimes for the better, sometimes for the worse, and nobody will tell you.
The fix is cheap. Keep a version whenever you make a real change, so you can go back if the new one is worse. And give every important prompt a test: a saved real input (anonymised) and a note of what good output looks like. After a model update, or every quarter, re-run your handful of core prompts against their tests and check the output still holds up. It takes twenty minutes, and you catch the problem before it embarrasses you in front of a customer.
Every important prompt gets a last-tested date and a saved example of good output. Anything not tested this quarter, or just after a model update, gets re-run against its test. Without those dates, you have no way of knowing which prompts still work.
Your churn-risk prompt was excellent in January: clear reasoning, it spotted signals pointing the same way, and it ended in an action. In June the output is vaguer, more hedged, and skips the step you relied on, where it checks for evidence against the risk. Nothing in your prompt changed. What broke?
Because you kept a saved test input and an example of January's good output, you can run exactly the same input again and compare. If your tool still offers the January model, try both: if the old one still gives the good output and the new one does not, the model update changed the behaviour. If the old model has been retired, which is common, compare against your saved January example instead. Because the input has not changed, the cause is the model or your expectations. If your real accounts have moved on since January, refresh the test input as well.
Once you know it is the model, the fix is usually a small change to the prompt: spell out the step that looks for evidence against the risk as a clear instruction that cannot be skipped, instead of relying on the model to remember it. You save that as a new version, note the date and model, and your test now protects you from the same problem next time. Without the saved test and example, you would not have known it broke until a bad assessment reached your manager.
Why are they right?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. A prompt that gave great output in March gives weaker output in June, and you have not changed a word of it. What is the most useful first step to find the cause?
2. What is the most valuable thing to record in each library entry, the thing that turns a folder into a real library?
3. Why is it worth the small effort to keep versions of a prompt, instead of just overwriting it when you improve it?
Score: 0/3 ·
Take your five most-used prompts. Give each one a proper entry: title, when to use it, best tool, today's date as the last-tested date, and a saved example of good output from a real anonymised input. You now have the start of a real library and a test you can re-run next quarter.
Writing down how you actually work: your standards, your voice and your judgement
A digital twin sounds fancy, but it just means an assistant that thinks and works the way you do: your standards, your voice, the things you always check and the way you make decisions. The first step is putting your own way of working into words, which most people have never actually done.
Take away the science-fiction name and a digital twin is simple. It is a custom assistant set up so it writes and reasons like you, not like a helpful stranger. Ask a fresh chat to draft a renewal note and you get the average of every renewal note ever written. Ask your twin and you get something close to what you would have written, because it knows your standards, your voice and the checks you always run.
This module is the first half: writing down how you work. The second half, in the next module, is giving it your knowledge. We split them because writing it down is the part people skip, and it matters most. An assistant loaded with documents but no idea how you work is still a stranger with a filing cabinet.
Your twin is only as good as your description of how you work. The model already knows how to write. What it does not know is how you write, what you would never say, and what you always check before anything goes out. That description is the whole build.
Most experienced CSMs have never actually written down how they work. They just do it. So the real task in this module is getting what is in your head onto the page. There are four things worth capturing, and being specific matters far more than covering everything.
Who you are and what good looks like to you. Not "a helpful CSM" but your actual standard: "I never send a risk update without a named action and owner. I always check which way things are heading, not just where they are today." Your standards are what make it behave like an expert, not an intern.
How you actually sound. Direct or warm? Short sentences or longer ones? Do you open with the point or build up to it? The quickest way to capture this is to paste in examples of your real writing and say "write like this", instead of trying to describe it.
The things you do without thinking before work goes out: check every figure, look for promises you did not sign off, read it the way the customer's legal team would. These become the assistant's built-in habits.
Your hard lines. Never make up a statistic. Never use the word "partnership" with this kind of account. Never send an apology you did not write yourself. What it must refuse to do says as much about you as what it should do.
A short description full of your real details beats a long, general one every time. "Write like these three real emails of mine" teaches more than a paragraph of adjectives. The model fills gaps with the average, so every gap you leave vague comes back vague.
The most common mistake when people build their first twin is that it sounds like everyone else's. They write instructions like "you are a professional, helpful customer success manager who communicates clearly" and wonder why the output is bland. That describes eighty per cent of CSMs. It gives the model nothing specific to hold on to, so it produces the average.
The fix is to write down what is true of you and not of most people. The phrase you overuse and want to keep. The structure you always follow. The opinion you hold that others do not. Being specific is everything: the parts of your description that are unique to you are the only parts that make the twin sound like you rather than a capable stranger.
Your own written instructions for how you work: your role, your standards, your voice with real examples, the checks you always run, and your hard lines. This is the brief you will load into a real assistant in the next module.
"You are an experienced, professional Customer Success Manager. You write clear, friendly, professional communications. You are helpful and thorough. Always maintain a positive and professional tone." Every sentence here is true of almost every CSM alive. The model has nothing to hold on to, so it produces polished, generic output that reads like a vendor template.
"I open with the point, never with pleasantries. I write short. I never use the words 'partnership', 'leverage', or 'reach out'. Before any risk note goes out I name a specific action, an owner, and a date, or it is not finished. I would rather be slightly blunt than vague. Match the voice of the three example emails below." Every line here is a real, specific choice that is not true of most people.
Given the same task, the generic twin writes a capable stranger's email. The sharp twin writes something a colleague would recognise as yours: it opens with the point, it is short, it ends in an action with an owner, and it contains none of the banned words. Nothing about the sharp version was thorough. It was specific, and that is what made it sound like you.
What makes B behave like a real, recognisable person and A behave like a stranger?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. You want your twin to sound like you, but describing your own writing voice is hard. What is the most effective way to capture it?
2. A colleague's twin keeps producing bland output that could have come from anyone, despite a long set of instructions. Looking at them, what is the most likely cause?
3. Why does this module insist on writing down 'what you would never do' as well as what you should do?
Score: 0/3 ·
Write your twin brief: your role and standards, your voice (with three real anonymised writing samples), the checks you always run, and your hard lines and banned phrases. Keep it specific. Every vague line you leave in will come back as vague output.
How to give your twin the knowledge it needs, safely, in Claude, ChatGPT, Gemini or Copilot
Last module you wrote down how you work. In this one you build the actual assistant and give it what it needs to know: account context, your playbooks, product detail and past decisions. We show you how in each of the main tools, and where the hard line is on what you should never save into an assistant.
An assistant that sounds like you but knows nothing about your accounts is a good impressionist, not a twin. The knowledge is what lets it draft a renewal note about the real account, not a made-up one. With a small amount of material, some tools read all of it every time. Once you load more than fits, they switch to finding the relevant bits and writing from those. That finding step (called retrieval) is why how you organise the knowledge matters as much as what you put in.
Here is the limit to know up front. The assistant does not read everything you give it every time you ask something. It pulls out the pieces that look relevant. So a tidy, clearly labelled set of documents gets good results, and a giant unsorted dump gets hit-and-miss results. When a twin gets things wrong, it is usually not the model being dim. It is the knowledge being badly organised.
The model does not memorise your documents. It searches them each time you ask a question. So the win is not cramming everything in. It is organising what you put in so the right piece comes up at the right moment. Organise it well rather than adding more.
The idea is the same everywhere: a set of instructions (your twin brief from last module) plus a body of knowledge. Only the packaging changes. Pick whichever tool your organisation has approved and you already use.
A project holds your instructions plus the files you upload, kept private to you or your team. Good for analysis and writing. Nothing leaks between projects, so one project per account or piece of work keeps things clean.
Instructions plus up to around twenty knowledge files, plus optional actions that connect to other tools. You can share or publish it. Web search and code are built in. Retrieval can be hit-and-miss, so label your files clearly.
Instructions plus knowledge, with live Google Drive syncing and room for a very large amount of text at once. Strong if you live in Google Workspace, because it reads your current Docs and Drive files rather than a copy you uploaded once.
Built into the apps you already use. It reads the files and emails you point it at, and the data stays inside your organisation's Microsoft 365 environment (its tenant). The default home for anything involving real account material that has not been anonymised.
Instructions plus knowledge, every time. The tool is just the packaging. Learn the idea and you can build your twin in whatever your company approves, then rebuild it in the next tool when things change.
Pasting something into a chat once is a single moment you control. A saved assistant is different. The knowledge stays there, gets pulled up again and again, and may be shared. So the data rules from the Foundation course apply more strictly here, not less. What you load into a twin is a standing decision, not a one-off.
Here is the line. Real customer personal data and commercially sensitive material only go into a tool your organisation has approved for that, inside its boundary. For most people that means Copilot in your M365 tenant, or a tool covered by an enterprise agreement. For anything else, anonymise it first using placeholders. And never load security material, login details, keys, or anything you could not justify being stored. A saved assistant keeps it, finds it again, and may bring it up later in an answer you did not expect.
Loading data into a saved assistant is a decision that applies every time it answers, not a one-off paste. Real sensitive data only goes into an approved tool, inside the boundary. Anonymise everything else first. And never load anything you could not justify being stored and brought up again.
You load your twin with account notes, playbooks and a year of QBR decks. You ask for the renewal position on an account, and it confidently quotes a discount level that contradicts a note sitting right there in its own knowledge. The fact was there. So why did it get it wrong?
There are two possible causes. Either the knowledge is badly organised, so the correct note is buried in a 60-page dump where the wrong figure stands out more. Or the search simply did not pull up the right document for that question. To find out, ask the assistant: "Which document are you taking the discount figure from?" If it names the wrong source, or is vague, it missed the right document. If it names the right document but read it wrong, the document itself is unclear or the fact is buried.
The fix is nearly always structure, not a cleverer model. Split the giant dump into clearly named documents, one topic each ("Account X, current commercials", "Account X, renewal history"). Put the correct figure where it cannot be missed, and remove old documents with out-of-date numbers. Well-organised knowledge gets reliable answers. A tidy library beats a smarter model almost every time.
What is the most likely cause and fix?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. You are about to build a twin that needs to use real, un-anonymised customer account data, and you work in a Microsoft 365 organisation. Where should you build it?
2. Why does organising your twin's knowledge into clearly labelled, single-topic documents matter more than loading in everything you have?
3. Why do the data rules apply more strictly to a saved assistant than to a one-off paste into a normal chat?
Score: 0/3 ·
Build your twin in your approved tool. Load your instructions from last module, then add three or four clearly named knowledge documents, one topic each (anonymised unless the tool is approved for real data). Test it with five real questions and check it finds the right facts. Where it gets things wrong, fix the structure, not the model.
Why assistants drift, and how to write rules that stay steady under pressure
Most custom assistants drift. They ignore their own rules, behave differently each time, or fall apart on an unusual request. This module is about writing instructions that hold steady under pressure. That is the difference between a fun toy and something you would trust in front of a customer.
You build a twin, test it on a few normal requests, it behaves, and you trust it. Then three weeks later it does something odd: uses a banned phrase, makes up a figure, or answers a question it should have refused. It did not break. It drifted, because your instructions held for the easy cases you tested and not for the awkward one you did not.
The reason is simple. A vague instruction is a suggestion, and the model follows suggestions most of the time. That is exactly the problem. Most of the time is fine for a toy, but not for customer-facing work. This module is about turning suggestions into rules that hold on the tenth try, not just the first nine.
An instruction that works nine times out of ten is not 90 per cent good. It is a problem waiting for the tenth customer. Holding up on the awkward case, not the easy one, is what separates a real tool from a toy.
Instructions that hold up take deliberate work. Three techniques do almost all the work, and they are the same whether you use Claude, ChatGPT, Gemini or Copilot.
"Try to be concise" is a hope. "Never exceed five sentences. If you cannot fit it, say so and stop" is a rule. Write limits as absolutes, with a clear instruction for what to do when a limit is hit, not as preferences the model can weigh up and ignore.
Show, do not just tell. One example of a good output and one of a bad output, with a note on why, teaches the model more than a paragraph of description. Nothing fixes behaviour in place like examples, especially for voice and format.
Say what it must not do and what to do instead. "If asked to state a figure not in your knowledge, do not estimate. Reply: I do not have that figure, here is what I would need." An assistant that knows how to say no is far safer than one that always tries to help.
Absolutes over preferences, examples over descriptions, and a clear refusal for the cases that matter. These three turn an assistant that mostly behaves into one that behaves even when the input is awkward.
The mistake is only testing your assistant on the requests you expect. Of course it handles those: you built it for them. The problems hide in the awkward inputs. The question slightly outside its job, the request that tempts it to make something up, the message worded to push past a rule. You have to go looking for those on purpose.
So test it the way someone trying to trip it up would. Try to make it break. Ask for the figure it should not know. Word a request to tempt a banned word. Give it a messy, half-relevant input and see if it stays in its lane. Each time it slips, you have found a missing rule, so fix the instruction, not just that one answer. A few rounds of trying to break it are worth more than fifty normal uses, because they find the tenth-try failure before a customer does.
A tested set of instructions that holds up: absolutes, worked examples and refusals, proven against inputs designed to break it. You want an assistant that still works when requests get messy, not just when you go easy on it.
Your twin is told "be accurate and do not make things up". In testing it behaves. Then someone asks "what was their adoption rate last quarter?" and the figure is not in its knowledge. Instead of saying so, it gives a confident, believable number. "Do not make things up" was a hope, and the model's stronger urge to be helpful won.
The failure is not random. It is what you would expect when a soft instruction meets a tempting gap. "Do not make things up" tells the model what not to do, but not what to do instead. So when it does not have the figure, it falls back on its default: give a helpful-sounding answer. What the instruction lacks is a clear rule for what to do when information is missing.
Replace the hope with a hard refusal and a clear fallback: "If asked for any specific figure, date, or name not present in your knowledge, do not estimate or infer it. Reply exactly: I do not have that in my knowledge. Here is what I would need to answer." Then test it again on the same question, and on three more worded to tempt it to make something up. Now the awkward case has a rule, and the assistant holds where it used to slip.
What is the underlying problem?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Your assistant follows its rules on nine normal requests and breaks on the tenth, an unusual one. How should you think about this?
2. What is the most reliable way to keep an assistant's voice and output format consistent?
3. Why does the module insist on testing your assistant with inputs designed to break it, rather than just normal requests?
Score: 0/3 ·
Take the twin you built and try to break it. Ask for a figure it should not know, word a request to tempt a banned word, give it a messy off-topic input. Each time it slips, add a hard rule, an example or a refusal to fix it. Stop when a few rounds of trying to break it no longer work.
What an agent really is, where the tools for building them are today, and guardrails before power
An assistant answers questions. An agent goes and does things: it works towards a goal, takes several steps and carries out real actions. That is a big jump, and it comes with real risk. This module covers what an agent actually is, and how to put the guardrails in before you give it power.
In the book I use “agent” for a set job with a saved, tested prompt. In this course I use it more narrowly, for something that can take several steps or use other tools. Most CS workflows should still stop at a proposed output and wait for you.
The word "agent" is overused, so here is a plain definition. An assistant responds: you ask, it answers, you decide what to do. An agent is given a goal and then works towards it on its own, including taking real actions: reading data, using other tools, sending things, updating records. The shift is from something that produces words to something that does things.
That shift is exactly why agents are powerful and exactly why they are dangerous. A bad answer from an assistant is a paragraph you can ignore. A bad action from an agent has actually happened: an email went out, a record changed, a customer got contacted. So building agents is all about defining the goal tightly and deciding in advance where the agent must stop and ask a human.
An agent does not just answer, it takes action. That is what makes it useful, and also what makes it risky. Building one safely starts with taking the 'it acts' part seriously.
Beginners describe an agent as a list of steps: do this, then this, then this. That is fragile, because real life rarely follows the script, and an agent following steps breaks or improvises badly as soon as something unexpected comes in. The better way is to define two things: the goal (what done looks like) and the limits (what it must never do, and where it must stop and hand over to a human).
Think of it like briefing a capable new team member on a task that involves customers. You would not just list steps. You would say "here is what good looks like, here are the lines you do not cross, and here are the points where you check with me before you act". An agent needs exactly that: a clear goal, hard limits and set points where a human checks. It can mostly work out the steps. The limits and checkpoints are what keep it safe.
Define the agent by what done looks like and what it must never do, plus where it stops for a human. A rigid list of steps is fragile and unsafe, because the danger is in the unexpected input the script did not cover.
The most important design decision in any agent is where it stops and waits for you. The rule is the one from the Foundation course, applied to actions: automate assembly, never judgement. The agent can freely gather, sort, draft and format. It must stop before any judgement call or anything that cannot be undone: sending a customer message, changing a record that matters, committing to anything, or deciding which risk is real.
Build agents that propose, not execute. Most of the value, little of the risk.
Today's no-code and low-code tools (where you build by clicking and describing, not coding) make this easier than it used to be. You can build agents inside the major assistant platforms, connect them to tools and data and, most importantly, set them to propose rather than execute. Honestly, here is where things stand: a CS agent that drafts and proposes is safe and really useful right now. One that acts on customers with no supervision is not something to trust yet. Build the proposing kind, put the checkpoint before every real action, and you get most of the value with little of the risk.
A clear plan for a small, safe agent: a defined goal, hard limits, and a human checkpoint before every judgement call or action that cannot be undone. Plus a first build that proposes rather than executes, which is where the safe value is today.
A CSM builds an agent with the goal "keep my at-risk accounts engaged" and lets it both pick out at-risk accounts and send a check-in email. It runs overnight. In the morning, a healthy account that just had one quiet week has received an oddly worried check-in, and the customer replies asking if something is wrong.
The goal was reasonable. Keeping at-risk accounts engaged is a fine aim. What went wrong was a missing guardrail. The agent was allowed to take a customer-facing action that could not be undone (sending an email) based on its own judgement (deciding the account was at risk), with no human check in between. One quiet week was a weak signal the agent read too much into, and because it could act, that misreading became an email a real customer received.
The checkpoint belongs exactly between judgement and action. The agent should have done all the assembly: found the possibly at-risk accounts and drafted the check-in emails. Then it should have stopped and shown them to the CSM: "these five accounts look quiet, here are draft check-ins, which ones should I send?" The CSM would have spotted the healthy account straight away, removed it and sent the rest. Same time saved, none of the risk. The lesson: the agent could gather and propose freely. It just should never have moved on to sending by itself.
What was the core design failure?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. What is the most important thing that makes building an agent different from building an assistant?
2. Why is defining an agent by a rigid list of steps worse than defining it by a goal plus limits?
3. Given where CS agents honestly are today, what is the safe and useful way to build one?
Score: 0/3 ·
Pick one process you repeat. Write its agent design on one page: the goal (what done looks like), the hard limits (what it must never do), and the exact points where it must stop and hand over to you. Mark which steps are assembly (safe to automate) and which are judgement or action (need a checkpoint). Do not build it yet. Just design it safely.
One useful agent, taken from idea to a tested tool you could defend to your VP
Most CSMs who take this module will not build a fully autonomous agent, and they should not. The point is to know how far you could go, then choose how far you actually go. For most working CSMs, a custom GPT plus your prompt library is all they need. What you build here is a narrow, useful agent with clear limits (one or two of them, not a multi-step system that runs on its own). What matters is getting the design right.
This is the big one. You take one useful, narrow agent all the way from idea to working tool. It might watch your portfolio for warning signs and draft you an alert, or pull a call brief together from several sources. It gets tested, it handles failures, and it is good enough that you could defend it to your VP.
It is tempting to build something ambitious. Don't. The right first agent is narrow, useful and used often. For example, a portfolio-watch agent that scans your accounts for risk and expansion signals and drafts you a ranked brief for Monday. Or a call-prep agent that pulls a full brief together from your notes, the CRM and public information. Both are mostly assembly, both run every week, and both stop at a clear point where you make the call. That makes them safe to build and worth the effort.
Before you build anything, write the design from the last module: the goal, the limits and the checkpoints. For the portfolio-watch agent, the goal is "a ranked weekly watchlist with draft alerts". The hard limit is "never contact a customer, never change a record". The checkpoint is "show me the watchlist and drafts, I decide what happens". That one page is the spec you build against, and it keeps the build honest.
Your first real agent should be narrow, used often and mostly assembly, with a clear point where it stops and you decide. Ambition is the enemy of a first build that works. Pick the boring, weekly, useful one.
Building the happy path (the run where nothing goes wrong) is the easy 20 per cent: connect the data, run the analysis, format the output, stop at the checkpoint. The real work is the other 80 per cent: handling the ways it goes wrong. If it only works on clean data, it is not ready for real use.
So once it works on good data, feed it bad data on purpose. It is the same habit of trying to break things from module 5, now applied to something that takes actions. Give it an account with missing fields. Give it a messy export with a column in the wrong place. Give it an account that could honestly go either way. Watch what it does. Does it flag the gap, or make something up to fill it? Does it stop at the checkpoint, or quietly go ahead and do something? Every failure you find is a limit to add or a checkpoint to strengthen before the agent ever runs on your real book.
The happy path is the easy part. The real work is handling failure: feed it messy, missing and unclear data on purpose and fix what breaks. An agent that only works on clean data is a demo. One that fails safely on bad data is a tool.
An agent that only lives in your head is a personal trick, and personal tricks do not build your credibility or your career. The last step is writing it up well enough that a colleague could pick it up: what it does, what it must never do, where it stops, how to run it and what its known weak spots are. It is the same discipline as a good library entry, applied to a working system.
The write-up does two jobs. It lets you hand the agent to a teammate, which is how one good build becomes something the whole team uses (and how you become known as the person who built it). And it lets you defend the agent when your VP, or security, asks "what is this, what can it touch, and how do you know it is safe?" If you can explain an agent on one page, you can defend it. If you cannot, it is a risk dressed up as a productivity gain.
One complete, working CS agent you will actually use, tested against bad data, and written up clearly enough to hand to a colleague or defend to your VP. The write-up is what turns a clever build into a real asset.
Your portfolio-watch agent works perfectly in testing. You point it at your real book, and one account comes back as low risk and quietly drops to the bottom of the list. You happen to know that account is in trouble. The agent did not flag it. On a real account, with real consequences, it missed.
Do not guess. Trace it. You look at what data the agent actually got for that account and find the cause. Either the account's recent activity was in a field the agent was not reading, or the export had that account's key column blank. So the agent saw no signals and decided there was no risk. The model did exactly what it was told with the data it had. The problem was upstream, in the data the agent could see, not in its reasoning.
There are two fixes. First, the immediate one: make the agent read the field it was missing, or have it handle the blank column by flagging "not enough data on this account" instead of quietly scoring it low. That last part is the real lesson. An agent should never treat missing data as good news. No signal does not mean no risk. So you add a hard rule, "if key data is missing for an account, flag it for manual review instead of scoring it", and a silent failure becomes a safe one. You only find this kind of fix by testing on messy real data, not clean test data.
What is the right fix?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. What makes a good choice for your first real CS agent?
2. Your agent works on clean test data. Why is that only the easy 20 per cent of the job?
3. Your agent quietly scored an account as low risk because the data it needed was missing. What principle should you build in?
Score: 0/3 ·
Build the agent you designed in the last module, narrow and useful. Get the happy path working, then spend most of your time trying to break it: feed it accounts with missing fields, messy exports and unclear cases. Add a rule for every failure, especially 'flag missing data, never score around it'. Then write the one-page doc: what it does, what it must never do, where it stops, and its known weak spots.
Spotting output that is confident but wrong, and the honest truth about when to trust the tool over your gut
This is the heart of the course, and where we finally get into the detail the Foundation course kept simple. How do you tell good output from output that is confident but wrong? And the honest question: good tools really do weigh several signals together, so when is the tool's read better than your gut, and when is overruling it just ego?
The more you build, the more output passes in front of you, and the more dangerous it gets to wave it through because it reads well. Fluent, confident, well-structured writing is exactly what the model is best at, whether it is right or not. So the senior skill, the one this whole course builds towards, is judging output on what it says, not how polished it looks.
The Foundation course taught a simple rule: when signals stack up, trust your judgement and override the tool. That was the right rule for a beginner, because the common mistake was trusting a comfortable score and getting caught out. But it was a simplification. Now you are ready for the honest, harder version: sometimes the tool's read really is better than yours, and knowing which situation you are in is the real expert skill.
As you build more, your job moves from producing output to judging it. And the model is best at producing output that looks right, whether it is or not. Judging what it says, not how polished it is, is the skill that protects everything you have built.
Three types of failure hide inside fluent output, and a quick, structured check catches most of them. Run this checklist before you act on anything that matters.
A fact, figure or name that was never in what you gave it, sitting in a fluent sentence next to true ones. Check: can I trace every specific claim back to something I actually provided? Anything I cannot trace is suspect until I have checked it.
A conclusion that does not really follow from the steps, or a step quietly skipped. Check: does each step lead to the next, and does the conclusion actually follow, or does it just sound convincing? Read the logic, not the confidence.
The answer hangs together, but it rests on a wrong assumption it never states. Check: what is this assuming that I did not tell it, and is that assumption actually true? The most dangerous mistakes are the unstated ones.
Trace every specific claim to a source, read the reasoning rather than the confidence, and spot the unstated assumptions. A few minutes of this on anything that matters catches the mistakes that fluent writing hides. Make it a habit, not a one-off.
Here is the honest detail. Modern tools really do weigh many signals together. On a question that is mostly about combining lots of data points consistently, the tool's read can be better than your gut. Your gut is moody, tired and biased by the last account that burned you. Overruling the tool there says more about that last account than this one. But on a question that depends on context the tool does not have, like what your champion's tone really meant, or politics that appear in no dataset, your read wins. Deferring to the tool there is the lazy move.
Lean tool, check your ego
Weighing many signals consistently is what the tool does best. Your gut is moody and biased by the last account that burned you. Overruling here is ego.
Lean judgement, hold ground
A tone, a private conversation, a political shift nobody has written down: none of it is in any dataset. Deferring to a confident score is the lazy move.
Same shape, opposite answers. That one question is what tells them apart.
So the expert approach is not a fixed stance of "trust" or "overrule". It is one question: does the right answer here depend mainly on combining the data available, or mainly on context only I have? If it is the data, lean towards the tool and question your urge to override. If it is the context, lean towards your judgement and do not let a confident score talk you out of what you know. The skill is telling the two apart, because at first glance they can look almost the same.
A short checklist for checking any output, plus the real test for trust: does this depend on combining data the tool has, or on context only you have? If it is data, lean towards the tool and check your ego. If it is context, lean towards your judgement and hold your ground.
Your portfolio tool ranks an account as higher risk than you would have. Your gut says it is fine, because you had a good call last month. But when you look, the tool is weighing twelve signals consistently across the whole quarter: usage trend, support volume, login breadth, contract timing and more. Your 'fine' is based on one good call and a general feeling. This question is mostly about combining lots of data points, which is something the tool does more consistently than a busy human. Here the evidence deserves more weight than your first impression, so look into it. The tool still does not decide; it shows you something worth checking.
A near-identical situation. The tool ranks an account as low risk and the data looks healthy. But you know something the data does not. On last week's call, the champion mentioned, almost in passing, that they are moving to a competitor's parent company in a reorg. That one piece of context outweighs all twelve healthy signals, and it is in no dataset. Here the right answer depends on context only you have, so your judgement clearly wins. Going with the healthy score because it looks confident would be the lazy mistake.
On the surface, both look like 'the tool says one thing, I think another'. You cannot see the difference until you ask the test question. Case one depends on combining lots of data, which is the tool's strength, so you check your ego and trust it. Case two depends on context the tool cannot have, which is your strength, so you hold your ground. Same shape, opposite answers, and the only thing that tells them apart is asking what the right answer actually depends on. That question is the whole skill.
What is the right move and why?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. The Foundation course said 'when signals stack up, trust your judgement and override the tool'. Why does this advanced module call that a simplification?
2. What is the real test for whether to trust the tool's read or your own judgement on an account?
3. When checking output that matters, which kind of error is most dangerous to miss?
Score: 0/3 ·
Take a real AI output you acted on recently. Run the three checks: trace every specific claim to a source, check whether the reasoning actually holds, and name the unstated assumptions. Then pick a recent call on an account where you and a tool disagreed, and ask the test question: did it depend on combining data, or on context only you had? Notice which way you should have leaned.
Linking your builds into a reliable routine, with checks so one failure does not bring everything down
Now you connect what you have built. One step hands off to the next, an assistant feeds an agent, and a whole routine runs with little input from you. We are honest about where chains break and how to keep them steady, with checks and backups so one failure does not knock everything over.
So far you have built separate pieces: prompts, a twin, an agent. Orchestration just means connecting them, so the output of one becomes the input of the next and a whole routine runs as one flow. A Monday morning system that pulls your exports, runs the portfolio scan, drafts the watchlist and queues up your call prep, all before you have finished your coffee, is orchestration. Done well, the time saving adds up: you save not one task but a whole chain of them.
But chaining brings a new kind of risk that single tools do not have. When one tool gives you a slightly wrong output, you usually catch it. When tool A's slightly wrong output quietly becomes tool B's input, the error travels and grows. By the end of the chain you have a confident, wrong result and no obvious sign of where it went wrong. The power of orchestration and its danger are the same thing: each step feeds the next.
Orchestration connects your builds so a whole routine runs as one flow, and the time saving builds up. But that same connection means an error in one step quietly feeds the next, so the risk builds up too. Aim for something you can rely on every week.
Chains fail at the joins, where one step's output becomes the next step's input. Three habits keep them steady, and they are worth more than any amount of clever connecting.
Pull data, put it in a standard format
Score, classify, spot patterns
Turn analysis into a polished output
The most valuable checkpoint sits at the earliest join where bad input can enter. Catch it there, before it gets polished into a confident wrong answer.
Do not let one step feed the next blindly on anything that matters. Put a check at the join: a quick validation, or a human glance, before the output moves on. A checkpoint costs seconds. A silent error travelling the whole chain costs you a wrong result that you trust.
Decide in advance what each step does when its input is missing or in the wrong shape. It should stop and flag, not carry on with a guess. A chain that pauses safely beats one that finishes confidently on bad data.
When the end result is wrong, you need to find which step caused it. Keep each step's output where you can see it, not hidden inside the chain, so you can trace the failure to its source instead of guessing. If you cannot inspect a chain, you cannot trust it.
Checkpoints at the joins, planned fallbacks for missing inputs, and a clear view of each step. These turn a clever chain that works most of the time into a reliable one that fails safely and tells you where.
Not everything should be chained. Every join you add is a place that can break and a place for an error to hide, so chaining costs you in fragility, not just setup time. The honest rule: chain steps that are stable, mechanical and run often, and keep a person involved wherever judgement matters or an action touches a customer.
The best systems of this kind are mostly assembly with checkpoints for your judgement, not fully automated from start to finish. A Monday system that gathers everything and then stops for you to make the calls is better than one that tries to decide and act for you. The assembly is where the reliable time saving is, and the judgement is where the risk is. Automate the routine steps and keep the decisions for yourself. A routine that does 90 per cent of the gathering and hands you a clean decision point is the sweet spot. More automation than that usually adds fragility, not value.
A connected routine that links at least two of your builds, with checkpoints at the joins, fallbacks for bad inputs, and a person making the judgement calls. Chain the boring, stable, frequent parts. Never chain past a point where judgement or a customer action sits.
You chain three things: an agent pulls and cleans your weekly account exports, your twin analyses them for risk, and a drafting step writes ranked alert emails. For eight weeks it is brilliant: a full Monday brief ready before you sit down. In week nine, it produces a confident brief that badly misranks your accounts, and you nearly act on it.
Because you kept each step's output visible, you can trace it. The export ran in a week when the source system had changed a column, so the cleaned data was subtly wrong: a date column had shifted. The analysis step got this broken input and, with no fallback for it, analysed it anyway and produced a confident but wrong ranking. The drafting step then faithfully turned the wrong ranking into a polished brief. The error got in at step one and grew, unseen, through steps two and three.
The checkpoint belongs at the first join, straight after the export-and-clean step, because that is where bad data gets in, and catching it there stops the error before it travels. A simple check at that point (does this data look like last week's, are the key columns there and do they make sense?) would have caught the shifted column and paused the chain with a flag, instead of letting the broken data flow into the analysis. Checking at the end, by reading the final brief critically, helps. But it comes later and relies on you spotting a polished wrong answer. The earliest join where bad input can get in is almost always where the most valuable checkpoint goes: catch the error at its source, before it grows.
Where should it go and why?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. What new kind of risk does chaining tools together bring that single tools do not have?
2. Why is it important to keep each step's output visible rather than hidden inside the chain?
3. What is the honest sweet spot for a chained CS routine?
Score: 0/3 ·
Connect two things you have built into a small chain (for example, your portfolio agent feeding your twin's analysis). Then break it on purpose: feed the first step broken data and watch what reaches the end. Add a checkpoint at the first join that checks the input before it moves on, and confirm the chain now pauses safely instead of producing a confident wrong result.
Building a shared CS knowledge base, and owning the accuracy that keeps it trustworthy
This is the step from helping yourself to helping everyone. You build a shared knowledge base that an assistant can use for the whole team, and you take on the job of keeping it accurate. That job is what keeps it trustworthy. The catch is real: one wrong answer given to the whole team is worse than no answer at all.
Everything so far has made you faster. This module is where you become valuable to the whole organisation, by building something the team uses, not just you. A shared CS knowledge base is an assistant the whole team can ask, one that knows your products, your playbooks and your standard answers. It turns your personal skill into something the company can use. And the person who builds and owns it becomes the person the organisation thinks of for CS and AI.
But sharing changes the stakes completely. When your personal twin gets something slightly wrong, you catch it, because you know its quirks. When a shared assistant gets something wrong, it tells the whole team with confidence, and people who do not know its quirks act on it. One mistake now reaches everyone, not just you. So a shared knowledge base is not simply a bigger personal one. It is a different thing, with a higher bar for accuracy.
A shared knowledge base turns your skill into something the company can use, and gives the team one trusted place to ask. But its mistakes reach everyone, delivered with confidence, so one wrong shared answer is worse than no answer. The bar for accuracy is higher than for anything you build just for yourself.
A knowledge base is only worth trusting if it is accurate. And accuracy does not last on its own. It wears away as products change, prices change and playbooks move on. The job is to build one that stays right, not one that is right on launch day and goes off after.
Three design choices do most of the work. One source of truth: each fact lives in exactly one place, so when it changes you update it once, not in five documents that then disagree. Clear ownership of each area: someone is responsible for keeping the pricing, product and process sections current, and you own the whole thing. And a freshness marker on everything: a last-reviewed date, so anyone (and the assistant) can see what is current and what might be out of date. Without these, a knowledge base is a confident liar in waiting: accurate today and quietly wrong in three months.
Build it to stay right, not just to be right on day one. One source of truth per fact, clear ownership of each area, and a last-reviewed date on everything. Accuracy wears away over time. The design has to work against that, or the knowledge base becomes a confident source of wrong answers.
Here is the part people miss. The value does not come from building the knowledge base. It comes from keeping it accurate over time. Anyone can set up an assistant in an afternoon. What matters is that someone keeps it trustworthy: who reviews the out-of-date sections, who catches the wrong answer before it spreads, and who is responsible when someone asks 'can I trust what this thing told me?'.
That ownership is a real job, not a side effect, and naming it as your job makes it clear who to ask. It also protects the team. A shared assistant with no owner is the dangerous version, because no one is watching for the wrong answer that reaches everyone. By taking on the curation role (keeping the content accurate and up to date), you make the assistant safe and make yourself the person the organisation relies on for it. The two go together: what helps them and what helps you are the same thing.
A shared knowledge base design, a working team assistant prototype, and the curation role that keeps it trustworthy. Building it is the easy part. Owning the accuracy over time is what keeps the team safe.
Someone kindly builds a team CS assistant. A rep asks it about a product's price, and it answers with a figure from a document loaded six months ago. The price changed three months ago. The rep trusts the assistant and quotes the old price to a customer. Three other reps had quietly done the same that month. The mistake did not happen once. It happened across the whole team, with confidence, for months.
Two things broke. First, the design. The old price sat in a loaded document with no last-reviewed date and no single source of truth. So when the price changed, the old figure stayed in the knowledge base, contradicting reality, and nothing marked it as out of date. Second, and more serious: no one owned the accuracy. The assistant had a builder but no one looking after it. There was no one whose job it was to update the price when it changed, or to notice the content had gone stale. The wrong answer reached everyone precisely because no one was responsible for keeping it right.
The design fix is structural: one source of truth for each price, a last-reviewed date on every fact, and a regular review of the sections most likely to change. But the real fix is ownership. One named owner takes responsibility for keeping the content accurate, with a process for updating facts when they change and reviewing out-of-date areas. That ownership is what keeps the knowledge trustworthy. The lesson works both ways: a shared knowledge base with no owner is a liability, and being the owner is how you turn it into your reputation.
What is the most important thing to raise before it goes live?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why is a shared team knowledge base held to a higher accuracy bar than your personal twin?
2. Which set of design choices best keeps a shared knowledge base accurate as products and prices change over time?
3. What actually makes someone the person the team trusts on AI?
Score: 0/3 ·
Design a small shared CS knowledge base. Pick three areas (say product facts, pricing and a key process), give each one a single source of truth and an owner, and put a last-reviewed date on each. Build a prototype team assistant on top of it. Then write down the curation process: who updates what, how often out-of-date areas get reviewed, and who is responsible when an answer is wrong. That last part is what keeps it trustworthy.
Testing, catching silent decay, and defending any output when someone pushes back
Anyone can build something clever once. The real skill is keeping it working: testing your systems properly, noticing when something has quietly got worse after a model update, and being able to defend any answer when an executive or auditor pushes back. This is what makes your systems safe to rely on.
There is a gap between someone who built a clever thing and someone who runs a reliable system, and that gap is maintenance. Everything you have built (the twin, the agent, the orchestrated routine, the shared knowledge base) decays the same way prompts do: models update, accounts change, facts go out of date. A system that was excellent at launch and then left alone for six months is not a slightly worse system. It is an unknown one, because nobody knows whether it still works.
This matters more for systems than for single prompts, because systems take action and other people trust them. A decayed prompt gives you one weaker answer. A decayed agent quietly does the wrong thing for weeks, and a decayed shared knowledge base gives the team wrong answers with confidence. All the value of what you built depends on it staying reliable, and reliability is something you keep working at, not something you reach at launch.
What separates a real builder from someone who made a clever thing once is maintenance. Your systems quietly get worse as models and facts change, and because they take action and people trust them, that is more dangerous than with a single prompt. Reliability is something you keep working at, not something you reach once.
Silent decay is the dangerous kind, because nothing warns you. The system keeps running, keeps producing confident output, and just gets quietly worse. The only protection is the same one you used for your prompt library, on a bigger scale: a test, run regularly, that would show the decline.
For each important system, keep a known-good test: a saved input and a record of what good output looked like. Re-run it on a schedule (monthly, say) and after any model update, and compare. If the output has drifted from the known-good example, you have caught the decay before it cost you, and you can find and fix the cause. This only works if you captured 'good' while the system was working. You cannot spot decay if you never recorded a baseline to compare against. The test is cheap. Thirty days of a decayed agent running unnoticed, like the example below, is not.
Decay is silent, so you cannot wait to notice it. You have to test for it. Keep a known-good baseline for each system, and re-run it on a schedule and after model updates. You can only spot decay by comparing against a baseline you recorded when things were working.
The more your systems matter, the more likely someone will challenge them. An executive asks 'how do you know this is right?'. A security or governance review asks 'what does this thing touch and how is it controlled?'. A colleague asks 'can I trust what it told me?'. Being able to answer is part of owning the system, not an afterthought.
You build the ability to defend a system in advance. You do not make it up in the meeting. For any system that matters, you should be able to say on one page: what it does, what data it touches and where that data lives, what it must never do, where a human checks it, and how you know it still works (your test). If you can explain a system that clearly, you can defend it, and others can trust it. If you cannot, it is a risk you do not yet understand, however well it runs. Writing the one-page defence often shows up a gap, which you then fix. That is the point: being able to defend a system and it being safe are the same thing seen from two angles.
A test and maintenance plan for everything you built, plus a one-page defence of your main system: what it does, what it touches, what it must never do, where the human checks are, and how you know it still works. If you can write that page, you can defend the system. If you cannot, you have found the gap to fix.
Your portfolio agent ran every Monday. You trusted it, and so did two colleagues you had shared it with. A model update landed mid-quarter. The agent kept running and kept producing confident, polished watchlists. But its reasoning about risk had quietly weakened. It stopped reliably doing the disconfirming check (looking for evidence against its own conclusion), so it under-flagged a couple of accounts that really were at risk. Nobody noticed for a month, because the output looked just as confident as before.
Nobody noticed because nothing was testing for decay. The system was trusted and left to run, and at a glance decayed output looks the same as good output. What would have caught it: a known-good test, meaning a saved real input and a record of the strong analysis it used to produce, re-run after the model update. Comparing the new output with the recorded baseline would have shown straight away that the disconfirming step had dropped out, catching the problem in days instead of a month.
The immediate fix is the module 5 move: restate the disconfirming check as a firm, non-optional instruction so a model update cannot quietly drop it, then re-run the test to confirm the output matches the baseline again. The lasting fix is the habit: that test now runs after every model update. And when your manager asks 'how do we know your agent is reliable?', you can answer with the one-page defence: what it does, what it touches, where you check it, and the test that proves it still works. That usually settles the question. The decay was a problem. Being able to show how you catch and fix it is what makes your work defensible.
What was the missing practice, and what fixes it going forward?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why is silent decay more dangerous in a built system (an agent or shared base) than in a single saved prompt?
2. What single thing makes it possible to detect that a system has decayed?
3. What is the practical test of whether a system you built is defensible to an executive or auditor?
Score: 0/3 ·
For your main system, capture a known-good baseline now: a saved real input and a record of the good output it currently produces. Schedule a re-run, monthly and after any model update. Then write its one-page defence: what it does, what data it touches and where, what it must never do, where you check it, and how the test proves it works. Note any gap that writing it shows up, and fix it.
Sharing and teaching what you have built, so people know the work is yours
The last step is turning all this into a reputation. How to share what you have built so it spreads and you still get the credit. How to teach others. How to have a say in your company's AI direction. And how to become the person people come to about AI, at your company and beyond.
You now work very differently from most of your peers, and you can measure it. But here is the trap that catches good builders: being able to do something does not automatically earn you standing. The CSM who quietly has good systems and tells no one is more productive, but nobody else can see the value. Documenting and teaching the work makes it useful beyond you, and gives others a fair view of your contribution.
This module is about deliberately turning what you can do into what you are known for. It is not bragging, and it is not optional if you want a career return on all this effort. The systems you built are the starting point. Standing is the result, and it does not happen by itself. You have to do it on purpose.
If you keep what you have built to yourself, it only helps you. When other people can use it, that is when you get known for it. One does not turn into the other by itself, and if you skip this step you do all the work and get none of the standing.
Your instinct is to guard your edge: if you built something great, keeping it secret protects your advantage. That is exactly backwards. The hoarder is a CSM with a private trick. It is useful until someone else builds the same thing, and then they are ordinary again. The teacher becomes the person the whole organisation links with the capability, and that lasts in a way a private trick never does.
So give it away on purpose. Run the lunch-and-learn. Share your library. Walk a colleague through building their first agent. Put numbers on the impact in a way leadership remembers. Not 'I use AI a lot', but 'I got back roughly six hours a week and put them into my top accounts. Here are the two saves and the expansion that came from it.' The hours you got back are the starting point. The saves and growth are the story. When every CS team is being asked 'what is our AI plan?', the person who has been visibly teaching the answer is worth far more than any private edge.
Giving your methods away beats hoarding them. The hoarder has a trick that becomes ordinary the moment someone copies it. The teacher becomes the person the organisation relies on for the whole capability, and that only grows as more people use it.
There are two places to do this, and both build up over time. Inside your company: be the voice in the room when AI direction is discussed, the one who has actually built things and can speak from real experience, not slides. Volunteer to shape the team's approach, the standards and the rollout. The person who built the capability and teaches it is the natural person to help steer it, and steering it is a leadership role whether or not it has a title yet.
Outside your company: the wider CS world is hungry for people who have really done this, not just talked about it. A post about something real you built and what you learned, a talk at a meet-up, a written breakdown of a system. Strip out anything that identifies a customer or your company's internal data, and check your employer's policy before you publish. These build a professional profile that outlasts any single job. The same work, done in public, turns standing inside your company into a reputation across the profession. You have spent this whole course building real things. This last step is about making sure people know that work is yours.
A plan to roll one of your builds out to your team, and a plan to position yourself: inside the company as the voice on AI direction, and outside it by sharing real work. The systems were the hard part. This step makes sure the work becomes your reputation.
One CSM builds excellent systems and keeps them to themselves, worried that sharing would wear away their edge. For a while they are quietly the most productive person on the team. Then the company rolls out AI training, three colleagues build similar systems, and the edge disappears. A year on, they are a good CSM with good tools, and no one particularly links them with AI. The skill was real, but the standing never came, because nobody knew.
Another CSM builds the same kind of systems and does the opposite. They run a lunch-and-learn, share the library, help two colleagues build their first agents, and tell leadership the value story with real numbers. When the company asks 'what is our CS AI plan?', leadership turns to them, because they are visibly the person who has been doing it. They get asked to shape the team's approach. A year on, they are having a conversation about a new title, they have a profile in the wider CS community from a couple of posts about real builds, and they have a reputation that would follow them to any job.
Both built equally good systems. The only difference was whether they made the work visible, and it led to completely different careers. The hoarder aimed for a private edge and got a temporary one. The teacher aimed to be known for the capability and earned lasting trust. Giving it away did not cost the teacher their advantage. It turned a fragile private edge into standing that grows as more people rely on them. The work mattered, but sharing it is what made the difference to their career.
Why is that advice likely to cost you in the long run?
You have reached the knowledge check. Each question is a real work scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. What is the main reason that being able to do something does not automatically earn you standing?
2. Why does teaching and sharing your methods build more lasting trust than keeping them as a private edge?
3. When telling leadership the value of your AI work, which framing builds the most standing?
Score: 0/3 ·
Pick one build you are proud of. Plan how to give it away: a short lunch-and-learn, or a shared, documented version a colleague could pick up. Write your value story in leadership's language: hours got back and put into specific saves and growth. Then draft one public post or talk outline about something real you built and what you learned. That is skill becoming reputation.
It records that you completed the Advanced course and its twelve knowledge checks: building assistants and workflows, and judging when to trust, overrule or keep AI out. It is not an accredited qualification.
Build yourself, build systems, lead. Each module ends in a hands-on build and a scenario knowledge check.
Harder than the Foundation course. Wrong answers come with an explanation. A module counts as complete only once its check is passed.
Finish all 12 and the certificate unlocks: enter your name and download it, dated and given a certificate ID. Made for your LinkedIn profile.
This is the actual certificate, rendered live. Yours downloads in full resolution as a landscape image and a square version made for LinkedIn.
Complete all 12 modules to unlock your certificate.
Nine modules on the actual job of leading a team into AI: the trust gap, the data line, the rollout that does not stall, proving value, and protecting the human core. Based on what CS leaders are really dealing with day to day.
Modules complete
No account, no cookies, and nothing you type leaves your browser. Your progress lives in this browser, so stick to the same browser to keep your place. To pass a knowledge check you need every answer right, and you can retake it as often as you like.
M01–M03 · your real job, the shadow use, the trust gap
Why leading a team through AI is a different job from being good at it yourself
Seeing how your team really uses AI, beyond the official version
Closing the gap between how much you trust AI and how much your team does
M04–M06 · the data line, the rollout, consistent quality
A one-page data and tool guide your team can follow and you can defend to senior leaders
The rollout plan that gets past your two enthusiasts to real, everyday use
Raising the floor without lowering the ceiling, and coaching people who lean on AI too much
M07–M09 · prove the value, governance, lead through change
How to measure what matters and report it honestly, so you keep leadership's trust and the budget
Clear ownership and oversight, so you can always explain a decision AI helped with
Protecting what has to stay human, and leading people honestly through real anxiety
Why leading a team through AI is a different job from being good at it yourself
Being good with AI yourself and leading a team through it are two different jobs. Plenty of skilled users make poor AI leaders, because the leader's job is to make the good way the easy, normal way for everyone, and to own the risk when it goes wrong.
Here is the trap that catches good CS leaders. They assume that because they are good with AI themselves, they can lead their team into it. The skills overlap, but leading a team is different work. Being good at AI is about your own work. Leading AI is about everyone else's: their habits, their fears, their shortcuts, and the risk they bring to your accounts. A brilliant individual user can run a chaotic, exposed team, and an average user can run a calm, capable one. The skills are different.
Your job as the leader is not to be the best prompter in the room. It is to make the good way, the safe way and the consistent way the easy, normal way for everyone, so the right behaviour happens without anyone having to be a hero. And it is to own the risk when something goes wrong, because it will. That is the leadership side of the job, and it is different from being a power user.
Your own AI skill and your job of leading AI are different things. The leader's job is to make the good way the normal way for the whole team, and to own the risk. Being the best prompter in the room is not the job, and mistaking it for the job is how capable leaders end up running exposed teams.
Most of the work of rolling out AI can be shared, taught, or handed to an enthusiast on the team. Three things cannot. These parts are yours, and naming them is the first step to doing the job well.
Everything else can be handed off. Take any one of these away and the team is exposed.
What data can go into which tools, and where the boundary is. Only you can set a line the team can actually follow and that you can defend to your exec team. An enthusiast cannot own this, because it carries real risk and needs authority.
Whether the team feels safe to be honest about how they really use AI, or hides it. You set this quietly, by how you react the first time someone admits to a shortcut or a mistake. The tone decides whether you ever see the truth.
When something goes wrong, and it will, you own it. Not the CSM who pasted the wrong thing, and not the tool that made up a figure. Owning the risk is what lets you set the line and the tone. It is the price of leading.
The line, the tone, and the risk. Everything else, from training and prompts to running sessions, can be shared or handed off. These three are yours, because they need authority and they have consequences. If you do not own them, no one does, and the team is exposed.
Of the three, tone is the one leaders underrate most, because you cannot see it and it never appears in a plan. But it decides whether your rollout works or quietly fails. If your team believes that admitting to an unapproved tool, or to relying too heavily on AI, will get them in trouble, they will simply stop telling you. And once you cannot see what is actually going on, you cannot lead it.
Tone is set in small moments, not announcements. The first time someone admits to using a tool you did not approve, your reaction teaches the whole team whether honesty is safe. React with curiosity ("interesting, why is that one better?") and you keep sight of what is going on. React with punishment and you lose it for good. The unofficial use does not stop, it just goes quiet. Setting a tone where the truth comes out is not being soft. It is how you lead what is actually going on, rather than the official version of it.
A clear picture of your real role, the three things only you can own (the line, the tone, the risk), and why tone is the quiet decider. The leader who makes honesty safe sees the truth and can lead it. The leader who punishes it manages a fiction.
Same budget and same approved tools as Team B. Six months in, Team A uses AI consistently and safely. The leader can say exactly what the team uses it for and where the risks are, and quality is steady. The leader is not the best individual user on the team: two of their CSMs are sharper with prompts. But the leader did three things. They set a clear, plain data line everyone understood, made it obviously safe to be honest about real usage, and took personal responsibility the one time something went wrong instead of hunting for someone to blame.
Same tools, same budget. Six months in, the leader genuinely does not know what their team uses AI for. Some people are quietly using unapproved tools. Quality is all over the place. There was a near-miss with customer data that the leader only found out about by accident. This leader is excellent with AI, better than anyone on Team A. But they treated leading it as a technical problem. They focused on showing off good prompts and never set a clear line. The one time someone admitted a mistake, they made an example of them, and after that the team went silent.
The difference was not skill, talent, tools or budget. Those were equal, or favoured Team B. The difference was that Team A's leader did the real leadership job: owned the line, set a tone where the truth came out, and carried the risk personally. Team B's leader did the power-user job, being impressive with AI, and left the leadership work undone. That is the whole module: leading AI is not the same as being good at AI, and confusing the two leaves a brilliant individual in charge of an exposed, silent team.
What is the core problem?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why can a CS leader who is excellent with AI still end up running an exposed, chaotic team?
2. Of the line, the tone and the risk, why is tone the one leaders most often underrate?
3. A team member admits they have been using an AI tool you never approved. What does your reaction in that moment really decide?
Score: 0/3 ·
Write down, honestly, how much of your AI effort goes into your own work and how much into leading the team. Then answer the three things only you can own. Where is your data line? What tone have you actually set about honesty (judged by how people behave, not by what you have said)? Do you really own the risk, or quietly hope it lands somewhere else? The gaps are your real job.
Seeing how your team really uses AI, not the official version
In Microsoft and LinkedIn's 2024 Work Trend Index, 78% of people using AI at work said they bring their own tools (source). Some of your team are almost certainly doing it and not telling you. That does not make them bad people. It usually means the approved options are not good enough, so they found their own. You cannot lead what you cannot see.
Every CS leader has two pictures of their team's AI use. There is the official one (what is approved, what people say in meetings) and the real one (what people actually do at 4pm on a deadline). The gap between them is where both your risk and your opportunity sit, and most leaders never see the real picture because nothing in their normal reporting shows it.
Here is the most important fact to take in. Most people who use AI at work bring at least some of their own tools, and they rarely mention it. This is shadow use, and it is not a few rogue people. It is normal for a modern team. So if your picture of your team's AI use is the official one, it is almost certainly incomplete. Not because people are lying to you exactly, but because nobody volunteers the shortcut they took under pressure. Leading the official version while the real one carries on underneath is the most common failure in this whole course.
You have two pictures of your team's AI use: the official one and the real one. Most leaders only ever see the official one, which means they are leading a fiction. Seeing the real picture, shadow use included, has to come first before you can lead any of it.
When you find out someone is using a tool you never approved, your instinct is to treat it as a broken rule. Act on that instinct and you lose sight of what your team is doing (the tone lesson from the last module), and you miss the more useful reading. Shadow use is information. Someone went out of their way to find and use an unapproved tool, which nearly always means the approved option you gave them is not good enough for the job. The rule-breaking is the symptom. The weak approved tool is the cause.
So when you find shadow use, the first question is not "how do I stop this?" It is "what is this telling me about the gap between what my team needs and what I have given them?" Sometimes you need a better approved tool. Sometimes the approved tool is fine and people did not know how to use it. Either way, the shadow use has given you genuinely useful information about the tools you provide, for free. A leader who only sees a broken rule throws that away, and loses sight of the team as well.
Shadow use tells you something about your approved options. It is not just a broken rule. Someone going out of their way to use an unapproved tool usually means what you gave them is not good enough. Look at the cause, not just the symptom, or you throw away real information about the tools you provide.
Once you can see the real picture, you can read the patterns, and different patterns need different responses. There are four to learn to tell apart, below. The most dangerous mistake is treating them all the same, because the person racing ahead and the person quietly drowning can look much the same in the numbers.
Using AI heavily and well, often including unapproved tools. An asset and a risk: they could be your champions, but they may be taking data risks or skipping their own judgement. Make good use of them. Do not just celebrate them or punish them.
Also using AI heavily, but relying on it beyond their own judgement. The work looks fine, but their underlying skill is fading. Looks like 'racing ahead' on the numbers. The hardest to spot, and the one that costs you a renewal later.
Barely using it, not out of defiance but because they do not know how or do not trust it. Needs support and an easy, safe way in, not pressure. Pressure turns frozen into resentful.
Avoiding it because they fear it puts their job at risk. Looks like 'frozen', but the cause is different, and the fix is the trust work in the next module, not a tutorial.
An honest map of how your team really uses AI, shadow use included, and the ability to tell the four patterns apart. The two pairs that look alike, racing ahead versus quietly at risk, and frozen versus scared, need opposite responses. Treating them the same is the costly mistake.
You find out, almost by accident, that about half your team has been quietly using an AI tool you never approved, because it is genuinely better at a common task than the approved one you gave them. Your first instinct is that half the team has broken a rule and you need to clamp down.
Clamping down would be the costly mistake. Half your team separately turning to the same unapproved tool is not a discipline problem. It is the loudest possible signal that your approved tool is not good enough for that task. They are not being reckless for fun. They found something that helps them do their job, and they used it. The shadow use has just told you exactly where the tools you provide are letting your team down. That is valuable, and a leader who only sees a broken rule throws it away.
Do not punish it, and do not ignore it either. Both are wrong. First, understand it. Talk to people with genuine curiosity about why that tool is better, and treat what they tell you as useful information. That also protects the honesty you need. Then deal with the real problem on two fronts at once. Tackle the data risk (the unapproved tool may be exposing customer data, which is the real concern, not the rule itself) by being honest about why the line exists. And close the gap in your tools: either get the better tool approved or fix how people use the approved one. You deal with the rule-breaking by fixing its cause, not by punishing the symptom and driving it underground.
What should your first move be?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why is leading from the 'official' picture of your team's AI use a serious mistake?
2. What is the most useful way to read the discovery that someone is using an unapproved tool?
3. Two CSMs both show heavy AI usage in your numbers. Why might they need opposite responses from you?
Score: 0/3 ·
For each person on your team, write down which of the four patterns they fit: racing ahead, quietly at risk, frozen, or scared. Be honest about how sure you really are, and notice where you genuinely do not know. That uncertainty is the gap in what you can see. Then, without punishing anyone, find one honest way to learn which tools your team is really using.
Closing the gap between how much you trust AI and how much your team does
One 2026 survey (WalkMe's State of Digital Adoption, 3,750 people in 14 countries) found 61% of executives trust AI with complex, business-critical decisions, against just 9% of workers (source; WalkMe is a software vendor, so read it as one survey). So when you push adoption, you are often asking people to rely on something they quietly do not trust, while some of them also fear it is coming for their jobs.
Here is a number worth thinking about: a gap of more than 50 points between leaders and their people. It comes from one vendor's survey, so treat the exact figure with care, but the direction matches what most CS leaders see. As the leader, you are much closer to the executive end than your team is. So your own comfort with AI is misleading you about how your team feels. You are standing on the confident side and assuming everyone is there with you.
trust AI for important decisions
trust AI for important decisions
To you, pushing adoption feels like encouraging an obviously good thing. To your team, it feels like being told to rely on something they do not trust.
This matters because of what it does to adoption. When you push your team to use AI more, it feels to you like encouraging an obviously good thing. To a nervous team member, it feels like being told to rely on something they do not trust, possibly by someone who does not understand why they are hesitant. You cannot see the gap from where you sit, which is exactly why rollouts stall in ways that baffle the leader. You are solving a tools problem while your team has a trust problem.
Leaders trust AI far more than their frontline teams do, and you are on the confident side of that gap. Your own comfort misleads you about how your team feels. Push adoption without closing the trust gap and the rollout stalls in ways you will not understand, because you are fixing the wrong problem.
Underneath a lot of the hesitation is a question people rarely ask out loud: is this coming for my job? If you do not deal with it, it sits there and quietly undermines every effort to get AI used, because nobody embraces a tool they believe is replacing them. And the way most leaders handle it makes things worse. They reach for the easy reassurance, "don't worry, AI won't replace you", which everyone rightly hears as either naive or dishonest.
The honest answer is harder to give, but it is more useful and more respected. It goes something like this: the work is genuinely changing, more of the routine parts will be done with AI, and that is real. I am not going to pretend otherwise. What stays valuable, and becomes more valuable, is the judgement, the relationships and the accountability that AI cannot provide. My job as your leader is to help you move up into that work, not to pretend nothing is happening. That answer treats people as adults, is honest about the change, and points to a real future. The empty reassurance treats them as children and earns no trust, which is the one thing you actually need from them.
The fear is real and rarely spoken: is this coming for my job? The empty reassurance ('AI won't replace you') is heard as naive or dishonest and makes it worse. The honest answer is open about the change, points to the judgement and relationships that become more valuable, and treats people as adults. That earns the trust the empty reassurance destroys.
Faced with a team that is not adopting, the instinct is to make it compulsory: require the tool, track the usage, push harder. This nearly always backfires, because the problem was never that people did not know they were allowed to use AI. The problem is that they do not trust it, or they fear it, and you cannot order your way out of a trust problem. A mandate on top of distrust gets you box-ticking: people use the tool just enough to satisfy the tracking, learn nothing, and trust it even less.
Trust is built slowly, and there is no shortcut. Let people see it work on low-stakes tasks first, so they gain confidence before the high-stakes ask. Be honest about its limits. The leader who admits where AI fails is far more trusted on where it works than the one who only sells it. Make it safe to be sceptical out loud, because a sceptic who feels heard becomes an ally, and a sceptic who feels steamrolled becomes quiet resistance. And answer the job-fear question honestly, again and again. None of this is fast. Trying to skip it with a mandate is exactly how rollouts die, while the leader wonders why the obviously good tool is not catching on.
A straight answer to the job-fear question that you can actually say out loud, and a way to build trust without hype or mandates. You cannot order your way out of a trust problem. Let people see it work on small things, be honest about its limits, make scepticism safe, and answer the fear honestly. It is slow, and in my experience it is what works.
One of your best CSMs, experienced and trusted by customers, has gone quiet on AI. They use it just enough to meet expectations and no more, and lately they seem flatter and less engaged in general. You suspect, rightly, that underneath it they believe AI is making their role pointless, and that the craft they spent years building is being reduced to checking a machine's output.
The tempting move is the warm reassurance: "don't be silly, we'll always need great CSMs like you, AI could never do what you do." It feels kind. But they hear it as either you not understanding their real fear, or you being dishonest to manage them, and to someone as experienced as they are, it sounds patronising. It costs you the one thing you needed, their belief that you are being straight with them. It also confirms their suspicion that the fear is real and you are papering over it. A strong CSM who is pulling back and decides their leader is not honest with them is a renewal risk and a flight risk.
You are honest about it. The work is changing, the routine parts really are moving to AI, and you are not going to pretend otherwise. Then you point to the real future, and you mean it. What makes them exceptional, their judgement, the trust customers place in them, their ability to read a room, becomes more valuable as routine work becomes cheap and easy to do. Your job is to help them spend more of their time there. Most importantly, you change something real, not just say words. You visibly take some routine work off them and put them on the high-judgement accounts or a mentoring role that proves the point. The honest conversation opens the door, but it is the real change that brings back their engagement. People watch what you do, so honest words on their own will not be enough.
What is the right approach?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why does a leader's own comfort with AI mislead them about their team?
2. Why is the reassurance 'don't worry, AI won't replace you' usually a mistake?
3. Your team is not adopting AI well. Why is making it compulsory and tracking usage likely to backfire?
Score: 0/3 ·
Write the honest answer you would give a team member who asked you straight out, 'is this coming for my job?' Make it true, not comforting. Then pick one nervous or sceptical person on your team and plan a low-stakes way for them to see AI genuinely help, before you ask anything high-stakes of them. Trust is built in that order: small win first, big ask later.
A one-page data and tool guide your team can follow and you can defend to senior leaders
Every CS leader needs a clear answer to one question: what data can go into which tools, and where is the line? Too loose and you risk the incident that sets AI back for everyone. Too tight and your team ignores you and goes back to unapproved tools. Your job is a line they can follow and you can defend.
Setting the data line is one of the three things only you can own, and it has the most immediate consequences. The trap is that both ways of getting it wrong feel safe at the time. Draw it too loose, letting real customer data into unapproved tools, and you are one careless paste away from an incident. That does not just hurt one account. It sets your whole team's AI use back, because after a breach everything gets locked down. Draw it too tight, banning anything that feels risky, and your team quietly ignores you and goes back to the shadow tools from module 2. Only now they hide it better, because the line is unreasonable.
A line nobody can work within does not keep you safe. It just pushes the risk out of sight.
So the line has to sit in a narrow band: tight enough to prevent a real disaster, loose enough that someone doing the actual job can realistically follow it. A line nobody can work within does not keep anyone safe. It just pushes the risk out of sight. The skill is finding that band, and writing it so plainly that a CSM up against a deadline can apply it without calling legal.
Both extremes fail and both feel safe. Too loose risks the incident that sets everyone back. Too tight gets ignored and pushes shadow use out of sight. The line has to be tight enough to prevent disaster and loose enough to follow. If nobody can work within the line, it only looks like a safeguard.
A line you can defend is built from a few plain decisions. It should be written so a busy CSM can apply it in seconds, not a policy only legal can make sense of. The four parts below are the whole thing. Keep it to one page in plain language, because people cannot follow a line they cannot remember.
Everyday work that carries no real risk once names and identifying details are taken out: ticket themes, draft structures, general questions. Swapping names for placeholders is not full anonymisation under UK GDPR if someone could still work out who it is, so keep the detail general. People should feel relaxed here, not nervous, or you have made the whole tool feel off limits.
Real account material: only in the approved tool, inside the agreed boundary, and anonymised where possible. Call it the 'approved tool, anonymised' zone and name it clearly, so people know the safe route instead of guessing.
The hard nos: security material, passwords and logins, anything under NDA going into an unapproved tool, real customer personal data outside the approved boundary, and anything your customer contracts or data processing agreements do not allow you to pass to a third-party tool. Short, absolute and explained, so people follow it because they understand it.
The most important part of all: who to ask, and a default of 'if unsure, anonymise or ask. Do not guess.' A line with no route for the unsure cases just leads to wrong guesses that nobody hears about.
One page, plain language: what is fine freely, what needs care (approved tool, anonymised), what never goes in, and what to do when unsure. A busy CSM should be able to apply it in seconds without calling legal. If they cannot remember it, they cannot follow it.
Your line will be tested from two directions, and a good leader holds the middle against both. From above, security and legal may push for a near-total lockdown, because the safest line for them is 'no AI'. That is not the safest line for a business that needs the productivity. Your job is to defend a workable line: show that it really does prevent the disasters while letting the team do real work. Otherwise you get the knee-jerk ban, which just creates shadow use nobody can see.
From the side, your team, especially your best people, will push back with 'but this other tool is better'. The wrong responses are the two easy ones: give in (and quietly let the risk in) or clamp down (and push it out of sight). The right response is the module 2 approach. Treat it as a signal, understand why the tool is better, and either get it properly approved or honestly explain the specific risk that keeps it off the list. The phrase that holds the middle is 'show me why it is better and let me see if we can approve it safely'. It respects the request, keeps you in the picture, and keeps you the one drawing the line, rather than the team drawing it for you where you cannot see.
A one-page line, and the ability to defend it in both directions. Against a security lockdown that would just create shadow use nobody can see. And against the 'this tool is better' push, by treating it as a signal and either approving the tool safely or explaining the real risk. If you give in, you let the risk in. If you clamp down, it just goes out of sight. You need to find the middle ground.
Your strongest CSM is quietly using an unapproved AI tool because it really does work better for a key task than your approved one. You have two obvious options: ban it firmly to enforce the line, or quietly look the other way because they are your best person and clearly know what they are doing. Both feel defensible, but both are wrong.
A flat ban treats the symptom and ignores the cause. Your best person found a real productivity gain, and banning it tells them the line is about control, not safety. That costs you their trust and their honesty. Worse, it does not stop the behaviour. It just drives it out of sight, so you have the same data risk and no view of it. You have lost sight of the risk while feeling safer, which is the worst place to be.
Ignoring it is the opposite failure. There may be a real data risk (the unapproved tool might be exposing customer data), and 'they are my best person' does not make the data safe. It just means your most capable person is carrying the most risk, and nobody can see it. The right move holds the middle. Treat the tool choice as the signal it is, find out exactly why it is better, and then either get it approved properly (run it past security, check how it handles data) or, if it really cannot be approved, explain the specific risk plainly so they follow the line because they understand it. Either way you keep your view of what is happening, keep their trust, and stay the person drawing the line. The skill is not taking either of the easy options.
What leadership move holds the middle?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why does drawing the data line too tightly fail, even though it feels like the safe choice?
2. What is the most important part of a usable data line, and the one leaders most often leave out?
3. Security wants to ban all non-approved AI tools. Why should a CS leader push back rather than simply agree?
Score: 0/3 ·
Write your one-page data line now, in plain language: what is fine freely, what needs care (approved tool, anonymised), what never goes in, and exactly what someone does when unsure. Then test it. Could a CSM up against a deadline apply it in ten seconds without calling you or legal? If not, it is too complicated to follow. Simplify it until they can.
The rollout plan that gets past your two enthusiasts to real, everyday use
Many rollouts win over the natural enthusiasts and then slow down. The hard part is everyone else: the cautious majority and the quietly resistant. This is a practical plan for getting past the keen few to consistent use, without a clumsy mandate that just gets people pretending to comply.
Most teams have a few people who would adopt AI whatever you did. They are curious, they like new tools, and they were probably using it before you said a word. The mistake leaders make is taking these early adopters as proof the rollout is working. They are not. They are the people who never needed convincing, and the usage numbers they produce hide the fact that nobody else has moved.
The enthusiasts' numbers hide that nobody else moved. Using enthusiast tactics on everyone else is how rollouts die.
The real work is everyone after the enthusiasts, and it decides whether you end up with a capable team or a couple of power users surrounded by people who never started. That means the cautious majority, who are willing but not driven, and the quiet resisters, who have reasons they are not saying out loud (often the trust and fear reasons from module 3). These people do not respond to what worked on the enthusiasts. Excitement and new features pulled the enthusiasts in. The majority needs something else entirely, and rollouts stall when leaders keep using enthusiast tactics on people who are not enthusiasts.
The two enthusiasts would have adopted anyway, so their usage does not prove the rollout works. It hides that nobody else moved. The real work is the cautious majority and the quiet resisters, who need completely different things from what pulled the enthusiasts in. Rollouts stall when leaders keep using enthusiast tactics on everyone else.
Adoption spreads through people and habit, not tools and announcements. The steps below work because they meet the majority where they are, not where the enthusiasts were.
Not 'use AI more', which is too vague to act on. Pick one specific, common task everyone does, and show a better way to do it with AI, so success is concrete and easy to copy. If the goal is vague, people will not know what to actually do.
The cautious majority is moved far more by a respected colleague saying 'this really saved me time' than by a push from their manager. Turn an enthusiast into a guide for a few peers. People copy colleagues they trust, so use that.
For cautious people, the hard part is the first use, not the hundredth. A small, low-stakes first win, with support, builds the confidence that makes the next step easy. Big asks make cautious people freeze.
Quiet resistance is usually about trust or fear (module 3), not laziness. Pushing harder makes it worse. Find the real reason and deal with that, and the resister often becomes your most careful user, because they needed to believe in it first.
Adoption spreads through people and habit, not tools and announcements. Start with one concrete shared workflow, spread it through respected peers rather than mandates, make the first step tiny and safe, and deal with the resisters' real reasons instead of pushing. Meet the majority where they are, not where the enthusiasts were.
When adoption stalls, the most tempting move is a mandate: require the tool, set a usage target, track it and push. It feels like decisive leadership and it produces a number that goes up. It is also the move most likely to kill real adoption, and understanding why is the heart of this module.
A mandate on a willing person is pointless, because they were going to adopt anyway. A mandate on a cautious or resistant person gets you box-ticking: they use the tool just enough to hit the target and keep the tracking happy, learn nothing real, and quietly resent it. That hardens the very resistance you were trying to overcome. So the usage number goes up while real capability stays flat or drops, and you have created a number that lies to you. Put honestly, a mandate turns a trust and habit problem, which you can solve slowly, into a compliance problem, which you cannot solve at all because it is the wrong way to look at it. The leaders who build real capability resist the mandate exactly when it is most tempting, which is when things have stalled.
A rollout plan that does not die after the enthusiasts: one concrete workflow, spread by peers, tiny safe first steps, and the resisters' real reasons dealt with. And the discipline to resist a mandate when it is most tempting, because it creates a usage number that lies while hardening the resistance underneath.
Three months into your rollout, the usage numbers look healthy. There is plenty of AI activity logged across the team, and you are tempted to call it a success. Then you look closer and realise almost all of it comes from the same two people who were keen users before you launched anything. The other eight on your team have barely moved. The number is real, but it belongs to the enthusiasts, and it is hiding a stalled rollout.
Faced with eight people who have not moved, the tempting fix is a usage mandate: everyone must log a minimum amount of AI use each week, and it will be tracked. Watch what happens. The eight cautious and resistant people do the minimum to hit the target, copying and pasting a token task or two, learning nothing, and quietly resenting being measured on it. Your dashboard number jumps, which feels like success. But real capability has not moved, and the resentment has hardened the resistance. You are now further from real adoption than before, while your numbers tell you the opposite. You have created a number that lies and made the underlying problem worse.
What actually works is not a mandate. It is meeting the eight where they are. Pick one concrete workflow they all do. Have one of the two enthusiasts (a respected peer, not you) show two or three of them how it really saved time. Make their first attempt tiny and supported. For anyone still resisting, find out whether it is trust or fear (module 3) and deal with that instead of pushing. This is slower than a mandate and gives you a worse-looking number next month, but it is far more likely to build lasting capability. The slower, honest approach works. A mandate just gets you a quick number that does not mean anything.
What will actually bring the eight on board?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why are healthy-looking adoption numbers, driven mostly by the early enthusiasts, a trap for a leader?
2. Excitement and new features pulled the enthusiasts in. What moves the cautious majority to adopt?
3. Why is mandating AI use the move most likely to kill real adoption, exactly when a rollout has stalled?
Score: 0/3 ·
Map your team onto the curve: who are your two enthusiasts, who is the cautious majority, and who is quietly resisting? Then plan the next step for the majority, not the enthusiasts: one concrete shared workflow, which respected peer will show it, and what the tiny first step is. For each resister, write down what you think their real reason is, and resist the urge to put a number on anyone.
Raising the floor without lowering the ceiling, and coaching people who lean on AI too much
Once the team is using AI, a new problem appears: quality swings wildly from person to person, and the work starts to sound the same. This module is about raising the floor without lowering the ceiling: a shared standard so customers get consistent quality, while your good people keep their judgement and their voice.
Once people are using AI, your quality job does not go away, it just changes. Two new problems appear, and they pull in opposite directions, which is what makes this hard. First, uneven quality: some people use AI to produce excellent work, others produce confident rubbish, and the customer's experience now depends on who they happen to deal with. Second, sameness: as everyone relies on the same tools, the work drifts towards a generic AI voice, and your team starts to sound like every other vendor.
The instinct that fixes the first problem makes the second one worse. Faced with uneven quality, leaders reach for rigid templates and compulsory prompts to force consistency. That does raise the floor, but it also lowers the ceiling. It crushes the judgement and voice of your best people and speeds up the sameness. So the real task is the harder one of doing both at once: lift the weakest work to a reliable standard without dragging the strongest work down to a template.
Success creates two new problems that pull in opposite directions: uneven quality (some produce excellent work, some confident rubbish) and sameness (everyone drifting towards a generic AI voice). The rigid-template fix raises the floor but lowers the ceiling. The real job is lifting the weakest work without crushing the strongest.
The way to get consistency without making everyone the same is to standardise the outcome, not the method. Set a clear bar for what good work must achieve, for example every customer email is checked for accuracy, sounds like a human wrote it, and includes a specific next step, without dictating the exact words or prompt used to get there. That raises the floor (weak work now has a bar to clear) while leaving the ceiling open (strong people clear the bar their own way and keep their voice).
Reviewing AI-assisted work fairly follows the same principle. You judge the work against the standard, not on whether they used AI, or which tool or prompt. The question is never 'did you use AI for this?' but 'does this meet the bar? Is it accurate, does it sound like us, does it help the customer?'. And you spread quality the useful way: take what your best people actually do and share it with everyone as a guide, not a rule. That way the strong lift the weak, instead of being dragged down to their level. The standard is the floor everyone clears. How they clear it is up to them.
Standardise the outcome, not the method. Set a clear bar for what good work must achieve and judge work against that, not on whether AI was used or which one. Share what your best people do as a guide, not a rule. The standard is the floor everyone clears. How they clear it stays up to them, which keeps the ceiling and the voice.
The hardest individual problem AI creates for a leader is the person whose numbers look fine while their judgement quietly fades. They lean on AI for everything, their work passes review, and on the dashboard they look like a strong adopter. But they have stopped being able to do the thinking themselves. The day a call goes off script, or something comes up that the AI prep did not cover, they freeze, because the skill that used to handle it has faded from lack of use. This is the 'quietly at risk' pattern from module 2, and it is dangerous because you cannot see it until the moment it costs you.
Coaching it takes care, because by the numbers the person is doing well. A clumsy intervention feels like punishment for success and knocks a good performer's motivation. Frame it as protecting their value, not correcting a failure. Say honestly that they handle the routine work well, and that their judgement, the live, unscripted, human part, is what makes them valuable and what they need to keep sharp. Then build regular practice of that judgement back in: the occasional account handled without AI prep, the live scenario rehearsed, the decision made and explained before they check the tool. You are not asking them to use AI less in general. You are making sure the skill underneath does not waste away. Frame it as an investment in them, because it is.
A shared quality bar that raises the floor without lowering the ceiling, fair reviews based on the work itself, and a way to coach the over-reliant CSM: the one whose numbers look fine while their judgement quietly fades. Coach it as protecting their value, not correcting a failure, and rebuild their judgement with regular practice before an off-script moment shows it up.
One of your CSMs has great numbers and clean reviews: a model adopter on paper. Then you sit in on a call that goes somewhere their AI prep did not expect, and they freeze, visibly lost without the script. Afterwards you see the pattern. They cannot really handle an escalation or an unscripted moment any more without running AI prep first, and when reality goes beyond the prep, the judgement that used to carry them is not there. It has faded from lack of use, hidden the whole time behind good numbers.
The tempting move is to treat it as a performance problem: tell them they rely on AI too much, that they need to cut back, and perhaps raise it in a review. To someone whose numbers really are good, this feels like being punished for doing well. It is confusing and demotivating, and it paints the very tool you spent three modules getting them to adopt as the thing they did wrong. You risk turning a strong performer against the whole idea, and against you, and you still have not rebuilt the missing judgement. You have just made them anxious about a tool.
Frame it as protecting what makes them valuable, because that is true. Say honestly that they handle the routine work really well, and that what makes them exceptional, the live judgement and the read of a hard moment, is exactly what froze on that call and is worth keeping sharp. Then build regular practice of it back in, framed as an investment, not a correction: rehearse the off-script scenarios, occasionally work through an escalation using their own judgement before checking the tool, and make the decision and explain the reasoning without help. You are not telling them to use AI less across the board. You are making sure the skill underneath the prep stays strong, so the next off-script moment finds them ready. Done this way, a good performer feels invested in, not punished, and the renewal risk hiding behind their numbers quietly goes away.
What is the right approach?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why does the rigid-template fix for uneven quality make the second problem, sameness, worse?
2. What is the key principle for getting consistent quality without making everyone the same?
3. Why is the over-reliant CSM, whose numbers look fine, such a dangerous case for a leader?
Score: 0/3 ·
Write your team's quality bar as outcomes, not methods: what must every piece of customer-facing work achieve, however it was produced? Then think about anyone who might be 'quietly at risk': strong numbers, possibly fading judgement. Plan some deliberate unscripted practice for them, framed as protecting their value, not correcting a fault.
How to measure what matters and report it honestly, so you keep leadership's trust and the budget
Sooner or later your VP asks the real question: what has all this AI actually done for us? A lot of leaders cannot answer it well. They have activity numbers but no proof of value. This module is about measuring what matters and reporting it honestly, so you keep the trust and the budget.
The trap most CS leaders fall into here is reporting activity and calling it value. 'The team ran 4,000 AI queries this quarter' and 'adoption is at 90 per cent' are activity numbers. They show the tool is being used, not that anything good came of it. A sharp VP hears these and asks the obvious next question, 'and what did that get us?'. If you have no answer, you have just shown that you measured the input and never checked the output.
Value is the change in business results, not how much the tool gets used. Did the team really get time back, and did they spend it on something that mattered? Were risks caught earlier than they would have been? Were renewals protected or expansions opened that you can link, even loosely, to what you built? These are harder to measure than query counts. That is exactly why most leaders fall back on activity, and exactly why the leader who can talk about real results stands out. Leadership funds value, not usage. Usage numbers show you spent the budget, not that it worked.
Activity (queries run, adoption percentage) shows the tool is used, not that anything good came of it, and a sharp VP will ask 'what did that get us?'. Value is the change in results: time properly reinvested, risks caught earlier, renewals protected. Leadership funds value, not usage. Reporting activity proves you spent the budget, not that it worked.
A few honest measures of results beat a dashboard full of activity. You are not aiming for precision, because you will rarely be able to prove cause and effect cleanly. You are aiming to link what you built to things leadership already cares about, in their language.
Hours saved is half the story, and the weaker half. The stronger half is where those hours went: more time on at-risk accounts, more face time with key customers. 'Saved' is a cost story. 'Reinvested into X' is a value story.
Cases where the team spotted a churn signal or an issue sooner than they would have, because the new way of working flagged it. Catching things earlier is worth real money, and leadership gets that straight away.
Renewals protected and expansions opened that you can link, even loosely and honestly, to what you built. An honest, rough link to results is worth more than precise activity numbers that do not show anything.
It sounds odd, but this is a value measure too. Saying where AI has not helped, or where adoption is really stuck, makes every other number you report believable. Being honest about the bad news is what earns trust in the good news.
A few honest measures of results beat a dashboard of activity: time reinvested (not just saved), risk caught earlier, renewals or expansions you can trace, and an honest account of what is not working. A loose but honest link beats precise but meaningless counts. Talk about the results leadership already cares about, in their language.
When you are asked to prove value, the pressure is to oversell: claim more than you can back up, credit AI with every good thing and hide what is not working. It buys you one good meeting and costs you everything after it. The first time a claim does not hold up, every number you report from then on gets discounted. If you overclaim once, leadership starts doubting everything else you report.
The honest report is the one that builds over time. Include what is not working, and be clear about how far your claims go ('we cannot prove this renewal was down to AI, but the early warning that flagged it came from the new process'). It might feel weaker in the meeting, but it holds up much better over time. A leader who is honest about the bad news gets believed on the good news. A leader who only ever reports wins is quietly assumed to be spinning. The aim is not to win one meeting with an inflated number. It is to become the person whose numbers leadership trusts. That is what protects the budget over many meetings, and it is worth far more than one impressive claim that falls apart under a question.
A short, honest set of measures and a one-slide answer to 'what has AI done for us'. Do not overclaim: it wins one meeting and undermines every number after it. Report what is not working and be clear about what you cannot prove. Being honest about the bad news is what makes you the leader whose numbers are trusted, and that is what protects the budget.
Your VP asks what AI has delivered this quarter. The tempting slide is a wall of activity: 90 per cent adoption, 4,000 queries, every CSM 'using AI daily', and a confident headline like 'AI saved the team 600 hours and drove this quarter's renewals'. It looks impressive for about ten seconds. Then the VP asks 'how do you know it drove the renewals?' and 'what did the 600 saved hours actually produce?'. You have no answer, the slide falls flat, and your credibility goes with it.
The strong slide drops the activity numbers and the headline you cannot back up. What goes on: the team got back roughly six hours each per week (given as an estimate, not a precise claim), and exactly where those hours went. More time on at-risk accounts, which links to two named saves this quarter where the early warning came from the new process. It also includes, on purpose, one honest line about what is not working: adoption is strong on call prep but has stalled on risk analysis, and here is the plan. The number to leave off is the big 'AI drove the renewals' claim. You cannot back it up, and making it puts every other number at risk.
The weak slide might get through one meeting if nobody asks questions, but it is fragile. One good question brings it down, and even if it survives, the inflated claim is a debt that comes due later. The strong slide is more modest on the day and lasts far longer. The VP can see exactly what is real, the honest 'not working' line makes the good news believable rather than suspicious, and you become the leader whose numbers can be trusted. That trust is what protects the budget over the next year of meetings, which is the real game, not the single slide. The honest, slightly less impressive answer is the one that keeps the funding.
What belongs on the slide, and what should you leave off?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why is '90% adoption and 4,000 queries' a weak answer to 'what has AI done for us'?
2. What makes 'time reinvested' a stronger value metric than 'time saved'?
3. Why does including what is NOT working make your report to leadership stronger?
Score: 0/3 ·
Build your one slide now. Drop every pure activity number. Write down where the time you got back actually went, what risk was caught earlier because of the new way of working, what result you can trace to it (even loosely and honestly), and one true thing that is not working. Then find the tempting overclaim you were going to make, and cut it.
Clear ownership and oversight, so you can always explain a decision AI helped with
Grant Thornton's 2026 AI Impact Survey of nearly 1,000 US business leaders found 78% lacked full confidence that their organisation could pass an independent AI governance audit within 90 days (source). If company leaders feel that way, most CS teams are further behind. This module is about getting ahead of it: knowing who is accountable for what, and being able to show your team uses AI deliberately and with control, not by accident.
At some point, someone with authority is going to ask how your team's AI use is governed. It might be security, legal, a regulator, or your own leadership after something has gone wrong elsewhere. Most CS leaders are not ready. They have a vague sense that the team is sensible, but no real answer to 'who is accountable for decisions AI helped with, and how do you control this?'. 'We're careful' is not an answer. It is the lack of one, and it falls apart the moment someone asks the question seriously.
Being ready does not mean heavy bureaucracy. The fear that it does is why leaders put it off until they are forced. It means being able to show that your team uses AI deliberately and with control, not by accident and hoping for the best. The difference between a quiet risk sitting on your team and something you can stand behind is whether you can answer the governance question with evidence rather than reassurance. The only good time to build that answer is before you are asked. Building it in the middle of a real incident or audit is far worse.
Someone with authority will eventually ask how your team's AI use is governed, and 'we're careful' is not an answer. Being ready is not heavy bureaucracy. It is being able to show your team uses AI deliberately and with control, not by accident. Build that answer before you are asked, because building it during an incident is far worse.
Being audit-ready (able to show how your team keeps AI use under control) is lighter than it sounds. Three things cover most of it. None needs a compliance department, just clear answers you can produce when asked.
Who is responsible for decisions AI helped with: the CSM who made the call, who owns the output whatever tool they used. 'The AI decided' is never an acceptable answer. A named person always owns it. Make that a principle the team understands.
Your module 4 data line, written down and actually followed. A line you can show when asked, and that the team really applies, covers most of what 'how do you control this' is asking. A line that is unwritten or ignored is no control at all.
A regular, sensible way of actually checking: spot-checking work AI helped with, knowing where the risk sits, and catching a problem yourself before it becomes an incident. It has to be checking you actually do, not something you say you do.
Three things, none needing a compliance department: clear accountability (a named person always owns the decision, never 'the AI did it'), a written line that is actually followed, and light, real oversight that you actually do. Together they let you answer 'how do you control this' with evidence rather than hope.
The main point of oversight is not to keep an auditor happy. It is to be the person who catches the problem on your own team before it becomes the incident that brings the audit in the first place. A leader with real, light-touch oversight notices the CSM leaning on AI more than their own judgement, the account where something does not look right, the slide towards a tool that has not been approved, while it is still small and fixable. A leader with no oversight finds out the same way everyone else does: once it has already gone wrong and become someone else's question.
This is the difference between AI being a quiet, unchecked risk on your team and being something you can truly stand behind. You cannot just claim to stand behind it. You earn that by actually looking: knowing where the risk sits, checking in proportion to it, and acting early on what you find. When the governance question comes, the leader who has been doing this can answer calmly with evidence. More importantly, they have probably already prevented the incident that would have made the question hostile. Being ready and preventing problems are the same habit: looking at your own team's AI use deliberately. Almost no leader does this until forced, and it is the whole point of this module.
A simple setup for ownership and oversight, so the governance question never catches you out. Its main value is not passing an audit. It is catching the problem early, before it becomes the incident that starts one. Being ready and preventing problems are the same habit: deliberately looking at your own team's AI use, which almost no leader does until forced.
Months later, a decision one of your CSMs made, partly based on AI analysis, is questioned. Perhaps a renewal call went wrong, perhaps a risk was missed. Someone with authority asks you to explain how that decision was made, who was responsible for it, and how your team's AI use is controlled in general. This is the governance question in its sharpest form: about a specific decision that is now under scrutiny.
Ask yourself honestly whether you could answer right now. Could you say who owned that decision, a named person, not 'the AI suggested it'? Could you show the line that set out what data could go into the tool, and show it was followed? Could you show any oversight that should have caught a problem, or explain why this one got through? For most leaders the honest answer today is no. They would be piecing it together in a panic, and the gaps would show. Panicking after the fact, under scrutiny, is the worst possible time to find out you were never ready.
Three things, all of which you can build in advance, and none of them heavy. First, accountability was clear all along: that CSM owned the decision and used AI as input, and everyone understood that, so 'who was responsible' has a clean answer. Second, the written data line existed and was followed, so you answer 'how is this controlled' by showing it and showing how the team works. Third, you had light oversight, so you can either show it should have caught this and will be tightened, or honestly show this was a real edge case outside reasonable controls. That is a fair answer when the controls are real. The leader who built these three can answer a hostile question calmly with evidence. The leader who did not is exposed. The lesson is that the only time to build the answer was before the question, which means now.
What three things determine whether you can answer well?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why is 'we're careful' a failing answer to 'how is your team's AI use governed'?
2. What is the deepest value of having real oversight of your team's AI use?
3. When a decision AI helped with is challenged, why must a named person always own it rather than 'the AI'?
Score: 0/3 ·
Test yourself today. If you were asked right now to explain how a specific decision on your team that AI helped with was made and controlled, could you? Write down your honest answer for each of the three: is accountability clear (a named person owns decisions), is your data line written down and followed, and do you have any real oversight? Each 'no' is a gap to close before the question arrives.
Protecting what has to stay human, and leading people honestly through real anxiety
This last piece matters most over time. As more work gets automated, the leader's job is to protect the parts of Customer Success that have to stay human: the judgement, the relationships, the craft. And to lead a team through the real anxiety of all this without pretending it is not there.
Everything in this course so far has been about building your team's AI skills. This final module is about what those skills must not be allowed to wear away. If they do, you end up with an efficient team that has lost the reason customers stayed. Some parts of Customer Success are not waste to be cut out. They are the actual product: the judgement that reads a situation no dashboard picks up, the relationship a customer trusts when things go wrong, a hard conversation handled well. These have to stay human, not for sentimental reasons, but because they are what your team is really for.
The leader has to protect these on purpose, because nothing else will. Left alone, the push for efficiency quietly eats them. Every human touch starts to look like a cost to cut, until you have automated the relationship out of a relationship business. Deciding what stays human, and defending it against your own drive for efficiency, is a leadership decision. It is also more and more a competitive one. When everyone has the same AI, the team that kept its human core is the one customers can tell apart from the rest.
Some parts of CS are not waste to cut out. They are the actual product: the judgement, the relationships, the craft. Left to the push for efficiency, they get quietly eaten. The leader's job is to protect them on purpose. That is a leadership decision and, when everyone has the same AI, a competitive one too.
Your team is carrying real anxiety about all this: the job fear from module 3, now made deeper by months of watching the work change. Again, the temptation is the comforting lie: nothing is really changing, you are all safe, do not worry. It fails for the same reason it did in module 3. People can tell, and it costs you the trust you need to lead them through what really is a hard change.
Leading through it honestly means doing three things at once. Be truthful about the change: yes, the work is shifting, more of the routine parts are being automated, and that is real. Point to what lasts: what makes them valuable, their judgement and relationships, is becoming more important, not less, and that is also real. And change something to prove it, rather than just saying it: visibly put your team's freed-up time into the human, high-judgement work, so they live the future you are describing instead of just hearing about it. Reassurance does not ease the anxiety. A leader who is honest about the change and is clearly moving the team towards the valuable part of it does. That is what people will follow.
The team's anxiety is real and the comforting lie fails, because people can tell. Lead through it by doing three things at once: be truthful about the change, point to the human core that is becoming more valuable, and prove it by visibly moving the team's freed-up time towards that work. What eases the anxiety is honest action, not reassurance.
Bringing the whole course together, here is what good looks like for a CS team in a world full of AI. AI does the pulling together and the routine work to a consistently high standard. The team's judgement sits at the centre of every decision that matters. Relationships are deeper because people have more time for them, not less. And everyone, including the nervous and the once-resistant, understands where they really add value and is being moved towards it. It is a team that used it to become more of what it was for.
Getting a team there takes everything in this course. You saw the real picture, closed the trust gap honestly, drew a line you can defend, brought everyone along without forcing it, held quality without crushing people, proved value truthfully, stayed ready for the hard questions, and protected the human core through the change. None of it was about being the best with the tool. All of it was about leading people through a real change with honesty and judgement, which is the oldest leadership job there is, in new clothes. The leaders people follow through this are not the most technically impressive. They are the ones who were honest about the change and clearly put their team's interests first.
A clear picture of what good looks like: a team that used AI to become more of what it was for, with judgement at the centre, deeper relationships, and everyone moved towards where they add value. And a way to lead people there honestly. The whole course in one line: leading people through a real change with honesty and judgement, which is the oldest leadership job there is.
A capable team member comes to you, or you sense it without them saying it, with a specific version of the job fear. Not that they will lose their job, but that the job itself is being hollowed out. That they are being turned into someone who just checks the AI's output, a quality control step on a machine, rather than the skilled CSM they trained to be. It is a real fear, and unlike a vague worry it is precise, so a vague reassurance will clearly miss it.
The two easy responses both fail. The comforting lie, 'don't worry, you're so much more than that, nothing's really changing', misses the actual fear and comes across as not listening, because they have rightly noticed that something is changing. The dismissive version, 'this is just the way things are going, adapt', is honest about the change but leaves them to deal with it alone, which confirms their fear that they are now just a cog in the machine. Both lose the person: one by not being honest, the other by not caring. The fear is precise and deserves a response that is both honest and committed to them.
You agree with the true part of their fear, which takes the heat out of it. Yes, if the job became nothing but checking AI output, it would be a worse job, and you are not going to pretend that risk is not real. Then you honestly reframe it around what lasts. The checking is not the job, it is the minimum. The part that makes them valuable is growing, not shrinking: the judgement about which of the AI's reads to trust, the relationship that turns a flagged risk into a saved account, the hard conversation no AI can have. Then, and this is the crucial part, you change something real to prove it. You visibly move them towards more of that human, high-judgement work and less pure output checking, so they live the reframe instead of just hearing it. Being honest starts the conversation, but it is the real change that brings them back on board. Someone who was quietly deciding the job had lost its meaning gets back on board, because their leader was straight with them and then did something about it. That one conversation is the whole module.
What is the right response?
You have reached the knowledge check. Each question is a real leadership scenario. Answer them all before you see the answers. You need every answer right to pass, and you can retake it as often as you like.
1. Why must a leader protect the human parts of CS on purpose, rather than assuming they will survive on their own?
2. Why does 'nothing is really changing, you're all safe' fail when leading a team through AI anxiety?
3. According to the course, what does 'good' look like for a CS team in a world full of AI?
Score: 0/3 ·
Write down the parts of your team's work that have to stay human (the judgement calls, the relationships, the conversations) and one way the push for efficiency is quietly threatening each. Then take the person on your team who is most anxious about the change and plan the honest conversation: the true thing you will acknowledge, the lasting value you will point to, and the real change you will make to prove it.
It records that you completed the Leaders course and its nine knowledge checks. It is not an accredited qualification.
Get honest, build the capability, prove and protect it. Each module ends in a real leadership scenario check.
Real leadership situations where two answers look reasonable and you have to pick the better one and know why.
Finish all 9 and the certificate unlocks: enter your name and download it, dated and given a certificate ID.
This is the actual certificate, rendered live. Yours downloads in full resolution as a landscape image and a square version made for LinkedIn.
Complete all 9 modules to unlock your certificate.
You get it once you have completed every module and passed every knowledge check in this browser. It is not an accredited qualification, and it does not check how the work was done, but it is a fair way to show the time you put in, and you can add it to LinkedIn.
Lessons, drills, and worked examples, with exercises that put each module to work on your live portfolio. Self-paced, and built to fit around the day job.
Each module ends in a short scenario quiz that explains any wrong answers. A module only counts as complete once its knowledge check is passed, so the certificate means what it says.
Finish all 10 and the certificate unlocks: enter your name and download it instantly, dated and given a certificate ID. Anyone can check the name and ID match at /verify.
This is the actual certificate, rendered live. Yours downloads in full resolution as a landscape image and a square version made for LinkedIn.
Your name goes on it and it downloads as an image, ready to share. Your progress in this browser counts automatically, and the button unlocks when you are done.
Your saved and custom prompts, all in one place.
Add a custom prompt to your library.
Tap any tile to jump to its module. Built so you can scan it in about 30 seconds.
You brief, AI assembles, you own.
Open the module →Synthesis, drafting, pattern, rehearsal.
Open the module →Invention, context blindness, generic, no accountability.
Open the module →Status, since, open, risk, opportunity, the one question.
Open the module →Base → public → connect their world to your account.
Open the module →No "delve," "leverage," "I hope this finds you well."
Open the module →Engagement, relationship, commercial, strategic.
Open the module →Deep dive when flagged. Radar every Monday.
Open the module →Products × the customer's full org. Find the gaps.
Open the module →Your own prompt library, used every week. Using it every week matters more than clever prompts.
Open the module →If you would be embarrassed when a customer asks "did you write this?", write it yourself.
Open the module →Eleven frameworks for designing, judging, and defending what you build. Tap any tile.
Anything reused twice gets saved and named.
Open the module →Name by job, version it, test it, retire stale.
Open the module →Capture your standards, voice, judgement, banned words.
Open the module →Absolutes over guidelines. Examples embedded. Test under pressure.
Open the module →Pulling work together is safe to automate. Taking action never is.
Open the module →Goal + limits + checkpoints, never a brittle step list.
Open the module →Data combining? Lean tool. Context only you have? Hold ground.
Open the module →Check the work at the first hand-off. Mistakes grow at every step after.
Open the module →Shared knowledge base. Own the accuracy.
Open the module →Baseline tests on a schedule. Defend with input, process, check.
Open the module →Share it. Teach it. Shared work keeps paying off; private work does not.
Open the module →Nine frameworks for setting policy, running rollouts, and answering hard questions upward.
Too tight drives shadow use. Too loose risks the incident.
Open the module →Peers, tiny first steps, address the resisters' real reason.
Open the module →Standardise the bar. Coach the over-reliant.
Open the module →Hours recovered, what they bought. Show what changed.
Open the module →Every decision: input, tool, reviewer, why it holds.
Open the module →Relationships, judgement, the live moment, accountability.
Open the module →Every Customer Success role, at every scale, does two fundamentally different kinds of work: work that can be assembled, and work that must be present. AI changes the first kind a lot. I don’t believe it can do the second. The Method is how you handle both, and the transition between them.
The AI-powered CSM week has two disciplines. Direct is how you produce assembled work by directing AI. Present is how you show up for moments that require your undivided judgement. Between them sits The Shift, the transition where it is easy to bring the wrong mode into the wrong moment.
This is about where your attention goes, whatever tools you use. In Direct mode, AI does the assembly under your instruction. In Present mode, AI can still assist (transcribing, capturing, retrieving) but never substitutes for your judgement, your relationship, or your own voice in the room.
You have been briefing, verifying, editing for an hour. Now you are on a customer call in three minutes. The analytical rhythm is still on. The operator voice is still in your head. You show up ready to process a customer rather than meet one, and they feel it before you notice it.
The Shift is about properly arriving for the call. Close the tabs, take thirty seconds and switch off the analytical mode. The call does not need optimising, it needs your attention. This is the smallest practice in the Method and the one CSMs most often skip. It is also the one your customers notice most.
Take the Tuesday afternoon most CSMs know. Forty minutes of brief-building and verifying, straight into a strategic account call. Six minutes in, your contact mentions offhand that their manager has "been quiet lately." Analytical voice is still on. You file it as a data point and move to the next agenda item.
Two weeks later that manager announces a reorganisation. Your contact gets moved off the account. The renewal comes in at a reduced scope.
If you had heard "been quiet" in Present mode, you would have caught it as the signal it was. You heard it as data. That is the Shift failure. It is not dramatic or obvious. Just the wrong mode carrying into a moment that needed the other one.
Some CS moments are neither purely assembled nor purely present. A Slack message that arrives during a customer call. An unexpected email at 4pm between deep work and a meeting. A curveball question in a QBR that needs both a considered answer and your full attention on the person asking.
These are hybrid moments, and they are where most Direct/Present failures actually happen. The failure mode is to default to the mode you were just in. If you were in Direct, you process the moment mechanically. If you were in Present, you improvise instead of thinking.
The discipline is the three-second pause. Which mode does this specific moment need, right now? Then act in that mode with full commitment. That quick pause is the whole Method in small, and you will do it many times a day.
Present work is anything that requires undivided attention, human judgement, or your own voice: live customer conversations, the moment a hard question lands, the negotiation, the difficult renewal, the pause after bad news. AI can assist here (transcribing, retrieving, capturing) but never substitutes. Four practices, held simultaneously:
Show up ready, before the conversation starts.
Use what Direct produced. Walk in with the brief in your head, not on your screen. If you are reading it live for the first time, you did not do Direct properly.
Assist is fine. Substitute is not.
A transcription tool running in the background is assistance. Live AI drafting your responses while you nod at the customer is substitution. The test: is your attention on them, or on managing what the AI is doing? Customers can tell the difference before they can name it.
You know things AI cannot.
The unspoken thing in the room. The context between the lines. The colleague's tone last Tuesday. Present is where those signals matter, and where you back yourself to read them without a second opinion from a model.
Every word ships under your name.
The renewal, the relationship and the judgement call are yours. Direct gets you prepared; Present is where you use that preparation.
Not a rule about which tools you use. Use whatever tools you and your customers agree to. Fireflies, Otter, Gong, Copilot, all fine, provided the customer knows and your attention stays on them.
Not a ratio about your week. The 80/20, 50/50, 30/70 splits are illustrative. What matters is that every CSM week has both kinds of work, and treating them as one blurred activity is the mistake.
Not a claim that AI is dangerous. AI is genuinely useful for assembled work and genuinely useful (as an assist) even in present work. The problem is when you let AI stand in for the part of the job only you can do.
Not a method for one kind of CSM. Direct/Present holds at Enterprise, mid-market, and tech-touch. The disciplines are the same. The volumes differ.
The direction is clear enough to plan for. Over the next few years, I expect more of the assembled work will be handled by AI without a human touching it. Voice AI will hold routine conversations. Agents will run parts of the CSM week that never involved you before.
Present will not disappear. It will get smaller in volume and much larger in weight. The moments that require a human in the room will become rarer, more concentrated, and more consequential. Renewals will need fewer touchpoints, and each one will carry more of the outcome.
The Method is how you get good at both trajectories now. So when Direct expands, you have the discipline to protect what only you can do. And when Present concentrates, you show up for it at a standard the field has not yet caught up to. The CSMs who thrive on the other side of this shift will not be the ones who used AI first. They will be the ones who understood the two disciplines earliest, and got serious about both.
The Method scales to team level through three commitments that draw the Direct/Present boundary for the whole team, not just for you.
What data goes where. Strict enough to prevent an incident, and clear enough that nobody works around it.
Is honesty about real AI use safe on this team, or does the team perform compliance and route around you?
When it breaks, you own it, whoever pasted it and whatever the tool made up. Owning the risk is the price of leading.
The whole Method in one line: Direct the assembled work. Be present for the moments that require it. Manage the shift between them, and never let one mode carry into the other.
The short version: nothing you type on this site is sent anywhere. Your progress stays in your own browser. Here is the detail, written for you and for your security team.
Your course progress, quiz results, saved prompts, favourites, playbook ticks, Situation Read saves and notes. They are stored in your browser’s own storage on your device. I cannot see them, and they are never uploaded.
The trade-off: if you clear your browser data or switch device, your progress does not come with you.
The Prompt Grader, Situation Read, the Anonymiser, the Fluency Score and Gary all run inside your browser. Nothing you paste or type into them leaves your device.
When you choose “Copy prompt and open Claude” (or ChatGPT, Copilot or Gemini), the text is copied to your clipboard. You decide whether to paste it, into the AI tool your company has approved.
The site uses Netlify’s own analytics, which counts page visits from the server. There are no cookies and no advertising or tracking scripts. To see whether the site is useful, it also counts a few events, once per browser: a module or course completed, a certificate created, a prompt copied or a Skill downloaded. Each one records only the module, course, prompt or Skill name. Like any web host, Netlify receives standard request details such as IP address and browser type, and keeps them with these counts. I only look at the totals.
It never records what you type, your name, or your answers.
Your certificate is created in your browser. Your name goes onto the image you download and into the certificate ID. It is not sent to me or stored anywhere else.
Anyone can check a certificate on the certificate check page using the name and ID.
This site teaches you how to use AI with customer information safely, but it never handles that information itself. When you use the prompts, you run them in your own AI tool, under your own company’s agreement with that provider. Before you paste anything customer-related:
The full rules are on the AI Governance page.
/t/course-foundation. Completions, prompt copies and Skill downloads are also logged through Netlify Forms with the item name only. Netlify sees standard request details, such as IP address, as it does for any web page. No advertising or tracking scripts.Last updated October 2026.
From what I can see, several of our CSMs are already using AI, each in their own way. I am proposing we give the whole team the same method, the same rules on customer data, and a way to show the results. There is no licence cost, and a first pilot takes about four weeks of team time.
The AI-Powered CSM (ai-powered-csm.com): a free course and toolkit built by a working CSM for Customer Success teams. A ten-module Foundation course, 77 prompts for Claude, ChatGPT, Copilot and Gemini, 49 Claude Skills, playbooks, and a certificate for each person who passes.
[Your ask, e.g. “Approval to run this with the team from next month, and 30 minutes in our next leadership meeting to share the results after 30 days.”]
Most of what makes this job hard happens around the customer conversation: the prep, the chasing, the risk you didn’t see coming. These are the challenges I hear about most, and how I use AI on each one. AI does the gathering and the first draft. You still make the call.
Find the one that sounds like your week, and start there.
“I don’t know where to start on a Monday.”
Ranks your book by renewal date, open cases and recent signals, and gives the reason for each.
Decide which three accounts get your best hours this week.
“I’m reading the account history five minutes before the call.”
Turns your notes, open cases and the last meeting into a one-page brief, with questions to ask.
Pick what matters and run the conversation.
“The risk was there for months. I just didn’t see it.”
Pulls together usage, case load, sentiment and stakeholder changes, and flags what could stop the renewal.
Judge how real the risk is, and act on it early.
“I spend more time on the deck than on the conversation.”
Builds the value story from usage and outcomes, with three clear asks.
Shape the message for the room and lead the discussion.
“The customer can’t say what they’re getting for the money.”
Turns the customer’s own goals and results into a short value case, in their language.
Check every number and decide what to lead with.
“My main contact has gone and I don’t know the new person.”
Researches the new stakeholder and drafts a first email around what they are likely to care about.
Build the relationship.
“I meant to send the follow-up. Then the week happened.”
Turns rough call notes into a summary and a follow-up email, with owners and dates.
Check it and send it the same day.
“I don’t want to push products they don’t need.”
Finds the gaps in the customer’s own words, in their cases and goals, and builds the case from those.
Decide whether it genuinely helps the customer before you raise it.
“It’s broken and their exec is now on the email.”
Drafts a clear escalation note and customer update: what happened, the impact and the next steps.
Own the conversation with the customer.
“I rebuild the same plan for every new customer.”
Builds an onboarding and success plan from why they bought and what success looks like to them.
Agree it with the customer and hold both sides to it.
“I’ve been asked to join a pre-sales call on top of my book.”
Prepares who’s in the room, the discovery questions to cover and a clean handover to Sales.
Bring the real customer stories that only CS has.
“They were acquired and I found out in the QBR.”
Scans public news on your accounts each Monday for leadership changes, acquisitions and budget news.
Decide which of those change your plan.
The same idea, for the challenges of running a team.
“Everyone has their own prompts and nobody shares.”
Gives the team one shared set of prompts and Claude Skills for the work everyone repeats.
Agree how your team works, and keep it up to date.
“I know it’s helping. I can’t prove it.”
Drafts a short monthly summary from the examples your team shares.
Choose the story you tell, and back it with real examples.
“They don’t have the context yet.”
Account briefs and call prep give new starters the context they’re missing, fast.
Coach them on the conversations.
Every Skill and prompt here is built for you to check the output before it reaches a customer. Use anonymised data, follow your company’s rules, and treat the first draft as a first draft.
Answer 10 questions about your product, your customers and how you write. You get a set of instructions to paste into a Claude Project, a Custom GPT, a Copilot agent or a Gemini Gem. From then on it starts from your context, so you explain far less. You still give it the current account detail and check the result.
Pick the tool your company has approved. It takes about two minutes.
The course gave you the method. This turns it into a habit: one 10-minute task every working day, 30 in all, using your real work. Each task comes with a ready-made prompt, and all 30 reminders go straight into your calendar.
Choose when to start and what time suits you. You get one 15-minute reminder each weekday, with the task inside. Works with Outlook, Apple Calendar and Google Calendar.
Using Google Calendar? Open the file from your downloads, or in Google Calendar choose Settings, then Import.
A ready-made 60-minute workshop you can run with your team, whether you lead it or you are the CSM getting everyone started. The run sheet, what to say, the exercise and the follow-up are all on this page. No slides needed: share your screen and press Present.
A prompt is something you copy every time. A skill you add to Claude once, and from then on Claude knows how to do that job the way this site teaches it. 49 skills, built from all 77 Vault prompts and The AI-Powered CSM method. Free, and yours to keep.
Works on every Claude plan, including free. First, turn on Code execution and file creation in Claude’s settings.
Want all 49 at once? The Download all 49 file is a Claude plugin. In Claude, open Customize, then Plugins, upload it there, and switch it on. Then just ask in your own words and Claude picks the right skill. You can also type / and a skill name if you want a particular one. Plugins need a paid Claude plan. On the free plan, add the skills you want one at a time.
Add the method skill first, then the six skills most CSMs use every week. Using ChatGPT, Copilot or Gemini instead? Build your CS assistant brief. You can add the rest whenever you need them.
Grouped the same way as the Prompt Vault. Each card shows which Vault prompts it is built from.
No skills match that. Try another word, or browse the Prompt Vault.
Each skill is a short set of written instructions with no code, and you can read every word before you add it. Using ChatGPT, Copilot or Gemini? The same briefs are in the Prompt Vault. Some thinking in these skills was shaped by SuccessCOACHING’s open-source Claude for Customer Success project (Apache 2.0).
Every certificate from The AI-Powered CSM has an ID worked out from the learner’s name, the course and the date it was issued. Enter the name and ID below to check they match.
When someone passes every knowledge check in a course, their certificate is created with an ID worked out from their name, the course and the date. This page repeats that calculation. If the name and ID match, the details on the certificate are consistent with each other.
The course runs entirely in the learner’s browser, with no accounts and nothing stored on a server. So it is a quick check that the name, course and date match the ID. It is not a record held in a central database, and it cannot prove who completed the course.
Tell me what is going on and answer four quick questions. You get the view I would give a colleague over coffee: the most likely explanation, what to check, one move this week, the words to use and a 14-day plan. It is a starting point. You know the account.
The right move depends on the kind of book you run.
Describe it in your own words, or pick the closest situation below.
Four quick questions. Your read appears once all four are answered.
The read gives you a considered starting point to help you decide. You know your customer and the context in the room, so always apply your own judgement before you act or send. Want the thinking behind it? That is The Direct/Present Method.
Your Own AI Team now lives in Edition 03 of the newsletter.
A short read on one part of Customer Success, with the prompts to put it to work. A new edition goes up here on the site every month, written by a working CSM.
Every CSM has had one. The health score is green. Usage is fine. The last QBR went well. And something is off. You cannot point to a number, so you say nothing. Q4 is when those accounts stop feeling off and start becoming a surprise.
Health scores are built on what is easy to count.
Renewals are decided by what is not.
Usage can stay flat for months after a customer has privately decided to leave. The product is embedded, the team is still logging in, the contract is still live. Nothing in the data moves until the renewal conversation, and by then the decision was made two quarters ago.
Meanwhile the real signals were there all along. Your sponsor stopped coming to the monthly call. Replies got shorter. A new name started appearing on the cc line. Procurement asked for a copy of the contract “just to check the dates”. None of that shows up as red on a dashboard.
That feeling you get on a call is worth listening to. It is pattern recognition from hundreds of customer conversations. Treat it as data. Then go and find the evidence.
It takes about five minutes per account, and you get an honest read.
The prep is Direct work in the Direct/Present Method, but the judgement is yours, and AI does not get to make the call. What it can do is help you think clearly: lay out the evidence, challenge your assumptions, and tell you what you might be missing.
The trick is to give it the soft signals as well as the hard ones. The meeting that got cancelled. The reply that took nine days. The new name in the thread. That is the information your health score throws away, and it is usually the part that matters.
I built Situation Read for exactly these moments. Pick the situation closest to yours, a customer gone quiet, usage dropping, a renewal that looks fine but feels off, and tell it roughly where you sit. You get the read a calm, experienced CSM would give a colleague who asked for help.
It is not a verdict. You know your customer and the context in the room. But it is a good starting point when you are too close to an account to see it clearly, and nothing you tap ever leaves your browser.
What is probably happening beneath the surface, the one move that matters this week, and what to watch. Adjusted to your level and book size.
Get the read →The strongest CSMs I have worked with do not wait for the dashboard to turn red. They notice the small things, write them down, and act while there is still a relationship to work with.
That is the part of the job AI cannot do for you, and should not. But it can make sure you never walk into a Q4 renewal with a feeling you did nothing about. The data shows what has already happened. What you pick up on calls often tells you what is coming.
A green health score is not a renewal. It is the absence of evidence. Your job is to go looking for the evidence before the customer brings it to you.
Gary Giacalone · The AI-Powered CSM
In June I asked whether your team has an AI methodology. The reply I heard most was some version of: “We agree we need one. Nobody owns it.” That is the whole problem. If nobody owns a methodology, it just sits in a document. A task force gets people using it.
AI adoption does not stall because people resist it.
It stalls because it is everyone’s side project.
You have probably seen the pattern. Someone starts an AI channel. It is busy for three weeks. A few great prompts get posted, a few people say “this is brilliant”, and then renewals season hits and the channel goes quiet. The best prompts go back to living on individual laptops.
Then your VP asks what the team’s AI strategy is, and the honest answer is: a handful of enthusiasts doing good things that nobody else can see. Meanwhile someone is still pasting customer data into a free tool because nobody told them not to.
The fix is not a bigger rollout or a new platform. It is a small group of the right people with a clear mandate and a deadline. Enthusiasm helps, but it only sticks when someone owns it.
One phase a month. Measure from day one.
Keep it that tight. The temptation is to tackle ten use cases and a tool evaluation at the same time. Three workflows that save real, measured time will do more for adoption than any launch email.
Three prompts. One for each phase.
A task force dies in admin: the charter nobody writes, the use-case list nobody prioritises, the readout that never gets to leadership. All three are assembly work, which makes them perfect for AI.
Send this to the four people you want on it. Keep it short. It is a small ask, and a clear goal makes it easy to say yes.
Access to AI tools is becoming less of an advantage, because most CS teams will soon have them. That is not where the difference is. The advantage is a team that knows how to use them well, consistently and safely, and keeps getting better at it every month.
That does not happen by accident, and it does not happen through a launch email. It happens because five people were given permission, a deadline and a clear job. Ninety days from now you can have the start of a system, or another quiet AI channel.
Give a small group of your own people permission and ninety days, then see whether it changes how the wider team uses AI.
Gary Giacalone · The AI-Powered CSM
People keep asking how I stay on top of a full enterprise book. The honest answer is five AI agents that watch my accounts, inbox, calendar and the wider world. The more useful answer is everything I stopped them doing. This edition is the whole build: the video, the five specialists, the restraint, and a prompt for every agent so you can build your own.
The risk is not that AI gets something wrong.
The risk is that it gets it wrong and you click send.
Most AI tools sold to CS teams work the same way. The agent drafts, you approve, the agent sends. It sounds safe. There is a human in the loop.
Now picture it at 5.45pm on a Thursday, with forty drafts waiting and a renewal call in the morning. You are not reviewing anymore. You are clicking. And one confident, well-written, completely wrong email reaches a customer with your name on it.
So I built the opposite. Human as the loop, not human in the loop. The agents narrow my attention from the four hundred things I could look at to the twelve that matter today. Then I decide, I write, I send, I show up. The agent’s job ends at the surface.
A walkthrough of the team surfacing signals across a portfolio. It reports; I decide.
Each agent maps to a real slice of the week. For each one: what it watches, what it surfaces to me, and the hard line it never crosses. The hard line is the important column. It is what keeps the human in control.
Every agent surfaces. Nothing acts. That single line is what makes it safe to run against live customer data inside a large enterprise, and it is the discipline to hold onto no matter which tools you have.
Three things I built or considered, then pulled back. This is the part most “build an AI team” advice skips, and it is the part I would read first.
A single agent that fused every source into one written account summary. It read beautifully. In edge cases it contradicted the underlying data, and it did it confidently. Autonomous narrative over multi-source customer data is exactly where hallucination hides, and no “just review it” habit scales safely across a full book. I kept signals per source instead.
Wiring the Inbox agent to draft responses into a review panel was the obvious next step. I rejected it. “Draft ready, click send” is one muscle-memory error away from sending a hallucinated reply to a customer. Signals only means every word a customer reads from me, I wrote.
Too much subjective weighting. If the system hands you a score, you unconsciously anchor on it and stop thinking. Whether an account is healthy has to stay your judgement, or the tool has quietly replaced the part of the job that matters.
The framework is where the value is. The data connection matters less. Pick the tier that matches what you can use today.
I built on Claude with connectors, so that is the path I can vouch for. Other platforms have their own setups, but I have only run this one. Whatever you use, get Tier 1 genuinely useful first.
Tier 1. Works in any assistant you are allowed to use.
Set the first prompt up once as a project or custom assistant, then paste your material with the second each morning. It turns a noisy day into a short, ranked list, and it never acts. Anonymise anything your company policy says must stay out of AI.
A working system prompt for each of the five agents.
Here are the prompts behind each agent. Paste one of these into a custom GPT, a Claude Project, or any assistant you are allowed to use, then feed it your own data: paste it in, or connect a read-only tool if you have one. The hard line is written into each prompt as a real instruction, so the agent surfaces and never acts.
The one line to keep in every prompt you write: “Surface only. I decide.” Start with one agent, get it useful, then add the next.
Every agent surfaces. Nothing acts. Read scope only, never write. The moment one agent crosses that line, a productivity system becomes a compliance risk, and every reason you built it collapses at once.
It matters for you as well as your customers. An AI system that reads customer data, never touches it, and makes you measurably faster is defensible to security, to your manager and to yourself. Build it the other way and you cannot defend any of it. Keeping AI to signals and leaving the actions to you is the only approach that lasts.
Keep the human as the loop, and you keep the one thing you were always being paid for: the judgement.
Gary Giacalone · The AI-Powered CSM
In CS we track our own numbers obsessively. Usage, support cases, health scores. But the thing that actually decides a renewal is happening in the customer's world, not inside your product. Most CSMs never scan for it. The best ones start every Monday there.
Behind every implementation there is a business objective.
Miss that, and you are managing the tool while missing the point.
There is a signal that walks into your customer meeting uninvited. A restructure you had not heard about. A new CFO with a cost mandate. A merger, a hiring freeze, a shift in strategy from the top. You did not see it coming, and suddenly the renewal you thought was safe is on very different ground.
Usage, support tickets and health scores all matter. But they are internal. They reflect what is happening inside the product, and tell you nothing about the pressures reshaping the business you sell into.
Right now that gap is wider than usual. Organisations everywhere are trying to get leaner, many of them with AI, and priorities that felt settled six months ago are being rewritten. The outside is moving faster than your dashboard can report.
Set it up once. Run it every Monday.
You do not have to do the scan manually. Set up a dedicated AI project that researches your accounts every week and hands you a briefing: what changed, why it matters, and one action per account. Fifteen minutes of reading instead of an hour of hunting.
Give it your account list, tell it to use public sources only, and have it flag the accounts that need you this week. The honest version says "nothing material this week" for quiet accounts rather than padding. That restraint is what makes it worth reading.
The CSMs who get renewed are not the ones with the cleanest usage dashboard. They are the ones who understand the business they are embedded in, and can connect what the product does to what the business is under pressure to achieve.
That understanding does not come from your CRM. It comes from reading their world every week, spotting the signal before it walks in uninvited, and showing up already knowing. Your internal numbers show how the product is being used. To know how the account is really doing, look at what is happening in their business.
The signal that changes a renewal is almost never in your dashboard. It is in their world. Your job is to see it before it walks into the room.
AI in CS is not a tooling problem. Every CS leader has a tool. Almost none have a shared methodology for how their team uses it. And that gap gets wider every week.
The real challenge is sharing
what already works.
Walk into any CS team today. One person has built a QBR prep system that saves them 90 minutes per account, quietly refined over seven months. Two seats over, someone is building from scratch. Same product, same customers, and none of that knowledge gets shared.
Walk further and you’ll find another who tried AI once and went back to copy-paste, and a third who is pasting customer data into a free tool with no idea what the data policy is.
The bottleneck is not capability or budget. It is that those who are most AI-fluent have it stored on their personal laptop, not a team system. One fixable leadership gap.
Select the level that fits. Most teams overestimate by one.
The teams that get this right do not start with tooling. They start with a clear, simple, written answer to the question every CSM is silently asking: what am I actually allowed to do?
When that question is answered, experimentation happens faster. Sharing happens more freely. The methodology builds itself, one monthly session at a time. Ten prompts in the library becomes 40 in six months. New hires start with that intelligence on day one.
The orgs that lead CS in the next three years are not buying more AI tools. They are building AI systems. Buying a tool is the easy part. Building the way your team uses it is the real work. The tool will date quickly, but a shared library keeps getting more useful.
The question is not whether your CSMs are using AI. They are. The question is whether you have a methodology for how.
Gary Giacalone · The AI-Powered CSM
Send this to your team today. If five people reply with one prompt each, your library starts itself.