Field note / Choosing what to automate
Which legal documents should you automate first?
Start with a document your team prepares often, where the same facts repeat, one approved master already exists, the variations are few and written down, and a named person reviews and maintains it. Leave rare, heavily negotiated or still-changing documents manual. If several copies of the master have drifted apart, consolidate them before automating anything.
The worksheet below is plain text. Copy it into a local editor or print this page; nothing is submitted to this site. It is a companion to Before automating legal documents: test one precedent workflow, which shows how to test one package once you have picked it.
What kind of documents work best for automation?
Documents of the same shape, drafted repeatedly from the same kinds of facts, with little variation between matters. One answer to a newcomer who was “not sure what kind of documents work best for automation” put it simply: documents “repeatedly drafted without many changes”.
Volume alone does not decide it. A commenter describing their own automation work named variability as “a huge limiting factor”: retainers and representation letters worked well, while multi-client demand letters would likely remain unfinished because the per-case variation was too hard to encode (r/LawFirm, September 2025). A reply in the same thread from an account that appears to offer practice-management services put it in one line: “Real time saver—if you pick the right docs and do the upfront work.”
So the question is not “which documents are most common?” but “which documents combine repetition, a stable source and rules someone has already approved?” Six criteria capture that.
How do you pick the right documents? A scoring worksheet
Score each candidate from 0 to 2 on six criteria, treat a zero on master stability or ownership as a stop, and rank what remains. The scale is an illustrative engineering heuristic, not a validated instrument.
| Criterion | 0 | 1 | 2 |
|---|---|---|---|
| Volume | A few a year | Most months | Every week or more |
| Repeated facts | Mostly bespoke text | The same facts typed several times in one document | The same facts typed across several documents in a package |
| Master stability | Several drifting copies; none clearly approved | One approved master, changed often | One approved master; changes rare and recorded |
| Conditional complexity | Choices made by judgment on each matter | Branches exist but some live only in someone's head | Few branches, each written as an approved rule |
| Review and maintenance owner | No named reviewer | Named reviewer; nobody maintains the master | Named reviewer and maintainer, with a backup |
| Error visibility | A wrong output is subtle and costly once relied on | Errors are usually caught in review | Errors are obvious and cheap to fix before issue |
Error visibility does not mean high-stakes documents should never be automated; consistent assembly can remove copy-and-paste mistakes. It means a first project should be one where the reviewer will catch what goes wrong while the team is still learning.
CANDIDATE SCORING WORKSHEET — copy one block per document
document / package = ________________________________
who prepares it today / tool used = ________________
volume (0-2) = ____ evidence: ____________________
repeated facts (0-2) = ____ which facts: _________
master stability (0-2) = ____ master ID/owner: ____
conditional complexity (0-2) = ____ rules written? __
review and maintenance owner (0-2) = ____ names: __
error visibility (0-2) = ____ what would go wrong: __
STOP if master stability = 0 or owner = 0: _________
total (0-12) = ____
existing tool that may already cover it = ___________
decision: native tool / standard content / specialist
tool / bounded build / fix first / manual = ____
Illustrative reading: 9 or more is a first candidate, 6 to 8 suggests partial automation or a fix first, and below 6 usually means leave it manual. The total ranks candidates; it does not choose the tool. That comes after the alternatives check further down.
Worked example: how would five fictional documents rank?
The highest score does not automatically justify a new system, and the most painful document is rarely the right first project. The team, documents and volumes below are invented for illustration.
| Candidate (fictional) | Vol / Facts / Master / Cond / Owner / Error | Total | Decision |
|---|---|---|---|
| D1 — Matter-opening letter. About 40 a month; client name, address and fee basis; one approved master. | 2 / 1 / 2 / 2 / 2 / 2 | 11 | Automate first, with the practice-management or Word fields the team already has. No custom build. |
| D2 — Ancillary pack. Three short documents prepared together, two or three packs most months; parties, property and dates repeat across all three; four options, one still unwritten. | 1 / 2 / 2 / 1 / 2 / 1 | 9 | Best candidate for package-level assembly. Cross-document repetition is where mail merge struggles. Test it with the hub's worksheet before choosing a tool. |
| D3 — Supplier contract. Weekly; three regional copies have drifted and nobody can say which wording is current. | 2 / 1 / 0 / 1 / 1 / 1 | 6 (stopped) | Stop: consolidate into one owned master first, then rescore. |
| D4 — Multi-party demand letter. Frequent, but content depends on each party's facts and a lawyer's narrative. | 2 / 1 / 1 / 0 / 1 / 1 | 6 | Partial: assemble the fixed skeleton (parties, headings, standard sections); keep the narrative manual. |
| D5 — Development agreement. A few a year; heavily negotiated; every deal differs. | 0 / 1 / 1 / 0 / 2 / 0 | 4 | Leave manual. A maintained clause library and checklist help more than automation. |
Reasoning. D1 scores highest but is a single document with a handful of fields; ordinary tools handle it. D2 scores lower but holds the problem a bounded build or specialist tool exists to solve: the same facts copied by hand into several documents, where one wrong party name in one of three outputs is easy to miss. D3 has the volume and the pain, but automating three drifting copies would only make the drift run faster. D4 and D5 fail on conditional complexity: the variation is judgment, not rules.
The order is D1 (native tools, this week), D3 (governance, before anything else touches it), then D2 as the first real automation project.
Have a package like D2 and want a second opinion on where to start? Discuss one workflow in a 15-minute fit conversation; no documents needed.
Is our volume too low for automation to be worth it?
Sometimes, but low volume with heavy repetition can still justify a simple setup, while low volume with bespoke content rarely does. One r/legaltech poster preparing 10 to 50 contracts a month asked whether dedicated tools would be “overkill for my use case given the relatively low volume” (June 2026).
A rough test: compare the hours to set up and maintain the template over a year with the hours actually spent preparing that document over the same year. Count maintenance honestly: the master will change, and every change needs retesting. If the comparison is close, improve the Word master and stop there.
What if paragraph 2 changes depending on the scenario?
Conditional clauses are fine to automate when someone has written the rule down and approved it; they are a poor first project when the rule lives in a lawyer's judgment. One r/LawFirm poster described exactly this need: “if scenario A then paragraph 2 changes to X” (September 2024).
Before scoring conditional complexity, list every variable that changes the document and the approved outcome for each value. A commenter on r/legaltech gave the same advice: “Start from the decision model,” not the template (August 2026). If you cannot complete the list without asking a partner case by case, score it 0 and leave those sections manual. The hub note's stop cases show what should happen when an input has no approved branch.
How do you stop template updates forking everywhere?
Pick one approved master per document, name its owner and retire the other copies before automating. An r/LawFirm poster with jurisdiction variants asked how to keep people from reusing stale language “so updates don't fork everywhere” (September 2025). A self-described transactional attorney described how every pass through the templates turns up something wrong, such as two related agreements with differently worded versions of the same provision (r/Lawyertalk, September 2026).
One vendor guide treats consolidating variants into a single master, with a named document owner, as part of automation work (Thomson Reuters). This worksheet asks for it first: until one master exists, a candidate's master-stability score is 0 and the first project is governance, not software.
Who maintains the templates when the person who built them leaves?
Name a maintainer and a backup before building, and prefer a setup someone else can change. On r/legaltech, a commenter said a single-person template setup “caused a real crisis for the office. Nobody else knew how to work on them” (February 2026). Another commenter in the same thread warned that home-grown systems can end up as “abandonware” when only the original coder can modify them.
That is why ownership is a stop criterion in the worksheet, not a bonus point. Lawyers may also keep wanting to see the underlying precedent rather than an automated template, which means two artifacts to keep in step (echo.legal, May 2024).
When is a better Word master, clause library or off-the-shelf tool enough?
Often. Most first candidates need a cleaner master and the tools already licensed, not a custom build. For a few fields across a set of documents, one reply on r/legaltech suggested “mail-merge and content controls, and a .CSV file” (October 2025).
| If the candidate looks like… | Usually enough |
|---|---|
| One document, simple fields, stable master (D1) | Word fields, content controls or mail merge, or the document features in your practice-management system. |
| Bespoke, negotiated, low volume (D5) | A clause library with named owners and a drafting checklist. |
| Many approved branches, regular volume | An off-the-shelf assembly tool. Check existing licences first. |
| Standard documents the team is willing to adopt | Licensed standard content or a managed precedent service, such as Clarilis, which covers design and maintenance. Applicability is for the responsible professional to judge. |
| An approved package with one specific handoff gap the tools above leave open (D2, sometimes) | A separately scoped build or integration, with an owner, reviewer and fallback. |
The hub note's build, buy or do neither table covers the same boundary in more detail. A no-build answer is a useful outcome.
Should you skip rule-based automation and use AI instead?
For assembling approved text from known facts, predictable rules are still the safer foundation; language models may help around them. A poster on r/legaltech asked whether it was “worth investing time in document automation” in an AI-heavy future (January 2026). Many replies favoured keeping assembly rule-based and using models to help build templates or read intake material.
That matches the scoring above. A candidate with written rules and a stable master does not need generated text. A candidate without them has a governance gap that a model cannot close, and the responsible professional still reviews every output.
What should you do first?
List five candidate documents, score each with the worksheet, and act on the results in order: native tools for easy wins, governance for drifting masters, then one bounded pilot. Keep real matter facts out of the worksheet; document types and counts are enough to rank.
For the pilot candidate, use the hub note to freeze one source set and write expected outputs before any tool is chosen. If an owned, bounded gap survives both exercises, that is the kind of workflow we help evaluate and connect. Engineering scope and support are agreed separately; the responsible professional retains legal review and decisions.
Please do not send confidential documents or client records. A conversation can start with the document types, current tools, owners and review requirements. Booking is optional; this worksheet stays ungated.
Related field note: How do you stop lawyers using old Word templates?
Sources and their limits
Public research cutoff: 11 October 2026. Practitioner quotations are short excerpts from public, pseudonymous forum posts. Identities, roles and experience are unverified, and some replies come from people selling tools or services. They show how the question is asked, not how common any view is. The worksheet, scores and worked example are original synthetic material.
- Reddit threads, accessed 11 October 2026: r/LawFirm document types for automation (19 January 2021); automating own Word templates (19 September 2024); hype or real time saver? (10 September 2025); templates across jurisdictions (18 September 2025). r/legaltech very light document automation (10 October 2025); worth investing in document automation? (25 January 2026); standard for contract generation (6 June 2026); struggles with document assembly (28 August 2026). r/Lawyertalk when does templating ever end? (11 September 2026). Comment dates may differ from post dates.
- Thomson Reuters: Definitive guide to legal document automation for law firms (no page date; case study refers to 2018). Supports piloting a discrete, high-volume area and consolidating variants into one master owned by a document owner. A software vendor's guide; its benefit claims are not adopted here.
- echo.legal: Common document automation issues (Julie Saliba, 24 May 2024). Lawyers may keep wanting the original precedent, and automation should not try to cover every circumstance. Written by a supplier.
- Clarilis managed service (publication date not established). Cited only to show that managed design and maintenance services exist; vendor material, not an independent comparison.
For practice context, see how Stratum Relay works. This organizational engineering attribution is not a statement that a lawyer, client or named individual has reviewed or endorsed the note.