The task audit
Before we teach a single instruction, we ask the group to list the work that actually repeats. Ten to twenty items is enough: a weekly status note, a customer reply category, a variance commentary, a policy question that arrives every Monday. We sit with the list and sort it into three piles. The first pile is work that can be handed to a model with a written review step. The second is work worth assisting, where a draft saves time but a person still has to decide. The third is work we leave alone.
Sorting is a conversation, not a score. We look at whether the source material is available in the room, whether an error would be easy to catch, whether the output goes outside the team, and whether the task involves personal data or a judgement the organisation would not want guessed. People often want to automate the task they dislike most. That is useful information, and it is not always the right place to start.
The third pile matters because it protects the programme. If we pretend every task is suitable, people learn a habit of pasting first and checking later. We would rather name the limits in week one. A support team may keep refund decisions with a person. A finance team may keep the final commentary on a restatement. A communications unit may keep anything that could be read as a public position. The audit becomes a shared map, and we teach against that map rather than against a generic syllabus.