Practical AI · 4 min read
How to choose your first AI workflow.
Start with a recurring task, a clear owner and a result you can check. A practical guide for small teams.
The first useful AI project is often a task your team already knows too well: copying details from a form, assembling an update, checking the same records, or chasing the next handoff.
Start there. A familiar workflow gives you something concrete to compare against. You know how it works now, where the frustration sits and who has to fix mistakes.
Choose a task with a clear beginning and end
“We need to use AI” is difficult to scope. “We spend every Monday collecting project updates from three systems” is much more useful.
Write the task as a short sentence: when this happens, someone needs this result. Name the person who owns the result. List the systems involved. Then walk through one real example, including the awkward parts people usually leave out of a process diagram.
The manual workaround is often the most informative part. It tells you where the existing process fails to match the work.
Establish the baseline before changing it
You do not need a complicated scorecard. You need enough evidence to tell whether the change helped.
For a handful of typical examples, note the time spent, the waiting between handoffs, the corrections required and whether the work was completed. Keep unusual cases visible rather than averaging them away.
The baseline also prevents a common mistake: claiming that an automated task saves time while ignoring the review and repair work it creates somewhere else.
Ask whether AI is actually needed
Sometimes the answer is a better form, a rule, an integration or one less approval. Those improvements are still worthwhile.
AI may be useful when work involves interpreting varied information, producing a first draft, or helping a person compare material. A predictable transfer between two systems may be better served by a conventional integration.
MenLiving’s contributing-gift integration is a useful example of choosing around the job. It connects a successful contribution to community access and tagging. The public case study also describes human review for no-gift requests and chapter entry. Different parts of the journey call for different kinds of control.
Make the review point explicit
Do not leave “a human will check it” as an assumption. Decide who checks what, when, and with enough information to make a meaningful judgment.
For a draft response, that may mean reviewing both the proposed message and its source. For a recruiting workflow, it may mean using assisted research while keeping responsibility for evaluation and client communication with a person.
Some actions should remain manual until the process has earned more trust. This is a design decision, not a failure to automate enough.
Test one small change against real examples
Choose representative cases, including missing information and exceptions. Define what a correct result looks like before running the trial. Keep a way to return to the existing process.
Check the whole task, not just the impressive moment in the middle. Did the information arrive? Was it accurate? Could the next person use it? Who handled the exception?
Use the result to decide what comes next
A useful first project leaves your team with more than a demo. It should leave a working improvement, a clear owner, a record of how it behaves and a decision about whether to extend it.
A short starting brief can contain just five things:
- The task and the person responsible for it.
- Its frequency and current cost in time or errors.
- The tools and information involved.
- The decisions that need human review.
- The evidence you will use to judge the trial.
That is enough to begin a much better conversation than “Which AI tool should we buy?”
Keep exploring