How I Simplified Renewal Prep With Claude — and What Has to Be True for It to Work

Renewal season at most SaaS companies looks something like this.

A CSM gets a heads-up that a renewal is coming. They spend the next two hours pulling data from four different tools, writing up a justification email from scratch, and hoping they remembered the context from that call three months ago where the customer mentioned what they’d need to show their board.

It’s manual. It’s inconsistent. And it’s happening right when your CSM should be focused on the actual renewal conversation.. not assembling context for it.

I built something to fix that.

I set up a shared Claude Project called a Renewals Co-Pilot — now available to every CSM on the team. The idea is simple: you tell it the customer, it does the research, and it generates a branded Customer Impact Report you can send as a PDF or share directly as a Claude artifact.

The goal is to significantly reduce the grunt work of renewal prep — the data gathering, the context assembly, the first-draft justification narrative. It won’t do everything. But it handles the parts that were eating the most time, so CSMs can spend that time in the actual renewal conversation instead.

Here’s exactly how it works, step by step.

Start by naming the account. That’s it. No templates to fill out, no manual data entry. Just the account name.

This is the first thing that makes it smarter than a template.

It asks: “Have you had a conversation with this customer about what they need to justify the renewal to their board or budget owner?”

If yes — it searches your meeting transcripts and emails automatically to find that context. If no — you tell it what you know, and it works from there.

This matters because the justification a CFO needs looks completely different from what a department head needs. The co-pilot is built to work from the customer’s actual language, not a generic value story.

Based on what you told it — or what it found in your transcripts — it pulls relevant data across every connected tool:

Meeting transcripts · CRM · Product analytics · Customer engagement data · Google Drive

It’s looking for usage signals, engagement trends, value drivers, account notes.. anything that supports the customer’s specific justification needs. Not a generic summary. A targeted pull based on what this customer said they need.

The output is a report tailored to what the customer said they need to justify the renewal internally.

If there isn’t much to go on, it doesn’t guess. It falls back to standard value justification templates — so you always have something to work with, even on accounts where the conversation hasn’t happened yet.

Every data point in the report is sourced. You’ll see where it came from so you can cross-reference before anything goes to a customer.

If it found a gap — missing data, an incomplete record, something it couldn’t verify — it flags it explicitly and tells you to check it yourself. It will not fill gaps with assumptions. That was a deliberate design choice and one of the most important ones.

Before anything goes to a customer, the co-pilot gives you a checklist of things to verify.

Something like: “Usage data for this account wasn’t available — pull before sending” or “Customer mentioned specific savings figures in their July call — confirm this is reflected in the report.”

It may also flag signals like low recent login activity, so you have the full picture going into the renewal conversation — not just the good news.

This checklist exists because I want CSMs treating this like reviewing an intern’s work. You still own the final output. The co-pilot is there to do the heavy lifting on research and assembly, not to replace the judgment call.

Once the CSM is happy with the report, the workflow prompts them to update the customer’s health record in HubSpot:

• Customer’s definition of value

• Key value drivers — time saved, revenue protection, value attained, outcomes achieved

No separate step. It’s built into the flow so the data stays current without anyone having to remember to go back and update it.

This is the part I want to be honest about, because I think a lot of AI tools skip it.

The co-pilot is designed to be transparent, not confident for confidence’s sake.

It shows its work. It flags gaps. It doesn’t assume. And the “Before You Send” checklist exists specifically because no data system is perfectly complete — and your CSM needs to know what’s been verified and what hasn’t before it goes to a customer.

Something I’ve noticed: occasionally the co-pilot surfaces data gaps in your source systems that nobody knew existed. That’s actually useful signal. It’s not a Claude problem — it’s the tool doing its job honestly and revealing something worth fixing upstream.

When something looks wrong or doesn’t add up, that’s a conversation for your team — not a reason to distrust the whole workflow. Build in that review culture from the start.

Here’s the part most AI rollouts skip — and it’s where most of them quietly fall apart.

If you’ve spent any time in post-sales, you know that expectation setting with customers is foundational. You define what success looks like. You agree on what the product will and won’t do. You build in a feedback loop so problems surface early instead of at renewal.

It’s no different with your internal team.

Anyone who is skeptical that AI will deliver consistently will find the first thing wrong with it. And guess what? They won’t be wrong. There will be something wrong. A data gap. An output that needs editing. A report that’s 80% of the way there and needs a human to get it the rest of the way.

That’s not a failure. That’s exactly how this is supposed to work.

The expectation isn’t perfection. The expectation is considerable time saved — with your team still owning the final mile. If you frame it any other way, you’re setting your team up to be disappointed the first time Claude surfaces an incomplete record or misses a nuance. And that first disappointment can kill adoption before it has a chance to take hold.

Be explicit about what the co-pilot does and doesn’t do. It handles research, synthesis, and first-draft assembly. It does not replace the CSM’s judgment, relationship knowledge, or final review. Those are human jobs. Make that clear from day one.

Tell your team this will be iterated on. A Claude Project is not a one-and-done deployment. It will be updated, refined, and improved over time based on what the team surfaces. That’s a feature, not a limitation. Build a clear, low-friction path for your team to submit feedback — whether that’s a Slack channel, a standing agenda item at your AI office hours, or a simple shared doc where CSMs can log what worked and what didn’t.

Don’t try to own the whole improvement loop yourself. As a post-sales leader, some of what surfaces will be outside your wheelhouse. Data gaps might need product or engineering. Template quality might need marketing. Output formatting might need ops. Build the collaborative muscle early — identify who you’d pull in for which type of issue and make sure your team knows there’s a path for every kind of feedback, not just the ones you can fix yourself.

Make the feedback loop visible. When a CSM flags something and it actually gets fixed in the next version, say so. That signal — “your input changed the tool” — is what turns skeptics into advocates.

