Building an AI roadmap prioritised by ROI
Most AI plans fail because they pile up ideas instead of arbitrating between them. Here is the method for turning a list of use cases into a defensible roadmap, sequenced by real value and feasibility.
What is an AI roadmap prioritised by ROI?
In one sentence: an AI roadmap prioritised by ROI is a decision document that ranks each use case by its net business value relative to effort and risk, and says in which order to launch them.
So it is neither a catalogue of use cases nor a list of tools to roll out. It is a decision document: it says what you do, in which order, with which resources — and above all what you do not do this year. Its prioritisation logic arbitrates on net business value rather than on the enthusiasm of the moment or the latest impressive demo.
The classic trap for a CEO or a CIO: confusing vision (“become an AI-driven company”) with an executable plan (“automate the triage of customer-support requests in Q3, estimated ROI 9 months”). Vision sets the heading; the roadmap gives the coordinates. A scoping exercise builds it in four layers: an ambition anchored in the business, a portfolio of scored use cases, a sequencing of quick wins and structural initiatives, and the prerequisites (data, infrastructure, skills, governance). A roadmap without the fourth layer remains wishful thinking.
Guiding principle: you do not prioritise technologies, you prioritise business problems whose resolution has a quantifiable value. AI is the means, not the end. If a use case cannot be tied to an indicator the executive committee already tracks (margin, lead time, NPS, cost per transaction), it probably has no business being at the top of the list.
CEO / CIO AI strategy: who decides what?
What is the role of the CEO–CIO pairing?
An AI roadmap only holds up if it is carried by the CEO and the CIO together. A CEO’s or a CIO’s AI strategy is not decided on the choice of a model but on three decisions: which strategic priorities AI must serve, what budget and pace to commit to it, and what level of risk the company accepts (compliance, vendor dependency, data quality). The CEO arbitrates value and ambition; the CIO guarantees feasibility, infrastructure and governance. When both roles sign the same document, the roadmap survives budget arbitration. When one of the two is missing, it remains a slide. That is precisely the alignment an AI assessment & scoping engagement equips.
How do you build the roadmap, step by step?
Here is the sequence we apply in scoping engagements. It fits into five steps and closes in a few weeks, not six months of committees. In practice, allow three to six weeks depending on the size of the organisation.
Frame the ambition and align it with the business
Start from the executive committee’s objectives, not from the technology. Three to five strategic priorities at most (cutting processing costs, accelerating time-to-market, improving retention). Every use case will later have to attach explicitly to one of them. Without this anchor, you will never be able to defend your trade-offs. Indicative duration: 3 to 5 days.
Identify the use-case portfolio
Collect widely (business workshops, frontline pain points, process mining), then deduplicate. Process mining brings an objective measurement here: it reconstructs how processes actually run from your systems’ logs (ERP, CRM, ticketing) and quantifies volumes, frequencies, cycle times and bottlenecks. You then prioritise on facts, not on anecdotal impressions. Aim for 15 to 30 candidates phrased as a problem plus an expected benefit, not as a solution. Indicative duration: 1 to 2 weeks.
Score each case: value, feasibility, effort
Score each candidate on three axes (1 to 5). Value = annualised and strategic business gain. Feasibility = data availability, technical maturity measured by evals, compliance risk (“can we do it?”). Effort = build/run workload and dependencies (“how much does it cost?”). A transparent score cuts the battles of opinion short. Indicative duration: 3 to 5 days.
Position on the value / feasibility matrix
Cross value and feasibility to surface the quick wins (high value, high feasibility) and the structural initiatives (high value, feasibility to be built). Sequence them: the quick wins fund and legitimise the heavy initiatives. Indicative duration: 2 to 3 days.
Quantify ROI, prerequisites and sequencing
For the top 5 to 8, estimate gains and full costs (build, LLM, infrastructure, run, change). List the blocking prerequisites (data quality, access to systems, skills). The result: a quarterly plan with milestones and go/no-go criteria. Indicative duration: 1 week.
This approach is at the heart of the ianaos AI consulting & strategy offer: the engagement closes on this roadmap signed off by the executive committee, not on a PowerPoint of intentions.
How do you prioritise AI use cases by ROI?
Which criteria belong in the value / feasibility matrix?
The value / feasibility matrix is a two-axis table that positions each use case by its business value (vertical) and how easy it is to deliver (horizontal), so that where to start becomes visually obvious. It is only worth something if the axes are broken down into explicit sub-criteria. Otherwise everyone scores “by gut feel” and prioritisation turns into a political brawl. Here is the recommended scoring grid, with each sub-criterion scored from 1 to 5.
| Axis | Sub-criteria to score (1 to 5) | What a high score means |
|---|---|---|
| Value | Annualised financial gain (hours saved × hourly cost, margin recovered, churn avoided), strategic impact, process volume and frequency, replicability across other teams. | A quantifiable, high, duplicable business benefit. |
| Feasibility (“can we do it?”) | Data availability and quality, technical access to source systems, model maturity for the task (validated by evals on your real data), GDPR / AI Act risk level, the business’s tolerance for error. | Data ready, model up to the task, risk under control. |
| Effort (“how much does it cost?”) | Build workload, cross-team dependencies, recurring run cost (LLM tokens, infrastructure, monitoring), change-management and adoption workload. | Careful: here a high score is unfavourable (it divides the priority). |
A simple, defensible calculation: priority score = (Value × Feasibility) / Effort. The value × feasibility product avoids promoting a high-value but unfeasible use case, or a very feasible but pointless one. Dividing by effort pushes the quick wins up. One clarification, to head off a legitimate criticism: feasibility answers “can we do it?” (does the data exist, is the model up to the task, is the risk acceptable) while effort answers “how much does it cost to build and to operate?”. A case can be perfectly feasible (clean data, mature model) yet demand heavy effort (multiple integrations, high token volume); keep the two axes watertight so you never count the same thing twice. Once each candidate is scored, you place it on the matrix.
| High feasibility | Feasibility to be built | |
|---|---|---|
| High value | Quick wins — launch these first, in production within 3-4 months. They fund and legitimise the rest. | Structural initiatives — high ROI but heavy prerequisites (data, platform). To be sequenced with milestones over 6-12 months. |
| Low value | Optional — small, quick gains, to pursue with residual capacity, without mobilising the executive committee. | To be ruled out — costly and of little use. Document the decision so it does not come back every quarter. |
A worked ROI example, from end to end
Take a real, anonymised use case drawn from scoping engagements, in a mid-sized B2B services company: automating the triage and pre-qualification of inbound customer-support requests via a governed LLM agent. The support team in question has 6 level-1 agents (generalist support) handling a volume of around 9,000 requests per month.
| Item | Calculation detail | Amount |
|---|---|---|
| Gross annual gain | 6 agents × 2 h/day of triage × 220 days = 2,640 h/year; the agent automates 70% = 1,848 h saved, at a fully loaded €38/h. | +€70,224/year |
| Build cost (one-off) | Design, ticketing integration, guardrails and evals: ~45 person-days at a €650 daily rate. | −€29,250 |
| Annual run cost | LLM tokens (~€600/month) + infrastructure and monitoring (~€400/month) + evals and maintenance (~€300/month) = €1,300/month. | −€15,600/year |
| Net ROI, year 1 | 70,224 − 29,250 − 15,600. | +€25,374 |
| Net ROI, year 2+ | Gross gain − run, build amortised. | ~+€54,600/year |
| Break-even (steady state) | At steady state, a net monthly gain of ~€4,552 ((70,224 − 15,600)/12) against €29,250 of build, i.e. 29,250 / 4,552 ≈ 6.4 months. | around the 7th month |
A point of methodological honesty: the break-even “around the 7th month” holds at steady state (net monthly gain of ~€4,552). Since the agent ramps up progressively, the first months mechanically deliver less, which pushes the real break-even beyond this theoretical calculation. It is a deliberately optimistic break-even, to be presented as such to an executive committee. On this case, the initial estimate assumed 60% automation; after the first quick win went into production, the agent held 70% once the evals had been refined on recurring request patterns — hence an ROI markedly better than the original business case. The detail matters less than the discipline: a use case only rises to the top of the roadmap if it withstands this kind of calculation, data prerequisites included. The fully loaded hourly cost of €38/h (level-1 support agent) and the €650 daily rate (integration/AI profile) are France 2025 orders of magnitude, to be recalibrated against your own pay scale and seniority levels. An honest range beats false precision — the goal is a defensible order of magnitude, not cost accounting to the cent.
Quick wins or structural initiatives: where should you start?
Start with one or two visible quick wins over the first three to four months. They serve a triple purpose: proving value to an often sceptical executive committee, bedding in your route to production, and politically funding the heavy initiatives. But do not stay stuck in quick-win mode: if after a year all you have is isolated automations, you have been sprinkling, not transforming. Structural initiatives (end-to-end process redesign, data platform, multi-step agents) launch in parallel, with a 6-to-12-month horizon and intermediate milestones.
The opposite risk exists too: launching a structural initiative too early, before you have a seasoned team and clean data. It is the costliest mistake we see in the field. To assess the quality and availability of your data before committing, read the guide Mapping your data for AI.
Build vs buy: should you develop or buy an AI solution?
Build vs buy is the trade-off between developing an AI solution in-house (build) and subscribing to an existing one (buy), with assembling building blocks as the middle path. The pragmatic rule: buy the commodity, build the differentiating advantage. An email-drafting assistant or meeting transcription are commodities: a vendor does them better and cheaper than you would. By contrast, an agent that orchestrates your business process, on your data, with your governance rules, is competitive advantage: you build it. In between, assembly (orchestrated open-source building blocks) covers the majority of enterprise use cases.
- Buy if the need is standard, non-differentiating, and a compliant SaaS exists — you are buying time-to-value.
- Build / assemble if the process is core business, if the data is sensitive, or if deep integration with your IT estate is what creates the value.
- Beware the false “buy”: a purchased tool that is heavily customised stacks the licence cost on top of the build cost. It is often the worst of both worlds.
How do you choose an LLM for the enterprise?
There is no single “best model”, only a model per use. Four criteria structure the choice: performance on your real task (measured by evals, not by marketing benchmarks), cost at the expected volume, confidentiality / sovereignty of the data, and latency.
A few mid-2026 reference points to make these criteria concrete (orders of magnitude, to be re-checked as they move fast): top-tier models via API sit around a few euros per million input tokens and up to several tens of euros per million output tokens, whereas a small “volume” model often costs less than one euro per million tokens — a gap of one to two orders of magnitude that on its own justifies a mixed architecture. On context windows, mainstream models offer from 128,000 to several hundred thousand tokens (useful for ingesting an entire case file without splitting it). On latency, expect something on the order of a second for a short API response; a real-time use (customer chat) and a batch use (classifying 9,000 tickets overnight) do not impose the same constraints at all.
Take care not to conflate two distinct axes. The first is the access mode: a model consumed via a managed API (you do not run the infrastructure) or a self-hosted model (you operate it on your own infrastructure, AWS or on-premise). The second is the licence: closed-weights or open-weights models. The two overlap imperfectly: a vendor such as Mistral offers both frontier models via API and open-weights models you can self-host, and open-weights models are also available through managed APIs. In practice: a managed API (Claude, Gemini, ChatGPT, Mistral) gives you access to frontier reasoning quality sooner and maximises time-to-value; a self-hosted model maximises control, sovereignty and cost control at high volume. The reasoning gap between closed weights and strong open weights narrows year on year, which makes self-hosting increasingly credible — one more reason not to set the choice in stone. The right architecture is often multi-model: a powerful model for complex tasks, a lighter model for the bulk of the volume.
What does an eval actually look like?
Evals are not only for model selection: they are what validates, as early as the scoring stage, the “model maturity for the task” criterion of your feasibility axis. Concretely, an eval is a hand-annotated test set: for example 50 to 100 real cases (past support tickets, with their correct category and priority), on which you measure an accuracy metric (correct-classification rate, F1) and compare it to a business acceptance threshold defined in advance (“at least 90% correct routing, otherwise human escalation”). A use case that no model can clear today is feasible “later”, not “now”. An eval is not a data scientist’s gadget: it is the quantified quality contract between the business and the technical team.
Never set the LLM choice in stone in the roadmap: abstract it behind an orchestration layer. Concretely, that layer handles multi-model routing (sending each request to the right model according to complexity and cost), fallback (automatically switching to a backup model in case of unavailability or failure), and observability (logging the cost, latency and quality of every call so you can arbitrate). This is exactly what a governed architecture enables — see the guide n8n, MCP and LLM agents.
Why do so many AI plans produce no ROI?
The gap opens up not at the experimentation stage, but at scale-up. A few orders of magnitude, with their source.
The common factor behind failures is almost never the model. It is the absence of a clear path from idea to production. The 3-4 month and 5-8 orders of magnitude come from the ianaos portfolio of scoping engagements between 2023 and 2025. The only external figure is a Gartner prediction issued in 2024 for the end-2025 horizon: according to its press release “Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025” (29 July 2024), a significant share of GenAI projects would be abandoned after the POC phase. Like any prediction, it should be read as an order of magnitude of its time, not as an observed measurement. If this concerns you, the checklist Taking an AI POC to production details the conditions to meet.
The pitfalls to avoid in an AI roadmap
- Prioritising by technology, not by value. “We’re going to do RAG” is not a use case. Always start again from the business problem and its indicator.
- Ignoring the run cost. Build is rarely the bulk of the cost over three years: depending on token volume, the run (tokens, infrastructure, monitoring, evals) can weigh as much or far more. In the support example above, over three years, the build (€29,250) accounts for only about 38% of the total cost against the run (3 × 15,600 = €46,800) — but this proportion depends heavily on volume and is by no means a universal rule. Build the run into the ROI from the first estimate.
- Underestimating the data prerequisites. A high-value use case on inaccessible or dirty data is not a quick win, it is a trap. Verify data feasibility before promising a deadline.
- Forgetting governance and compliance. GDPR and the AI Act are not an end-of-project formality. A poorly scoped high-risk use case can be blocked from production. Anticipate the trust layer from the scoring stage.
- Neglecting change management. A solution with 20% adoption has a negative ROI. Bring end users on board from the scoping stage and budget for training and enablement time.
- Freezing the roadmap. It gets revised every quarter. Models, costs and your priorities move fast; a rigid annual AI plan is obsolete by Q2.
Frequently asked questions
How long does it take to build an AI roadmap?
A few weeks are enough for a first prioritised, defensible portfolio, not six months of committees. A structured scoping exercise (workshops, scoring, matrix, ROI estimate for the top 5 to 8) typically fits into three to six weeks depending on the size of the organisation.
How do you build a value / feasibility matrix for AI?
Break each axis down into sub-criteria scored from 1 to 5. Value aggregates the annualised financial gain, strategic impact, volume and replicability. Feasibility (“can we do it?”) aggregates data availability and quality, access to systems, model maturity validated by evals, and GDPR / AI Act risk. Effort (“how much does it cost?”) remains a separate axis. Then cross value and feasibility: high value + high feasibility = quick wins to launch first; high value + feasibility to be built = structural initiatives to sequence; low value = optional or ruled out. Weight for effort with a priority score = (Value × Feasibility) / Effort.
How do you estimate the ROI of an AI use case before building it?
Quantify the annualised business gain (hours saved x hourly cost, margin recovered, errors avoided) against the full cost over three years: build, LLM and infrastructure run cost, monitoring and change management. Example: 1,848 hours saved at €38/h = €70,224 of gain, minus €29,250 of build and €15,600 of run = +€25,374 net ROI in year 1, with break-even around the 7th month at steady state (a little later in reality, while the agent ramps up). An honest range beats false precision; refine it after the first quick win.
Should you build or buy your AI solution?
Buy the commodity (standard, non-differentiating needs where a compliant SaaS exists); build or assemble the differentiating advantage (core-business processes, sensitive data, deep integration with your IT estate). Beware tools that are bought and then heavily customised: they stack licence and build costs.
Which LLM should you choose for an enterprise project?
The choice depends on the use, not on a leaderboard. Decide on four criteria: performance measured by evals on your real task, cost at volume (from under one euro to several tens of euros per million tokens depending on the model), data confidentiality and sovereignty, and latency (on the order of a second via API for a short response). Distinguish the access mode (managed API vs self-hosted) from the licence (closed vs open weights). A multi-model architecture (a powerful model for complex work, a light model for volume) is often optimal; abstract the model behind an orchestration layer (routing, fallback, observability) so you can switch.
Who should own the AI roadmap: IT or the business?
Both, under executive-committee arbitration. The business owns value and adoption; IT owns feasibility, infrastructure and compliance. The roadmap must be co-signed by the CEO and the CIO: that is the condition for it to survive the year’s budget arbitration.
Move from experimentation to AI in production
Start with a short, fixed-price diagnostic: maturity, high-ROI use cases, and a prioritised roadmap. No commitment.