The order of decisions, from a business pain point to something that stays up and running
A method guide for companies turning over €3–50M that have already tried a tool and haven't managed to get anything into production. Where to start, how to prioritise, what a pilot that works looks like and what has to happen for it to survive.
The sequence repeats itself in almost every mid-sized company. Someone tries a tool and it works for them. It gets bought for the team. For three weeks there's enthusiasm. By the third month two people are using it, nobody can say what has improved and the conversation has moved on to the next tool.
It isn't a technology problem: the tool did what it promised. It's a problem of order. It started with the answer—the tool—without having written down the question—what hurts, and how much. And an answer without a question can't be evaluated, so it can't be defended when the first busy week comes along.
One technology changes a task. Several together change the system.
It isn't negotiable and it can't be done in reverse. Each step conditions the next, and skipping one explains almost every project that never gets there.
Four decisions, in this order. If you catch yourself talking about a tool before step 4, you're back at the start.
“It costs us , and today that's hours a month or € a year.” If you can't put a figure on it, it isn't a case yet: it's a nuisance.
One specific task, for one specific person, in one specific process. “Improve customer service” isn't a use case; “draft the first reply to a warranty claim” is.
Where it lives, who maintains it, what state it's in and who can authorise its use. Without those four answers, you don't go on.
It's chosen last, and it's chosen against the three previous steps. It's the easiest decision to change, and that's why it comes last: changing it doesn't invalidate the work done.
In a mid-sized company, the value is rarely where people talk about it most. These four places share one feature: the work is already written down somewhere, so it can be measured before and after.
Quotes, cost breakdowns, acceptance criteria, technical answers. When someone has been there twenty years and everything goes through them, the risk isn't one of efficiency: it's one of continuity. Capturing that judgement in something people can consult is worth it on its own, with or without AI.
Offers, tender documents, complaints, the usual questions. The first draft is where the time goes; the review is still human and should stay that way. This one is easy to measure: time to first draft and number of rounds.
From the delivery note to the ERP, from the email to the CRM, from the job sheet to the timesheet. It isn't the flashiest case and it's usually the most profitable, because the error it removes costs more than the minute it saves.
Contracts, supplier invoices, regulations, tender specifications. Slow work, subject to deadlines and with consequences if something slips through. Start by extracting and comparing, never by deciding.
Score each candidate from 1 to 5 in the five columns and rank them by the total. The fifth column is the one that has saved the most pilots and the one almost nobody includes.
| Criterion | What you ask | Scores high if… |
|---|---|---|
| Value | How much is solving it worth, in hours or in euros a year? | The figure from step 1 is large and someone in finance recognises it. |
| Measurability | Can you measure the before and after without setting up anything new? | The data is already recorded today, even if by hand. |
| Effort | What does it take to have something working in ninety days? | It doesn't require integrating systems or migrating data to get started. |
| Risk | What happens if the result is bad and nobody notices? | The error is visible, reversible and a person reviews it before it goes out. |
| Owner | Who answers for this still being used six months from now? | They have a name, they're inside the process and it's in their interest for it to work. |
The owner column isn't a formality. A case without an internal owner holds up while the project's enthusiasm lasts and falls apart exactly when the project ends. If nobody inside wants to be the owner, that's information about the case, not about the people.
Almost no implementation stalls because of the model. They stall because the data needed was in five places, under three different names, maintained by nobody in particular and with a part that couldn't be used. These four questions are answered in writing before looking at any tool.
Ninety days are enough to know whether something works and too few for it to turn into an endless project. The end date is set on day one, and with it the stop criterion.
One case, one person, one number. Not two cases “while we're at it”: the second case doubles the work and splits attention just when it's needed in full.
Today's number, actually measured and not estimated in a meeting: how long it takes, how many rounds it goes through, how many errors slip in. Without a baseline there's no improvement, just opinions.
Something the person who does that work actually uses in their day. With mandatory human review and an obvious place to say “this came out wrong”.
The corrections that come from use, not from a list of improvements written in advance. This is where you discover what the process was doing that nobody had mentioned.
The same number as in week 1, measured the same way. And one of three decisions, in writing: it's rolled out further, it's adjusted and extended once, or it's stopped. Stopping well is a result.
A pilot that works isn't a system that stays. These five conditions separate one from the other, and all five are about organisation, not technology.
The fifth condition is the one most often skipped and the one that turns an improvement into a dependency. A system that only the person who built it understands isn't a company asset: it's a risk with a friendly face.
The resistance is almost never to the tool. It's to the implicit message, which people read before anyone says it: if this does my job, what am I here for? As long as that question has no public answer, everything else is theatre. And the answer has to be true, because it will be checked.
Training isn't a generic course for the whole workforce. It's matching what each person needs to know to what they actually do: who uses the system, who reviews its output, who makes decisions with it and who answers if it goes wrong. As well as being what works, it's what European law requires, and since earlier than almost everyone thinks.
What it's for, what it isn't for, how to recognise bad output and what to do with it. With examples from their own work, not generic ones.
What to look at and in what order, where the system tends to fail and the threshold beyond which things get escalated. Review without judgement turns into a click.
What can and can't be claimed with this, which obligations apply and what the company is liable for. It's the shortest training and the one most often skipped.
Two obligations under the EU AI Act affect any company using these tools today, whatever its size: AI literacy for the workforce, in force since February 2025, and transparency, which requires telling people when they're interacting with an AI and labelling certain synthetic content.
It isn't a layer added at the end. Deciding where human review comes in, what data can be used and what the customer is told are design decisions for the use case: taking them at step 2 costs a conversation; taking them once it's in production costs redoing it.
PDF guide, with the prioritisation matrix and the preliminary checklist
The whole guide, with a blank prioritisation matrix and the checklist of twelve questions to ask before signing up to any tool.
Everything in the file is also on this page, open and without asking for anything. The email is so we can send you the version you can print and take to a session.
Done. Here it is.
Download the guide as a PDFIf the file doesn't open, save this link: it will keep working.
You decide which cookies we use
With your permission, we measure, in aggregate, how quether.com is used and remember your visit to show you Quether ads on Facebook and Instagram. You can accept everything, reject everything or choose. More detail in our cookie policy.
