Method
What a contract process diagnosis actually covers
A contract process diagnosis is not requirements gathering. Its purpose is to locate the one stretch worth fixing first. The eight questions to answer beforehand, how the hour is spent, what it produces, and when to skip it.
- By
- Zico Team
- Published
5 min read
The short version
A contract process diagnosis is not requirements gathering, and it is not a product demo under another name. Requirements gathering produces a feature list. A diagnosis produces a judgement: which stretch of the process is worth fixing first, which systems that touches, and how you will know it worked.
That difference shapes how the meeting runs. Requirements gathering tries to collect everything. A diagnosis deliberately narrows, and marks most of what was raised as explicitly out of scope for now. A useful diagnosis ends with both sides agreeing on three things: where the main friction is, which path is recommended, and what happens next.
Eight questions to answer beforehand
These eight decide what gets demonstrated and what does not. Answering them in writing before the meeting keeps the hour from being spent exchanging basic facts. Rough answers are fine; being unable to answer one is itself information.
| Question | What it establishes |
|---|---|
| Which system do contracts start from today | Whether there is one entry point or several in parallel |
| Is the document a Word file, an online doc, or generated by a system | Whether document and structured fields are separate, and where versions originate |
| Does external negotiation run over email, chat or something else | Whether the process spills outside internal systems, and where risk concentrates |
| Where do you most often lose a version or re-enter the same data | Locates the friction directly, and usually the first loop worth fixing |
| How many legal entities, tenants and business systems are involved | Whether a cross-entity view is needed, and how complex permissions get |
| Where do approval, sealing, ERP and spend control, and archiving sit today | Where the boundaries fall and which way fields should flow |
| Can data leave the corporate network; is self-hosting or a specified model required | Deployment shape and where inference runs, which narrows the options immediately |
| Are you willing to replace the contract system of record, or only to augment what exists | Path selection, and the highest-priority answer of the eight |
The last question is often treated as commercial. It is a technical precondition. Replacing the system of record and augmenting what exists lead to entirely different designs and acceptance criteria, and leaving it ambiguous makes every later discussion unfocused.
How the hour is spent
A diagnosis does not follow the feature menu. It follows map, hypothesise, test. A typical sixty-minute session allocates time roughly as follows.
| Time | Activity | Output |
|---|---|---|
| 0–5 min | Agenda and scope statement | Agreement that not every feature will be covered |
| 5–18 min | Map the current process | People, documents, systems, decision points, data boundaries |
| 18–23 min | State the diagnostic hypothesis | Main friction, recommended path, and what is out of scope today |
| 23–40 min | Live walkthrough | One contract taken through one complete loop, no menu tour |
| 40–50 min | Integration and deployment boundaries | Which entry points stay, which are taken over, where data lives |
| 50–57 min | Summarise in the room | Fit, gaps, risks and how success would be measured |
| 57–60 min | Agree one next step | Sample validation, a technical session, or a POC |
Minutes 18 to 23 carry the session. Stating the hypothesis out loud, so the other side can reject it, works far better than sending a report afterwards. A hypothesis being overturned is a good outcome: it means the current state differs from the initial read, which is exactly what the session is for.
What it produces
First-pass fit assessment
A thirty to sixty minute session produces a path judgement: system of record, capability integration, or a hybrid; one or two points of highest friction; and whether the next step is worth taking. It deliberately does not deliver a detailed process blueprint, a prototype or a schedule commitment, because producing those before seeing real samples and system boundaries yields something too imprecise to decide on.
Contract operations diagnosis and POC
When an executable conclusion is needed, scope extends to one or two weeks and produces six fixed deliverables: a current-state process map with an issue list, a target process and system boundary diagram, validation results on real samples, integration options and data boundaries, a go-live scope with explicit exclusions, and acceptance criteria with responsibilities on both sides. This is quoted separately and can be credited against a subsequent project.
The difference between the two is not time spent but how executable the conclusion is. The first answers whether to proceed. The second answers how, and what counts as done.
Setting acceptance criteria
The last step of a diagnosis is turning the improvement target into measurable numbers, and baselining them before any work starts. Without a baseline there is no way to tell afterwards whether anything improved.
| Criterion | How to measure |
|---|---|
| Time from receipt to a decision-ready result | Upload timestamp to the moment legal issues a conclusion |
| Revision rounds | Number of rounds before a contract is finalised |
| Duplicate data entry | Fields still keyed into other systems after execution |
| Wrong-version incidents | Times a superseded draft was signed or sent out |
| Ruleset coverage and traceability | Run your own checklist over samples; count misses and check each finding locates its position |
When to skip the diagnosis
Companies with modest contract volume, fixed templates, almost no external negotiation and no multi-entity complications can usually see their friction at a glance, and looking straight at the product and the price saves time. The value of a diagnosis rises with process complexity; in simple settings it is a long way round to an obvious conclusion.
The other case is a company that has not yet decided internally whether to change anything. A diagnosis needs business, legal and IT in the room together. With any one of them missing, the current-state map comes out distorted and the conclusion cannot be acted on. The better starting point is an internal agreement on whether this is worth doing now, and a diagnosis after that.
Related
- Which companies a standard CLM does not fitThe question about replacing versus augmenting, worked through in detail.
- Adding AI contract review without replacing your existing systemWhat the augmentation path looks like in practice.
- Procurement FAQDeployment, integration, pricing and data handling.
- Book a diagnosisBringing answers to the eight questions makes the session considerably more productive.
Bring these questions to a demo
Book a dedicated demo and walk one complete path matching your organization, collaboration platform and deployment requirements.