The first 90 days of an AI workflow in production
A practical 90-day AI implementation plan starts with the work, earns trust in a controlled pilot, and ends with a result the team can inspect.
Moving fast is useful. Moving fast without knowing what finished looks like is just motion.
We describe a custom AI workflow as an engagement that takes about 90 days. The exact calendar depends on the systems, risk, and scope.
The work still has a clear shape. Learn the process. Set the baseline. Define the boundary. Build narrowly. Test the exceptions. Launch with owners. Measure what changed.
Days 1 to 10: see the work as it is
Watch the process run. Identify where it starts, which systems it touches, where information is copied, what waits for approval, and which exceptions live only in somebody's head.
Alex keeps the conversation tied to one question: what should be different for this team when the work is done?
Capture the current turnaround, manual touches, corrections, queue size, or another measure the team already trusts. If no baseline exists, collecting it is the first deliverable.
Outputs: A current-state map, representative examples, known exceptions, and a baseline.
Owners: The process owner leads. Frontline users provide the operating truth.
Exit criteria: Agreement on one workflow, one result, the baseline, and what is out of scope.
Days 11 to 20: define the job and the boundary
Turn observation into a plan people can read. Say what the system receives, what it may decide, what it may change, and when it must stop for a person.
Settle access now. Use the least privilege needed. Separate reading from writing. Put approval in front of irreversible or high-impact actions. Decide what must be logged.
Our 2-Week AI Audit is built around this work because a clear plan can prevent a build in the wrong direction.
Outputs: Plain-English requirements, a system map, access plan, approval points, acceptance tests, and release plan.
Owners: The process owner approves behavior. IT and security approve access. The technical lead approves architecture and testing.
Exit criteria: Everyone can explain what the system will and will not do, how it will be tested, and who can stop it.
Days 21 to 50: build the narrow production path
Build the shortest end-to-end path that can complete real work. Start with one trigger, the minimum data, one useful action, an exception queue, and an audit record.
Test representative work, including missing fields, conflicting records, unavailable systems, and inputs the workflow should refuse.
The system needs a safe way to fail. Partial work should not look complete. Retries should not create duplicates. An outage should leave a visible recovery path.
This is the engineering work inside our custom FDE builds. The build stays close to users because their feedback is part of the specification.
Outputs: A working path, test results, audit logging, exception handling, monitoring, and a recovery runbook.
Owners: The technical operator and delivery engineer own the build. Users validate it.
Exit criteria: The workflow passes agreed tests repeatedly, refuses unsafe cases, and can return to a known-good state.
Days 51 to 70: run a controlled pilot
Use real work inside a narrow boundary. Limit volume, users, scope, or action authority. Keep a person approving the final action while the team learns the real exceptions.
Review the operating measure, overrides, exceptions, and work that never reached the system. A pilot can look accurate while quietly missing part of the queue.
Alex also watches adoption. If users avoid the workflow, learn why before expanding it.
Outputs: A pilot scorecard, issue log, revised rules, user guidance, and support plan.
Owners: The process owner runs the pilot. The reviewer handles exceptions. The operator investigates failures.
Exit criteria: Stable results, understood exceptions, trained users, and owner approval for production.
Days 71 to 85: launch without losing the controls
Expand in steps. Do not remove review just because the pilot ended.
The team should know where to see status, how to submit an exception, who answers an alert, and how to pause the workflow. Training should show recovery, not only the happy path.
Retire any replaced manual step deliberately. Running both forever creates two sources of truth.
Outputs: A production runbook, owner roster, alert routes, training, rollback procedure, and launch record.
Owners: The business owner accepts the process. IT accepts the boundary. The technical operator owns the run.
Exit criteria: The workflow runs without builders babysitting it, while owners can inspect, pause, recover, and improve it.
Days 86 to about 90: show the before and after
Return to the baseline. What changed in turnaround, manual effort, corrections, queue size, or the chosen measure? What does the workflow cost to operate? Which exceptions still consume attention?
Improve, hold, expand, or stop. The decision should follow the evidence.
Outputs: A before-and-after review, open-risk list, improvement backlog, and recommendation.
Owners: The process owner presents the result. Technical and security owners report on operations. The sponsor decides what happens next.
Exit criteria: The team can explain what changed, who owns the workflow, and why the next decision makes sense.
Hypothetical example: emailed work orders
Consider a hypothetical service company where work orders arrive by email and are entered into dispatch software.
The team maps intake and measures re-keying, corrections, and time to dispatch. It limits the first build to one work-order type. The system extracts required fields, creates a draft, and routes conflicts to a coordinator.
The pilot keeps final approval with that coordinator. Production expands only after exceptions, owners, and recovery are clear. The final review uses the measures captured at the start.
That is one handoff working better, with evidence.
About 90 days should end with proof
The point of a 90-day AI implementation plan is not the calendar. It is the sequence.
Start close to the work. Make the boundary explicit. Build narrowly. Test uncomfortable cases. Pilot with real users. Keep ownership visible. Return to the number that justified the project.
If the result holds, expand from what the team learned. That is how one useful workflow automation becomes a durable capability.