---
title: "The second implementation as proof"
description: "Once is a demo, twice is a pattern: how to tell whether an AI workflow is genuinely repeatable."
source_name: "Gen8"
source_url: "https://gen8.app/en/kennis/tweede-implementatie-als-bewijs/"
site_home: "https://gen8.app/"
source_description: "Managed AI service for SMEs. We set up, connect and manage; you stay in control."
locale: "en"
authors:
  - name: "Sasker Soontiëns"
    url: "https://gen8.app/en/kennis/author/sasker-soontiens/"
copyright: "© 2026 Gen8 VOF · Dutch Chamber of Commerce 92978789 · Delft"
published_at: "2026-09-10T00:00:00.000Z"
modified_at: "2026-10-21T20:11:40.922Z"
---

# The second implementation as proof

The first implementation proves it can work. Only the second shows whether it worked because of the workflow or the people standing beside it. That distinction determines what you promise the next client.

By Sasker Soontiëns · September 10, 2026 · Decisions and control

## Why the first time does not count

The first implementation has everything that will no longer be there afterward. The builder watches daily. Users know they are in a trial and report every odd result. Exceptions are solved on the spot by someone who understands why the workflow does what it does.

This is no criticism of pilots — that is how a pilot should work. It only means the outcome blends the workflow with the attention around it, and you cannot separate those while you have only one example.

## What the second time demonstrates

In the second implementation, in another organization or department, exactly one thing changes: the builder's attention is no longer there in the same way. What holds up was in the workflow. What collapses was in the surrounding people.

Three things become visible that you could only suspect before:

- **Which exceptions are structural.** An exception occurring in both organizations is a process characteristic. One occurring in only one place was a local agreement.
- **How much of the instruction was truly general.** Everything you rewrite for the second client belonged to configuration, not the workflow — even if it was in the same text.
- **Whether the documentation is correct.** The only honest test is having someone else do it using only what is written.

## What you must measure to say this

This only works if the first implementation already records what you want to compare in the second. At minimum: the share of proposals approved unchanged, adjusted and rejected, with reasons. That distribution is a workflow's fingerprint — and the only way to say whether the second implementation performs equally well.

Without that log, comparison is a feeling, and feelings about the second implementation are systematically too positive: you remember the first one's startup problems better than the second's.

## What this means for your promises

Before the second implementation, you can honestly say: we built this and this is how it works there. Only afterward: this works this way in different organizations, and these are the exceptions to expect. The difference between those statements is exactly the difference between a reference and a product.

## If the second time disappoints

That is a good outcome if you use it. A workflow stalling in the second organization reveals the hidden assumption — usually source-data quality or an unwritten working agreement everyone knew. Making that assumption explicit is more valuable than the time saving calculated at the first client.

## What to do with this

Look at the workflow you mention most often in conversations and answer one question: can someone other than the builder set it up using only the documentation? If not, the first task is finishing the documentation rather than finding the second client.

## Frequently asked questions

Does a second department in the same organization count too?

Partly. It tests documentation and configuration separation, but not the assumption that systems, data quality and working agreements differ elsewhere. Treat it as half a second implementation.

How long must you measure before saying anything?

Long enough to see recurring exceptions, which mainly depends on how often the process runs. A daily process gets there faster than a monthly one; the number of runs matters, not the calendar.

## Want to apply this to your own process?

Bring one process to a conversation. We assess suitability, risk and the cost of the first step.

[Book an introduction](<https://gen8.app/en/contact/>)

- Reply within one business day
- No obligation