The 45-day pilot: how to prove in six weeks what AI delivers
A 45-day pilot takes one management question, records a baseline measurement up front and builds one working application on your own sources in six weeks. On day 45 there is a factual decision: sharpen, stop or scale up. No year long program, no report full of recommendations, but measurable proof.
What is a 45-day pilot?
A 45-day pilot is a bounded experiment with one goal: to show whether AI adds value at your leadership table, measured against a baseline recorded up front. You change nothing in your systems. You connect sources, build one application and test it with real management questions.
Six weeks is not an arbitrary term. It is long enough for two full management cycles and short enough to hold everyone's attention. Anything that runs longer quietly turns into a program.
What does the 45-day pilot look like, phase by phase?
- Day 1: AI impact scan. Ten questions, three minutes, a personal report right away. It surfaces your biggest decision bottlenecks, plus a first estimate of available information, feasibility and value. This is the basis for choosing the question.
- Day 2 to 7: diagnosis and baseline measurement. We speak with three to five people, look into the sources and record how things work today. How many days sit between signal and decision? How many hours of digging come before that? How complete and how current are the sources? By the end of this week one question is fixed, along with the standard and the measuring points.
- Day 8 to 30: build. One application, one agent, on your own data. We read sources, we write nothing back into them. Halfway through, around day 18, there is a working version the leadership team can already look at.
- Day 30 to 44: prove. Real users, real management questions. Every outcome gets tested: is the number right, does it trace back to the source, and would you have known this without the application? Findings that do not hold up come off the list.
- Day 45: decide. One two hour session with the leadership team. The outcomes sit next to the baseline measurement. Three possible decisions: sharpen, stop or scale up.
What exactly do you measure?
Four quantities, all recorded up front. What you did not measure beforehand, you cannot claim afterward.
| What | Baseline measurement (example) | After 45 days |
|---|---|---|
| Decision lead time | 19 working days from signal to decision | 6 working days |
| Research time per decision | 11 hours, spread across 4 people | 2 hours |
| Validated value opportunities | Not in view | € 54.000 in unbilled additional work |
| Traceability | Unknown or not recorded | 100% of the numbers traced back to the source |
Validated value opportunities come in three kinds: margin leaks (work you deliver but do not invoice), missed revenue (opportunities picked up too late or not at all) and avoidable costs (rush shipments, duplicate work, penalties for late delivery). An opportunity only counts once someone responsible puts their name under it. An estimate from a model does not count.
Decision quality is measured differently. You test it by putting three decisions from the past year back to the application. Would you have decided the same way with this information? For two of the three decisions the answer should be ‘yes, but faster and with more certainty’. For at least one decision a new insight should come to the surface that you missed at the time.
When do you stop the pilot?
Stopping is a normal outcome, not a failure. You stop in four situations.
- The sources are too thin. If hours are structurally logged three weeks late, no application can repair that. Process first, then technology.
- Decision lead time drops by less than a third. Then the bottleneck is not information but decision making or mandate. That is a governance question.
- The value found is smaller than the upkeep. If it produces € 15.000 of value a year and monitoring it costs half a day a week, the math does not work.
- There is no owner. Without a leadership team member who looks at it every week, any application disappears within a quarter.
A pilot that stops honestly on day 45 is cheaper than a program that runs for two years because nobody dares to intervene.
What does embedding mean, and when do you scale up?
Embedding is the dull step that makes the difference. The application gets a fixed place on the leadership team agenda, an owner, a quarterly review moment and an agreement on what happens when a signal comes in. Without those four, the result evaporates.
You only scale up once the first application has run at least one full cycle without help. After that the next application comes on the same digital foundation, not alongside it. From about five applications on, a Digital Twin takes shape: a coherent management layer across your whole company.
What does it ask of you and your team?
Count on about 14 hours of leadership team time over six weeks: two hours in week one, one hour every two weeks, and two hours on day 45. On top of that you need one employee involved in the substance for about three hours a week, plus someone from IT for two to four hours in total for access to sources. Which agreements you record before the start is set out in AI at the table, people at the helm. What the application actually does you read in What are AI agents, and why this is something other than reporting in From BI to Management Intelligence.
Frequently asked questions
- Why 45 days and not three months?
- Six weeks covers two full management cycles, enough to see a pattern and test the result. In practice, longer means less sharpness: the question broadens, attention drops and the decision moment slips. The hard end date is exactly what makes the pilot useful.
- Do we have to change anything in our ERP or CRM?
- No. During the pilot we read from sources and write nothing back into them. You do not have to migrate, switch vendors or build a data warehouse. If data is missing, that is an outcome of the diagnosis, not a condition up front.
- What happens if the pilot delivers nothing?
- Then we stop on day 45 and you keep the baseline measurement, the diagnosis and a concrete picture of what is wrong with your information supply. That is valuable in itself: you then know where the real bottleneck sits, and that is often process or mandate rather than technology.
- Who from our company has to be involved?
- One leadership team member as owner of the question, one employee with subject knowledge who knows the sources and the rules, and someone from IT for access. More people make it slow. Fewer people make it unreliable.