I look for the tasks where AI removes real work rather than adds novelty — synthesis, drafting, triage, retrieval across your own data. Then I prototype it, test it against the manual version it replaces, and ship what holds up. If it doesn’t beat the manual version, I say so.
There's pressure to “use AI” and no agreement on where. Someone has automated a process that was broken to begin with. Or a team is spending hours a week on work that is obviously repetitive but nobody has mapped it well enough to hand off.
The first job is honest mapping. What actually happens, who touches it, where the time goes, and where the judgement calls sit. Most automation projects skip this and end up encoding a bad process at higher speed.
Then a straightforward sort: what should be automated fully, what should be assisted with a human confirming, and what should be left alone because the judgement is the value. That middle category is usually the largest and the most useful, and it's the one that gets skipped in favour of a more impressive-sounding full automation.
Finally, what happens when it's wrong. An automated step with no error path is a liability, not a saving.
Two to four weeks for a mapping and recommendation pass. Implementation support afterwards depends on what you're building on.
Will you tell us not to automate something?
Regularly. Automating a process nobody has fixed is the most common and most expensive mistake here.
Do you build the automations?
I can prototype and specify. Production implementation usually belongs with your engineering team or your platform vendor.