Five months out from Pied Piper's renewal you've got an internal review on the calendar with your account executive and your solutions architect, and you need a brief for it. So you ask Claude for a renewal brief on Pied Piper, attach the last two QBR decks, and read what comes back. It's organized, it's accurate, and it could be about any account you have.
What turns that into the brief you actually needed is something you already do a few times a week, with people. You brief the AE before that review. You brief the solutions architect before a technical call, and support before an escalation lands on them at 4pm on a Friday. That handoff has a shape you stopped noticing years ago.
The four things you already hand a colleague
When you brief someone, four things go across without you thinking about it.
- Who they are in this: you're covering my accounts this week, or you're the technical voice on this call
- What's going on: the champion left in March, usage is flat, the new VP hasn't engaged
- What you need back and in what form: a one-pager I can read on the way in, not a deck
- What material to work from: there's a QBR in the CRM and some recent notes
Pull any one of the four out and what comes back misses, however capable the person is. Claude answers to the same four.
Anthropic's own prompting guidance says as much. It tells you to treat Claude as a capable new hire who doesn't know your norms or your workflows, and it offers a test worth borrowing: show your prompt to a colleague who has almost no context on the task, and if they'd be confused, Claude will be too. You can run that on a prompt you already use, this afternoon, without changing anything else.
Briefing Claude for a renewal review
GitLab publishes its renewal mechanics in the open: once a renewal falls inside six months, the CSM books two renewal reviews with the account executive and the solutions architect, the first at five months out and the second at three. The brief exists to prepare the people walking into that room.
The request that produces the general-purpose brief usually reads something like this:
Write me a renewal brief for Pied Piper. Docs attached.
The briefed version carries the same ask with the other three parts restored:
Role: You're helping me prep for an internal renewal review. I'm the CSM
on this account. The audience is my AE and our solutions architect, not
the customer.
Situation: Pied Piper renews in five months, 180K ARR, third term. Their
original champion left in March and the new VP hasn't engaged with us.
Usage in their two core workflows is steady. The two modules they bought
in last year's expansion have almost no activity. I need to walk into
this review knowing whether we're defending or growing, and what my AE
should know before pricing gets discussed.
What I need back: A one-page brief in four parts: where the account
stands today, the two or three risks I'd raise out loud in the review,
what I'd argue is expandable and why, and the questions I still can't
answer from this material. Write it as prose except the open questions.
Where something isn't in the material, say so rather than filling
the gap.
Material: attached are the last two QBR decks, the usage export through
July, and my notes from the June check-in.
The brief comes back changed in substance: it leads with the champion gap instead of burying it fourth, treats the two dormant modules as an open question rather than an expansion story, and tells you which of your questions it can't answer from what you gave it. That last behaviour comes from a single line in the briefing.
The audience line does similar work. Telling Claude the brief is for your AE and your solutions architect rather than the customer changes what surfaces: pricing exposure and internal risk get in, customer-facing diplomacy stays out. Anthropic's guidance calls this giving context and motivation rather than instruction alone, and it moves the output further than any adjective you could add to the ask.
Prepping a CSM for a customer conversation is one of the places Bain names AI as genuinely useful, in a brief built on a survey of 235 customer success practitioners. The same brief reports that around 70 percent of CS leaders aren't yet using AI in any meaningful way, so whatever you've set up so far, you're early rather than late.
Separating the parts of a briefing
Margot van Laar, an applied AI engineer at Anthropic, rebuilt a broken customer support prompt on stage in London, and her first move was structural. She separated the parts so role, rules, and data stopped running together as one block, and the output improved before she changed a word of the content. If a person reading the prompt can't tell the guidelines from the data, the model is working with the same ambiguity.
Her other finding travels well to this work: insisting doesn't add capability. Typing MUST in capitals doesn't make Claude better at something it can't do, and when her support bot kept getting arithmetic wrong the fix was handing it a calculator. In a renewal brief, no amount of emphasis on "be specific about usage trends" will produce a trend that isn't in the material, so attach the export instead.
The phrasing habit from van Laar's talk carries over too: tell Claude what you want rather than what to avoid. "Write this as flowing paragraphs" works better than "don't use bullet points," which is exactly how you'd say it to a person anyway.
Putting the reusable half in a Claude Project
Read that briefing again and notice how much of it is true every time. The role, the four parts you want back, and the instruction to flag what isn't in the material stay constant; what changes is the account, the situation, and the question you're carrying into the room.
In Claude, the permanent half has somewhere to live. A Project is a workspace with its own chats and its own knowledge base, and the instructions you set on it apply to every chat inside it. So the setup is short: create a Project called something like Renewal prep, paste the role and the what-I-need-back parts of your briefing into the project instructions, then put the material that's true for every account into the project knowledge. Your brief template, how your team defines a healthy account, and one or two past briefs you were happy with, which show Claude the standard rather than describing it.
Before you lean on it, one distinction helps. The project instructions and the project knowledge are the part you control, and they apply to every chat in the Project without fail. Claude's memory feature, when you have it turned on, can also carry context from earlier chats in a Project into new ones, but the dependable home for anything you always want applied is the instructions. When you refine the format on a Friday afternoon and want to keep it, the refinement goes into the instructions, not into a chat you may never open again.
After that, each renewal is a new chat in the Project. You upload the account material, give the situation, and ask the question. The briefing is still complete; you've just stopped retyping the half of it that never changes.
Where your judgment still does the work
Describing what you want well is one competency out of four. The AI Fluency Framework, built by Rick Dakan and Joseph Feller with Anthropic, splits the skill into Delegation, Description, Discernment, and Diligence: choosing what to hand over, describing it, judging what comes back, and owning the result. Briefing is Description, and it's the one that pays back fastest.
The other three stay where they've always been. You decide the review needs a brief at all. You're the one who reads the draft and knows that the champion gap matters more than the dormant modules, because you were on the June call and heard how the new VP talked about the contract. And you're the one in the room five months from now, doing the reading of it that nobody else can do for you. What the brief buys is walking in having actually read everything.
So pick the prompt you use most often for account prep, give it the four parts, and run it once. The Project can wait until the second time you need the same brief.