A practical working resource
Describe the work, the proposed AI assistance and the decisions people retain.
Use the guide, editable worksheet and fictional example together. Download the ZIP, open the HTML guide in a browser and work in a copy of the CSV template.
What is included
- Printable instructions and a completed fictional brief
- Editable section-by-section CSV template
- Three prompts for scope, exceptions and provider questions
Who it is for
Business leaders, operations teams and advisers turning an AI idea into a clear business decision.
How to use it
Complete the record with the people who perform and own the work. Keep evidence and unresolved questions visible. Use the prompts to challenge a draft, then have the relevant owners confirm the decision.
All worked examples are fictional. The material helps structure planning and review; it does not promise a particular outcome.
Using this resource
Make the work understandable
A workflow brief helps leaders, technology colleagues and implementation providers discuss the same problem. Complete it before requesting a proposal or evaluating a tool. It should explain how work happens today, why a change is useful and which decisions remain with people. A practical brief can be short, provided it includes real examples and the difficult exceptions.
Ask someone who performs the workflow to walk through a recent ordinary case and an awkward one. Record the trigger, inputs, steps, handoffs and final output. Observe the existing system where possible. Separate a demonstrated fact from an estimate or a future preference. Describe missing information as an open question with an owner, rather than filling the gap with an assumption.
Complete the brief in order
| Section | Questions to answer |
|---|---|
| Purpose and boundary | What starts the workflow? What marks completion? Which neighbouring activities are outside this brief? |
| People and decisions | Who does the work, who receives the result and who owns exceptions? What requires approval? |
| Inputs and systems | Which documents, messages or records are used? Where are they stored? Who can approve access? |
| Current steps | Describe the order, handoffs and sources of delay. Include the work needed when information is missing. |
| Proposed assistance | State whether AI would retrieve, summarize, classify, draft or recommend. Specify any proposed action separately. |
| Quality and failure | What makes the result useful? What errors matter most? How would a person catch and resolve them? |
| Evidence and decision | What can be measured now? What still needs investigation? What decision should follow the review? |
Keep the initial scope narrow enough to evaluate. “Improve operations” leaves too much undefined. “Suggest the category for a new internal service request, with a coordinator confirming every assignment” identifies a task, a user and a retained decision. Document any wider ambition in a later-opportunities note so it does not expand the first scope.
Fictional worked example
An example distributor receives internal service requests through a shared form. A coordinator reads each request, asks for missing detail and assigns it to a team. Employees sometimes choose the wrong form category. Requests may also contain restricted information that should reach only a designated team.
| Brief field | Illustrative entry |
|---|---|
| Problem | Coordinators repeatedly interpret request descriptions. The extent of avoidable work has not been measured. |
| Trigger and completion | Begins when a new form is received. Ends when a coordinator confirms a destination and records any follow-up. |
| Proposed AI role | Suggest a category using the approved category definitions and the request fields available for that purpose. |
| Human decision | The coordinator confirms, changes or rejects the suggestion. AI does not send messages or reassign requests. |
| Exceptions | Missing information, an unfamiliar request, conflicting category definitions and restricted content require manual handling. |
| Evaluation approach | Use an approved sample with independently reviewed expected categories. Record disagreement and the reason. |
| Open question | The systems owner must confirm which fields can be used and whether the sample represents ordinary and unusual work. |
This is a fictional planning example, not a completed deployment. Its missing baseline is intentionally visible. A useful brief allows someone to say “we need more information” before committing to a build.
Blank brief for your workshop
| Field | Working notes |
|---|---|
| Workflow name, owner and date | ________________________________________________ |
| Problem and evidence | ________________________________________________ |
| Trigger, end point and exclusions | ________________________________________________ |
| People, systems and approved inputs | ________________________________________________ |
| Current steps and exceptions | ________________________________________________ |
| Proposed assistance and retained decisions | ________________________________________________ |
| Quality criteria and failure response | ________________________________________________ |
| Baseline, open questions and next decision | ________________________________________________ |
The editable CSV includes a row for every section, with a prompt, answer, evidence reference and unresolved question. Copy it for each workflow. Review the finished brief with the people who perform the work and the person responsible for systems access. Keep their corrections with the record.
Prepare a useful handoff
Share the agreed brief with a provider together with representative examples that you are allowed to share. Ask the provider to identify assumptions, dependencies, proposed exclusions and evaluation requirements before giving a firm solution. The accompanying prompts help check scope and prepare questions. A polished AI-generated brief still needs confirmation against the actual workflow.
More from Authentia
Explore Authentia resources or contact Authentia to discuss the next decision.