A CLM warning story, as told by a GC
I had a chat with a General Counsel the other day who was regretting a move that many legal teams consider—going all-in on a fully featured Contract Lifecycle Management (CLM) system.
With their permission, I’m sharing their story anonymously:
“Why I regret buying the CLM
I run a legal team of 8 lawyers. I feel we’re quite forward thinking and always interested in improving how we work. A year ago we invested in a leading CLM solution, and it hasn’t gone well, so I’m happy to share this story in case it helps others.
In short, at the time of buying we did realise it was going to be a big investment, both in terms of the time we’d have to invest in getting it live, changing our workflows and processes and getting other teams bought in, but also in terms of the annual license fees.
Reflecting back on the decision, it just felt like something we ‘ought’ to do.
At every conference, every conversation with other in-house legal teams, they seem to be talking about buying a CLM. So.. in terms of Legal Ops improvements, I was swayed to look into it as well.
The Unintended Consequences
We’re now 12 months on, and it hasn’t been a great experience. Don’t get me wrong, some things have improved as a result, but on balance it just hasn’t been worth it.
For the last year it has often felt like we were stuck in quicksand. Spending more and more time putting out fires that just didn’t exist before.
I often hear ‘it’s going to get worse before it gets better’. But on a lot of fronts it felt like it got a lot worse, before it got to a similar place as to where we were before.
The main promise of CLMs is that it will streamline things and dramatically improve efficiency. Yet throughout the journey, we kept having to fix things that simply hadn’t been broken before.
One example was the 'legal front door' / ticketing part of the solution.
Before we bought the CLM we had a simple but easy-to-use legal front door. It didn’t have loads of analytics but it did allocate the work really well, forced the business to give us enough context to start the work, and provide the business with a place to check-in.
Getting the CLMs version of that working didn’t go well. It kept duplicating tickets, or starting SLA timers when it shouldn’t. Basically the promise was we’d be able to report on SLA hit rates etc, but to be able to get the data accurate enough turned out to not be possible. We’ve now turned that part off, whilst we figure out how to fix it.
This is just one example.
To be fair, the part of the solution that works really well is the analytics of signed contracts. It’s neat to be able to see the reports on that and it worked really well right out of the box.
However, if I’m honest, the main problem in our team was that we are overworked on BAU contract negotiations. So we need to be able to get through contracts more quickly, it wasn’t the analytics on signed docs..
The benefit of hindsight
When I drilled into where the time was going on the contract review work, it was the usual: creating mark-ups, escalating points internally, and too many rounds of negotiation.
I believe that to solve that requires us to look at our templates again and make sure the positions we take are market, and that we document more fallbacks to reduce the back-and-forth on internal escalations.
I’d ideally also like to be able to easily standardise replies to common customer questions etc so our junior lawyers can really run with it. The CLM does have a word add-in with some AI risk analysis on the contracts, but because our work is mostly on our own template, what I really need is to document our playbook, which it doesn’t do that well.
So in hindsight, I think we would’ve been further along as a team if a year ago, we had focussed on that, instead of buying the CLM.”
My thoughts on this
I’m really grateful the GC was willing to share so openly. It’s quite rare. It’s also a very familiar story to me personally.
Most of the mistakes I made building out Lexoo were because I ‘pattern matched’ what other companies were doing.
Marketing strategies, tools they bought, positioning etc. Whereas what I should’ve done is to follow the “Theory of Constraints”.
This means: figure out what’s the bottleneck in our business (which may be very different from those other teams!), and just solve that.
Then layer in an 80/20 to solve the majority of the bottleneck with the least possible effort. In terms of buying ‘big’ all-in solutions, 20% of the features usually create 80% of the benefits. But all those other non-contributing features will take a lot of time/energy/fees to implement.
So before buying a big tool, I feel it’s better to:
take a step back
identify the constraint, where are things getting stuck, what’s the biggest efficiency opportunity?
then try to improve that part. Often it’s better to not start with tech. E.g. in law, best to streamline the positions you take first. Document fallbacks, template language, comment bubbles etc, like the GC set out above.
Only then look at a bit of tech if it makes sense, and you’ll have a better ROI on tech that is solely focussed on your constraint, as opposed to ‘all-singing-all-dancing’ solutions that may not actually be particularly strong on your constraint.
Thanks for being here,
Daniel
CEO at DraftPilot
LinkedIn