Our first post is here! And we’re starting with questions on the topic of CLM pricing. We invite you to share your experience. Below are a few prompts to get you started, but feel free to answer your own questions on the topic, if that’s more compelling (or just easier).
How did CLM pricing play into your decision when evaluating CLM vendors?
How does your current CLM vendor’s pricing structure prevent or promote adoption of the software across your business?
Do you feel like you’re paying for more tools than your business is able to adopt?
How do you defend your CLM budget to your CEO/CFO during the annual renewal period. Or, put more simply, do you have to defend the business case and budget for CLM on an on-going basis, and if so, how do you do it?
How would you change your current CLM pricing? And why?
Thanks for your experiences and insights on this important topic.
[Note: This is a small, private community of in-house attorneys and contract managers, like yourself, who we’re invited here to help us on this CLM discovery process. You’re in good company, but use your best judgement in terms of the information you share.]
I agree with Jason Richardson's feedback. My biggest pain point is licenses for requestors. I need everyone in the company to be able to submit a request, but most will never actually do so. I don't want to have to pay for licenses for those folks, if only a handful will use the tool frequently, then most others will only use it once or twice a year (or never). Trying to manage licenses for these users (in order to keep costs down) would be a an administrative burden I don't want.
I'd rather have a license fee based on role.
We're actually limiting further adoption of our current tool due to the cost of requestor licenses.
Mindy, this is helpful and feels like a critical flaw in pricing. You need your sales team to have requestor access to ensure wide scale product adoption, but adoption takes time and isn’t guaranteed enterprise software (as we all know). So putting up the paywall for requesters has the result of both less access upfront but also results in less aggressive promotion by legal to the business-- if promotion results in budget hurdles.
I agree with Jason's and Mindy's feedback. Once hurdle we have experienced is the limited offerings that do not include enterprise level licensing. What I have found over the years is that each organization that adopts a CLM will inevitably be required to identify a core set of "super users" and adjust its contracting process in order to accommodate the CLM tool. This certainly is not inherently a "bad" thing, but the opportunity to offer general licensing to contract Requestors is helpful and would greatly help organizations from a change management perspective deal with any potential "shock" of the licensing requirements for users which may only require one or two contract a year.
In terms of defending the business case for CLM, the metrics around a consistent and predictable contracting process proves valuable to not only the Legal department, but also other impacted organizations. In addition to saving time for in-house and outside counsel, the metrics around the length of time it takes Risk Management, Privacy and/or Information Security to review/approve a contract are also valuable. The CLM provides a hard audit trail in one place for these departments to determine the "story" around the contracting process. In addition, the ability to tell a year-by-year story around pricing and to project trends has assisted in terms of eliminating guess work around contract pricing.
As to what I would change around my current CLM pricing, has been explored below by Jason. I completely agree with a pricing structure where requestors or either "free" or there is a general "enterprise" requestor license would be most helpful. As legal counsel, the individuals most involved in the process are (1) Legal (internal and external), (2) Procurement/Supply Chain Managers, (3) SMEs, (4) Contract Approvers (think VPs within the reporting line of the requestors), (5) Contract Signers, and (6) CLM Admins.
Larry, this is great. This is what I'm hearing: (1) offering a free or an enterprise license for Requestors would improve adoption and overall value, (2) the business case extends beyond legal efficiency and into other departments that touch the contract review/approval process.
A couple of follow up questions, if you have a moment:
1. Who is an SME in your example above? Any contract expert in the business?
2. Are you indicating that your list of 6 user types would all fall into the "paid" category, and all other users in the "free" category?
An SME is any expert needed to review or approve specific portions of the contract outside of inside counsel. For example, we would need to leverage the knowledge of someone familiar with the insurance policies of our client (usually Risk Management) to determine if changes made are acceptable. I would probably urge that any SME license be a reduced fee as those individuals' usage is very limited in terms of actual engagement with the CLM. Their attention is needed within the contract and the main necessity is to get the relevant contract portions in front of them so review and then approve/reject and/or propose appropriate contract updates.
Got it. Very helpful. Two tiered + a free tier (3 user tiers total) might make the buying process too complex, but I appreciate there's a clear way to define roles/access rights that might warrant more than a single paid tier. We'll explore that further! Thanks, Larry.
I love the topic of CLM business-case justification and more specifically ROI. As a potential provider, I think you can position yourself to win a lot business by simply arming folks with ROI data to take back to the GC/C-Suite. I've seen a few studies in the marketplace re CLM ROI, but it's poorly developed, in part because legal departments haven't historically tracked benchmark data to drive a future-state value capture..
SO, many legal departments have paid for software with somewhat hefty license costs, 3rd-party configuration fees, and maybe throw in the Ironclad contract review/extract fee literally ONLY on the basis that well we need one, everybody has one. MAYBE discussions of "better/faster" contracting were thrown around but with no system, data structure, or governance to actually track or verify as proof as ROI won't need to be shown moving forward, we'll just trust the CLM took was worth it. So what would an ACTUAL ROI summary consist of? A lot of freaking new, currently untracked data points. And part of the problem is that folks think simply buying and implementing the system should "just produce" that data.
MANY CLM buyers have gone off the deep end when the configuration team enters day 1 and the legal department realizes that in large part, whatever data is about to tracked SHOULD COME FROM the legal department, as in for them to define! That is PARTICULARLY the case with structured contract data, i.e. do you have a hierarchy in mind or have specific, substantive, structured positions you want us to extract? But it also applies to process data. As in, data about efficiencies and such. MANY CLM tools operate as something akin to no-code platforms, where they can be configured to do perform workflows the legal department wants (whoops we have none/few of those defined) and to track whatever data points you want us to extract from contracts (whoops we have no pre-defined systematic data structure for contract data) and can track process data to benchmark your historical performance (whoops we have none of that tracked).
SUMMARY, there's no REAL WAY to define ACTUAL ROI for you customer! Will you have better/faster contracting, per a system you don't know how to define and have never defined, well who knows.
(QUICK ASIDE, on the matter of structured contract data, CLM systems are growing in their awareness of coming with pre-packaged data points against which to scan contract data through their ML Models. MOST of them have historically ended too high in the data hierarchy, e.g. great you've decided this is a Limitation of Liability clause - but who cares - what TYPE OF limitation of clause is it? As in go further down the hierarchy to get more granular contract data...so we can populate our database with usable metadata. Examples, Limitation of Liability Clause - Cap on Liability: YES, Type of Cap on Liability: FEE BASED, Multiple of Fees: 2x, Exclusions: YES, Exclusion Types: INDIRECT DAMAGES. THat's actual contract metadata that needs a structure. I GO ON THAT RANT here because That's what's required to prove ROI in terms of RISK AVOIDANCE or VALUE GAINED. In other words, the system helped us achieve better contracting positions for the company - as in our contracts are better! But of course without a data structure in place, without extracting that data from legacy contracts, without defining a company formal RISK PROFILE, beyond just desired starting positions, there's nothing to measure the future against.. I repeat that CLM vendors have awoken to contract data here, but they may use their own structured data model, and of course this will not be portable across systems since there's no standardization in this area yet. Regardless, a lot of CLM vendors have historically shown demos with things like "governing law", largely on the basis that Named Entity Recognition was good at things like recognizing a list of states. But there was no similar "list" of limitation of liability clause types and metadata. This are is near and dear to my heart because I built what I believe to be best contract data model in existence while at Unitedlex. But one model to rule them all is HOW portability happens and more importantly benchmark data can form in order to measure the ROI.)
So what has to happen to ARM YOU with the TOOLS to create and communicate ROI?
1. Need to create/leverage Structured Data across contracting processes and contract substance, borrowing from the most used standardized sources where possible. SALI and other sources are a start, but the industry is lacking. I'd be happy to share my contract process data sheet. Ideally there would be industry standards associated with all of it so that companies could benchmark and know what to track so as to build out their tech stacks to do that work.
2. Need to incorporate as much of this structured data into the fabric/dna of the product architecture as possible so that it doesn't require/rely on customer defining.
3. Example of this is a back-end database that is configured to as large of contract data model as possible, as a means to SELL on this diversity and specificity but that is as no-code configurable to client use case as possible.
4. Need to gather as much data as possible (and there won't be much haha) as can from client in their current state. I left a fairly long list of specific questions under the "are we asking the right questions" Post that works as a start. YES/NO/NA answers to certain questions will be immediate red or green flags to identify ROI capture. But will need actual data, again that probably doesn't exist.
5. Between process and substance data, if can paint a current picture of efficiency, compliance, and overall production: This will set the stage for arming them with an estimate of HOW and in WHAT WAYS your tool will produce ROI.
• How did CLM pricing play into your decision when evaluating CLM vendors?
The pricing played a small role in the adoption of the CLM vendor as there was a big push to start using a CLM program that could be adopted globally by the legal department. Our CLM program is used by the Australia, Asia, Europe and Americas legal teams. Therefore, the biggest concern was global adoption and a program that was considered user friendly to a global community with various needs.
• How does your current CLM vendor’s pricing structure prevent or promote adoption of the software across your business?
Our current CLM vendor pricing is a per user license fee. Each legal department head requires its direct reports to use the system and requires it to be downloaded on the respective direct report’s computer upon starting at the company. The head of our contract management group occasionally will send out an email to each lawyer ensuring that they are saving their documents to the CLM. Our legal department’s dedication to using the CLM is the true promotion of the software. Therefore, the pricing doesn’t dictate the adoption.
• Do you feel like you’re paying for more tools than your business is able to adopt?
We were until recently. We recently went through all the tools purchased and determined the number of people in the company using each tool. If the tool was under-utilized by the employees (e.g., less than 10-20% of the people in the company is using the tool), the service was canceled.
• How do you defend your CLM budget to your CEO/CFO during the annual renewal period. Or, put more simply, do you have to defend the business case and budget for CLM on an on-going basis, and if so, how do you do it?
We don’t have to defend our budget, but we do try to make sure we have a healthy budget that reflects tools we are actually using and make our processes simpler and faster. We will depreciate tools that we no longer find beneficial.
• How would you change your current CLM pricing? And why?
I would prefer we had a flat rate instead of a per user license fee as we have employees who want to use certain tools but don’t want to have to go through an arbitrary long approval process to use the tool so don’t get access to the tool. For example, some people in the group don’t have docusign but look to/request the paralegal to do all of their docusign tasks since the paralegal has the docusign tool.
I do find it a bit odd to have pricing for the CLM divorced from the pricing we pay for the eSign portion of our eSignature tool even though it is the same provider for both. In the one case (CLM) I'm counting user licenses and in the other (eSign) the document count we'll send for signature and those frameworks are completely different. Pros and Cons to both but I would like to see those two things meshed a little more to simplify things especially as estimating a document count feels a bit like a crapshoot at times and historical usage doesn't account for the things that inevitably come up that skew your estimates. It feels easier to say who needs to access this tool (or who can we live with having access to this tool) and do pricing that way rather than me having to make that assessment for the CLM and then count documents for the eSign portion.
I don't feel like we're paying for more of the tool then we could adopt but it has definitely been a long process to get the CLM up and running that we've paid for more of the tool than we've been able to implement so far. The potential is there with the tool but a long implementation time has dampered some excitement for what the tool can do.
Overall, pricing wasn't the main consideration for us, rather it was fit for our use case and ensuring that what we would use would work well with our current eSign tool which is one of the reasons we ended up going with the vendor for CLM who also ran our eSign tool.
As an attorney for a state government agency, I may have a bit of a different perspective here, although I agree with much of what others have said. We want to make good use of the public's money, so pricing of a CLM solution is definitely a major consideration. However, features that make the CLM easy to use and maintain as the primary repository of agency contracts are also critical because of the role our CLM plays in government transparency and accountability. Like many states, we have a strong open records act, and most of our contracts must be provided to any citizen who requests them. Having all contracts in a single place that is easily searchable facilitates responding to those requests; but if the CLM is hard to use, user adoption rate will suffer and contracts will end up outside of the CLM. Additionally, we are subject to state audits, which from my understanding in the past have randomly examined contracts in our CLM.
We do have to defend our CLM choice and budget, but the ability of the CLM to also help serve these secondary purposes (in addition to the main purpose of moving contracts through) makes it a fairly easy selling point to our CFO and leadership if the price is reasonable and feature set matches our needs.
Our current CLM pricing structure is not user based, rather it is based on the number of contracts entered per year. I think this model promotes adoption because we are able to add any employee as a user of the system without additional cost. The one exception is that there is a cost for each user with administrative privileges, which we only have a handful of those. I personally prefer simplified cost structure versus a complicated one with multiple user tiers etc. However, as long as the pricing model is transparent, reasonable, and not too convoluted, then I think decision makers can work with it. But, again, simpler is better in my opinion.
This is great, John. I really appreciate this perspective re ROI/defending the budget to CFO, and it's great to hear CLM has been relatively easy to defend. I also really appreciate your comment on pricing simplicity. We want to land on a pricing model that's reasonable, simple, but also (and this may not be intuitive) a pricing model that is easy to compare against other vendors. We've built and sold software elsewhere where our pricing was TOO innovative, and buyers had difficulty stacking us side by side. One follow up question.
Regarding "contracts per year pricing". Are you paying for this on a per document basis, or do. you buy up to a certain amount every year, and anything over comes with an added cost? Any detail you could provide on that would be awesome. We're less familiar with this model for CLM, but have experienced a similar concept with email marketing software among others. THANK YOU!
We buy up to a certain amount of contracts every year (we set the number based on our historical usage with some cushion), and anything over comes with an added cost.
Regarding price comparisons, in our recent experience in selecting a new CLM vendor, we were told by one potential vendor that many of its competitors in this market do not make their pricing available on their web site and are very non-transparent about it (this vendor did and was transparent). We found that to be true, and we had to get very deep in post-demonstration discussions with some vendors before they would give us pricing; and even then, it was somewhat nebulous, ballpark pricing. This was a turn off.
Pricing played a key role but I think capabilities and a clean user experience were given slightly more weight in the evaluation. These products tend to be very costly when you pair the annual subscription fee coupled with seat licenses. Perhaps offering various “stacks” of solutions (i.e. stack 1 is strictly workflow offerings, stack 2 is workflow coupled with AI automating routing decisions, and stack 3 is AI automated workflows with robust AI contracting options) coupled with seat licensing bundles would be attractive to customers. We utilized the metrics gathered by the system (time saved and less outside counsel spend) to justify a continued investment in enhancing the tool. The value in the legal space was evident after the first year. The buzz created as more users adopted the system has led to business units outside of legal to begin evaluating use cases in other departments. The metrics to evaluate the savings on those use cases are a little different but are focused on time saved and headcount. If I could change anything about the pricing it would be around the definition and need for a seat license. Ideally, I would not want a requestor to require a seat but all remaining players in the contracting process should require a seat. From what I have seen, the people requesting a contract are not heavily involved in the contracting process other than answering initial intake questions. It is the SMEs, senior leaders, and attorneys that really engage with the solution.
Jason, this is great feedback. We're already looking at unbundling core features into 3 packages to allow customers to be more targeted and cost efficient in what they purchase. We're also thinking about (like you said) creating 2 licensing categories (one free, one paid) where HR/Sales/Others users aren't required to pay. If you have another couple of minutes, could you expand on how you would define the paid license category? You started doing this already with "SME's, senior leaders, attorneys". But it would be great if you could share maybe 3-5 types of product access that would be exclusive to the paid license. THANK YOU!
Preston, this may be a little wordy, but I hope it is helpful.
Requestor - typically submits the request based on an ongoing business effort but typically does not provide any revisions to the contractual language. Their license would need to allow for them to submit requests and respond to questions raised by the attorneys or SMEs. If the solution offers a contract repository, they will also need access to the documents.
Attorney - full access but not at an admin level.
Internal SMEs (Risk, IP, Finance, etc.) - depending on the org, they may not make changes to the contractual language but would need to be able to provide feedback to any comments or questions raised by the attorneys.
Business Leaders/Signers - they would need access to review and approve a contract before signing, but they typically do not modify the contractual language.
Internal Approvers (mid-level leaders or project leads) - they would need access to review and approve a contract before signing, but they usually do not modify the contractual language.
Outside Counsel (working on behalf of the company, not External/Opposing Counsel) & External SMEs (Data Privacy Counsel, IP Counsel, Relevant Consultants, etc.) - they would need access to the in-flight contract to revise during negotiations BUT you would want to limit their access to the contract repository to only the documents they are actively working on. Once the contract is signed, you would not want your Outside Counsel or External SMEs to maintain access to your repository.
Taking all that into account, maybe a role-based license model would work.
Requestor
Approver
Negotiator
General (Viewer) - access only to document repository but no workflow access.
Admin - all powerful and can modify/enhance the system
Jason, this is wonderful. In a future post, I'm going to convert this feedback into a proposed licensing table (paid v free) with proposed access rights, and possible corresponding roles/job titles. I'll ask for your feedback back again there. So so great!
I agree with Jason Richardson's feedback. My biggest pain point is licenses for requestors. I need everyone in the company to be able to submit a request, but most will never actually do so. I don't want to have to pay for licenses for those folks, if only a handful will use the tool frequently, then most others will only use it once or twice a year (or never). Trying to manage licenses for these users (in order to keep costs down) would be a an administrative burden I don't want.
I'd rather have a license fee based on role.
We're actually limiting further adoption of our current tool due to the cost of requestor licenses.
Mindy, this is helpful and feels like a critical flaw in pricing. You need your sales team to have requestor access to ensure wide scale product adoption, but adoption takes time and isn’t guaranteed enterprise software (as we all know). So putting up the paywall for requesters has the result of both less access upfront but also results in less aggressive promotion by legal to the business-- if promotion results in budget hurdles.
I agree with Jason's and Mindy's feedback. Once hurdle we have experienced is the limited offerings that do not include enterprise level licensing. What I have found over the years is that each organization that adopts a CLM will inevitably be required to identify a core set of "super users" and adjust its contracting process in order to accommodate the CLM tool. This certainly is not inherently a "bad" thing, but the opportunity to offer general licensing to contract Requestors is helpful and would greatly help organizations from a change management perspective deal with any potential "shock" of the licensing requirements for users which may only require one or two contract a year.
In terms of defending the business case for CLM, the metrics around a consistent and predictable contracting process proves valuable to not only the Legal department, but also other impacted organizations. In addition to saving time for in-house and outside counsel, the metrics around the length of time it takes Risk Management, Privacy and/or Information Security to review/approve a contract are also valuable. The CLM provides a hard audit trail in one place for these departments to determine the "story" around the contracting process. In addition, the ability to tell a year-by-year story around pricing and to project trends has assisted in terms of eliminating guess work around contract pricing.
As to what I would change around my current CLM pricing, has been explored below by Jason. I completely agree with a pricing structure where requestors or either "free" or there is a general "enterprise" requestor license would be most helpful. As legal counsel, the individuals most involved in the process are (1) Legal (internal and external), (2) Procurement/Supply Chain Managers, (3) SMEs, (4) Contract Approvers (think VPs within the reporting line of the requestors), (5) Contract Signers, and (6) CLM Admins.
Larry, this is great. This is what I'm hearing: (1) offering a free or an enterprise license for Requestors would improve adoption and overall value, (2) the business case extends beyond legal efficiency and into other departments that touch the contract review/approval process.
A couple of follow up questions, if you have a moment:
1. Who is an SME in your example above? Any contract expert in the business?
2. Are you indicating that your list of 6 user types would all fall into the "paid" category, and all other users in the "free" category?
An SME is any expert needed to review or approve specific portions of the contract outside of inside counsel. For example, we would need to leverage the knowledge of someone familiar with the insurance policies of our client (usually Risk Management) to determine if changes made are acceptable. I would probably urge that any SME license be a reduced fee as those individuals' usage is very limited in terms of actual engagement with the CLM. Their attention is needed within the contract and the main necessity is to get the relevant contract portions in front of them so review and then approve/reject and/or propose appropriate contract updates.
Got it. Very helpful. Two tiered + a free tier (3 user tiers total) might make the buying process too complex, but I appreciate there's a clear way to define roles/access rights that might warrant more than a single paid tier. We'll explore that further! Thanks, Larry.
I love the topic of CLM business-case justification and more specifically ROI. As a potential provider, I think you can position yourself to win a lot business by simply arming folks with ROI data to take back to the GC/C-Suite. I've seen a few studies in the marketplace re CLM ROI, but it's poorly developed, in part because legal departments haven't historically tracked benchmark data to drive a future-state value capture..
SO, many legal departments have paid for software with somewhat hefty license costs, 3rd-party configuration fees, and maybe throw in the Ironclad contract review/extract fee literally ONLY on the basis that well we need one, everybody has one. MAYBE discussions of "better/faster" contracting were thrown around but with no system, data structure, or governance to actually track or verify as proof as ROI won't need to be shown moving forward, we'll just trust the CLM took was worth it. So what would an ACTUAL ROI summary consist of? A lot of freaking new, currently untracked data points. And part of the problem is that folks think simply buying and implementing the system should "just produce" that data.
MANY CLM buyers have gone off the deep end when the configuration team enters day 1 and the legal department realizes that in large part, whatever data is about to tracked SHOULD COME FROM the legal department, as in for them to define! That is PARTICULARLY the case with structured contract data, i.e. do you have a hierarchy in mind or have specific, substantive, structured positions you want us to extract? But it also applies to process data. As in, data about efficiencies and such. MANY CLM tools operate as something akin to no-code platforms, where they can be configured to do perform workflows the legal department wants (whoops we have none/few of those defined) and to track whatever data points you want us to extract from contracts (whoops we have no pre-defined systematic data structure for contract data) and can track process data to benchmark your historical performance (whoops we have none of that tracked).
SUMMARY, there's no REAL WAY to define ACTUAL ROI for you customer! Will you have better/faster contracting, per a system you don't know how to define and have never defined, well who knows.
(QUICK ASIDE, on the matter of structured contract data, CLM systems are growing in their awareness of coming with pre-packaged data points against which to scan contract data through their ML Models. MOST of them have historically ended too high in the data hierarchy, e.g. great you've decided this is a Limitation of Liability clause - but who cares - what TYPE OF limitation of clause is it? As in go further down the hierarchy to get more granular contract data...so we can populate our database with usable metadata. Examples, Limitation of Liability Clause - Cap on Liability: YES, Type of Cap on Liability: FEE BASED, Multiple of Fees: 2x, Exclusions: YES, Exclusion Types: INDIRECT DAMAGES. THat's actual contract metadata that needs a structure. I GO ON THAT RANT here because That's what's required to prove ROI in terms of RISK AVOIDANCE or VALUE GAINED. In other words, the system helped us achieve better contracting positions for the company - as in our contracts are better! But of course without a data structure in place, without extracting that data from legacy contracts, without defining a company formal RISK PROFILE, beyond just desired starting positions, there's nothing to measure the future against.. I repeat that CLM vendors have awoken to contract data here, but they may use their own structured data model, and of course this will not be portable across systems since there's no standardization in this area yet. Regardless, a lot of CLM vendors have historically shown demos with things like "governing law", largely on the basis that Named Entity Recognition was good at things like recognizing a list of states. But there was no similar "list" of limitation of liability clause types and metadata. This are is near and dear to my heart because I built what I believe to be best contract data model in existence while at Unitedlex. But one model to rule them all is HOW portability happens and more importantly benchmark data can form in order to measure the ROI.)
So what has to happen to ARM YOU with the TOOLS to create and communicate ROI?
1. Need to create/leverage Structured Data across contracting processes and contract substance, borrowing from the most used standardized sources where possible. SALI and other sources are a start, but the industry is lacking. I'd be happy to share my contract process data sheet. Ideally there would be industry standards associated with all of it so that companies could benchmark and know what to track so as to build out their tech stacks to do that work.
2. Need to incorporate as much of this structured data into the fabric/dna of the product architecture as possible so that it doesn't require/rely on customer defining.
3. Example of this is a back-end database that is configured to as large of contract data model as possible, as a means to SELL on this diversity and specificity but that is as no-code configurable to client use case as possible.
4. Need to gather as much data as possible (and there won't be much haha) as can from client in their current state. I left a fairly long list of specific questions under the "are we asking the right questions" Post that works as a start. YES/NO/NA answers to certain questions will be immediate red or green flags to identify ROI capture. But will need actual data, again that probably doesn't exist.
5. Between process and substance data, if can paint a current picture of efficiency, compliance, and overall production: This will set the stage for arming them with an estimate of HOW and in WHAT WAYS your tool will produce ROI.
• How did CLM pricing play into your decision when evaluating CLM vendors?
The pricing played a small role in the adoption of the CLM vendor as there was a big push to start using a CLM program that could be adopted globally by the legal department. Our CLM program is used by the Australia, Asia, Europe and Americas legal teams. Therefore, the biggest concern was global adoption and a program that was considered user friendly to a global community with various needs.
• How does your current CLM vendor’s pricing structure prevent or promote adoption of the software across your business?
Our current CLM vendor pricing is a per user license fee. Each legal department head requires its direct reports to use the system and requires it to be downloaded on the respective direct report’s computer upon starting at the company. The head of our contract management group occasionally will send out an email to each lawyer ensuring that they are saving their documents to the CLM. Our legal department’s dedication to using the CLM is the true promotion of the software. Therefore, the pricing doesn’t dictate the adoption.
• Do you feel like you’re paying for more tools than your business is able to adopt?
We were until recently. We recently went through all the tools purchased and determined the number of people in the company using each tool. If the tool was under-utilized by the employees (e.g., less than 10-20% of the people in the company is using the tool), the service was canceled.
• How do you defend your CLM budget to your CEO/CFO during the annual renewal period. Or, put more simply, do you have to defend the business case and budget for CLM on an on-going basis, and if so, how do you do it?
We don’t have to defend our budget, but we do try to make sure we have a healthy budget that reflects tools we are actually using and make our processes simpler and faster. We will depreciate tools that we no longer find beneficial.
• How would you change your current CLM pricing? And why?
I would prefer we had a flat rate instead of a per user license fee as we have employees who want to use certain tools but don’t want to have to go through an arbitrary long approval process to use the tool so don’t get access to the tool. For example, some people in the group don’t have docusign but look to/request the paralegal to do all of their docusign tasks since the paralegal has the docusign tool.
I do find it a bit odd to have pricing for the CLM divorced from the pricing we pay for the eSign portion of our eSignature tool even though it is the same provider for both. In the one case (CLM) I'm counting user licenses and in the other (eSign) the document count we'll send for signature and those frameworks are completely different. Pros and Cons to both but I would like to see those two things meshed a little more to simplify things especially as estimating a document count feels a bit like a crapshoot at times and historical usage doesn't account for the things that inevitably come up that skew your estimates. It feels easier to say who needs to access this tool (or who can we live with having access to this tool) and do pricing that way rather than me having to make that assessment for the CLM and then count documents for the eSign portion.
I don't feel like we're paying for more of the tool then we could adopt but it has definitely been a long process to get the CLM up and running that we've paid for more of the tool than we've been able to implement so far. The potential is there with the tool but a long implementation time has dampered some excitement for what the tool can do.
Overall, pricing wasn't the main consideration for us, rather it was fit for our use case and ensuring that what we would use would work well with our current eSign tool which is one of the reasons we ended up going with the vendor for CLM who also ran our eSign tool.
As an attorney for a state government agency, I may have a bit of a different perspective here, although I agree with much of what others have said. We want to make good use of the public's money, so pricing of a CLM solution is definitely a major consideration. However, features that make the CLM easy to use and maintain as the primary repository of agency contracts are also critical because of the role our CLM plays in government transparency and accountability. Like many states, we have a strong open records act, and most of our contracts must be provided to any citizen who requests them. Having all contracts in a single place that is easily searchable facilitates responding to those requests; but if the CLM is hard to use, user adoption rate will suffer and contracts will end up outside of the CLM. Additionally, we are subject to state audits, which from my understanding in the past have randomly examined contracts in our CLM.
We do have to defend our CLM choice and budget, but the ability of the CLM to also help serve these secondary purposes (in addition to the main purpose of moving contracts through) makes it a fairly easy selling point to our CFO and leadership if the price is reasonable and feature set matches our needs.
Our current CLM pricing structure is not user based, rather it is based on the number of contracts entered per year. I think this model promotes adoption because we are able to add any employee as a user of the system without additional cost. The one exception is that there is a cost for each user with administrative privileges, which we only have a handful of those. I personally prefer simplified cost structure versus a complicated one with multiple user tiers etc. However, as long as the pricing model is transparent, reasonable, and not too convoluted, then I think decision makers can work with it. But, again, simpler is better in my opinion.
This is great, John. I really appreciate this perspective re ROI/defending the budget to CFO, and it's great to hear CLM has been relatively easy to defend. I also really appreciate your comment on pricing simplicity. We want to land on a pricing model that's reasonable, simple, but also (and this may not be intuitive) a pricing model that is easy to compare against other vendors. We've built and sold software elsewhere where our pricing was TOO innovative, and buyers had difficulty stacking us side by side. One follow up question.
Regarding "contracts per year pricing". Are you paying for this on a per document basis, or do. you buy up to a certain amount every year, and anything over comes with an added cost? Any detail you could provide on that would be awesome. We're less familiar with this model for CLM, but have experienced a similar concept with email marketing software among others. THANK YOU!
We buy up to a certain amount of contracts every year (we set the number based on our historical usage with some cushion), and anything over comes with an added cost.
Regarding price comparisons, in our recent experience in selecting a new CLM vendor, we were told by one potential vendor that many of its competitors in this market do not make their pricing available on their web site and are very non-transparent about it (this vendor did and was transparent). We found that to be true, and we had to get very deep in post-demonstration discussions with some vendors before they would give us pricing; and even then, it was somewhat nebulous, ballpark pricing. This was a turn off.
Pricing played a key role but I think capabilities and a clean user experience were given slightly more weight in the evaluation. These products tend to be very costly when you pair the annual subscription fee coupled with seat licenses. Perhaps offering various “stacks” of solutions (i.e. stack 1 is strictly workflow offerings, stack 2 is workflow coupled with AI automating routing decisions, and stack 3 is AI automated workflows with robust AI contracting options) coupled with seat licensing bundles would be attractive to customers. We utilized the metrics gathered by the system (time saved and less outside counsel spend) to justify a continued investment in enhancing the tool. The value in the legal space was evident after the first year. The buzz created as more users adopted the system has led to business units outside of legal to begin evaluating use cases in other departments. The metrics to evaluate the savings on those use cases are a little different but are focused on time saved and headcount. If I could change anything about the pricing it would be around the definition and need for a seat license. Ideally, I would not want a requestor to require a seat but all remaining players in the contracting process should require a seat. From what I have seen, the people requesting a contract are not heavily involved in the contracting process other than answering initial intake questions. It is the SMEs, senior leaders, and attorneys that really engage with the solution.
Jason, this is great feedback. We're already looking at unbundling core features into 3 packages to allow customers to be more targeted and cost efficient in what they purchase. We're also thinking about (like you said) creating 2 licensing categories (one free, one paid) where HR/Sales/Others users aren't required to pay. If you have another couple of minutes, could you expand on how you would define the paid license category? You started doing this already with "SME's, senior leaders, attorneys". But it would be great if you could share maybe 3-5 types of product access that would be exclusive to the paid license. THANK YOU!
Preston, this may be a little wordy, but I hope it is helpful.
Requestor - typically submits the request based on an ongoing business effort but typically does not provide any revisions to the contractual language. Their license would need to allow for them to submit requests and respond to questions raised by the attorneys or SMEs. If the solution offers a contract repository, they will also need access to the documents.
Attorney - full access but not at an admin level.
Internal SMEs (Risk, IP, Finance, etc.) - depending on the org, they may not make changes to the contractual language but would need to be able to provide feedback to any comments or questions raised by the attorneys.
Business Leaders/Signers - they would need access to review and approve a contract before signing, but they typically do not modify the contractual language.
Internal Approvers (mid-level leaders or project leads) - they would need access to review and approve a contract before signing, but they usually do not modify the contractual language.
Outside Counsel (working on behalf of the company, not External/Opposing Counsel) & External SMEs (Data Privacy Counsel, IP Counsel, Relevant Consultants, etc.) - they would need access to the in-flight contract to revise during negotiations BUT you would want to limit their access to the contract repository to only the documents they are actively working on. Once the contract is signed, you would not want your Outside Counsel or External SMEs to maintain access to your repository.
Taking all that into account, maybe a role-based license model would work.
Requestor
Approver
Negotiator
General (Viewer) - access only to document repository but no workflow access.
Admin - all powerful and can modify/enhance the system
Jason, this is wonderful. In a future post, I'm going to convert this feedback into a proposed licensing table (paid v free) with proposed access rights, and possible corresponding roles/job titles. I'll ask for your feedback back again there. So so great!