Failure is Not an Option
Sometimes, 50% is good. If an NBA player shoots 50% from the 3 point line, he’ll light the record books on fire. If you win the lottery 50% of the time, you can retire tomorrow. Sometimes, though, 50% is bad. A 50% on a Geometry test would likely cost a 16 year old the car keys for the weekend. Few would want to undergo a medical procedure with a 50% chance of success.
When it comes to CRM implementation, roughly 50% of them fail. This is undeniably an example of when 50% is not good. These failures are costly–they burn money, hurt employee morale, and often leave companies wandering aimlessly from one CRM to the next. Growth-driven CRM is all about how you systematically implement RevOps so your CRM can be useful for your company. Despite the relative newness of the term itself, RevOps is something that every company does. Therefore, you’re either doing it well or you’re doing it poorly. Period. The solution is to leave those 50% coin flips for the football field and begin treating CRMs as products, not continual projects.
The 5 Reasons CRMs Fail
CRMs fail often, and, often, for the same reasons.
Reason number one is adoption. If there is not widespread adoption, your CRM will fail. Full stop.
Reason number two is over-customization. When you value processes and tools over adoption, your CRM becomes fragile. And fragile things break.
Number three is scope creep. During the typical 6 to 9 month-long implementation period of a CRM, a business, along with its priorities, processes, and requirements, will change. What was a top priority 6 months ago, may not be now. This shift in prioritization causes CRM failure.
Fourth, lack of support and training. New employees are often a welcome addition, but when they are not properly trained, adoption rates drop.
The last death knell for CRMs is a lack of integration. This usually occurs between finance, sales, and marketing.
While these may be five separate and distinct reasons, they are all rooted in one cause: “waterfall” project-based CRM implementations. When you have rigid plans with finite start and end dates, the impacts of CRMs are prevented and delayed. These CRMs are not built for adoption, they are built to complete what’s in the project plan. And if your CRM is not built for adoption, IT WILL FAIL. Don’t go chasin’ waterfalls.
Mo’ CRMs, Mo’ Problems
Some things should be changed frequently: the oil in your car, the air filters in your home, and diapers to name a few. CRMs are not on that list. Unfortunately, many companies go through a CRM reboot cycle every 2-3 years that is expensive, risky, and difficult. That is not a three word combination you want anywhere near your business.
A CRM reboot cycle generally has three phases: implementation, decreasing usage, and a repeat of steps 1 and 2. (see above) In phase 1, there is a 6 to 9 month implementation of a CRM. The next 1.5 to 2 years, phase 2, is an increasingly decreasing usage of said CRM. When phase 2 occurs, there is a perceived need to change CRMs. Many companies choose a fresh start over a commitment to adoption and the correct implementation of processes. A new CRM is chosen, and the cycle, predictably, repeats. Insanity is often defined as “doing the same thing over and over again, but expecting a different result.” If that’s true, then the CRM reboot cycle is the height of madness.
Repeated, project-based CRM implementations come with costs. To name a few, they spawn rogue spreadsheets with no process to merge them into the CRM; they decrease CRM adoption rates; they decrease the accuracy, and eventually the usefulness, of your data; shadow IT costs emerge; and more data integration requirements emerge. The end result of these is a search for “one source of truth,” i.e. a new CRM.
I Only Have Eyes For You
Be faithful to your CRM! To break the CRM reboot cycle of jumping from one CRM to another, a dedication to the growth-driven design (see below) is essential. This design allows a business to create an iterative process that can eat and ingest new requirements and new questions in a way where they can grow faster, spend less money, take on less risk, and move faster. Growth-driven CRMs offer stability.
Much of that stability comes from the four principles they are built on:
Adapt: MVP (minimum viable product) then iterate
Realize: RevOps as a differentiator.
Many consultants in the world of CRM implementation will prioritize the drawing of your process, and from that drawing determine the necessary tools you will need. Adoption, for them, comes later in the process. That is backwards. The process doesn’t exist if people aren’t using it. Adoption. Adoption. Adoption. Adoption must be your true north. In turn, this means you must have support such as issue tracking and processing. Adoption, to be done well, must be thought about continuously and at all points by someone within your organization.
CRMs are not static, though their core function remains the same. If adoption is the most important aspect of a CRM (and it is), then adaptation may be a close second. Overtime, your user’s needs will change and so will the needs of your company as it grows and becomes more complex. Your CRM must constantly be collecting input and changing accordingly.
You must prioritize training and have an uncommon level of attention to potential issues. A small error, fixed quickly, will increase adoption and improve efficiency. If that same small error is not attended to, employees will find a solution that is often outside of the CRM. When you operate outside of the CRM you have failed to secure adoption.
The ultimate goal of RevOps or a CRM is to answer questions quickly. Because those questions rarely change, best practices can emerge. RevOps is a science, not an art. There are very specific data models and processes for collecting, synthesizing and disseminating revenue data information accurately. This will result in much smaller pivots because your foundation is solid. Build your CRM on the foundation that is the rock of growth-driven CRMs, not the shifting sands of project-based CRMs.
Trust the Process
Preparation and intent are important, but without the proper processes those intentions often don’t come to fruition. Recognizing why project-based CRMs fail and committing to growth-driven CRMs are great first steps, but a commitment to the process of actually adopting and implementing them is where the real difference is made.
Growth-driven CRMs follow a specific 4-step process:
- Define the data model
- Define MVP requirements and features
- Prioritize MVP and features
- Start sprints.
Define the Data Model
Defining your data model is the first, and most important, step. It is your foundation. It defines what you will collect (volume, conversion, time points), synthesize (customer lifecycles, lead scoring, forecasting), and disseminate (questions you’ll answer and report on). Each of the different data models, B2B, B2B2C, and B2C, will, for example, produce different lifetime customer values. These different models are the catalyst for your company's performance of RevOps. They will give you the ability to answer questions surrounding what happened (hindsight), what is happening (insight), and what will happen (foresight). The work you put in during step one helps create clarity for the rest of the process for your company and your users.
Define MVP Requirements and Features
Step 2 is defining the MVP and features. It begins with drawing. A tool such as Miro will allow you to draw and color code future sales and marketing processes in left to right, linear journeys. Red, for example, could be used for processes that don’t currently exist. Then, ask yes/no questions. These types of questions require a definitive response and can often yield more information than an open ended one. “Failure if” statements follow this. This gives you the ability to see how the CRM might fail. These statements can then be bucketed and used to create objectives and “must have” (your MVPs), “nice to have”, and “in the future” lists.
Prioritize MVP and Features
Next, is prioritization. Here, MVPs are further broken down into epics (projects). Although these are then structured and numbered, it is not a waterfall as you may, for example, work on number 1, 2, and 3 all in the same week. There is also constant reprioritization as weekly meetings take place.
Last, but not least, is to start sprints. This is where you’re selecting tasks within an epic and pushing it into a sprint. You can then pull tasks and commit to finishing them within a given timeframe. You meet weekly and reprioritize from there. This allows you to track any issues that come up.