Start with one unit of work
A useful first AI workflow has a clear beginning, a small deliverable, and an identifiable reviewer. “Improve marketing” is too broad to test. “Create three draft subject lines from an approved event description” is specific enough to compare with the current process. In administration, turning a public office guide into a draft visitor checklist is easier to supervise than allowing a tool to manage every visitor interaction. Pick work that occurs often enough to study and that your team already understands.
For this course, imagine a small training company preparing public workshops. Its coordinator has an approved event sheet containing dates, venue, price, and accessibility contact information. The proposed AI task is to draft a reminder message using that sheet. Sending the message remains a separate step. This distinction gives the team a visible checkpoint and prevents a writing experiment from quietly becoming an automated communication system.
Compare usefulness and consequences
Use a simple course worksheet to compare candidate tasks. Record their frequency, time spent today, input sensitivity, ease of checking, and consequence of a mistake. Do not collapse these into a single score that hides a serious problem. A frequent task can still be unsuitable if its errors are difficult to detect or affect someone’s rights, money, or access to services. A small task with visible errors may be a better starting point.
For the workshop example, public reminder drafts are promising because the source is short and the facts are checkable. Automatically deciding who receives a refund has different consequences and falls outside this pilot. Drafting a refund explanation could still require specialist review and explicit authorization. NIST’s voluntary AI Risk Management Framework offers four functions: Govern, Map, Measure, and Manage. Here, use that broad orientation to ask who owns the workflow, what could go wrong, what evidence matters, and how problems will be addressed.
Write the pilot boundary
Before opening the tool, write a short operating brief. Name the task, approved source, allowed output, prohibited additions, reviewer, and handoff. For our coordinator: draft one reminder under 120 words, use only the approved event sheet, mark missing details as questions, and never invent testimonials, discounts, or guarantees. The coordinator checks the draft before copying it into the authorized sending system.
Define an exception route as well. If the event sheet contradicts itself, the tool should surface the conflict instead of selecting a convenient answer. If a request needs attendee records, stop this public-data pilot and ask the owner to reassess the scope. Keep an example of an acceptable output beside the brief. Another colleague should be able to read the boundary and understand both the expected result and the exact point where human judgment resumes.
Apply it in your own notes
Create a one-page pilot brief for your own marketing or administrative task. Compare three candidates using frequency, current effort, input sensitivity, checkability, and error consequences. Select one and explain why the other two should wait. Write a task instruction containing an approved source, output limit, forbidden additions, reviewer, and stop condition. Test it with a fictional event sheet that deliberately omits the start time. Your draft should flag the missing time, not invent it. Completion check: another person can identify what the tool may produce, what it may not do, and who authorizes the next step. Do not enter real personal or confidential data for this exercise.
Get a worksheet →Practice questions
1. Which task is the best starting point for this course’s public-data pilot?
2. The approved source contains two different venue addresses. What should happen?
3. Why should drafting and sending be separate in a first pilot?