You don’t have to document everything before you start.

A familiar job can be surprisingly hard to explain from a blank page. The person who does it moves between records, remembers a customer's exception and knows when to ask for a missing detail. Much of the procedure has become automatic to them.

Asking that person to document everything before an AI project starts creates another job for someone who is already busy. A better starting point is a real example. Show what came in, what happened next and what a good result looked like. We do the interviewing and writing.

The expertise is already yours. It doesn't have to be neatly documented before we can build from it.

Start with the last few times the job happened.

An SOP gives us the outline. A checklist shows what someone remembers to verify. A completed example reveals details neither may mention. If there is no document, the walkthrough gives us the starting point.

Ask what triggered the work, which inputs were available, what the person checked and where they needed judgment. Then look at an unusual case. The exception often reveals the knowledge that makes their work good: why this customer gets a different onboarding step, or why that order needs another approval.

We turn the walkthrough into clear steps, required inputs, exceptions and an expected result. Your people review and correct it. The written procedure should sound like the work they recognize.

Agree the differences that matter.

When three people do the job differently, compare their approaches. Some differences are preferences; others affect accuracy, timing or the customer. The procedure's owner chooses the standard to build.

This is focused work on the task you want to improve. If it exposes a larger process problem, make that decision explicitly. You can resolve the immediate rule and keep the first workflow bounded, or change the scope before building.

Capture what the expert actually looks for.

Illustrative example: an equipment-service company's quotes.

The owner writes each quote from site notes because they know which details change the job. We walk through recent quotes and capture what the owner looks for, which pricing references apply and what they need to confirm before quoting.

The workflow takes the next set of site notes and prepares a draft in the company's format. It includes the items the notes support and lists the details still needed. The estimator has something useful to work from; the owner reviews the price before the quote goes out.

The past quotes and the owner's explanation define the approach. The new site notes are the input each time the workflow runs. Keeping those two roles clear helps everyone understand what has been built.

Keep the procedure as a business asset.

The written procedure helps beyond the AI workflow. It gives a colleague a way to cover an absence, helps a new hire learn and gives the team something concrete to improve.

The 2-Week Team Sprint captures one team's procedures and builds one priority workflow, in about two weeks from the first interview. We agree the team's scope and review time before starting. If the procedure is already written and agreed, the 3-Day Workflow Sprint starts from it.

In either case, you bring someone who knows the job. You receive the documented procedures, workflow and handover notes, with use and adaptation rights set out in your agreement. The first useful result begins with knowledge the business already has.