Teach the team and change the routine

A talk about model types is not the first lesson most employees need. Show a familiar job: the input, a useful request, an imperfect output, the source check, and the corrected result. Let each participant try a case from their role while a peer watches. The learner should leave with something they would actually use tomorrow.

Give people a short starting prompt or instruction, but do not turn prompt wording into a secret craft. The important parts are the job, approved sources, output format, and instruction to say when information is missing. Teach people how to challenge a confident answer and how to change the task when the first result is poor. One shared example with a visible correction is often more valuable than a library of 100 untouched prompts.

Managers need a different session. They should learn what success looks like, what cannot be delegated, how to give practice time, and what to do when an employee reports a bad output. A manager who only asks for “more AI usage” trains staff to maximize clicks rather than accepted work.

Make a simple issue log: what job, what went wrong, how often, how much it matters, owner, and next response. Review it weekly with the business owner and data partner. Tell contributors what changed. If the assistant keeps using an old policy, correct the policy source rather than asking each employee to write a cleverer prompt.

Not every complaint is a model defect. Some are access problems, slow approvals, unclear job instructions, or a tool that cannot read the format people actually use. Fix the route people take through work. If the approved route is slower than the unofficial one with no visible benefit, employees have a rational reason to leave it. The answer is a usable safe path, not a louder ban.

Keep reviewers in the process until the evidence supports a narrower review. A pilot may show that ordinary summaries need a spot check while price changes need full approval. Record that distinction in the job instructions. Human approval is meaningful only if the person can see the source, has time to check, and can reject the output.

Rotate demonstrations across roles. Ask each trailblazer to bring one good case, one failure, and one change to the process. Recognize the person who found a dangerous omission as much as the person who found a time saver. Otherwise the program will quietly reward only optimistic stories.

New employees should inherit the revised workflow and its examples, not a one-time launch presentation. Update the guide when the source, tool, or approval path changes. If the original champion goes on vacation and nobody can continue, the organization has not adopted the practice; it has borrowed one person’s enthusiasm.