CRM Lessons Learned

I have spent much of the past eight years working with CRM systems. Although I have a lot of faith in the promise of CRM, I believe that the realization of that promise requires a mind-set and a commitment that many companies are not aware of or prepared for.

At a previous employer, a software development company, I was actively involved as a software engineer in three essentially different CRM implementations, although all three used the same CRM product.

Strike One

When the need for a CRM system became clear, we selected a product that we knew had been effectively implemented and used by another company with a similar business model. In fact, we basically just borrowed its design.

Our first release, which took six months, included only the sales department. Later releases, staggered over the next year, integrated technical support, product distribution, finance and -- to a lesser degree -- marketing.

But after a couple of years of working with this system, we realized we had a model that was flawed in two key areas.

First, it focused on serving individuals as customers, rather than companies as customers. This became a problem as our business strategy changed and we entered into larger deals selling software to development companies rather than to individual developers. We needed a more comprehensive view of all our interactions with our new customer base.

Second, the overall implementation was built piecemeal from the bottom up, focusing on the needs of individual departments. While this was generally efficient for each department, the resulting system didn't allow us to smoothly move work among different departments.

So we tried again.

Strike Two

For the second implementation, my company invested significant resources to design a system with complete involvement by all current and potential client groups. The design team consisted of both cross-functional and cross-location representatives, and we had a big budget to work with.

We completed a design that met the (often negotiated) requirements of marketing, sales, technical support, professional services, software development, product distribution and finance. And it met U.S., European and Asian needs. To speed up implementation, we hired a number of consultants from the vendor and completed implementation within nine months of starting the project.

It didn't take us long to realize that we hadn't built the ultimate system we had envisioned. The overall complexity of the product introduced some significant process issues, and it wasn't amenable to the types of rapid changes that the company wanted.

So we tried yet again.

Strike Three

For the third implementation, we tried a solution that was as "out of the box" as possible. We focused the system design on sales, where we had experienced most of the pain with the existing system. We upgraded to the latest version of the software, which significantly improved the user interface.

We also vowed to adapt our processes to the product to minimize the need for customization.

A third-party process consultant with significant CRM experience was brought in to help us design a workflow that met the specific needs of sales, and that would fit well with the strengths and the weaknesses of our CRM product. Most of the effort of implementation was handled internally. The entire project took not quite a year.

Still, no success. The new software, though more user-friendly, was relatively immature; the sales process, carefully designed though it was, wasn't consistently followed. And the out-of-the-box vendor solution was simply not robust enough for an implementation of our size and complexity.

You're Out -- but Why?

So three tries, three failures. What went wrong? I have identified the following:

  • Workstyle differences. The workstyles of our individual client groups were so diverse that it was very difficult to make one product accommodate them all. It's not just a matter of different processes, but of different overall styles. Technical support, for instance, wants a structured, linear workflow, whereas sales needs an intuitive, nonlinear workflow. Our efforts were further complicated by being geographically distributed around the world.
  • A lack of adequate off-line and integration tools. This was the single largest technical issue we faced (and never resolved). There are two aspects of this problem: the ability to reference, create and modify data while disconnected from the network; and the ability to integrate data between PDAs, Outlook and other contact management tools. Although this is due in large part to the limitations of our specific CRM product, it is, I believe, an issue commonly faced by most CRM implementers.
  • The process resistance of sales teams. I have found it quite difficult to get the sales team, more than any other group, to define a process that all members agree to live with and stick to. I say this without, I hope, offending my sales colleagues -- I see the roots of this behavior in the nonprocedural and independent nature of their work.
  • The rate of desired change typically exceeded our ability to implement it. As we added more and more customization and automation, it became increasingly difficult to quickly adjust to changing business and process demands. Eventually, this led to an environment in which IT resisted, rather than embraced, change.
  • Poor data quality control. My company didn't pay nearly enough attention to entering data into the system correctly and into maintaining its integrity. Over time, we ended up with so much clutter, duplicate data and invalid data that the overall value of our data store was severely diminished.
  • The failure of consensus design. Common belief holds that a sufficiently representative and empowered design team, like we had in our second implementation, will deliver the best possible solution. But it's easy to overlook the fact that design teams often don't include the true visionaries and leaders in an organization. These individuals are typically too valuable to invest in internal systems design work. Thus, our "consensus design by representation" ended up being built by representatives without sufficient authority and influence to effectively champion the proposed design.
  • A failure of enforcement. A CRM system will work well only if it's used consistently. It must be used consistently in two different ways: It must be used each and every day, and it must be used the same way each time. The groups that used our CRM system most effectively were those that had a clear mandate and enforcement from the top; the groups that gained the least value from the system were those whose management was lax in enforcement.

How to Do It Right

Despite all these flaws, I firmly believe that it's possible to implement an effective CRM system, but only under the following conditions:

  • The benefits expected from the CRM system must be clearly identified. These can be companywide benefits or workgroup benefits. A companywide benefit can be obtained, for instance, by tracking product life-cycle metrics. How much effort must be expended by marketing to generate each sales lead? What is the length of the product sales cycle? How many leads turn into sales? How much effort is spent by technical support in maintaining the product? How much work is generated for software development in terms of maintenance and enhancement requests? Workgroup value is easy to obtain: Technical support can put alerts on requests with long response delays, or marketing can track the number of responses to a marketing campaign.
  • Consistent processes must be defined (even if their granularity is coarse) and enforced. Most CRM systems are built to work around explicit processes within departments (such as a process for obtaining and qualifying leads in marketing) and between departments (such as handing off leads from marketing to sales or moving customers from sales to technical support). Further, consistent use must be enforced: It must be clear that using the CRM system -- as inefficient as it may seem -- is a requirement of the job.
  • Sufficient attention must be dedicated to data quality control. This is one of the most critical -- and most easily overlooked -- keys to success. There is nothing more frustrating than having the entire company's sales history stored in the CRM system but being unable to easily answer the question "Who are our top 100 customers?" because 3-Com is entered variously as "3-Com," "3Com," "3-Com, Inc." and "3-Com Corp."
  • Process and tool "rough spots" are recognized and resolved. Our implementations, for instance, never really created a smooth marketing-to-sales transition -- one of the most obvious workflow transitions there is. The result was constant tension and inefficiency between the two groups.
  • Customization must not be overdone. In order to retain as much agility as possible for process change (and for CRM product upgrades), the amount of customization must be minimized -- but not, and I stress this, not to the point of jeopardizing key internal processes. Just remember that there is an ongoing maintenance obligation that is created for each line of customization you add.

No two companies are the same, so no two CRM implementations can be the same. But many aspects of CRM design and implementation will remain the same across products and industries. Success, in my opinion, is much more dependent on your ability to think broadly and to speak persuasively than on the features of the CRM you select and the technical skills of your team.

Special Report

CRM Goes Vertical

Stories in this report:


Copyright © 2004 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon