How to build an AI roadmap before picking tools
Most AI initiatives start with a demo. A vendor shows an impressive application, someone on the shop floor plays with a new tool or management hears that a competitor is already working with AI. Then comes the question: how do we use this technology in our own company?
That sounds logical but there is a catch. You start from the solution while the problem is not yet clearly defined. A good AI roadmap therefore does not begin with technology. It begins with your business goals, your processes and the decisions you make every day.
In short: A good AI roadmap does not start with a tool but with your business goals, your processes and the decisions you take daily. You first establish which bottlenecks AI should solve and what that is worth. Only then do you pick the technology that fits. That way you compare vendors on your criteria instead of on their demo.
How AI then takes over real work in custom business software is explained on our service page.
An AI roadmap is not a shopping list of tools
A roadmap is not a list of tools you plan to buy later. It describes which results you want to achieve, which bottlenecks you want to solve and in which order you will tackle them. Technology only enters the picture once you know what you want to automate, accelerate or improve. Anyone who works the other way around ends up with scattered experiments without a common thread and without measurable impact on the organisation.
Step 1: start from your business goals
Every AI roadmap starts with the question of what your company concretely wants to achieve over the next two to three years. For example:
- protecting your margins despite rising costs
- quoting faster for complex products
- lowering your inventory without disappointing customers
- keeping administration flat while your order book grows
- capturing the knowledge of experienced staff before they leave
- lifting your delivery reliability
- speeding up your reporting
- replying to customers faster
As long as you do not make these goals explicit, AI remains a technology looking for a problem.
Step 2: find the structural bottlenecks in your processes
Once your goals are on the table, look specifically at the processes that weigh on you the most:
- Where do people spend hours every week searching through documents, contracts or specifications?
- Where do staff copy information by hand from one system to another?
- Where do you repeatedly run similar analyses for different cases or clients?
- Where do you struggle to combine data from ERP, CRM and Excel before making a decision?
- Where does a lot of time go into classifying exceptions or answering repetitive questions?
- Where would you like to forecast from historical data while you lack the time or the model to do so?
These bottlenecks form the foundation of your roadmap.
Step 3: describe the desired result for each bottleneck
A roadmap only gains weight when you describe the target result sharply for each bottleneck. "Quoting faster" is too vague to act on. "Reducing the lead time of a quote for product X from an average of 90 to 60 minutes without more errors" is workable. That kind of wording immediately gives you a yardstick: you know what you measure, when you measure it and when a solution is good enough to build on.
Step 4: assess opportunities on more than business value
Not every opportunity with high business value is also immediately realistic. To avoid choosing on enthusiasm, assess every opportunity on seven dimensions:
- Business value: how large is the gain in time, money or quality?
- Process volume: a solution for ten cases a year rarely justifies the investment.
- Data: is the data you need available, reliable and up to date?
- Impact of an error: a minor irritation or an incorrectly paid invoice?
- Exceptions: how many exceptions sit inside the process?
- Integration: how heavy is the connection with your existing systems?
- Change capacity: does your organisation have room to really engage with it?
These seven dimensions help you separate real priorities from interesting ideas.
Step 5: define the function first, technology second
For each opportunity, describe what the solution has to do functionally, independent of any model, platform or vendor. For example: extracting information from a specific type of document, formulating a proposal based on similar cases, showing the sources behind that proposal, indicating how confident the model is, leaving the final decision to a staff member, storing the approved result in your ERP and logging every change for audits.
This functional description keeps you vendor neutral later on. You compare candidates on what they actually solve, not on who gives the flashiest demo. It also helps you plan for what happens if your AI vendor disappears.
Step 6: split initiatives across three categories
Once your opportunities are scored and functionally described, split them across three categories:
- Quick wins deliver measurable gains within a few months, without heavy integration or major data preparation.
- Strategic projects reach deeper into your processes and systems. They require more preparation, budget and change management and carry a clearly heavier business impact.
- Foundations are not AI applications in themselves. They are preconditions without which the rest cannot run sustainably: data quality, master data, access management, an integration layer, monitoring and governance.
Without those foundations, ambitious projects remain built on shifting sand.
Step 7: plan experiments with clear boundaries
Before you launch a strategic project, plan an experiment with sharp boundaries. Decide up front which results the experiment must achieve to count as a success. For example:
- the model classifies at least 85% of cases correctly
- the average time per case drops by at least 20 minutes
- staff adjust fewer than one in five proposals
- the operational cost stays below an agreed monthly amount
Without such criteria, a pilot drifts into a project without a clear end point.
Step 8: make ownership visible
Every opportunity on your roadmap gets three owners:
- The business owner is responsible for the value the solution has to deliver.
- The process owner knows the working method, the exceptions and the colleagues who work with it every day.
- The technical lead safeguards the integration with existing systems, the data sources and the security.
Without these three roles, an AI project stays an IT experiment disconnected from daily operations.
Step 9: revisit the roadmap periodically
An AI roadmap is not a document you dust off once a year. Models, vendors and prices evolve so quickly that what seems unfeasible today may become realistic within six months. The reverse happens too. So plan a short review at least every six months. Check whether the goals still hold, whether new bottlenecks are emerging, whether experiments deliver their promised results and whether the foundations have matured enough for heavier projects.
semanu builds custom business software with AI as the engine and starts from your goals and processes, not from a tool. Tell us what you want to achieve. Together we work out the first step.
Get in touch →Conclusion
A good AI roadmap does not start with a vendor, a demo or a tool. It starts with the question of which goals you want to reach, which bottlenecks you want to solve and which foundations you need to carry AI sustainably. Those who respect this order avoid tunnel vision on one technology and keep control in their own hands. Those who reverse it often pay twice: first for a tool that does not fit, then for the correction.
Frequently asked questions
Why should you not start an AI roadmap with a tool or vendor? Because you would be choosing a solution for a problem that is not yet defined. A roadmap starts from measurable business goals such as margins, speed and quality. Only then can you score opportunities and only then does technology come into view.
What is the difference between an AI experiment and a strategic AI project? An experiment answers a concrete question with stop criteria and a small budget. A strategic project has more impact on processes and integrations. It requires foundations such as data quality, access management and governance in advance.
Who should own an AI project? Three roles: a business owner responsible for the value, a process owner who knows the working method and the exceptions and a technical lead for integration and security. AI must not be an IT-only project.
How often should you review an AI roadmap? At least every six months. Models and vendors evolve quickly and what looks unfeasible today may become realistic within half a year. Reassess the opportunities, the foundations and the open risks at that point.

Tom de Vree · founder of semanu
Tom de Vree builds 3D configurators, business software and automations for SMEs in Europe.
