# A 90-day AI adoption plan for a business that still has to run

https://palnau-systems.vercel.app/insights/ai-90-day-adoption-plan

Published 2026-11-10 by Oliver Palnau and the Palnau Systems team. Prepared with AI assistance. Audience: Business owners and managers leading an initial AI implementation.

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.

## Key takeaways

- 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.

## First steps

1. Name the workflow owner and reserve weekly time for staff feedback.
2. Establish baseline measures and test cases before building the prototype.
3. Use shadow mode to identify errors without exposing customers to untested actions.
4. Launch with bounded scope, monitoring and a functioning fallback process.
5. Hold an evidence-based expand, revise or stop review at the end of the pilot.

## What to measure

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.

## 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 and further reading

- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

## Work directly with Oliver and his team

Oliver and his team can help turn a broad AI ambition into a focused implementation plan, a tested workflow and a clear decision about what to scale next.

Free introductory call: https://calendly.com/oliverpalnau/30min

Services and scope: https://palnau-systems.vercel.app/services

Current pricing: https://palnau-systems.vercel.app/pricing