When a Client Wants You to Train Their Team on the Build
- A client asking you to train their team is good news. It means they plan to use the build. The risk is that 'a bit of training' has no edges, so it quietly becomes open-ended support.
- Use the Profit Room's Teach-Back Plan: agree on who is being trained, the short list of tasks they must be able to do alone, a fixed number of recorded sessions, a one-page runbook, and a teach-back where each person does the tasks while you watch. Training is done when the teach-back is done.
- If training was not in your original scope, price it as its own small project or a line in the monthly plan. Training covers using the build as delivered, never new features, and questions after the sessions go through the support plan.
The Short Answer
When a client asks you to train their team, say yes with enthusiasm, then ask one question before you agree to anything else: 'Happy to. What should each person be able to do on their own when we are done?' That question turns a vague request into a list of tasks. A list of tasks can be scoped, scheduled, priced, and finished.
That is the Teach-Back Plan. The mistake is treating training as a favor you squeeze in, because favors never end. The opposite mistake is refusing or overcharging, because a team that cannot use the build is the fastest way to end up with a [client who isn't using the build you delivered](/blog/client-isnt-using-the-build-you-delivered). I think training is one of the best things you can sell. You just have to sell it as a deliverable with a finish line.
Why Clients Ask for Training
Usually it is one of three things. The person who hired you understood the build, but the people who will use it every day were not in the room. A staff member is nervous about AI and wants to see it work before trusting it. Or the owner is planning ahead for the day you are not around and wants the knowledge inside the business. All three are healthy. Each one tells you what the training should focus on.
Pay attention to the second one. A nervous team member can quietly sink a good build by working around it. Training that lets them try the build themselves, make mistakes in a safe setting, and see where it stops and hands off to a person does more for adoption than any feature you could add.
Build the Teach-Back Plan
Write the plan down and send it to the client before the first session. Keep it to five parts.
- Who: the names or roles of the people being trained. New hires later are a separate request, which is why the recordings in step three matter.
- Tasks: the short list of things each person must be able to do alone, such as reviewing a draft before it sends, updating the price list the assistant reads from, or spotting when something needs a person. If a task is not on the list, it is not part of training.
- Sessions: a fixed number of short, recorded sessions on a video call, each covering a few tasks. Recording means the client keeps the training and you do not repeat it for every new hire.
- Runbook: a one-page guide for each task, in plain words, with where to click and what to do when something looks wrong. Claude Code can help you draft it from the build itself, and you can work through it in the desktop app without opening a terminal.
- Teach-back: a final session where each person does every task on the list while you watch and only step in if they get stuck. When everyone can do the tasks, training is done, and you say so in writing.
| Part | What you agree on | What it prevents |
|---|---|---|
| Who | The people or roles being trained | Training every future hire for free |
| Tasks | The short list each person must do alone | Training that drifts into new features |
| Sessions | A fixed number of recorded calls | Open-ended 'quick calls' with no end |
| Runbook | A one-page guide per task | The same questions asked again and again |
| Teach-back | Each person does every task while you watch | Arguing later about whether training finished |
The Teach-Back Plan: what each part settles
How to Price Training
Check your original agreement first. If training was in your [scope of work](/blog/scope-of-work-that-prevents-scope-creep), deliver it and use the Teach-Back Plan to define what it means. If it was not, it is new work, and the polite way to handle it is the same as any other [scope creep](/blog/stop-scope-creep-on-a-claude-code-project): name it, size it, and give the client a choice. Price it as a small fixed project based on the plan, never as open hourly time, so the client knows the full cost up front and you know where it ends.
If the client is already on a monthly plan, or about to sign one, you can also fold a set amount of training into it, such as one recorded session a quarter for new staff. [Packaging a maintenance plan for AI builds](/blog/package-a-maintenance-plan-for-ai-builds) covers how to structure that. Either way, the training price should feel small next to the build, because the whole point is protecting the client's investment in it.
Keep Training From Becoming Free Support
Training covers using the build as it was delivered. When a session turns into 'could it also do this?', write the idea down, say you will send a short proposal, and get back to the task list. When questions keep coming after the teach-back, point them to the runbook and the recordings first, then to the support plan. [When a client wants free help after the project ends](/blog/client-wants-free-help-after-the-project-ends) covers the words for that moment, and [how to offboard a Claude Code client](/blog/how-to-offboard-a-claude-code-client) covers handing everything over cleanly if the engagement is ending.
Then prevent the surprise next time. Bring up training in your [expectations conversation](/blog/set-client-expectations-before-a-claude-code-build) at the start of every project: who will use the build day to day, and do they need to be trained? Put the answer in the agreement as a line item or a clear 'not included.' Training that is planned from day one is easy to sell and easy to finish.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
Should I charge a client to train their team?
If training was not in your original scope, yes. Price it as a small fixed project based on a clear plan, or fold a set amount into the monthly plan. If it was in scope, deliver it and use a written plan to define what it covers.
How many training sessions should I offer?
As few as it takes to cover the task list, set before you start and agreed in writing. Keep sessions short and recorded, and finish with a teach-back where each person does the tasks themselves.
What should a client training runbook include?
One page per task: what the task is, where to click, what a good result looks like, and what to do when something looks wrong, including when to hand off to a person. Keep the wording plain enough for a new hire.
How do I know when training is finished?
When each person can do every task on the agreed list while you watch, without help. Confirm that in a short email so both sides agree training is complete.
What if the team asks for new features during training?
Write the idea down, say you will send a short proposal, and return to the task list. Training covers using the build as delivered. New features are new work.
Last reviewed November 3, 2026.
Co-founder of the Claude Code Profit Room. Built and sold AI services to real clients; writes about offers, pricing, outreach, and closing with receipts.
More from Duncan Rogoff →