THE BUSINESS AI PLAYBOOK
A 90-day AI adoption plan for a business that still has to run
Plan your first 90 days of AI adoption with a focused pilot, practical testing, team training and a measured decision about what to expand next.
Discuss with Oliver and his team 
A useful 90-day AI adoption plan moves one important workflow from observed baseline to a measured operating decision. Use the first month to define the process and build a reviewed prototype, the second to test real cases and improve handoffs, and the third to evaluate controlled live use. Treat the dates as planning windows, not guaranteed delivery promises. Expansion should depend on quality, ownership and demonstrated value, not the calendar alone.
What to take away
- Protect time for staff review and training alongside technical implementation.
- Move from historical examples to shadow use before broad live automation.
- Make the final decision expand, revise or stop based on evidence.
Days 1–30: define the job and build the smallest useful version
Choose a workflow with a clear owner and observable outcome. Collect representative examples, including failures and exceptions, and record the current effort and quality baseline. Map the sources, permitted actions and review requirements. Agree on the test cases and success criteria before demonstrating the prototype.
Build only the capabilities needed to test the central assumption. If the value depends on interpreting inbound requests, begin with classification and draft responses rather than a full autonomous sales department. Schedule time with the employees who know the work. Their feedback is part of implementation, not an optional activity after the software is finished.
Days 31–60: test the workflow under real conditions
Run historical cases and then shadow current work without letting the system make consequential changes. Compare its proposed actions with experienced staff decisions. Classify errors by cause: missing context, unclear policy, failed integration, bad extraction or an unrealistic workflow design.
Repair the highest-impact causes and repeat the relevant tests. Train staff on what the system can do, what needs review and how to pause it. Test outages, duplicate events and requests outside scope. If quality is not adequate, stay in this phase. Reaching day sixty does not create permission to automate a process that still fails important cases.
Days 61–90: run a controlled pilot and decide
Limit live use to tested cases, a manageable customer group or a defined department. Monitor outcomes, review effort and exceptions. Keep a fallback process that staff can operate if an integration fails. Record changes to prompts, sources and rules so performance shifts can be investigated.
At the end of the window, compare the results with the baseline and include operating costs. Decide whether to expand, revise or stop. Write down what evidence supports that decision and what remains uncertain. A pilot that identifies an unsuitable use case can still prevent a larger waste of money and management attention.
Illustrative plan: customer intake for a service firm
Imagine a firm receives incomplete project requests through a shared inbox. During the first month, the team identifies five required fields and builds a draft completeness check. In month two, staff review its questions against real inquiries and discover that one field is often already available in the CRM.
The live pilot therefore asks fewer questions and routes missing information to the correct owner. The final review measures complete handoffs, customer response and staff effort. It does not claim all saved minutes became revenue. The next investment depends on whether the improved intake actually helps the delivery team start work sooner.
FROM READING TO ACTION
Your first steps
- Name the workflow owner and reserve weekly time for staff feedback.
- Establish baseline measures and test cases before building the prototype.
- Use shadow mode to identify errors without exposing customers to untested actions.
- Launch with bounded scope, monitoring and a functioning fallback process.
- Hold an evidence-based expand, revise or stop review at the end of the pilot.
What to measure
| Measure | How to track it |
|---|---|
| Accepted work quality | Pilot outputs meeting the agreed standard divided by outputs reviewed. |
| Net handling effort | Human review and exception time plus system operation effort per completed case, compared with baseline. |
| Outcome improvement | Change in the selected business result for comparable work, with confounding factors noted. |
Common questions
Can we launch faster than ninety days?
Sometimes. A narrow internal tool may take less time, while complex integrations or sensitive workflows may take longer. Use evidence-based gates rather than treating the timeline as a promise.
Should several departments start together?
Only if each has ownership and review capacity. One well-measured workflow often provides a better foundation than several pilots competing for the same people and unclear data access.
Sources & further reading
These sources provide background. The workflow designs are Palnau Systems implementation guidance; examples are illustrative, not reported client results. Product capabilities and requirements can change.
Prepared with AI assistance for business owners and managers. For a recommendation based on your actual systems and requirements, work directly with Oliver and his team.
