How to Prompt AI to Build a Staff Training Plan

Ask for a staff training plan and you will get a four-week curriculum with a week on culture, a week on tools, a week on process, and a week of shadowing. It looks professional. It is the same plan for a dental practice and a logistics firm, which is how you know it is worthless.

The fix is not a better-worded request. It is refusing to ask for a plan until you have given the model the three things that make one specific: the tasks people actually fail at, the level they start from, and how you will know a module worked.

The three inputs a plan needs

The failure list, not the job description

A job description says what someone is responsible for. A training plan should be built from where people currently get it wrong. Write down the last several mistakes a new hire made in this role, or the questions they ask in week three, or the tasks that always come back for correction.

Six real items beat a full task inventory. "New starters quote for a job without checking material lead times" tells a model something a job description never will.

The starting level, stated bluntly

Say who these people are. "Two new hires, both worked front of house before, neither has used a booking system" produces a very different plan from "experienced staff moving to a new tool". Without it, models default to assuming no prior knowledge, which insults experienced staff and wastes the first week.

The checkpoint

For each module, what would you watch someone do to be satisfied they have it? If you cannot name an observable task, the module is a talk rather than training. Forcing this into the prompt is what stops the model producing modules that end in "understands the importance of" statements nobody can verify.

A prompt that produces something usable

Give it context first, then constraints, then the ask. Something close to this:

You are helping a [type of business, size] design training for [role]. Here is what new people in this role currently get wrong, in order of how often it happens: [your failure list]. The trainees are [starting level]. They have [realistic hours] available for training per week, over [duration]. Training happens [during shifts, in a back office, remotely].

Build a plan where each module names: the specific failure it prevents, what the trainee does rather than reads, who delivers it, how long it takes, and an observable checkpoint that shows they can do it unsupervised. Order modules so the highest-frequency failure is addressed first. Do not include any module I have not given you a corresponding failure for. If a failure on my list cannot be fixed by training, say so and explain why.

That last instruction is the one that earns its place. Roughly a third of what gets labelled a training problem is a process or tooling problem, and a model given permission to say so will often catch it. Some of the value of this exercise is discovering that the plan you needed was a checklist.

Follow-ups that improve the draft

The first output is a starting point. Four follow-ups do most of the improving:

• "Which module will trainees find hardest, and what would make it easier?" This surfaces where you have compressed something that needs two sessions.

• "Rewrite this for someone who has done this job elsewhere for five years." Run it once. Comparing the two versions shows you which modules are genuinely role-specific and which were filler.

• "What can be cut if we only have half the time?" Every training plan meets this reality eventually, and deciding the cut list in advance beats improvising it.

• "Write the checkpoint for module three as something a supervisor can observe in under ten minutes." Vague checkpoints are the most common weakness in the first draft.

For the reading level and tone of any written material the plan produces, prompting AI to change reading level is the shortest route to something staff will actually read.

Feeding it what your business actually does

Generic output usually means a generic input. If you have an existing procedure document, a shift checklist, or last year's onboarding notes, paste them. A model working from your real materials produces modules that reference your systems by name, and that difference is most of what makes staff take a plan seriously. Giving AI context about your business covers how to assemble that briefing once and reuse it.

Two cautions. Do not paste anything containing personal information about named employees, particularly performance issues. And where the plan touches policy rather than skill, keep the policy source authoritative: the training plan can reference the handbook, but the handbook itself is the document that has to be right.

Knowing whether it worked

The checkpoint tells you someone can do the task on the day. It does not tell you the training changed anything, and the gap between those two is where most training budgets quietly disappear.

Ask the model for this explicitly, because it will not volunteer it: for each module, what measure in the business would move if this training worked, and how long after the session should you look. Some answers will be immediate and countable, like the rate of corrected quotes. Some will be slower, like retention at six months. A few modules will produce no measurable answer at all, and finding that out is useful, because it usually means the module exists for a reason nobody has stated.

Keep the measures few and already-collected. A training plan that requires a new tracking system to evaluate will not be evaluated. The CIPD's guidance on evaluating learning and development is a reasonable reference if you want the fuller framework, but for a small team the practical version is two numbers you already have and a date in the calendar to look at them.

One prompt closes the loop nicely three months later: give the model the original plan, the checkpoint results, and what actually happened in the business, and ask which modules to cut from the next round. It is the same reasoning as the first draft, run with evidence instead of guesses.

What this is not

A training plan is not an onboarding plan. Onboarding covers accounts, introductions, payroll, and the first week's logistics; training covers competence. Models blur them constantly, and the merged version is usually weak at both. Build them separately and let the onboarding schedule reference the training modules, which is how onboarding a new employee with AI fits alongside this rather than replacing it.

It also is not an assessment. If the outcome affects someone's employment, the criteria need to be defensible and consistent, which is a different exercise closer to prompting AI to write a hiring rubric. Keep the training plan formative and the assessment separate.

The general technique underneath all of this, giving a model your real constraints before asking for an artefact, is the whole of prompt engineering applied to one document.

FAQ

Why does AI always produce a four-week plan?

Because a four-week structure is overwhelmingly common in its training data, and an underspecified request gets the average answer. Stating your real available hours and duration in the prompt removes the default.

How detailed should the failure list be?

Six to ten specific incidents is plenty. Specific means naming the task and the mistake, not the category. "Books double appointments on Saturdays" works; "scheduling issues" does not.

Can I use this for a single new hire?

Yes, and it is arguably more useful there, because the plan can be built entirely around the gaps that one person has rather than a role average.

Should the AI write the training material too?

It can draft it, but the checkpoint should stay yours. Material that is slightly generic is survivable; a checkpoint that does not test the real task means you cannot tell whether the training worked.