Which companies a standard CLM does not fit

One: there is a single entry point

A standard product needs a defined starting point from which all contracts originate. The common reality is that sales contracts start in CRM, procurement contracts in ERP and employment contracts in the HR system, several legal entities each run their own collaboration tenant, and part of the organisation is still on an older OA suite. Forcing those entry points into one new system means changing the habits of several departments at once, and that effort frequently exceeds the cost of the system.

Two: contracts are mostly drafted on first-party templates

Template libraries, clause libraries and approval rules all assume you write the first draft. If most contracts arrive from the other side, which is typical when dealing with large customers, platforms or dominant suppliers, the template library loses most of its value and the work concentrates on reading the counterparty's paper, finding departures and negotiating them back. That work needs version comparison, clause-level risk location and a record of the negotiation, not a richer template set.

Three: the process can be rearranged to fit the product

Every standard product carries process assumptions about who drafts, reviews, approves and signs. Most companies can absorb a one-time adjustment. Regulated industries, groups under internal control mandates and companies fresh out of an acquisition often cannot: their process is pinned by external rules and will not move to suit a system. There the system has to adapt to the process, which is the opposite of what a standard product is built for.

The second row is the least visible of the four. A company concludes it simply needs to add some AI, buys a full contract system on that basis, and discovers after go-live that two entry points now exist. The business reverts to the old system out of habit, and the new one becomes a register that somebody has to keep filling in.

This is where evaluations most often go wrong. Having found that the standard product does not fit, the instinct is to move to bespoke development, which stretches timelines, makes cost hard to control and, worse, blocks upgrades: every custom change is a potential obstacle in the next release.

There is middle ground. Differences can live in rules, flows, configuration and adapters rather than in the product's core. A review checklist configured to the company's own policy, approval chains configured per entity, and integrations built as adapters are all configurable or pluggable, leave the trunk untouched and therefore do not block upgrades. Genuine core changes should be rare; if most of a proposal falls into that category, it is worth rechecking whether the category of product is wrong.

The conclusion should not come from comparing feature lists. It should come from a small run on your own data. The scope can stay narrow: take the loop that currently costs the most time and run twenty or thirty redacted real contracts through it, then see whether legal can act on the output directly.

Watch process outcomes rather than AI metrics: time from receipt to a decision-ready result, number of revision rounds, fields still re-keyed by hand, and whether each conclusion locates its position in the source text. Baseline those numbers before integration and measure them again afterwards; the difference is the basis for the decision. Without a test set and an evaluation method, no headline accuracy figure belongs in acceptance criteria.

If the run shows friction concentrated in one or two stages, replacing the whole system of record is almost certainly over-investment. If it shows problems spread across drafting, approval, signing and obligations, and the existing system genuinely cannot carry them, that is when wholesale replacement earns its cost.