Days 1–15: watch the work before changing it
The new hire should shadow at least two experienced workers and one person downstream from them. Trace a case from arrival to accepted completion. Note each system touched, each manual copy, each approval, and every exception. Ask what people keep in a spreadsheet that the official system does not show.
This is not a hunt for employees breaking rules. A side file often records an unmet need. The hire should separate legitimate control from avoidable duplication, and bring those findings back to the workflow owner before proposing a tool.
Illustrative example
In a recruiting team, the official applicant system records interview status, but managers maintain a sheet of candidate availability because the system cannot show it. The new hire identifies the missing field before offering an AI scheduling assistant.
Where this fails
The hire is told to present a vendor shortlist before seeing one real case.
Days 16–30: set a baseline and choose a safe first case
Count eligible cases and a few outcomes that matter: elapsed time, corrected work, customer or applicant complaints, and duplicate entry. Pick one recurring case with stable inputs and a reviewer who can say no. Document what data may enter the tool and what action still needs a person.
The first trial should be reversible. For hiring workflows, be especially careful about AI screening or ranking of applicants: the Equal Employment Opportunity Commission explains that algorithmic assessments may disadvantage applicants with disabilities and that reasonable accommodations can be required. Drafting an interview schedule is a different risk from rejecting a person.
Illustrative example
Start with summarizing approved job requirements for a recruiter to check, not with automatically rejecting resumes.
Where this fails
The first project is the most sensitive decision in the department because it is easiest to demonstrate.
Days 31–60: trial with the people who will live with it
Run a limited test in which a person checks every consequential output. Hold a weekly 20-minute review of rejected or heavily edited cases. Show the hire the real follow-on work: who re-enters data, who apologizes to a customer, who fixes a record, and who has to explain an exception.
Measure accepted work per eligible case, not merely tool use. Also track rework, unsupported claims, and the number of cases still handled through side spreadsheets. If usage rises while duplicate work does not fall, the process may have gained another step instead of removing one.
Illustrative example
Out of 100 eligible supplier inquiries, the assistant drafts 60 responses, reviewers accept 42, edit 12, reject 6, and 25 are still tracked in a separate sheet. This is an illustrative measurement example, not a reported result.
Where this fails
A vendor usage chart becomes the project’s only evidence.
Days 61–90: decide what to repair, expand, or stop
Ask three questions in order. Is the output sound enough for its use? Is the approved path easier than the workaround? Does the result improve the original business measure without moving work or harm elsewhere? Expand only when the answer is supported by reviewed cases, not a launch announcement.
If the trial stalls, keep the finding. Perhaps the source records are too inconsistent, or the reviewer is overloaded, or the product cannot update the system of record. Those are valuable operating facts. The hire should recommend a repair or a stop decision, not defend the pilot at all costs.
Illustrative example
The team pauses expansion because reviewers spend more time fixing source mismatches than drafting saved. The next project is cleaning the policy source and routing disputed rules to an owner.
Where this fails
The hire is penalized for stopping a weak pilot, so every pilot is called successful.
Make the 90-day review a shared decision
The sponsor, workflow owner, reviewer, and new hire should each sign a one-page review: baseline, trial volume, accepted output, corrections, user behavior, cost, and remaining risks. Ask a frontline user to explain whether they would choose the new path tomorrow without being told to.
Keep released capacity and cash savings in different lines. If the team handled more work with the same staff, that is capacity. If a planned outside spend or vacancy was actually removed, record the budget action and its date. Neither should be guessed from a stopwatch.
Illustrative example
The new hire reports that the trial reduced repeat typing but did not change headcount or contractor spend. That is a credible capacity result, not a failed savings story.
Where this fails
A spreadsheet “hours saved” calculation is presented as an audited financial result.
Use it at work
The 90-day review page
- 01Name the starting workflow and its owner.
- 02Record eligible cases and the old baseline.
- 03Count accepted, edited, and rejected outputs.
- 04Count side-channel or spreadsheet cases.
- 05Record customer or employee corrections.
- 06Separate released capacity from cash savings.
- 07Decide: repair, expand, pause, or stop—and name who decides.
Use AI to help with the hiring work
Summarize a trial without laundering estimates into savings.
Use an approved tool and de-identified or public material. Keep applicant information out of an unapproved system.
Human check: The workflow owner reconciles counts with source records; frontline users explain workarounds; the sponsor—not the model—decides whether to repair, expand, pause, or stop.
Evidence and limits
Check the sources behind the method
Sources were reviewed in October 2026. The examples and operating frameworks here are editorial teaching tools, not documented company results. Occupational wage figures are national medians for named occupations and do not establish an AI-specific pay rate.