Why Contract Review Is Slow: The Playbook Only Exists in Someone's Head

The document that governs the decision, and never makes it

Ask a legal team how they decide whether a contract is acceptable and you will be shown a playbook. It sets out the positions the company has agreed: what indemnity caps are tolerable, where liability must be limited, what happens on assignment or termination, how data processing is handled.

It is real institutional knowledge and it took real work to agree. It is also inert. The playbook never reviews anything — a person does, holding it in memory while reading a contract someone else drafted, deciding clause by clause where the two disagree.

That is slow, and more importantly it is uneven. Two reviewers produce two answers, and the same reviewer produces different answers in March and in December. The playbook was written to make the company's risk position consistent, and the way it is applied is the least consistent part of the process.

Why generic contract AI does not solve this

There is no shortage of tools that will read a contract and tell you what is risky. They are answering a different question — what is risky in general — and general is not the standard anyone is actually held to.

Your company might accept uncapped liability for a data breach and refuse it for consequential loss. That is not a legal universal; it is a decision your team made and wrote down. A tool that does not know your playbook cannot flag a departure from it, and a flag that is not a departure from your position is noise the reviewer has to clear.

So the playbook is ingested first, in whatever format it already exists in — PDF, Word, or a spreadsheet template — and turned into structured guidelines. Everything downstream is measured against that, not against a general model of contract risk.

What the review actually produces

Each clause is matched to the playbook terms that govern it, rather than to whatever is textually nearest — the clause that matters for a liability cap is often not the one with the word 'liability' in it. Each is scored across twelve legal categories, assessed for risk, and given a suggested revision.

The output is deliberately not a summary. A summary of a contract is something the reviewer then has to work from. What comes back is the list of places this contract departs from what the company already decided, with the departure named and a redline proposed.

Delivered where the work already happens

It runs as a Microsoft Word add-in. Contract review happens in Word, and it is going to keep happening in Word regardless of what any vendor prefers.

A reviewer opens the document they were going to open anyway and the risky clauses are highlighted in place. There is no export step and no second application to keep a tab open for. A separate tool is a separate habit, and a separate habit is the most reliable way to make a genuinely useful system go unused.

What transfers to other review work

The pattern is not specific to contracts. Wherever an organisation has written down how it makes a judgement — an underwriting guide, a credit policy, a clinical protocol, a supplier standard — you will usually find the same gap: the document sets the standard, and a person applies it from memory under time pressure.

The useful move is rarely to automate the judgement. It is to make the written standard active: able to say where this specific case departs from it, in the tool the reviewer already has open, leaving the decision where it belongs.