The CSMs who will get the most out of this are the ones who treat it like a new hire they’re onboarding. They check the work. They give feedback. They help it get better over time. The ones who approach it expecting magic will be disappointed. The ones who approach it as a co-pilot they’re actively developing will see their renewal prep time drop and their conversations improve.

Set that expectation clearly. Then build the channel to back it up.

Let me be straight with you before you download anything.

This co-pilot works. But how well it works depends almost entirely on what’s already true in your environment. I’ve seen it save significant time on renewal prep. I’ve also seen it surface gaps that needed fixing before the output was usable. Both are valuable.. but only if you go in with the right expectations.

Here’s what needs to be in place:

Your data sources have to be connected and reasonably clean. This is the biggest one. If your CRM records are stale, your meeting transcripts aren’t being captured, or your product analytics aren’t flowing — the co-pilot will flag those gaps rather than fill them. That’s by design. But it means your first few runs may feel more like a data audit than a time-saver. That’s actually useful.. you’ll quickly learn where your data hygiene problems live.

Your team has to have had the justification conversation with the customer. The co-pilot is built to work from what the customer said they need to justify the renewal internally. If that conversation hasn’t happened, the output defaults to your standard value narrative — which is still useful, but less targeted. The better your team is at asking “what do you need to show your board or budget owner?” the better the output will be.

You need at least one connected transcript or meeting notes tool. Without call context, the co-pilot is working blind on the relationship side. It can pull usage data and CRM fields, but it won’t know what the customer said they cared about, what commitments were made, or what objections are sitting under the surface. A meeting transcript tool is the single highest-leverage integration you can add.

Someone has to own the maintenance. This isn’t set-and-forget. The prompt instructions, value framework, and data source configuration will need updating as your product evolves, your team grows, and your renewal motion matures. If nobody owns that, it will slowly drift out of sync with reality. Assign someone — even 30 minutes a month is enough to keep it current.

High-volume renewal teams where CSMs are managing 50+ accounts and can’t give every renewal the same level of prep time. The co-pilot creates a consistent baseline so no account goes into renewal cold.

Accounts with complex internal buying processes — enterprise customers who need to justify the spend to a CFO, procurement team, or board. The co-pilot is especially good at tailoring the justification narrative to the specific stakeholder.

QBR preparation — not just renewals. The same workflow works for building quarterly business review decks, pulling together account health summaries, and generating talking points for executive check-ins.

New CSMs ramping up — instead of spending weeks learning the account history, a new CSM can run the co-pilot and get a synthesized picture of the account in minutes. It doesn’t replace relationship knowledge but it accelerates the ramp significantly.

At-risk account preparation — when you need to build a case fast for a customer who’s on the fence. The co-pilot pulls together everything you have and flags what’s missing, so you walk into that conversation prepared rather than scrambling.

Teams transitioning off spreadsheet-based renewal tracking — the co-pilot creates a forcing function to get data out of spreadsheets and into your CRM and connected tools. The first time it flags a gap, your team knows exactly what to fix.

Every renewal motion is different. Before you build your own version of this, get clear on these five things — they’ll determine how you configure the co-pilot and what it prioritizes.

1. What triggers your renewals? Time-based, usage-based, and event-based renewals all need different logic. If your renewals are time-based, the co-pilot should pull contract end dates and auto-renewal terms first. If they’re usage-based, it should lead with consumption vs. contracted commitment. Configure accordingly.

2. Who is your economic buyer? A CFO justification looks nothing like a department head justification or an IT buyer justification. Define your buyer segments upfront and build a value narrative for each one in your value framework. The co-pilot should always ask who the economic buyer is before generating a report.

3. How complex is your product? Simple SaaS products can run on lighter data pulls. Deeply configured enterprise products need more context — implementation history, custom workflows, integration dependencies. The more complex the product, the more detailed your data source configuration needs to be.

4. What data sources do you actually have? Not every team has a product analytics tool or meeting transcription software. Be honest about what’s connected and build your fallback logic around what’s missing. A co-pilot that knows its own limitations is more useful than one that pretends to have data it doesn’t.

5. How standardized is your motion? High-touch enterprise renewals need more customization per account. Transactional or low-touch renewals need speed and volume. If you run both, consider building two versions of the project instructions — one for each tier.

I’m making two files available for free below — the README that walks you through the full build and setup, and a feedback log your team can use to improve the co-pilot over time. These are genuinely useful on their own. The README covers how the co-pilot works, how to set it up, and how to adapt it for different renewal models. The feedback log gives your team a structured way to flag what’s working and what isn’t so the tool gets better over time. Think of the free pack as the blueprint and the operating manual.

What it doesn’t include is the actual build files — the system prompt that drives the co-pilot, the value framework that shapes the output, the data source configuration that tells Claude where to look and what to look for, and the “Before You Send” checklist your CSMs use before anything goes to a customer. Those four files are what turn the blueprint into a working co-pilot. They’re in the full template package on Gumroad.

→ Download the free starter pack

→ Get the full template package on Gumroad

And if you’d rather have it built for your team than build it yourself — that’s exactly the kind of work I do. Reach out and we can talk through what it would look like for your motion.

Renewals are one of the highest-stakes touchpoints in the customer lifecycle. The customer is evaluating whether you’ve delivered on your promise. The last thing your CSM should be doing in that window is scrambling to build the case.

This workflow doesn’t replace the CSM. It removes the prep work that was getting in the way of the actual relationship work.

If you’re thinking about building something similar for your team — the foundation is simpler than it looks. A shared Claude Project, connected to your existing tools via HubSpot and a few integrations, with a clear prompt structure and a human review step built in. That’s it.

The hard part isn’t the build. It’s deciding what you want Claude to do and what you want your humans to own.