Start with a task someone already needs to finish. Ideally, it happens often enough to be familiar and has an outcome you can recognize. Turning meeting notes into a useful follow-up is a clearer starting point than “using AI across the business.”
Before choosing a tool, watch one example move from beginning to end. What starts the work? Where does the information come from? Who makes a decision? What makes the result acceptable? You are looking for the actual sequence, including the awkward parts people have learned to work around.
Map one ordinary example
Write the workflow as a handful of steps. For a customer call, those might be: collect notes, identify decisions, extract commitments, draft a follow-up, review it, and send it. Mark the points where someone must interpret an ambiguous statement or make a promise on behalf of the company.
This small map tells you where AI might help and where a person needs to remain responsible. Summarizing a discussion is a different job from deciding which requests deserve a commitment. Put them in separate steps so the system cannot quietly treat one as the other.
Define what “good” looks like
Choose a few observable checks before you build. Does every action have an owner? Are dates taken from the notes? Are open questions clearly marked? Can the reviewer trace an important statement back to the source?
Include a rule for missing information. A draft that says “owner not yet assigned” is more useful than a confident guess that creates work for the wrong person. Uncertainty is part of the output contract, not an exceptional condition to hide.
Run a small, bounded experiment
Choose a limited sample you have permission to use. Include a straightforward example, an incomplete one, and one with a disagreement or ambiguous request. Keep the existing process available while you evaluate the draft workflow.
Record the time spent checking and correcting the result as well as the time spent generating it. A draft that arrives instantly can still be expensive to review. Look at the whole task: total effort, important omissions, correction burden, and whether the person responsible would choose to use the system again.
Improve the weak step
When a test fails, name the failure precisely. “The model is unreliable” gives you little to change. “It converts tentative ideas into commitments” points toward a better instruction, a separate extraction step, or a required review checkpoint.
Change one meaningful part, then run the same examples again. Save the inputs, the outputs, and the decision you made. That record helps you distinguish improvement from a result that merely reads better.
The first useful outcome may be a clearer brief or a simpler manual process. That still counts. The aim is to make a piece of work easier to complete and easier to trust. Once that happens, you have a sound reason to expand the system.