A licence and a login do not teach a business team to use a generative tool. The session that earns its cost puts non-engineers on work they already owe, and it leaves a manager with a way to see, in the following fortnight, whether the skill showed up on a task the room never rehearsed. If the only record afterwards is a completion row, the organisation paid for a tour.
The skills in the room
The skill is not a magic sentence. Before someone asks the tool for a draft they should be able to say what the page is for, who will read it, what must be true, what must stay out, and which facts the tool does not already have. That is the prompt. It is the same instruction they would give a new colleague who had never seen the file.
They then have to stay in the thread. The first answer is a draft with holes. The next move is to add the missing fact, the constraint the first pass ignored or the format the reader needs, and to ask again. Wiping the box and starting from a shorter line throws away the only context the tool is holding. A made-up email about a holiday is not practice. The note, the brief or the reconciliation the person will send next week is.
Tool choice and the check belong in the same hour. Use the approved tools, and have the person say which job each one is for. A public chat window is a poor place for a client file. A search over internal files is a poor place to invent a slogan. The check is the part a polished demonstration skips. The person marks what they would send, what they would look up, and what would be expensive if it were wrong, then opens the true source once so the check is a habit. Put the reviewer in the session, even for an hour, or that standard will be invisible the following week.
What a short overview failed to do
Boston Consulting Group ran a version of this question on its own people, with researchers from Harvard Business School, MIT Sloan, the Wharton School and the University of Warwick. BCG's write-up of the experiment covers 758 consultants in junior, client-facing roles. The tasks were the sort a business team already recognises: ideas for a product, a launch plan, a slogan, a press note, and a business problem with a right answer. They were not engineering tasks. Before the experimental work, each person completed a baseline task with no AI tool. Within each kind of work, people were assigned to one of three conditions. One group used GPT-4 after a training of about 30 minutes. One group used GPT-4 with no training. One group had no GPT-4.
The training was a tell, show and do. People heard the practices, saw them on a sample and tried them. On the business problem they were also shown that the model can fail at reasoning, and warned not to lean on it. That is more instruction than many corporate sessions provide, and it was still a short overview. On the creative task, where the model is strong, around 90 percent of the people using it improved, and that group reached a level about 40 percent higher than the group working without it. On the business problem, built so a first pass from the model would be wrong, the people using GPT-4 performed 23 percent worse than the people who did not use it. About 85 percent of the control group found the right answer on their own. Many of the people with the tool accepted a fluent, mistaken recommendation, because the rationale arrived after the answer and sounded like thinking.
The warning did not close the gap. BCG reports that the harm on the business problem did not disappear for the group given the overview, and that this group did considerably worse on average than the colleagues who had GPT-4 and no training. The authors say this does not mean all training is ineffective. They read it as a sign of overconfidence: people who have just been shown how to prompt can believe they are safe on a task the model is not safe on. A room that only watches the creative task will see the gain and miss the loss. If the session never includes a task the model is likely to get wrong, and a moment where someone has to catch it, you have bought the condition that hurt the consultants.
The sameness you should also count
On the creative task, the ideas from people using the tool were individually stronger and collectively more alike. The diversity of ideas was 41 percent lower than in the group working without the tool. A manager who only scores speed and polish will miss that. When you sample the work afterwards, read the set together, not only the best page. If the pages could have been written by one person, the next hour of practice should ask for an option the model did not offer.
How a product demo gives itself away
A vendor demonstration and a training day can share a title on a slide. They do not share a test, and the BCG experiment is not itself a test of sales demonstrations. It tested access to the tool, and access plus a short overview. The buying judgement is separate, and a manager can make it in the first ten minutes of a proposal. In a demonstration, the vendor types. The file is a sample the vendor prepared, or a public page that cannot embarrass anyone. The prompt is a line spoken while the presenter is already clicking. The answer is fluent, and nobody is asked to find the sentence that is wrong. The follow-up is a licence.
Ask who will have their hands on the keyboard for most of the hour. If the answer is the presenter, you are buying a demonstration. Ask whose work will be on the screen. If the answer is a fictional company, or the vendor's own customer story, you are buying a demonstration. Ask whether the agenda includes an answer the group is supposed to reject. If that item is missing, the session can only teach trust. Ask what each person will carry out that they could send, and who would still check it. If the answer is a prompt sheet and a smile, the skill has not been bought.
A useful session is slower than a demonstration, because the context takes time to write. Someone finds a confident error and has to say so in front of their manager. People argue about what must not be pasted in, and the argument ends with a line they can apply on Monday. A provider who removes that friction, so the hour stays smooth, has removed the practice. Non-engineers learn this by doing it on work that has a reader and a cost. You would not accept a writing course in which only the teacher wrote.
What to measure in the fortnight after
Attendance and a completion row will not tell you the skill landed. Before the day, pick two tasks the team already does. One should be drafting or sorting the tool is likely to help, such as a first pass, a summary or a rewrite for a known reader. One should have a checkable answer, where a fluent mistake would be costly: a figure, a date, a policy exception or a comparison that has a source. Time a normal pass on each, and note what the person checks today. Without that baseline you will argue about feelings.
During the day, run both. On the drafting task, look at whether the person can brief the tool with the aim, the reader, the constraints and the missing facts, and whether they can ask again without wiping the thread. On the checkable task, look at whether they catch the error, or whether they paste the model's answer because it reads well. If nobody catches anything, the task was too easy or the room was too polite. Change the task before you call the day a success.
Two weeks later, do not rerun the same exercise and call the repeat a proof. Ask each person to bring a task that was not in the room, done since the session, with the thread or the notes still attached. The reviewer, named before you booked, marks three things. Did the person state the aim and the constraints before they asked. Did they check the part that would be expensive if wrong. Did the work go out, or did it sit in a draft because the old way felt safer. A team that can show those three on a new task has learned something. A team that can only describe the session has not.
A tally a manager will keep
Keep a short tally: how many of the sampled tasks named a check, how many used an approved tool and how many were sent with a human still accountable. If the tally is worse than the baseline, change the practice rather than book a second tour. If it is better on the drafting task and flat on the checkable task, you have the consultants' pattern in your own building, and the next hour should be about judgement. A faster answer that is wrong is a worse outcome than a slower one that was checked.
Name the function, the approved tools and the two tasks before you book. Name the reviewer who will look at the work two weeks later. If the rules on data are still being written, say so, and run the day on material that is safe to paste, with a date for when the real files become allowed. A team that is uneasy about the tool will not build a habit in a room that pretends the unease is silly.
Collective Campus is building high-performance culture and teams for the AI world. The AI training workshop is built for a non-technical team, on the tools you have approved, with a real task and a check the reviewer can see. The wider staff curriculum is in generative AI training for employees. The failure of a one-line prompt is in the first draft a team keeps. What one day should leave a named person able to run is in what a corporate AI training day should produce.
What to bring
Bring the two tasks and the reviewer's name. If the provider wants to swap them for a sample about a fictional company, you are looking at a demonstration again, and you should say so before you sign.
