# Business workflow brief

By John Rice · Make AI useful.

Use this brief to prepare one workflow for an AI implementation conversation. Fill it out with a person who does the work today. A recent example is more useful than an ideal process diagram.

## 1. Name the job

- Workflow name:
- Business owner who can decide whether it is useful:
- Person doing the work today:
- Person receiving the result:
- Trigger and frequency:
- Current tools:
- What starts the task:
- What counts as finished:
- Why this workflow deserves attention now:

## 2. Walk through one real example

Choose an example you have permission to share. Use fictional or redacted information if needed. Describe what actually happened, including interruptions and corrections.

| Step | Input or source | Person responsible | Action | Time or friction |
| --- | --- | --- | --- | --- |
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |
| 4 | | | | |
| 5 | | | | |

- Which step involves chasing information?
- Which step needs interpretation or a business decision?
- What can go wrong, and who notices?
- What happens when a required source is unavailable?

## 3. Define the first useful output

- One output the pilot will produce:
- Where the draft will appear:
- Required fields:
- Source references the reviewer needs:
- Information the system must leave unresolved rather than guess:
- Reviewer and review deadline:
- Action the reviewer takes after accepting the draft:

Example output contract for a weekly client report: completed work, next milestones, blockers, commitments with owners and dates, source links, and a visible missing-information section. The account manager approves the final report before sending it.

## 4. Map access and authority

List the specific sources needed for this output. Being able to connect a tool does not mean every record in it belongs in the pilot.

| Source | Required records or fields | Access owner | Read/write scope | Refresh or cutoff |
| --- | --- | --- | --- | --- |
| | | | | |
| | | | | |
| | | | | |

- Actions the system may perform without additional review:
- Actions requiring approval:
- Changes, messages, or commitments outside the pilot:
- Who provisions and removes access:
- Where credentials are managed, without including credentials here:
- What run records are retained, where, and for how long:

## 5. Write the checks before building

| Check | How to verify it | Person checking | Pass condition |
| --- | --- | --- | --- |
| Important facts match their sources | | | |
| Owners and dates are supported | | | |
| Missing inputs are visible | | | |
| Output is useful for the next step | | | |
| Tool access stays within the agreed scope | | | |

- A failure that stops the pilot:
- Existing process used when the pilot cannot finish:
- Maximum acceptable review and correction effort:

## 6. Choose a contained test

- Pilot start and review dates:
- Sample selection method and number of examples:
- Straightforward example:
- Incomplete example:
- Ambiguous or conflicting example:
- Example with an unavailable integration:
- Current-process baseline to record:
- Setup and ongoing operating costs to track:

Use the AI pilot scorecard to record preparation, review, correction, result quality, and the next decision. Keep setup effort separate from recurring effort.

## 7. Make the decision explicit

- Decision: continue / revise / expand / stop
- Evidence supporting it:
- Unresolved questions:
- Next action and owner:
- Condition that must be met before expanding access or automation:

Bring this completed brief and one permitted example to an implementation conversation. They provide enough context to scope a concrete first step.