Running a Tvijo pilot and measuring the benefit

A pilot is not "let the team try it for a month". It is one workflow, one acceptance check, a fixed set of numbers, and exit criteria agreed before the first task runs. Without those, the only possible result is an opinion.

🧭 Step 1 — pick one workflow, not a department

Good pilot candidates share three properties:

• the output is checkable (a test passes, a document matches a template, a query returns the expected result);
• the work is repeated (so a small improvement compounds);
• a mistake is cheap and visible (so nobody has to trust the pilot blindly).

Bad candidates: anything that ends in a customer-facing promise on day one, anything involving regulated personal data, anything with no acceptance check.

🧭 Step 2 — agree the gates

Write them down. "We'll see how it goes" is not a gate, and it guarantees that the pilot's cost cannot be attributed to anything.

🧭 Step 3 — measure four numbers, every week

Two derived numbers are worth reporting but not optimising directly:

• Rework rate — accepted results ÷ all produced results.
• Cost of the discarded work — receipts of tasks whose output was rejected. This is the number pilots usually hide, and it is often the largest one in week one.

Do not report "time saved" without a baseline. If the team did not do this work before the pilot, there is nothing to compare against — say so.

🧭 Step 4 — instrument before you start

You need, from day one:

• the receipt of every task (provider, model, tokens, spend, state);
• the acceptance check, run by a person or a script, with a timestamp;
• a count of manual corrections;
• a list of incidents (data sent by mistake, a wrong action, an outage).

If any of these is missing, the pilot's conclusion will be a story rather than a result.

🧭 Step 5 — weekly review, written

A 20-minute weekly review with a one-page note:

• what was accepted, what was rejected, and why;
• cost per accepted result, and its trend;
• interventions and their causes;
• one change for next week;
• risks that appeared.

Four of these notes are worth more than a final slide deck, because they show the trend rather than the summary.

➡️ Exit criteria — both directions

Agree in advance what would make you:

• expand (accepted-result ratio above X, cost per accepted result below Y, no data incidents);
• stop (ratio below X after two iterations, an unresolved data incident, or a cost curve that does not bend).

A pilot with only an expansion criterion is a purchase with extra steps.

🚧 When this does NOT work

• You cannot define acceptance. Then you cannot measure anything; fix that first.
• The workflow is not repeated. One-off work cannot show a trend.
• You need a guarantee of savings. Tvijo gives you receipts, not a promise. Savings are computed from your before/after numbers.
• The team cannot change its process. A tool that is bolted onto an unchanged process usually shows cost without benefit — and that is a valid finding.

➡️ Next

• Costs, budgets and limits — reading the ledger you will report from.
• Permissions and data flow — the data gate in detail.
• AI judging — the acceptance check the metrics depend on.