My friend Hank retired from the Coast Guard after a 20-year career, and now he’s pursuing a second career of service as a director for the Alameda Food Bank, another truly worthy career path.
During a Fourth of July 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 non-profit organizations do. Generally, non-profits treat their donors as customers – 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.”
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. That takes a number of volunteers to do these small tasks. Often, civic or church groups volunteer as groups to perform these duties. But what happened when a group cancels out? That leaves the food bank with food to pack and distribute – but no one to do the work.
But what if you had a way to manage and contact volunteers when cancelations happened? 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 non-profit) fail to do when they start talking about CRM: he defined his goals.
By knowing what he wanted to accomplish, Hank took the first step toward a successful CRM implementation. That implementation may come sooner than he expected; this week, I was tipped off by Esteban Kolsky about the Data Bank, a contestant in CRM Idol this week and a possible solution to the food bank’s problems.
But the requirements definition phase deserves more discussion. In my mind, this is the part of the CRM lifecycle that makes or breaks the entire effort. My friend Richard Boardman writes about this extensively at his excellent blog and I fully recognize his influence on my viewpoint –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.
The other problem that often manifests itself is that managers have a vague feeling that they need CRM, but 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.
I wrote more on this topic in our white paper “The 10-Step Guide to Buying the Right CRM Solution.”problem identification and requirements definition? Four of the 10 steps are all about those topics.
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.