When a company gets excited about AI, the list of things to automate grows very quickly. Customer emails, reports, onboarding documents, sales proposals, training material, meeting notes. Everything looks like a candidate.
At WiZR, part of my job was choosing which enterprise workflows our LLM content generation should take on first. Some of the most obvious-looking candidates turned out to be poor choices, and some boring ones turned out to be the most valuable. Here's how I'd sort them now.
Five questions for each workflow
| Question | Good sign | Warning sign |
|---|---|---|
| How often does it happen? | Many times a week, by many people | A few times a year |
| How much variation is there? | Similar structure, different details | Every case is unique |
| What happens if the output is wrong? | Easy to spot and fix | Hard to spot, costly if missed |
| How is output checked today? | There's already a review step | Nobody checks, or only experts can |
| Where is the time actually spent? | Drafting or reformatting | Gathering information or waiting for approval |
The last question catches a lot of people out. If a report takes three days, but two and a half of those are waiting for data from another team, automating the writing saves very little.
Start where mistakes are cheap and visible
The best early candidates are tasks where the output gets used often, follows a familiar pattern, and is easy for a person to check. Drafting a first version of a standard document is a good example. The person still reviews it, but they start from something instead of a blank page.
Bad early candidates are tasks where a subtle error could slip through and cause real harm, especially if the person reviewing doesn't have the expertise to notice. Those might be worth automating eventually, but not first.
Look at the whole workflow
Automating one step can create work in another. If AI drafts documents much faster, but the approval step stays the same, you've just moved the bottleneck to the approver.
Before building, I'd map the workflow end to end:
- What triggers it?
- What information is needed, and where does it come from?
- Who drafts, who reviews, who approves?
- Where does the output go?
Then decide which step to target. Sometimes the best first step is helping gather the information, not writing the output. If review is part of the picture, it's worth designing that properly too. I wrote about human-in-the-loop review separately.
Talk to the people who do the work
The people doing a task every day usually know exactly which parts are tedious and which parts need judgement. They're also the ones who'll use the tool, so their buy-in matters.
I'd ask them to walk through a recent example, step by step. Where did they slow down? What did they copy from somewhere else? What did they have to check twice? Those are the moments where automation actually helps.
Measure time saved honestly
When you pilot an automation, measure the whole task, not just the drafting step. Include review and editing time. If AI saves twenty minutes of writing but adds fifteen minutes of checking, the real saving is five.
Also check quality. Faster output that needs more corrections later isn't a win.
A rough order
If I had to give a general order, it would be:
- High-volume, structured drafting with existing review.
- Summarising or reformatting existing material.
- Information gathering and first-pass research.
- Tasks that need domain judgement, with strong review.
- Anything with legal, safety or financial consequences, last and carefully.
That order isn't a rule. But the first two are usually where an LLM pays for itself quickly, and that earns you the trust to try the harder ones.