Training Proposal

When To Use

A client asks for "a quote for a one-day workshop" on something that took years to build. You need a document that answers the request and still tells the truth about what a day can do. It answers one question: what are we agreeing to, what does each side put in, and how will we both know?

When Not To Use

If you are still working out what the session is for, run Session Purpose Brief first: it is your own one page, with no options and no price. If you have not yet spoken to the sponsor, Sponsor Kickoff Questions prepares that call, and the proposal is better written after it.

Inputs

• The client's request as they wrote it (the email, the brief, or your call notes), and what is fixed: dates, length, who takes part by role, anything already promised.
• What you are willing to offer and what you are not, in your own words. If you have none of this, I start from one sentence of the client's request and mark the output as a first draft.

Approach

The scoping follows the first area of the International Association of Facilitators' core competencies, creating collaborative client relationships: the agreement is designed with the client, not handed over. The spine is before, during and after, from Salas, Tannenbaum, Kraiger and Smith-Jentsch's 2012 review of the science of training, which found that what happens around the session matters alongside the session. The failure this prevents: a one-page quote for "one day, leadership", accepted in an hour, that quietly makes you responsible for a result no single day produces. Claude drafts; you set the scope and the price.

Workflow

1. Ask at most three questions: what did the client ask for in their exact words, what would they see people doing at work that they do not see today, and what is the client able to put in (the sponsor's time, the managers' part, access to participants afterwards)?
2. Open with the situation in the client's own words, quoted from their email or the call note. Do not tidy it into your framing: a client who recognises their own sentence reads on.
3. Write the outcome and "how we will both know": what would be seen at work, what will be looked at afterwards, by whom and when. Promise the work you will do, never a result at work, and put no figure on it.
4. Lay out the design in three stages. Before: the sponsor call, the questions to participants, the note to managers. The sessions: what happens and what people practise. After: the follow-up, the practice at work, the debrief with the sponsor.
5. State what the client must provide as conditions, not as a wish list: the sponsor's time, the managers' part, access to participants for follow-up. Then write the out-of-scope lines in plain words: what an engagement of this size is not expected to fix.
6. Build two or three options that differ in scope, not only in length. Each says what it includes and what it leaves out. Leave [price], [days] and terms blank: I give no price, rate, benchmark or view on what to charge. Contract and payment terms: check with a qualified adviser. Then I reread it as the client would, cut any sentence that claims a result, and mark every gap. In Claude Docs (beta) the draft becomes a document you edit and send yourself.

Output Format

# Training Proposal
For: [client role] | From: [your name] | Date: [date] | Status: [first draft / ready to send]
## The situation, in your words
"[the client's own sentence, from their email or the call note]"
## The outcome and how we will both know
Seen at work: [behaviour, in the client's words] | Looked at afterwards: [what] | By whom: [role] | When: [date]
## The design
| Stage | What happens | Who does it |
|---|---|---|
| Before | [sponsor call, participant questions, note to managers] | [role] |
| The sessions | [what happens, what people practise] | [role] |
| After | [follow-up, practice at work, sponsor debrief] | [role] |
## What you provide
| Condition | From whom | By when |
|---|---|---|
| [the sponsor's time / the managers' part / access to participants] | [role] | [date] |
## Out of scope
- [what this engagement is not expected to fix]
## Options
| Option | Includes | Leaves out | Days | Price | Terms |
|---|---|---|---|---|---|
| [A / B / C] | [scope] | [scope] | [days] | [price] | [terms, to check with a qualified adviser] |
## Decision
[Your name] sets the scope and fills in the price and terms by [date]. [Client sponsor] chooses an option, or says no, by [date].

Done When

• The situation section quotes the client, every stage has a row, and every client condition has a role and a date.
• The options differ in what is included, not only in days.
• Price, days and terms are still blanks for you to fill, and no result at work is promised anywhere.

Quality Bar

• "How we will both know" names what will be looked at, by whom and when. It never names a target.
• Out of scope is written so a client could repeat it back, and the smallest option is still one you would be glad to deliver.
• No price, day rate, market comparison or return figure appears, not even as an example.
• Nothing in the proposal offers a report on individual participants.
• Claude drafts the proposal; you set the scope and the price, and it promises no result at work that a session cannot deliver.

Next

Run fac-70-20-10-programme-plan (70-20-10 Programme Plan) to design the larger option when the right answer is a programme and not a day.

About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).