I am reasonably assured that the How To articles I have been writing for the past year or so are fairly well received (one colleague called them "powerful", and she said so more than once, so I think she meant it.) Here, then, are three things I think everybody heading into a CRM project should know.
#1: Basic Rules For Avoiding Bamboozlement
A CRM integrator should be prepared to help a client make tangible, meaningful improvements to the business (and, by the way, materially improve the customer experience as well, keeping that "C" in CRM.) Too often, integrators are eager to sell a fancy package of services around a "methodology" that doesn't speak directly to how it will identify and ameliorate shortcomings in the company's customer processes.
Use a common-sense guideline as a test. If it takes a spreadsheet or a flowchart that spans more than one page to describe a business diagnostic, crank the BS meter up a notch. If you cannot read through the methodology aloud and find that it makes sense coming from your own lips, strongly consider an alternative vendor. Don't get befuddled into a major business investment.
#2: Contact Center Agents: Specialize or Generalize?
The jury is still out—way out—over whether or not a "360-degree customer strategy" means that contact center agents should be deployed across all channels, or trained to serve a broader category of customers, or both. Clearly, things got broken in a hurry during the rapid WWW build-up of the late 90s, when a significant amount of customer service strategy was often completely disconnected from the central service organization, farmed out to IT, or worse, to no one in particular. With universal queue technology making it extremely feasible to manage online, telephone, and even printed service requests in one system, there is no hard and fast rule for blending agent proficiencies.
There are compelling reasons to specialize—basic resource allocation theory says that it's usually better to let two entities specialize in doing the thing each does best, even if one is better at both. But if you do plan to specialize your agents, and therefore create a system where you have various company representatives who cannot, in fact, accurately represent your company under many (or most) circumstances. Therefore, if specialization is the preferred method, there needs to be a very clearly articulated method to the specialization, and all agents need to be trained not only in basic diagnostics, but have access to an experts database that can still speed the customer to the right resolution.
It's not difficult to see why specialization can be a benefit... although the benefit won't be terribly great unless you invest in it substantially. I liken this problem to the choice facing hardware store customers in the Midwest: "Menards or Home Depot?" Home Depot proudly emblazons on each of its employee's smocks that they are ready, able, and willing to offer aid throughout the store. This is almost always laughably inaccurate.
On the other hand, Menards assigns each of its employees to a specific department, in which they are expected to display ultimate mastery. Since I know first-hand just how little training a Menards employee gets before being put on the floor of that department, I know full well that there may not be a single person in the store who has an accurate answer to a question I may have. But by going to the relevant department and flagging down an employee who belongs there, I'm at least giving myself a better chance than I would grabbing a random Home Depot redsmock. (If I can find one.)
As if I haven't stretched this analogy far enough, I will further decimate the elastic by saying that a specialist bluesmock at Menards is only useful to a customer in two situations—either when that customer has a question pertaining to his department, or when he can accurately route that customer to another department. Which means the bluesmock needs to know how to diagnose what the customer is looking for ("Oh, you need a new bathroom vanity!") as well as to send the customer to the right department ("You'll need to go to the electrical department. I know, you'd expect it in cabinetry and millwork, but we keep the bathroom vanities in electrical!") in order to keep specialization from hindering the customer.
#3: CRM Is Still (Somewhat) About Technology
First, it was chic to say that CRM is not about technology because it was about people and process. Then, thanks largely to Salesforce.com (and a refrain of "us too!") it became chic to say that CRM didn't even require software in the conventional sense. The former is true, with a major caveat, while the latter was always silly and has only become more silly as Salesforce.com has turned the tables on itself and acknowledges with a wink and a grin that, in fact, they run an awful lot of software indeed.
The line here is actually remarkably simple. The best and most meaningful CRM improvements come from changes which are not, themselves, bound by technology but are enforced or reinforced by technology. Computers are wonderful at doing what they are told to do—very very quickly these days, as it turns out. The rules now are no different than in the first waves of computerized automation from the 1960s and 1970s. Don't implement a recommendations engine or an IVR or a customer knowledge base. Create the rules and the customer flow and the information for those handy automation tools, and make it good. Then put technology to work to make it happen.
Click here for the next article in this series.