In most organisations, contracts are not managed by lawyers. They are managed by a buyer, an office manager, a controller or an executive assistant. People who can read a contract perfectly well, but have no legal training and no appetite for one.
Yet much legal tech is built with a legal department in mind. That difference explains why implementations stall on something other than functionality.
Where legal tech for lawyers comes from
The first generation of contract software came out of large law firms and the legal departments of multinationals. There the work is about clause libraries, negotiation rounds, deviation analysis and version control down to the sentence.
That is real work, and the software genuinely solves it. But it assumes three things that do not hold in a mid-sized company:
- There is a legal department that owns the system
- Contracts are negotiated line by line
- There is time and budget for a months-long implementation
For an organisation with two hundred contracts, no in-house lawyer and a controller doing this alongside their day job, none of the three applies.
What then goes wrong
Too many fields. A screen with forty inputs of which you use six does not cost time in filling them in, but in working out which six.
Legal jargon as an interface. "Obligation extraction", "clause deviation", "playbook compliance": everyday language inside a legal department, a barrier outside it.
A process that is too heavy. A five-step approval route works when five people are involved. With three people, it gets bypassed.
The system belongs to one department. Once contract management is "legal's", procurement and finance stop maintaining it. And they are the ones who see renewals and invoices first.
The most common ending for a legal tech project is not failure but fade: after six months only the mandatory minimum is maintained, and everyone else is back to folders and mailboxes.
What to look for when you are not a lawyer
- Can you add a contract within a day without reading a manual?
- Are the fields in plain language, or in legal terminology?
- Can you hand it over to a colleague without a day of training?
- Can you set permissions so not everyone sees everything?
- Does it still work when you only have half the details?
- Do you get a signal before you can miss something, or only after?
- Can you leave: do you get your documents and data back?
That fifth point is underrated. When building a register you rarely have everything complete. A system that demands mandatory fields you do not know yet guarantees that contracts never get entered.
And the last point is a legal question you ask about your own supplier. Record how you get your data back, in what format and within what period.
What lawyers do need
This is not an argument for dropping the legal side. A lawyer needs things a buyer will not miss:
- Finding the version of a document that applied at a given moment
- Seeing who approved what, and when
- Recording risks against the contract they arise from
- Restricting who sees which files
The point is that these also work when they are set up simply. An audit log and role-based permissions are not lawyer features. They are just more often buried in software aimed at lawyers.
The practical middle ground
In Looop we made this an explicit choice: the system has to be usable by people who are not lawyers, without dropping what a lawyer needs.
In practice that means:
- The contract register uses the fields everyone knows: who, what, until when, who owns it
- Expiry alerts reach the person responsible, not a department
- Approval workflows are as light or heavy as you configure them, and never mandatory
- Risk management records risks on the contract itself, in plain language
- NORA proposes the data on upload, so you do not have to hunt for the notice period
For legal teams, this page covers what that means concretely; from a procurement angle, start at contract management for procurement teams.
How to choose
Ask one thing in every demo: show me how my contract gets added and monitored. Not a tidy sample from the vendor, but a real agreement of yours with all its mess: a missing end date, general terms living elsewhere, a counterparty with an awkward name.
What you see there is what you will do every week. The clause library you may never open.
Frequently asked questions
- Why do legal tech projects in SMEs often stall?
- Because much of the software is built for legal departments: too many fields, legal jargon, heavy processes and a system owned by one department. The result is rarely failure but drift: after six months only the mandatory parts are still maintained.
- What should you look for if you're not a lawyer?
- Whether you can add a contract without a manual, whether fields use plain language, whether it works with incomplete data, whether you can set permissions, whether you get a signal before a deadline, and whether you get your data back if you leave.
- How do you choose the right contract software?
- Ask in every demo to add and monitor your own contract, with the messy reality included: a missing end date or terms in a separate document. What you see there is what you'll do every week.
