B2B / distribution
A recurring contract process spanning multiple brands, contract types and languages was turned into an internal tool. Not by digitising the existing document, but by first making the rules, exceptions, numbering and historical data explicit — and then, above all, testing what could never be allowed to go wrong.
The situation
The process worked. Agreements were drawn up from existing templates, details were filled in, the right version was chosen, and documents found their place in the archive. That worked because whoever carried out the process also knew how it was put together. It's just that not every rule was written down anywhere.
There were multiple brands, different types of agreements, and multiple languages. Sequence numbers had to line up correctly with the existing history, certain combinations were explicitly not allowed, and existing data and already-issued numbers couldn't be put at risk. As long as everything happens manually, experience absorbs that complexity. With automation, that safety margin disappears.
The business question
The first question looks simple: can we automatically generate the right contract from a set of inputs? Technically, that's not the hardest part. The harder questions came before it: which data determines which document gets used, which fields are mandatory, which combinations have to be blocked, how do you handle multiple people within one agreement, and how do you prevent two actions from getting the same contract number?
A mistake in a social post is something you fix. A tool that issues duplicate contract numbers or damages existing records creates a different kind of problem. That's why reliability outweighed extra functionality from the start.
The choices made
Existing behaviour wasn't replaced right away. First it was established what was happening correctly today, and which behaviour absolutely had to be preserved. The existing data remained the starting point — not something rebuilt during development because that was easier.
Business rules had to be fixed in place. Contract type, brand, language, numbering and permitted combinations couldn't depend on a model that "probably" landed on the right interpretation. AI helped with analysis, development and review; the rules themselves stayed explicit and verifiable.
From that followed a simple design rule: whatever isn't allowed gets blocked before a document exists — not flagged afterwards. And for the numbering, one hard requirement applied: two actions, even simultaneous ones, may never result in the same contract number.
My role
My role didn't start with code. First, the existing workings were taken apart: document types, choices, exceptions, historical numbering, and how data was kept up to date. That produced an explicit description of the process — the rules the tool had to comply with no matter what.
After that, the tool was built and tested iteratively. AI was used in several roles along the way: producing code, questioning assumptions, spotting exceptions, and having a second model check the workings. Important behaviour wasn't just checked visually: automated tests were added for rules that weren't allowed to shift when something about the tool changed later. That test set gradually became more than an after-the-fact check. It became the description of the behaviour we wanted to preserve.
Execution
The first working version ran locally: a simple interface, the existing data, and document generation. The user selects what's needed; the tool checks the input, applies the rules, generates the document, and logs what happened.
Then came the situations that are easy to forget in a demo: multiple people within a single process, existing number ranges, document conversion, a bug in a program the tool depended on. Each time, the question wasn't just whether we got it working again, but also whether the same mistake could quietly come back later. Where possible, fixes were therefore followed by tests and a separate review of the behaviour involved.
When an online version came up for discussion, the local technical choices weren't copied blindly. Storage, access, files and document conversion were redesigned for the web environment, because what works well locally isn't automatically a good server-side solution. The rule stayed the same: fix the behaviour first, only then change the platform.
What was deliberately not done
No chatbot built around a process that mainly needed fixed rules. No AI left to decide which contract rules "probably" applied. No rebuilding of existing data or resetting numbering because that would have made development easier. No fix counted as successful just because the document could be regenerated once. No online version designed by simply copying the local choices. And no automation added just because it was technically possible.
The tool had to save time. But not by giving up control over the process.