An automation idea becomes interesting when you can describe a completed piece of work. An incoming request has an owner. A packet has been checked. A record has the right fields and a traceable source. Someone who was waiting can move on.
“Use AI on our documents” leaves that finish line open. The work of choosing a project is to make it specific enough to build, evaluate, and operate. I start with the path a case takes through the organization.
Follow a case all the way through
Choose a recent, ordinary example and ask the person who handled it to walk through every step. Include the small actions: opening another tab, checking a spreadsheet, asking a colleague, correcting a name, moving an attachment. Those details reveal where time goes and which information is actually available.
Then follow an awkward case. Look for an incomplete submission, conflicting fields, an unusual request, or a handoff that stalled. A system designed entirely around the ordinary example will inherit a lot of undiscovered work.
The useful artifact is a short account of the current process: what arrives, who touches it, what they need to know, what gets produced, and what happens when they cannot proceed. Keep the exceptions beside the main sequence.
Draw a boundary around the first version
A shared inbox is a recognizable input. “Help the support team” is a much wider ambition. For a first release, the output might be a proposed routing destination and a short explanation attached to each new request.
That boundary gives you something to test. Did the request reach the right queue? Was important context preserved? How long did review take? Which cases required information the system could not access?
The same approach works for extracting fields from PDFs, checking a submission for missing documents, or preparing a recurring summary. Define the recipient and the next action. A summary that nobody reads has no useful finish line.
Boundaries also make disagreement visible. If two experienced people route the same case differently, find out why. There may be a legitimate distinction, an unwritten policy, or a process that needs a decision before it needs software.
Count the work and its consequences
Repetition matters because it gives a system recurring structure to work with. Volume determines whether the improvement is worth its upkeep. Look at weekly arrivals, handling time, the number of people involved, and the amount of correction work.
Include the full queue. An impressive improvement on a small, easy subset may barely change anyone's day. Equally, a modest improvement on a task repeated throughout the week can be valuable.
Error cost changes the design. Incorrect routing may create a recoverable delay. A wrong record update may travel into several other systems. Decide which results can be checked automatically, which need human review, and which should remain manual in the first release.
Use a baseline you can repeat after launch: handling time per case, total elapsed time, backlog, error rate, or the share completed without intervention. Choose a few measures that describe the actual work.
Check whether the project can learn
A promising workflow has an owner who can settle questions about what counts as correct. It also has accessible examples, a place to test safely, and a way to collect corrections after launch.
High volume helps here: it exposes a wider range of cases sooner. Low-volume work may still justify automation, but it takes longer to gather evidence. Plan for that rather than interpreting a quiet pilot as proof of reliability.
Stability helps too. If the team is replacing its core system or rewriting the process, the automation will move with it. That can be worthwhile, but it is a different project from improving a settled workflow.
Write the release decision before building
For a hypothetical intake pilot, the agreement might be: propose a destination for every new request, route a defined subset automatically, send everything else to an existing review queue, and measure handling time and incorrect routes. Keep the original process available while comparing results.
That agreement names the first capability, its limits, the evidence to collect, and the person responsible. It also makes a disappointing result useful. You can decide whether to improve extraction, narrow the scope, repair an integration, or stop.
Pick a workflow where a completed case is visible and a failed case is understandable. Those properties give the engineering somewhere solid to land.