Choose a workflow that happens often, has inputs you can actually access, and produces an output someone can check before it affects a customer or a financial decision. Keep the first version narrow enough that you can compare it with the way your team works today.
That is a more useful starting point than choosing a model or buying a collection of AI tools. The decision is about a piece of work: where it starts, what good looks like, and who handles the cases that do not fit.
Start with a task your team can describe
Ask the person doing the work to walk through the last three real examples. Look at the documents they opened, the information they copied, the decisions they made, and the questions they had to ask someone else.
A useful candidate sounds like “prepare a draft quote from a complete enquiry and the current price list.” “Automate sales” leaves too many decisions unresolved.
Write down five things before discussing the technology:
- The event that starts the work.
- The information needed to complete it.
- The output and where it goes.
- The person who checks it.
- The cases that need a different path.
If the team disagrees about the correct result, resolve that disagreement first. If the job only copies a fixed value between systems, a conventional integration may be enough. AI becomes a candidate when the work involves interpreting varied text, preparing a draft, or organizing information that does not arrive in a consistent format.
Compare value with the cost of getting it wrong
The following is a hypothetical comparison, not a report of Codi client results.
| Candidate | Possible first version | What must stay with a person |
|---|---|---|
| Quote preparation | Extract requirements and prepare a draft using approved pricing | Check scope, approve price, and send the quote |
| Weekly reporting | Assemble a summary with links to the underlying records | Resolve conflicting numbers and approve the summary |
| Customer follow-ups | Draft a message from an approved next step | Check context and approve delivery |
For each candidate, ask whether the output is easy to check, whether the inputs are dependable, and whether a mistake can be caught before it causes harm. A workflow with moderate time savings and a straightforward review step can be a better first project than one with larger theoretical savings and hard-to-detect errors.
This is a selection framework, not a technical guarantee. A pilot still needs representative examples, including incomplete requests and unusual cases.
Compare your own ideas with the First AI Project Kit. Get the playbook and editable worksheet.
Measure the whole job before you build
Record the number of cases, hands-on time, review time, rework, and the delays between handoffs. Use a sample that includes normal days and exceptions. State what the sample leaves out.
For a hypothetical team handling 40 requests a week, saving six minutes on each request would free four hours. That estimate only holds if those six minutes include the new checking and correction work. It says nothing yet about software costs, maintenance, or whether the team can put the time to useful work.
Track these separately:
- Time spent preparing the output.
- Time spent checking and correcting it.
- Cases the system could not complete.
- Errors that reached the next stage.
- Operating and support costs.
The first goal is a defensible comparison. Do not count generated drafts as completed work, or assume every minute freed becomes a cash saving.
Put the review step inside the workflow
Name the reviewer and the decision they are making. Give them the source information beside the proposed output. Define what happens if they reject it, do not respond, or discover a missing input.
For quote preparation, the system might gather the enquiry, identify missing specifications, and prepare a draft. It should stop before sending a price commitment. The reviewer needs to see which price list was used and where the scope came from.
Human approval is a concrete workflow capability. For example, Microsoft’s approval documentation describes flows that wait for an approver’s response before continuing. Whether that product fits your business is a separate choice. The useful principle is that approval controls the next action.
The broader risk review should include the people affected, the data involved, and the consequences of an incorrect result. NIST’s AI Risk Management Framework provides voluntary guidance for incorporating trustworthiness into AI design, use, and evaluation. A small workflow pilot does not establish compliance with that framework.
Set a boundary and a stop condition
Keep the first pilot limited to one type of request, an approved set of inputs, and a named owner. Test it on representative historical examples before allowing it into live work.
Decide the acceptance criteria before looking at the results. Use the baseline to choose a worthwhile time reduction and an acceptable correction rate. Treat an unauthorized customer message or price commitment as a reason to stop and investigate, even if average preparation time improves.
Keep the existing process available while the pilot runs. Log failures with enough context to reproduce them, and assign someone to decide whether an exception belongs in the workflow or should remain manual.
Leave with a decision you can act on
You are ready to scope the first build when you can explain the trigger, inputs, output, reviewer, exception path, baseline, and success criteria on one page.
If those answers are still unclear, the next useful step is workflow mapping. At Codi, that is where the workflow audit starts: understanding how the work happens and which constraints the first system must respect.
The outcome may be an AI-assisted workflow, a simpler integration, or a process change. A worthwhile first project earns its place through the result your team can verify.