The First Step to CRM Success: Name Your Problems

My friend Hank retired from the Coast Guard after a 20-year career, and now he’s pursuing a second career of service as the executive director for the Alameda Food Bank, another truly worthy career path.

During a recent party, we got to talking about work — me about CRM, him about the food bank. As it turns out, the food bank had a need for CRM, much as many nonprofit organizations do. Generally, nonprofits treat their donors as customers — and having a record of their donations and the campaigns to which they respond is extremely valuable.

But, said Hank, the food bank needed a bit more. “We’re also managing volunteers,” he said, “and we’re not just keeping track of hours. Scheduling isn’t that difficult — but we’d like to know where our most reliable volunteers are, how to contact them, and how to allow them to opt in to be contacted.”

Keeping the Gears Moving

If you’ve never volunteered in a food bank, it involves a lot of small tasks — sorting food, bagging it, and handing it out to the people who rely on it. It takes a number of volunteers to do these small tasks. Often, civic or church groups volunteer as groups to perform these duties. But what happens when a group cancels out? That leaves the food bank with food to pack and distribute and no one to do the work.

What if you had a way to manage and contact volunteers when cancellations occurred? That’s what Hank was asking about.

I didn’t have an answer, but I did congratulate Hank for doing something that many businesses (profit and nonprofit) fail to do when they start talking about CRM: He defined his goals.

Stay on Target

By knowing what he wanted to accomplish, Hank took the first step toward a successful CRM implementation. In my conversations with managers in charge of CRM solutions, it’s astounded me how many were unable to name the problems CRM was intended to fix, or who rattled off a laundry list of dozens of problems. In both cases, that lack of focus and clarity is a warning that their CRM implementations are rudderless ships — and the rudder most often goes missing early on, during the requirements definition phase.

This phase is the part of the CRM lifecycle that makes or breaks the entire effort, which Richard Boardman writes about this extensively at his excellent blog. It’s so simple and elemental that it’s easy to overlook, and Richard’s true talent is not losing sight of the foundational aspects of CRM even as the flashier elements are added on top on them.

It’s about keeping your eyes on the ball. If you have a problem you need to solve, stay focused on solving that problem while you establish your requirements and your goals. Additional capabilities are great, and you should fully explore them — but not at the cost of fixing the problems that drive the need for CRM in the first place.

And don’t treat CRM as the cure for a menagerie of unrelated issues; if there are widespread problems in the organization, the odds are good that many of them are process design issues rather than issues around automation and CRM. Solve the problems, certainly — but winnow out those for which CRM is not the ideal solution.

Hold Your Fire

Often, the CRM decision devolves into the dreaded “feature shootout,” a data-sheet-driven exercise in checking off boxes based on what competing solutions have or lack. This is a default IT approach to product selection, but it gives features equal weight. In CRM, there will be features you use regularly and others that come into play only on occasion — why would you give the same emphasis to a seldom-used feature that you give to one used constantly to run your customer processes?

The other problem that often manifests itself is that managers have a vague feeling that they need CRM, but they can’t get to the granular level Hank was so adept at reaching. In other words, they lack the ability to name their problems. The fact that you lack a CRM application is not a sufficient problem — these products are supposed to fix business problems, and failing to establish your requirements from the outset means that your CRM deployment will itself become your business problem.

Define your problems, map them to your requirements, and then make your CRM decisions. I suspect that if the CRM decision maker lives his business’s problems — like Hank does — this is easier to do. The rest of us need to work at it.