The 30/60/90-day AI roadmap: one automation live, then measure, then expand

A scored shortlist without dates is a wish list with numbers on it. The 30/60/90-day roadmap is how that list becomes commitments: one automation live in a month, evidence in two, a decision about scale in three, with a named owner for each and a written reason to stop.

Why 90 days, not a year

Annual AI strategies fail in a specific way. They promise a platform, staff it in quarter three, and produce their first measurable result after the budget that funded them has already been reviewed. Ninety days is long enough to put something in production and measure it, and short enough that the people who made the plan are still the people executing it.

The other reason is learning rate. The first live automation teaches more about a company's data, permissions and tolerance for model error than any amount of planning. A 90-day plan is built to get that lesson in month one and spend the next two acting on it.

The three windows

Days 1–30: one narrow automation, live

The top item from the shortlist, cut down to the narrowest version that still produces a measurable change. Not the email responder for all inboxes; the one for one shared mailbox, with a human approving every reply. The architecture sketch becomes an n8n workflow, the integrations get real credentials, and by day 30 it runs on real inputs with a person watching. "Live" means real traffic, not a demo. "Narrow" means the scope was cut until day 30 was realistic.

The milestone is binary: it runs in production on the agreed input, or it does not. The owner is the process owner, not the engineer. The engineer builds; the owner decides the output is acceptable and signs off on turning it on.

Days 31–60: measure, then start the second

The first automation now has four weeks of logs. This window is where the number promised in the scoring session gets checked: minutes per item before and after, error rate, how often the approver overrode the model, and what the overrides had in common. The approval gate is relaxed only where the data justifies it, and only per category.

In parallel, the second use case starts, using what the first one taught: which credentials took three weeks, which data field was not what anyone thought. Two things run in this window, and one of them is boring on purpose.

Days 61–90: operate, then decide

The first automation gets an operating routine: monitoring with alerts, a weekly ten-minute review of failures, a named person who gets paged, and a runbook for the day the model provider has an outage. The second use case reaches its own day-30 milestone. The window ends with a decision taken on the measured numbers: expand the first automation, start a third, or stop. All three are acceptable outcomes if the numbers support them.

Owners, milestones and kill criteria

Each window has one milestone, one owner and one kill criterion, written on day one. The kill criterion is the part most teams skip and the part that makes the plan credible.

A kill criterion is not an admission of failure. It is a pre-agreed line at which the team stops and re-scores instead of pushing through. It takes the sunk-cost argument out of the room before the cost is sunk.

A worked example: a facilities-management company

A facilities-management firm with about 60 office staff had shortlisted work-order email triage first and supplier invoice matching second. The roadmap as written on the workshop wall:

1. Day 30. Triage live on the main service mailbox: classify request type and urgency, draft an acknowledgment, route to the right dispatcher, human approves every message. Owner: head of service desk. Kill: Microsoft 365 mailbox permissions not granted by day 20.
2. Day 60. Measured: median time to first response, override rate per category, dispatcher minutes per request. Invoice matching build started with read-only access to the ERP. Owners: head of service desk for the numbers, finance lead for the second build.
3. Day 90. Alerts and weekly failure review in place; acknowledgment gate removed for categories with an override rate under 5%; invoice matching live in proposal-only mode. Decision meeting on day 88.

What actually happened: in week three the urgency label was overridden on 31% of items, above the kill line. The team did not kill it. It invoked the re-score, found that "urgent" meant three different things to three dispatchers, and replaced the label with two concrete flags (safety risk, tenant without service). The override rate fell to 9% by day 45. Median first-response time went from 5 hours to 35 minutes. The day-88 meeting approved expansion to a second mailbox and pushed a proposed customer-portal assistant to the next quarter, because nobody could name its number.

What gets cut, and why the cuts are the plan

A roadmap is mostly a list of things that are not happening yet. The items that lose their place most often:

• The platform. "An AI layer for the whole company" is not a milestone. It is what might exist after three roadmaps.
• The second channel. One mailbox, one form, one branch. The others join after measurement.
• Full automation. Human approval stays until the override data says otherwise, per category.
• The custom UI. A pre-filled form link, a Notion page or a ticket in the existing system beats a new screen in the first 90 days.
• Any use case whose data scored under 5 on the readiness scorecard. It gets a data task on the plan, not a build.

In Hilluter's workshops the roadmap is the final artifact, and the cuts are written on it explicitly so that "why aren't we doing X" has a dated answer. If you have a shortlist and want it on a calendar with owners and kill lines, send us the list and we will draft the three windows.