Every claim in a bid, traceable to its source.
Tender documents turned into a requirement matrix the partners can actually review — for a Nordic engineering consultancy.
A small, honest engagement: a consultancy's tender documents read clause by clause, answered from the firm's own material, with every gap named instead of filled.
A delivered engagement, presented with the client anonymised — a Nordic engineering consultancy. Figures are not published for this work: the scope was one tender at a time, deliberately small.
The problem
In a small consultancy the partners write the bids, and they write them at night. The material arrives as a pile: the client's requirements, the annexes, the forms, the evaluation criteria — in the formats and languages the clients happen to use.
One missed requirement can disqualify the whole bid, so every clause is checked against every answer, twice. The work is not hard. It is simply endless, and it lands on the same people who are already running projects.
The environment
Tender documents and the firm's own answers live in different places: the client's PDF, the consultancy's project archive, the CVs, the reference list, the price sheet from last time.
A bid is assembled from all of it, under a deadline, and it has to be defensible clause by clause afterwards — because that is exactly how it will be read if the firm wins.
Constraints
Nothing may be invented. A bid is a commercial document the partner signs, and every claim has to trace either to the client's own requirement or to material the firm can stand behind.
The system therefore has one hard behaviour: when it cannot source an answer, it says so and leaves the section to a person. A plausible sentence is worse than a visible gap.
System
The system extracts the requirement list and builds the matrix: every clause numbered, categorised and paired with the answer it needs. It then pulls candidate material from the firm's archive — comparable projects, the right CVs, prior references.
Drafting happens against that matrix, section by section, with the source attached to each claim. What is left is a document a partner can review by exception rather than by reading everything from the beginning.
Workflow
Documents in → requirement matrix → answers sourced from the firm's material → gaps flagged → partner review and pricing → submission. The order never changes, and the last step is always a person.
On a repeat tender — the same client, the next framework — the matrix and the sourced material carry over, so the second bid starts from a structure instead of a pile.
Validation
Each answer names its requirement and its source. Anything without one appears in a gap list; nothing is filled in to look complete.
Acceptance was run on live tenders with the partners who write them: they checked whether they could defend each answer without leaving the document.
What it changed
Bid work moved from reading the whole pile again to reviewing a matrix and filling named gaps. The evenings came back, and the firm can say yes to more invitations to tender that it would previously have let pass.
The partners keep the part that is theirs — judgement, pricing and the signature. The system keeps the part that never needed a partner: finding, pairing and checking.
What we learned
In commercial documents the value is traceability, not generation. A bid that cannot be defended clause by clause is worse than a slower bid, because the failure arrives after the work is priced.
It also taught us how small an engagement can be: sometimes a system should not replace a department. It should remove one recurring evening from two people who are good at their jobs.
The system, layer by layer.
Each layer does one job and hands a defensible result to the next. Nothing is inferred into the record, and the last layer is always a person.
Questions about this work.
Does the system write the bid?
It assembles the material and drafts against a requirement matrix, but it does not price, promise or sign. Those stay with the partners, and every generated claim carries the source it came from — or it appears in the gap list instead.
Why is there no benchmark or metric on this page?
Because the engagement was small and the client's figures are not ours to publish. We describe what was built and how it was validated; where a client agrees to publish measured numbers, we publish those too — this one did not, and we would rather show nothing than show something invented.
How does it avoid inventing claims in a legal document?
By refusing to close gaps. Every extracted requirement is paired with material from the firm's own archive; if no source exists, the section is left open and listed. The partner sees exactly what is answered and what is not, before anything is submitted.
See what we can engineer for your operation.
The same systems thinking applies to document flows, operations, sales and knowledge — not only technical design.