Why a pilot stalls
A pilot that works technically but still disappears almost always stalls for the same reason: nobody agreed beforehand when it would be good enough, or who would manage it afterward. The technology was the easy part. The five decisions below cover everything else.
Decision 1 — Which problem, and why that problem?
Choose a high-frequency process with reversible errors. Not the process with the largest annual cost, because that is usually also the process with the most exceptions, the most stakeholders and the slowest feedback.
Record what the process currently costs in time per run and in turnaround time. This is a baseline, not a business case; without those two numbers, you cannot demonstrate anything afterward and the discussion becomes a battle of opinions.
Decision 2 — Where does the data come from, and where does it stay?
This decision is often postponed until the security review, which is where pilots fail. Determine beforehand: which systems will be read, whether anything will be written, which data will leave your own environment, how long anything will be retained, and where processing will take place. Processing in the EU is a firm requirement for many organizations; that is a design decision, not a detail to configure later.
Also make explicit which data you deliberately exclude. A workflow that sees less is easier to approve and easier to explain.
Decision 3 — What control level for each step?
For each step, choose between read-only, proposals with human approval, and automatic execution with a log of every step. This is not a setting you look up later: it determines what the workflow looks like, who is involved and how fast it runs.
Almost every step that changes something or sends something externally starts with approval. You change that later, supported by the log of approved and rejected proposals — not on instinct or because approval feels like a delay.
Decision 4 — When is it good enough?
Agree on the acceptance criterion before building, and express it in terms of the user's work, not model metrics. For example: out of a hundred real cases, at least x proposals are approved unchanged, and cases requiring changes take less time than the old process.
More importantly, also agree what happens if the criterion is not met. Stopping is a valid outcome and much cheaper than endlessly polishing a pilot because nobody dares to end it.
Decision 5 — Who will manage this in six months?
A production workflow needs an owner who reviews exceptions, someone who intervenes when a source system changes, and an agreement about where the workflow, credentials and logs will reside if the collaboration ends. Arrange this at the start. Afterward it is a negotiation; beforehand it is a paragraph.
What you gain
Four of the five decisions together take a morning and concern agreements, not code. That is the cheapest point at which a pilot can still be canceled — and the only reason a successful pilot then actually keeps running.