OXHN / Working notes

Use your browser’s Print command to print or save as PDF. This is a static worksheet: write on a printed copy or copy the text into your own document.

Is this workflow worth an AI pilot?

A practical worksheet for professional-services teams

Start with one recurring task—not a company-wide AI plan. Use this worksheet with the person who does the work and the person who reviews it. The aim is a useful next decision: improve the process, use an existing tool, test a bounded pilot or resolve an uncertainty first.

No score. No signup. No assumed savings. Unknown is a useful answer. Write it down and name how you will find out.

Print this page or copy it into your own document. Keep working examples in the systems appropriate for your organization; a description is enough to begin. You do not need to send this worksheet to OXHN to use it.

1. Name the work—not the technology

Complete this sentence:

When [trigger] happens, [person or team] uses [inputs] to produce [output], which [reviewer or approver] checks before [next step].

Your starting point	Notes
Workflow name
Person who owns the process
People doing and checking the work
Where the workflow starts and ends
Why it matters now
What is outside this exercise

Make it concrete: “Prepare a source-linked requirements list from an incoming project brief” is a workable starting point. “Transform proposal development with AI” is too broad to test as one task.

2. Follow one recent example

Choose a completed instance and reconstruct what actually happened. Include rework and waiting, not just the ideal process.

Step	Person or system	Input → output	Active effort	Waiting or rework	Evidence or estimate?
Intake
Preparation / drafting
Review / correction
Approval / handoff

Ask:

Which step is repeated, and how often? Does volume vary by season or project?
Is the bottleneck producing an output, finding information, reviewing it or waiting for a decision?
What was wrong or missing last time? How was it detected?
What would improve even if no AI were involved?

Evidence check: One recent example helps reveal the process; it does not establish a reliable average. Record the period and number of examples behind any estimate. If you do not know the effort or frequency, observe a few ordinary cases before claiming a business case.

3. Check inputs and the review path

Question	What we know	Unknown / next action	Owner
Where are the source materials, and who can access them?
Are the inputs consistent, current and readable?
Can we use suitable examples with the proposed tools under our actual agreements and policies?
Can a reviewer trace important statements back to the source?
Which decisions must remain with a named person?
What errors would be easy to spot? Which could slip through?
What happens when an input is missing, contradictory or out of date?
Can we return to the current process if the output is unusable?

Apply requirements that actually govern this work; do not assume every workflow has the same restrictions. If an input cannot be used in a proposed environment, consider an approved environment, a narrower task or synthetic examples for early exploration. A synthetic test cannot establish performance on real work.

Review is part of the workflow. If someone must reread every source to trust the output, include that effort. Faster generation alone is not the same as a better process.

4. Compare the simplest credible options

Consider each route before deciding to build.

Route	When it may fit	What to check in this workflow
Improve the process without AI	Missing inputs, unclear ownership or approval delays are the main problem	Would a template, checklist, clearer handoff or better source organization solve it?
Use an existing tool as it is	A capability you already have appears to meet the need	Does it work on representative examples, within the required environment, with acceptable review effort?
Configure or connect existing tools	The main capability exists, but inputs, handoffs or review steps need adaptation	What setup, integration and maintenance are needed? Who owns them?
Build a bounded custom workflow	Existing options leave a specific, important gap	Is the gap worth the additional implementation and maintenance effort? Can the scope stay small?
Keep the current process for now	Frequency is low, consequences are hard to evaluate, or important facts remain unknown	What evidence or change would justify revisiting the decision?

Our leading option: ____________________

Why this option, and not the simpler alternative? ____________________

What could change our mind? ____________________

5. Define a small, informative test

A useful test can end in “stop.” Decide what you need to learn before choosing the tool.

Test design	Your notes
One task included; tasks explicitly excluded
Proposed tool or approach, including the existing-process comparison
Examples to test and why they reflect the work
Ordinary case, difficult case and incomplete-input case
What the responsible reviewer considers an acceptable output
Errors or missing evidence that make an output unacceptable
How source references, omissions and corrections will be checked
Who reviews, who approves and who can stop the test
What happens if the output is unusable
Setup, tool, integration and maintenance effort or cost
Decision date and person responsible for the next step

