Interviews with the teams that do the work. Processes mapped, data inventoried, systems checked. Every candidate written as a one-line problem with an owner.
Sales wants a chatbot, finance wants invoice matching, operations wants forecasting. Without a shared measure, the loudest request goes first.
The most visible use case is rarely the one with the data, the owner and the process to make it work. It stalls, and the second project inherits the doubt.
An AI line in the plan with no phases, no gates and no number that says whether it worked.
We look at your processes, your data and your systems, score the candidates on value and feasibility, and write the roadmap: what goes first, what it needs, how you will know it worked.
Three parts: find the candidates, rank them, plan the first one properly.
Where the routine and the data meet.
Value against feasibility, in the open.
Enough detail to start on Monday.
Four phases, most of them in your building.
Interviews, process maps, data inventory.
Score, rank, explain.
Phases, gates, owners, budget.
The first project, planned to the day.
A shared list, a defensible order, and a first project built to succeed.
The candidates, the scores and the order, written with the people who own the processes. The debate moves from opinions to the scoring.
Data, owner, process and permissions confirmed before a line of code. The most common cause of a stalled pilot is removed up front.
Each project ends with a number against a target. The next one starts because the last one worked, or does not start at all.
| Side by side | Project by project | With a roadmap |
|---|---|---|
| How the first project is chosen | Loudest request or best demo | Scored on value and feasibility |
| What it has on day one | An idea | Data, owner, permissions, a measure |
| Speed | Fast start, long stall | Two weeks to plan, then a clear run |
| Risk | Found during the build | Named before it, with a gate |
| Knowing it worked | A feeling | A number against a target |
AI Discovery is two weeks at a fixed price and produces the ranked backlog, the roadmap and the plan for the first project. Larger organisations with many candidate processes can take longer; we say so after the first week of interviews.
The roadmap is written around your processes and your constraints on data, which change slowly. Model and vendor choices are made per project, at its start, with the options available then. A model policy in the roadmap says how those choices are made, so a new release changes a decision without changing the plan.
Time from the people who own the candidate processes, for interviews and for scoring. Read access to a sample of the data and to the system inventory. A sponsor who can settle the ranking. The sprint is designed to need a few hours a week from each of them, and no new hires.
Each project on the roadmap carries its own measure and target, agreed with its owner. The strategy is measured by those numbers landing, project by project, and by the gates being honoured: a project that misses its gate stops, and that is the strategy working.
We are a small team of senior specialists. We pick the right model and the right layer, and we build the least machinery that does the job. You get a call with an engineer, not a sales deck.
