Find the work. Build the fix. Hand it over.
Four things I do, usually in this order, usually inside one engagement rather than as separate purchases.
Process discovery from the inside
I embed with the team and trace the work end to end: where a request enters, every hand it passes through, where it waits, and why. I count the repetitions and the handoffs rather than estimating them from a meeting.
The output is a map of the process as it is actually performed, with the candidates for automation marked and ranked. It is useful on its own, even if you never build anything from it.
Automation build
I build the candidates we agreed on and put them in front of the people who do the work early, while it is still cheap to hear that they are wrong. What gets built depends entirely on the process:
- Reading unstructured inbound, then classifying and routing it
- Extracting structured fields out of documents, forms and email
- Drafting and summarizing inside the tool where the work already happens
- An internal assistant answering from your own documents and records
- Integrations between systems that were never meant to talk to each other
- Scheduled jobs that replace a manual routine someone repeats weekly
Enablement and handover
Automation that only one person understands is a liability with a countdown on it. Before an engagement ends, the people who will live with the system get walked through it: how it works, what it assumes, how to tell when it is wrong, and who to call.
This also covers the everyday side: helping the team use AI tools well in their own work, and setting sensible boundaries on where they should not be used at all.
A second opinion on a plan you already have
If you already have an AI roadmap, a vendor proposal on the table, or a pilot that has not moved in months, I will read it and tell you what I think, in plain terms. Shorter than a full engagement, and occasionally it ends with me saying you do not need one.