Matter pack
One structured input produces the full document set for a transaction, including agreements, letters and notices.
Service · Document automation
Document automation that produces the finished set, not a draft
Enter the matter details once. Get the configured document set for that matter type, correctly formatted, with the wording held in one versioned place instead of in whichever file someone copied last.
The problem
The document is not the work. Rebuilding it is.
Most teams that produce high volumes of similar documents are not writing them from scratch. They are opening the last similar one, stripping out the previous client's details and typing new ones in. It works until it does not: a stale clause survives a copy, a field gets missed, a fee changes and only some templates learn about it.
The cost is not really the typing. It is the checking, and the fact that the correct wording lives in someone's head and in a folder of near-identical files.
Fit
Who this is for.
Teams producing repeated, high-consequence documents from structured data: conveyancing and property, professional services engagement paperwork, lettings and tenancy, finance operations. Usually somewhere between five and fifty people, with at least one person whose week is partly document assembly.
Not a fit if every document is genuinely bespoke, or if the wording is not settled enough to template. We will say so on the call rather than build you something that needs rewriting.
In practice
What gets built.
Clause bank
Standard wording lives in a spreadsheet the team owns and extends, not in code. Future documents generated from that template reflect the update.
Completeness gate
A required field that is missing stops generation and says which one, instead of producing a document with a blank where a party name belongs.
Version control on wording
Templates are versioned separately from the generation logic, so a fee or statutory change is a template edit, not a developer task.
Deliverables
What you get.
- A generator per document type
- A structured input your team fills in
- Versioned master templates you own
- A validation layer that refuses incomplete data
- A one-command run that produces the whole set
- Documentation written for handover
Design decision
Why no model touches the approved wording
Where the output is a legal or financial document, the wording must match the approved template every time. For this system, generation is deterministic: the same input produces the same output, and the text comes from templates the team controls. AI can support the surrounding workflow by extracting fields, checking inputs and routing matters. It does not generate or rewrite the approved clauses.
Integrations
What we have built against.
Spreadsheets and CSV as structured input, DOCX output via python-docx, email and file delivery, n8n for the surrounding workflow, and CRM write-back where the CRM has an API. If your document system is something we have not worked with, we will say so before quoting.
Delivery
How the build runs.
Discovery
We map the document set and the data behind it, and find the fields that actually vary.
Templating
Your existing documents become versioned masters, and we agree who owns them afterwards.
Build
One generator per type, plus the validation layer that stops incomplete data.
Handover
Your team runs it, edits templates and adds document types without us.
- Scope
- Your document set, fixed
- Typical timeline
- 4 to 8 weeks
- Ongoing
- Support, optional
- Ownership
- Templates and code stay yours
Timelines depend on the number of document types and how settled the templates and wording are. Ongoing work runs as Integration Cover: a monthly block of 10, 20 or 40 engineering hours on a three-month minimum, with overflow agreed in advance at the tier rate.
Oversight
Data handling, and what happens when something is wrong.
- Templates stay yours and stay editable by you
- Generation is deterministic, so output is reproducible and reviewable
- Client data goes only where you already send it
- Incomplete input fails loudly rather than producing a document with a gap
- Nothing is sent to a client automatically unless you ask for that
Proof
Open it, then read it.
Questions
What buyers ask.
Can we edit the wording ourselves afterwards?
Yes. The templates are ordinary documents held in a versioned master set, and editing them is a document edit rather than a developer task. That is the point of separating the wording from the generation logic.
What happens when the law or a standard fee changes?
You update the master template once, and future documents generated from that template reflect the change. Documents already produced are unaffected, because they are finished files rather than live views.
Do you need our real client data to build it?
No. We build against the structure of your data, not its contents, so realistic sample records are enough. If a build genuinely needs live data to validate an edge case, we agree that in writing first.
How many document types can this cover?
Each document type gets its own generator, so the number is a scope question rather than a technical limit. The conveyancing engine we built covers seventeen types, including agreements, tenancy documents and fifteen letter types.
What if two documents share most of their wording?
Shared wording lives once, in a clause the templates draw on, so a change to it lands in every document that uses it. This is usually where the largest reduction in maintenance comes from.
Does this replace our case management system?
No. It sits alongside it and produces the documents. Where your system has an API, the engine can read from it and write finished documents back.
What happens if someone enters the wrong data?
Missing and malformed required fields stop generation and name the field involved, rather than producing a document with a gap in it. Values that are valid but wrong are a human review question, which is why the output is reviewed before it goes out.
Who owns the templates and the code at the end?
You do, and the handover includes documentation written for your team rather than for us. You can keep us on for changes, but you are not dependent on it.
Bring us the document set.
Send the document types and roughly how often each one goes out. If a document engine is the wrong answer for your set, we will say so. If you would rather map the whole process first, the systems audit does that as a standalone piece of work.