AI Training Should Start With Real Work, Not a Slide Deck

Most AI training starts too far from the work.

A team sits through a presentation, sees a few examples, and leaves with broad ideas but no change to the way estimates get drafted, follow-ups get written, or reports get assembled. That kind of session can help with orientation. It usually does not change behavior.

People use new tools when they can tie them to a task they already own. Think of the spreadsheet someone cleans every Friday, the client update that keeps getting rewritten, the inbox triage that turns into missed handoffs, or the monthly report built from exports, notes, and memory.

A better training session starts there.

Instead of asking what people should learn about AI, ask which recurring task they should be able to do better by the end of the hour.

Start with one recurring task

Pick a task that happens often enough to matter, but not one so sensitive that the first session turns into a policy meeting.

Good candidates include:

• recurring customer emails
• internal status updates
• proposal drafts
• review summaries
• spreadsheet cleanup
• research briefs
• meeting follow-ups
• job descriptions
• onboarding checklists
• client education materials

The task should have a clear before and after.

Before the session, the person is pulling from scattered notes, old documents, inbox threads, or CRM records and doing too much manual shaping. After the session, they should have a workable way to gather inputs, produce a first pass, review it, and decide what happens next.

That does not mean the tool owns the task. It means the person learns where it helps, where judgment still matters, and what a usable output looks like in the context of the business.

Bring the real inputs

Practical training needs source material.

For a sales manager, that may be call notes, CRM fields, a proposal template, and examples of strong follow-up emails. For an operations lead, it may be exported order data, a checklist, exception notes, and the weekly report they send. For a recruiter, it may be job descriptions, interview notes, scorecards, and tone guidelines.

The point is not to feed every file into every tool. The point is to teach people how to identify the minimum context required for a useful output.

This is also where safety becomes concrete.

Some inputs are fine to use. Some should be anonymized. Some should stay out of the tool entirely. Some outputs can be drafted by AI but still need approval before they go to a customer, employee, vendor, or public channel.

Training should make those lines visible. If it does not, people either avoid the tool because they are unsure, or use it too casually because no one set rules.

Build the workflow live

A useful training session should produce something tangible.

That might be:

• a saved prompt
• a checklist
• a template
• a cleaned spreadsheet
• a reply draft
• a decision summary
• a short SOP

It does not need to be perfect. It needs to be real enough to use again on the next cycle.

A simple structure works well:

• define the task and the desired output
• identify the inputs, including what is off limits
• write the first instruction with the role, task, input context, output format, and review criteria
• run it on real material
• inspect what it gets right, what it misses, and where the instruction needs tightening
• add the human review gate
• save the working version somewhere people can find it

That is the difference between awareness and adoption. Awareness says AI can help with writing. Adoption says your account manager has a repeatable way to turn call notes and CRM context into a reviewed follow-up draft.

Teach judgment, not prompt tricks

The main lesson is not the prompt.

It is judgment.

People need to learn:

• what good context looks like
• when an output is incomplete
• when a follow-up question is needed
• when to stop and check source material
• how to spot an answer that sounds confident but is not grounded in the inputs

Say an assistant drafts a client update from meeting notes. A person still needs to check whether a promise was actually made, whether the timeline is realistic, whether pricing belongs in the message, and whether the tone fits the relationship.

That is not a problem with the tool. That is the work that still belongs to the person.

Good training helps teams separate the parts that can be sped up from the parts that need ownership.

Save what works so it can be reused

If a workflow works two or three times, it should stop living in one person’s head.

Document it.

A lightweight workflow note can include:

• the task name
• when to use it
• required inputs
• prohibited inputs
• the saved instruction or prompt
• the expected output format
• the review checklist
• the approval owner
• examples of acceptable results

If your team uses Codex, this is the point where a workflow may become a skill. OpenAI describes Codex skills as task-specific packages of instructions, resources, and optional scripts that help Codex follow a workflow reliably: https://developers.openai.com/codex/skills

Not every training exercise needs a formal skill on day one. Most should not. Start with the human workflow. Once the steps are clear and repeated, the stable parts can become reusable instructions, templates, scripts, or a skill.

Later, if the workflow needs to run on a schedule, it may become an automation. OpenAI's Codex automation docs describe recurring background tasks that can report findings to an inbox and combine with skills for more complex work: https://developers.openai.com/codex/app/automations

For a small business, the path is usually straightforward:

• train on one real task
• save the working prompt and review checklist
• use it manually for a few cycles
• document the repeated steps
• turn the stable parts into a reusable workflow or skill
• automate only the predictable, low-risk parts that still have clear review gates

What useful training output looks like

A good session should leave behind more than notes.

It should produce a working artifact, a saved workflow, a review rule, and a next assignment.

Examples help.

An account manager might leave with a call-to-follow-up workflow. Inputs include call notes, account context, open commitments, and the company’s follow-up tone. The output is a customer-ready draft, an internal task list, and a list of missing details. The review gate is simple: no promise, price, timeline, or scope change goes out without approval.

An operations lead might leave with a weekly exception report workflow. Inputs include exported rows, business rules, last week’s report, and unresolved issues. The output is a cleaned exception list, a short summary, and three recommended actions. The review gate is that the AI can identify issues, but a person chooses the operational change.

A recruiter might leave with an interview-summary workflow. Inputs include interview notes, job requirements, scorecard criteria, and hiring-stage definitions. The output is a structured summary and open questions. The review gate is that the assistant can organize evidence, but it cannot make the hiring decision.

These are small wins. They matter because they improve the next real piece of work.

The practical test

If people leave training with only general knowledge, the business still has an adoption problem.

If they leave with one improved workflow, one saved artifact, one clear review gate, and one next assignment, the business has something it can build on.

That is a better standard for judging the session: which task is easier, faster, or clearer now, and which recurring task should be next.