Examples should be varied enough to expose relevant differences in your work. There is no universal sample count or pass percentage that makes a pilot reliable. Explain what your examples cover and what remains untested. If examples were used to configure the workflow, keep additional examples for checking whether it handles new material where feasible.

Useful observations to record: completeness; factual correctness; source traceability; corrections needed; reviewer effort; end-to-end turnaround; and whether the next person can use the output. Choose only the measures relevant to your decision and define them clearly.

6. Make the economics honest

Use observed values where available. Label estimates and keep uncertainty visible.

For the same kind of case	Current process	Proposed process	Source / uncertainty
Preparation / drafting effort
Review and correction effort
Handoff / exception-handling effort
Waiting time, recorded separately
Recurring tool and support cost
One-time setup and training effort

Net active effort change per case = current active effort − proposed active effort, including review, correction and exceptions. The change may be zero or negative.

To explore possible capacity, apply that difference only to the volume of cases that the workflow could realistically handle and the share of people likely to use it. Show a cautious and a more favorable scenario when inputs are uncertain. Keep setup, training, maintenance and tool costs visible rather than hiding them inside a single optimistic savings figure.

Time released is capacity, not automatically cash savings. Write what the team could actually do with that capacity. Keep faster turnaround, better consistency and reduced rework distinct from monetary returns. If the benefit depends on an unmeasured assumption, test that assumption rather than presenting a precise payback date.

The benefit we would need to observe: ____________________

The cost or review burden that would make this unattractive: ____________________

7. Choose the next action

These are decisions, not maturity levels. Select the one best supported by the evidence.

Improve the process first. The bottleneck is unclear inputs, ownership or handoffs. Name a small process change and how you will check whether it helps.
Try an existing tool. A simpler option appears to fit. Test it on suitable examples before commissioning custom work.
Run a bounded pilot. There is a recurring task, a responsible owner, usable examples and a way to judge the result. Define the test and stop conditions.
Resolve an uncertainty first. Access, quality, review, cost or ownership is unclear. Name the missing fact, who will find it and when.
Do not pursue this workflow now. The expected benefit does not justify the effort, or the consequences cannot be evaluated adequately in the proposed test. Record why and what would warrant revisiting it.

Our decision: ____________________

Evidence behind it: ____________________

Next action / owner / review date: ____________________

Conditions that would change the decision: ____________________

Worked example: a requirements-review list

Fictional example. Not client work or measured results.

A consulting team receives a project brief and prepares a list of requirements for a proposal lead to review. The possible AI task is to draft that list with source passages. The team—not the tool—decides what the requirements mean and approves the response.

Worksheet question	Illustrative answer
Bounded task	Draft a source-linked requirements list; exclude proposal writing, pricing and submission.
Current uncertainty	We have not measured whether drafting or checking takes most of the effort.
Simpler alternative	A shared checklist may be sufficient; test it alongside an existing approved tool before considering custom work.
Difficult example	A brief mixes mandatory deliverables with optional attachments. The output must distinguish them.
Missing-input example	A deadline refers to an absent cover sheet. The output should flag the missing source, not invent a date.
Human decision	The proposal lead confirms completeness and meaning before the list is used.
Evaluation	Compare the draft with a reviewer-prepared reference list; record omissions, incorrect classifications, source issues and correction effort.
Stop condition	The team cannot verify the output adequately, or checking and correction make the approach unattractive.
Next step	Observe the current process and test suitable sample briefs. There is no basis yet for a savings claim or rollout decision.

Want to inspect the work product? See a complete synthetic requirements-review example, including its source pack, unresolved exception and evaluation rules.

Open the worked example

Want another perspective?

Book a conversation about your team, the workflow and where it gets stuck. You can share a non-sensitive summary of the decision you reached; you do not need to send source documents or a completed worksheet.

Book a workflow conversation

Opens Google Calendar scheduling. Please don’t include confidential information.

OXHN Advisors · Practical AI for complex work.