For the executive or manager deciding whether a Workflow Audit is the right place to start: what happens, what you get, what it needs from you, and what comes after.
You have a team that knows its work by heart. Most of them have opened an AI tool. Somewhere there is a list of things that "should be automated," and it keeps getting longer.
I spent twenty-five years building and running one services company through three reinventions, and that list crossed my desk more than once. The list is rarely the problem. The problem is that nobody has written the work down in a way a new hire, a manager, or an AI could actually follow. Automating work nobody can describe produces a faster version of the same confusion.
A Workflow Audit fixes that first. One workflow, written down as it really runs, before anyone builds anything.
One workflow. One recent, completed example of it. Captured as it actually happens: what arrives, who does what, where it waits, what gets copied between tools, what gets checked, what goes out, and which decisions stay with a person.
Then it is turned into a package your team can read, correct, keep, and test.
The audit runs on a method I use in my own work: a structured interview, an evidence audit, and a builder that produces a plain, editable package. Nothing in it is a black box. Every claim in the package points back to something your team said or a document you supplied. When something is unknown, the package says so instead of filling the gap.
An editable web page, with a Markdown copy your own AI can read. It covers the workflow in ten sections.
A readiness read on the workflow: what the evidence supports, where accounts conflict, which assumptions the plan rests on, and the questions still open. Reported facts are labeled as reported, not as independently verified.
The instruction files for the recommended folder structure, and the prompts for the first slice, ready to copy. If a single saved prompt is enough, that is what you get. I do not build a workspace to justify the engagement.
A completed example with an answer you can check, a missing-data case, and a real exception when one exists. Each test names its input, expected result, manual comparison, and pass rule.
Everything is plain files. You own them. There is no login to my system, no subscription, and no dependency on me to open or change them.
Free, about thirty minutes. We decide whether a Workflow Audit is the right place to start, and if so, which workflow. If it is not the right place, I say so.
The person who does the work, not the person who manages it. Managers come in at the walkthrough.
One session, sixty to ninety minutes, with the person who does the work. One question at a time. Rough words and voice are fine; nobody has to translate their job into technical terms. One recent completed example anchors everything. I ask about the step that got skipped, the copying between tools, the exception, the wait, and the check nobody mentioned.
Within two business days I return the interview record. The person who does the work corrects it. Their corrected account outranks my summary, every time.
I audit the record and build the package. Five business days.
Sixty minutes with the workflow owner and the manager. Read it, correct it, and decide what the first test should be.
Run the first slice on a completed example with an answer you can check. Compare the result against what actually happened. Then decide what comes next.
The audit looks at five places value could come from: capacity, cost avoided, revenue, throughput, and risk. I look for the strongest evidence, not a score in every category.
Every number carries its unit, period, scope, and source. Measured and estimated are kept apart. Elapsed waiting is not counted as work. Reclaimed hours are not cash savings until spending is actually avoided, and I will not multiply a team's hours by the team size twice to make a chart taller.
If the baseline does not exist yet, you get a measurement plan instead of a fabricated return. An unmeasured baseline does not block a small trial. It blocks a claimed saving.
Every workflow has a judgment the team would not hand off without looking. The audit finds it and names it. That decision stays with a person.
The package records what that person looks at, what tells them to stop, the actual threshold if one exists, who has final authority, and what would make an AI-drafted result untrustworthy until checked. Nothing gets automated past a human check that is not written down.
The package is enough. Your team runs the first test, corrects the package, and extends it on its own.
A focused working session or a short build, scoped to the first test.
More workflows, the team structure around them, and the training to run them. Each one is scoped separately.
Every engagement has a defined end state: you own the system and run it without me. If you come back, it is because you want to build something new.
Pricing is set at the first conversation and scoped to the workflow. There is no retainer and no platform fee. The conversation itself is free.
The interview record, the audit, and the package are yours. Names, client details, and anything you flag are removed before any material reaches an AI service, and I tell you which service is used. Sample files stay described rather than uploaded unless you decide otherwise. Nothing about your workflow is reused as an example without your written permission.
Schedule a team conversation. Bring one workflow your team keeps circling around. We will know quickly whether a Workflow Audit is the right place to start.
A focused conversation about the work, not a sales funnel.