3 reasons why Salesforce.com falls short when it comes to contracts
When it comes to enterprise solutions, organizations normally gravitate to just a handful of vendors. Whether it’s SAP, Oracle, or another major player, the list is pretty short, and unfortunately the cost per solution is high. Enterprise solutions often end up costing millions, or even tens of millions, of dollars.
Since these systems are such large investments, companies tend to stretch their capabilities to ensure a positive ROI. For instance, they will try to leverage systems for functionalities that simply aren’t within their scopes. This is common with ERP systems. However, there is another system that organizations extend beyond its means — Salesforce.com.
Salesforce.com has grown in popularity among companies, driving them to want to do everything within the system. According to the common adage, there’s an app for that, people generally expect simple solutions for just about every technological need. And while Salesforce.com is an easy solution for managing customer relationships, it’s not the right program for everything.
If your company attempts to use Salesforce.com to automate and streamline contract lifecycle management, you’re missing out on key steps and critical functionalities. From a contracting perspective, organizations should only use Salesforce.com for three things:
Sales teams tend to think that they only need to be able to search for existing agreements, request new agreements, and track the status of an agreement when managing contracts. And in that case, since much of this information lives in Salesforce.com, many sales teams attempt to leverage the system to execute the entire contracting process.
However from a contracting perspective, Salesforce.com lacks critical functionality that is essential to successful automated contract management, such as authoring, rendering, redlining, and approving. Salesforce.com doesn’t effectively manage these functional requirements of contract management. Because of this, companies should adopt a full-fledged contract management system.
Here are three reasons why proper contract management is best performed in a focused contract management solution:
1. Functionality. Salesforce.com is the clear leader in CRM, but contract rendering, authoring, reviewing, redlining, approving, storing, and securing aren’t key customer relationship functions. These steps require contract expertise, and must be completely auditable and secure. Organizations that bog down their CRM solutions with other functions often see a decreased performance in the true CRM capabilities (the reason for the purchase in the first place).
2. Scalability. As businesses grow, so do their contract volumes. Systems unprepared to handle large quantities of documents fail to scale when an organization needs it most.
3. Licenses. The number of people needed to move a contract from initiation through approval can end up being much larger than originally anticipated. Sales, marketing, administration, contracting, legal, finance, channel management, and procurement each have their own role in the contracting process. Now think about how many of these departments currently have access to Salesforce.com. The number of Salesforce.com licenses required might need to double, triple, or more to ensure all the right people have access. And that’s not practical or cheap.
Most organizations seek the maximum return on their enterprise software investment. However, forcing systems to work considerably outside of their “comfort zones” is a slippery slope. By stretching solutions in the search of maximum ROI, companies might cost themselves more in the end.
Organizations can source a dedicated contract lifecycle management system that integrates with Salesforce.com, but adopting a system that performs the contract heavy lifting outside of Salesforce.com is often a better solution. Organizations can still utilize Salesforce.com for contract initiation and monitoring, but by implementing a singular contract management system, organizations no longer have to fear the headaches associated with asking systems to work outside of their comfort zones.