You do not need a massive “AI transformation program” to see value. You need one clear outcome, a focused pilot, and a 90‑day window where everyone knows what “good” looks like and how you will measure it.
This article is Part 1 in a three‑part series on turning AI and automation from idea to proven results. In my earlier post, A Practical Roadmap for Your First AI and Automation Pilot, we focused on how to pick the right outcome and workflows, get your data and plumbing ready, and design a pilot in plain language. That roadmap helps you choose the right thing to work on.
This post picks up where that one left off. Think of it as the execution playbook for the first month: a simple framework you can use to go from “we have a pilot concept” to “we have a clear, testable plan with baselines, guardrails, and buy‑in.”
Over this series, we will break 90 days into three phases:
- Days 1–30: Set up the pilot for success
- Days 31–60: Build, test, and refine in the real world
- Days 61–90: Launch, measure ROI, and decide what to scale
Here, we will go deep on the first 30 days, because what you do early usually determines whether the pilot becomes a visible win or a quiet failure.
Days 1–30: Set up the pilot for success
The goal of the first 30 days is simple: turn your promising idea into a clear, testable pilot with baselines, guardrails, and buy‑in from the people who will actually use it.
By the end of this phase, you should be able to describe your pilot in a few plain sentences, know how you will measure it, and have a realistic plan for what you can build in the next 60 days.
A helpful way to think about this first phase is in three moves:
- Confirm the outcome and scope
- Map the “before” process in detail
- Design your minimum viable automation
Let’s walk through each.
Move 1 (Week 1): Confirm the outcome and scope
Start by freezing what you are not going to do, as much as what you are. It is very easy for an AI pilot to quietly expand until it touches half the business.
Bring the right people into one short working session: the business owner for the outcome, one or two people who live in the workflow every day, and someone who understands your systems. Then answer four questions in plain language:
- What single outcome are we trying to improve in the next 90 days?
- Which 1–2 workflows will we actually touch in this pilot?
- Who is accountable for the pilot’s success?
- How will we know, in simple terms, if this worked?
You can reuse the kinds of outcomes from the previous post, but make them concrete and time‑bound. For example:
- “Reduce time to prepare for key client meetings by 50% for our account managers this quarter.”
- “Cut average invoice processing time from 10 days to 3 days without adding headcount.”
- “Give operations a single daily view of high‑risk incidents across tools, instead of scraping four dashboards.”
Next, capture baselines. You do not need perfect analytics; you need a reasonable starting point you can compare against later:
- How many items per week flow through this process today (meetings, invoices, tickets, etc.)?
- Roughly how long does it take from start to finish?
- How many people touch each item, and where are the big handoffs?
- Where do errors, rework, or delays usually happen?
Write this up as a one‑page pilot charter. It does not need to be pretty. It just needs to be clear enough that anyone in the room can explain what you are doing and why.
A simple example:
“Over the next 90 days, we will pilot an AI‑assisted meeting intelligence workflow for our top 50 clients. The goal is to cut prep time by 50% and improve follow‑through on next steps. We will measure prep time, meeting outcomes logged, and subjective satisfaction from account managers.”
You can refer back to your earlier roadmap for inspiration on outcomes and workflows, but resist the urge to re‑debate the pilot itself. The job now is to execute.
Move 2 (Weeks 2–3): Map the “before” process in detail
Once the pilot is scoped, slow down before you speed up. One of the most common reasons AI automation pilots underperform is that they automate a fuzzy, unofficial version of the process, not the process people actually follow under pressure.
Spend a couple of short sessions with the people who do this work today and walk through it step by step:
- What is the real trigger? (Not the ideal one—the one that actually starts the work right now.)
- What tools do they open, in what order?
- What information do they copy and paste between systems?
- Where do they improvise or use their own judgment, and where is it pure routine?
- What exceptions or “weird cases” eat up disproportionate time?
Capture this as a simple, linear flow with timestamps and owners. You do not need enterprise‑grade process mapping tools; a shared document with bullets or boxes is enough. The key is to make invisible work visible.
For example, an “invoice processing” workflow might look like:
- Invoice arrives in a shared inbox
- Finance coordinator downloads the PDF, renames it manually, and saves it to a folder
- They key supplier details and amounts into the finance system
- They look up the right approver based on department and amount
- They send a manual email and track approvals in a spreadsheet
- Once approved, they mark it paid and move the file to another folder
Alongside the steps, note:
- Approximate time for each step (even a rough guess is useful)
- Pain points (“always waiting on X,” “we lose track here”)
- Systems and data sources involved (email, shared drive, ERP, CRM, ticketing tools)
What you are really looking for are:
- Repetitive, rules‑based steps that could be automated safely
- High‑judgment steps where AI might assist but humans should stay in control
- Clear boundaries where you can pilot without touching core financial or compliance controls in the first 90 days
This detailed “before” view will become your anchor when you design the new workflow and when you measure improvement later.
Move 3 (Weeks 3–4): Design your minimum viable automation
With the outcome, scope, and current process mapped, you can now design the simplest version of automation that could deliver meaningful value in 90 days.
The mindset here is: what is the smallest useful slice we can ship, not “how do we automate everything in one go?”
You can reuse the structure from your earlier post, but now with more precision:
- Trigger: What exactly starts the automated flow? Be specific. “A meeting is scheduled with a top‑50 client,” “A new invoice email arrives in the AP inbox,” or “A severity‑1 ticket is opened in the helpdesk.”
- Inputs: What data does the system need to do its job? Which systems are the sources of truth? Which fields really matter, and which can wait?
- AI tasks: Where will you use AI models—reading documents, summarising, classifying, drafting messages, ranking items by risk?
- Rules and guardrails: Where will you keep simple rules (“if amount > X, send to Y”) and hard limits (which systems the automation is allowed to update, and which it can only read)?
- Outputs and owners: Who receives what, in which tool, and what do you expect them to do next?
Your design goal is to produce a “minimum viable workflow”: enough automation to remove meaningful friction, but still easy to explain and safe to test.
For example:
“For invoices under $5,000 from known suppliers, the system will:
– Read the invoice PDF from the shared inbox.
– Extract supplier, amount, and due date.
– Match to an existing supplier in the finance system.
– Draft an approval request to the right manager, including a one‑line summary and due date.
– Log all of this in a shared channel, where the finance team can review.”
Notice what this does not do yet: it does not automatically pay invoices, alter bank details, or override existing approval limits. Those might be future steps, but they are not required to demonstrate value in the first 90 days.
At the end of Week 4, you should have three assets:
- A refined pilot charter (outcome, scope, metrics, stakeholders, and guardrails)
- A clear “before” process map with time, volume, and pain points
- A minimum viable automation design written in plain language, which your team can understand and challenge
These become the blueprint for Days 31–60, where you will connect the actual tools, run in “read‑only” and “suggested actions” modes, and start collecting feedback and data from real users.
What’s next in the series
In Part 2, we will cover Days 31–60: how to plug into your systems, run your pilot in the real world, and refine it based on real‑world behaviour and feedback.
In Part 3, we will walk through Days 61–90: turning on limited automation, measuring ROI against your baselines, and deciding what to scale.