The first project sets the tone. Pick something narrow enough to understand, useful enough to matter, and observable enough to tell whether it is working.
Start with work, not technology
List the tasks people repeat each week. Look for time spent searching, re-entering information, triaging requests or assembling a first draft. Talk to the person doing the work before deciding what the solution should be.
Use a simple scorecard
For each candidate, record how often it happens, the time it takes, how consistent the inputs are, whether the necessary data is accessible, what an error would cost and who can review the output. Prefer work with a clear owner and a manageable consequence of failure.
Separate potential capacity from actual savings
Suppose a team handles 100 requests a week, spends 8 minutes on each, and estimates that 40% of the work could be assisted. That suggests about 5.3 hours of potential weekly capacity before review and maintenance. This is an illustration, not a forecast. Measure the real workflow before claiming a saving.
Choose the smallest meaningful pilot
Limit the first version to one team, one request type or one approved knowledge collection. Define what success and failure look like. Compare results against the current process, including the extra time spent checking AI output.
Know what happens next
A successful pilot should leave you with evidence and a decision: improve it, expand it or stop. Record the scope, baseline, test results, operating cost and owner so the decision is based on what happened, not how impressive the demo looked.
A first-project worksheet you can use
Fill in one row for each candidate workflow. Use observations from the current process and name any assumptions. A promising idea should have an owner, usable information and a way to check its result. If one of those is missing, make preparation part of the scope.
| Decision | What to record | What it tells you |
|---|---|---|
| Useful result | The specific piece of work the team needs completed. | Whether the project has a clear finish. |
| Current effort | Frequency, handling time and time spent correcting errors. | The baseline to compare against the pilot. |
| Available inputs | Sources, owners, access permissions and missing information. | Whether the pilot can work with suitable evidence. |
| Consequence of error | What could go wrong and who can review the result. | The approval and recovery steps to design first. |
| Operating owner | Who maintains the process, sources and system connections. | Whether the team can use it after the demo. |
| Decision after testing | The quality, effort and cost evidence needed to continue. | Whether to expand, revise or stop. |
This guide shares a practical approach to evaluating AI. Any examples are illustrative; the right design and results depend on your business, systems and scope.