The 30/60/90 dashboard: a CFO-ready AI ROI scorecard

An AI program that can only show one number, once, at the end of the year, gets defunded before that number arrives. The reason is timing. Adoption signals show up in weeks, operational gains in months, financial outcomes in two to four quarters. A single annual ROI figure asks a CFO to fund a year of spend on faith, then grades the bet after the budget is already gone.

The fix is a reporting cadence that matches when each kind of evidence actually exists. The 30/60/90 dashboard is becoming the default shape for that cadence in enterprise AI reporting, and the structure is simpler than the framework name suggests.

Why the horizons exist

The horizons are not arbitrary review dates. Each one is the earliest point at which a specific class of evidence becomes trustworthy.

Opag's guide to building an AI ROI dashboard splits the timeline into 30 days for adoption and quality, 90 days for operational improvement, and 6 to 12 months for financial and risk outcomes. The same split shows up in a 2026 CFO dashboard breakdown from C-Suite Strategy, which frames the day-90 mark as the first honest funding decision: expand, revise, hold, or shut down.

At 30 days you can prove people are using the thing and that its output is good enough to ship. You cannot yet prove it changed a cycle time, because one month of operational data is noise. At 90 days the operational trend is real. The dollar figure still is not, because finance needs a couple of closed cycles to attribute the change. By month 6 to 12 the P&L line is defensible.

Reporting a number before its horizon is how AI dashboards lose credibility. A "money saved" figure published at day 20 invites exactly the scrutiny that kills the program, because anyone in finance can see the sample is too thin to support it.

The three artefacts

Each horizon consumes a different artefact. Build all three once and the dashboard fills itself.

Artefact 1: the per-task baseline (before day 1)

The baseline is the minute value of the human work each automation replaces, recorded before the automation goes live. Forrester has argued that the AI ROI problem is a measurement problem, not a technology one, and the missing baseline is where most of that measurement failure starts. You cannot compute saved time against a number nobody wrote down.

A baseline is one row per task type: the task, the median minutes a person spends on it, and the loaded hourly cost used for conversion. Ticket triage at 5 minutes. Invoice line-item extraction at 12 minutes. Meeting summary at 30 minutes. Keep the note that says where the number came from, because that note is what survives the finance review.

Artefact 2: the per-execution log (feeds day 30 and day 90)

Every time an automation completes work that a human would otherwise have done, it writes one event. This is the raw material for both the adoption signal and the operational trend.

{
  "agent_id": "invoice-extractor",
  "task_type": "invoice_data_extraction",
  "outcome": "success",
  "human_baseline_minutes": 12,
  "executed_at": "2026-05-21T09:14:00Z"
}

The log volume sits in a range a CFO can reason about. A mid-size ops team runs somewhere between 1,000 and 100,000 of these events a month across its agent stack, the same order of magnitude an n8n Insights or LangSmith trace view reports. At day 30 the log answers adoption: how many tasks ran, how many succeeded, which automations are live versus shelfware. At day 90 the same log, now with three months of history, answers the operational question: is cycle time falling, is the success rate stable, is volume growing.

The placement rule matters more than the schema. Log the event after the work is confirmed done, on the success branch, after any human approval gate. An agent that drafts a reply a human then rejects saved nothing, so a tracking call before the gate inflates the number and fails the audit.

Artefact 3: the monthly hours-saved digest (feeds month 6 to 12)

The digest rolls the per-execution log into one figure per month: total human-equivalent hours saved, converted to money saved at the loaded hourly rate from the baseline. This is the artefact finance actually reads.

May 2026 digest
  invoice_data_extraction   1,840 runs x 12 min = 368.0 h
  ticket_triage             6,210 runs x  5 min = 517.5 h
  meeting_summary             430 runs x 30 min = 215.0 h
  ------------------------------------------------
  total                                  1,100.5 h
  at 65/hour loaded cost          71,533 money saved

Everworker's CFO-ready metrics guide makes the case that the figure has to land in a unit finance already uses, which is hours and money, not executions or tokens. A digest in hours converts in one step to an FTE-month equivalent and a P&L line. A dashboard of execution counts converts to nothing a CFO can sign.

Mapping the digest to a P&L line

The digest produces hours. Finance needs a line item. The conversion is one multiplication, but the discipline is in the denominator: count human-equivalent hours, not raw runs. A run that failed, got rejected at approval, or duplicated another run is not a saved hour. Larridin's notes on AI usage dashboards make the same point from the operations side: the dashboard is only as honest as the filter that decides which executions count.

Run the digest against the same loaded hourly rate finance uses for headcount planning, not a market wage, so the saved-money figure maps to the cost base the CFO already manages. Now the month-12 review is not a debate about whether AI worked. It is a line that reads "1,100 human-equivalent hours, mapped to the support and finance cost centres," and the only question left is whether to expand.

That is the entire point of the 30/60/90 shape. It stops you from arguing about the annual number, because by the time the annual number is due, you have eight monthly digests behind it and a per-execution log anyone in finance can audit.