The useful outcome
Leave with one clearly defined workflow, a rough value estimate, and a small test you can approve without committing to a large rollout.
Good first-project signals
This approach is a good fit when…
- The task happens every week or every day
- The input and a good result can be described
- A person can review mistakes during a pilot
Name one task, not a department
Start with a sentence specific enough to observe: “route website inquiries to the right salesperson” is useful; “use AI in sales” is not. Record what triggers the task, who touches it, the tools involved, and where the finished work goes.
Do this: Ask the person closest to the work to walk through the last real example—not the ideal process.
Find the friction before choosing technology
Mark the places where people retype information, wait for context, search for the same answer, or chase an unclear owner. Some friction needs a better form, policy, or handoff rather than AI. Fixing that first makes any later automation simpler and safer.
Do this: Circle the one delay that appears most often and can be changed without redesigning the whole business.
Estimate value with visible assumptions
Use a range rather than an impressive guess. Multiply weekly volume by minutes per item, then add time spent correcting errors or following up. Compare that with the build, review, and maintenance effort. Time returned is potential capacity—not guaranteed savings.
- Weekly volume × minutes per item ÷ 60
- Plus correction and follow-up time
- Minus the review and maintenance time the new process will need
Design the smallest useful pilot
Test one input type, one team, or one customer segment for two to four weeks. Keep the existing process available, name a human owner, and decide what result would earn a larger test. A pilot should be easy to stop and teach you something even if the tool is not adopted.
Do this: Write the success measure and stop rule before anyone configures a tool.
Use it with your team
One-page opportunity brief
Fill this out before comparing software.
- Task: What repeated job are we evaluating?
- Trigger: What starts it?
- Volume: How many times per week?
- Current effort: Minutes per item and correction time?
- Failure cost: What happens when it is wrong or late?
- Owner: Who reviews the pilot and exceptions?
- Win: What measurable change would justify continuing?
Measure what matters
What to track
- Minutes of staff effort per completed item
- Correction or exception rate
- Percentage of cases completed without a missed handoff
Common traps
What to avoid
- Starting with sensitive or high-consequence decisions
- Buying a platform before mapping the work
- Calling faster output a win when review time increases
Want a second set of eyes?
Turn the guide into a practical next move.
If you have a recurring task but are not sure whether it needs AI, automation, or a simpler process, bring it to a free assessment. We’ll help you identify one practical next move.