Are you (still) doing the right things?

Are you doing the right things?  Are you still doing the right things?  This is one of the questions that a good CRM system can help you come to grips with.  Customers don’t know what’s “right” or “wrong” in your organization, so they ask, “Why don’t you do this...”.  When they ask questions like that, try to be sure you are giving a correct, current answer.

There's story of a research experiment involving chimpanzees, bananas, and a garden hose.

The chimpanzees are put in a room with a bunch of bananas hanging from the ceiling.  The room also has a stepladder in it; it doesn’t take long for a chimp to move the ladder to under the bananas and start to climb.  But as soon as the monkey gets near the bananas, the researcher sprays him down with cold water from the garden hose, and sprays the rest of the chimps in the room as well.  It doesn’t take very many repetitions for the chimps to all learn not to try to get the bananas.

Now a chimp is removed and a new one replaces him.  The new chimp moves the ladder and tries to get the bananas.  Of course all the other chimps in the room tackle him - they don’t want to get sprayed with cold water.  So the new chimp quickly learns the same lesson, don’t try to get the bananas!

One at a time, all the original chimps are replaced - there are now none there that were ever sprayed with cold water.  Yet when a new chimp comes in and tries for the bananas, the rest still tackle him - but if they could talk, none could tell you why, just that it was bad, not done.

Is that your organization?  Are you still doing (or not doing) things a certain way “because that’s the way we do them here”? 

And what is it costing you?

WNTD: “Who signs your paycheck?”

What Not To Do: Random horror stories from the trenches.

“Who signs your paycheck?”  A consumer products company outsourced part of their call center operations to the wilds of Utah, where labor was much cheaper.  They worked with a company who’s expertise was outbound telemarketing, not that it mattered much.  After weeks of training, they went live, and it worked okay.  There was much monitoring from the parent company at first, then gradually the reins were loosened. 

What was interesting was the metrics the call center reps were judged on - how long was the call (short is good) and how satisfied are your callers (based on surveys).  One rep started getting higher marks, then much higher marks - in fact, he collected all the possible bonuses.  He was demure when he was asked how he achieved his success - “I just listen to them, and try to do what’s right for the customer” was his reply.

The real answer turned out to be he essentially answered the phone with “Hey, it doesn’t matter what your problem is, will $25 in coupons solve the issue?  What about $50?  Great, let me get your name and address.”  He was giving away ten times what some other reps were, over $2000 each day - but the cost of the coupons came from the parent company, not the outsourcing company that signed his paycheck. 

Short call times, happy callers... but somehow, not good overall customer service.  At least, not very cost-effective.

Designing your CRM system (Part 2) - An iterative, user-focused process

Design of your CRM system should evolve during the implementation process.  “Release early, release often” is a mantra of many open-source developers, and it turns out to help in many applications.  (I’ve heard of exactly one system that had no changes between initial design and final acceptance, and they spent four years in the design phase.  It was aerospace-related.)

If you can get a good suggestion from a user, implement it quickly, show them the result during the programming / testing phase, you’ll develop a feeling of “ownership” with that user.  When you have other glitches (and you will!), that goodwill will help you - they won’t be so quick to badmouth “their” system.  Keep the lowest-level users as involved as you can (their managers will resist, wanting them to keep doing their jobs, but it’s important).

And once the system starts coming together, users will be able to try it in increasing completeness.  In various implementations, in the few weeks before final testing I’ve done things like:

• Change field order on all main screens, and reworded all menus.  (This is common.)
• Remove 20% of the app (Adding 6 fields to another area let them drop 8 full screens.)
• Add a complex nested dropdown field that subsequently powered lots of their reporting.  During the design & implementation process, a manager had expressed “decreasingly vague” frustration with the design; after a series of meetings and fact-finding missions, it coalesced into needing this field added.  If she hadn’t seen all the earlier iterations, we never would have gotten to this point.

Users are smart - when you (finally) show them what they want, they’ll know it.

Of course you’ll need some more changes right after go-live, but that’s okay too.  Change is good - you're making the system and process better, removing friction and saving money.

Designing your CRM system (Part 1)

Okay, you need a new CRM system - what do you want in it?  Management has high-level needs that will be part of the design, but the bulk of the system design will be screens, fields, databases, interfaces, etc.  What should they look like?  If you ask this question early in the implementation process, you will (deservedly) probably get blank looks back.

Brian Sooy’s General Theory of Design: "Design consists of creating things for clients who may not know what they want, until they see what you've done, then they know exactly what they want, but it's not what you did."  (from http://bscodesignmatters.blogspot.com/2006/05/skeet-shooting-in-dark.html)

This is a common place to start.  You want to reap the benefits of a good CRM system, but that’s awfully vague.  If you ask people what they need, some will jump into too much detail (I’m sometimes guilty of this) , and some will know only the high level requirements and not be able to drill down to individual requirements.

Brian Sooy goes on to say, “Thankfully in my experience, the antithesis of the Theory has been true in most instances: "Clients who know what they want will provide a design brief, and evaluate all designs based upon that brief."

So how do you get to a decent design brief?  I advocate, “Do one to throw away”, a true pilot system.  Make an incomplete (quick-and-dirty) CRM system as fast as you can, and improve from there.  The “system” may be as simple as some quickie web pages or linked PowerPoint slides with mocked-up screens on them; but preferably, it will be a very simple (almost out-of-box) version of the software, with anything complex put in the “work on this later” pile.

Then take this system to the stakeholders, as many of them as you can get together.  Explain to management where the data they need for reporting will be entered; they will also have technical questions.  Explain to the users what the screens might look like - they will be different than what they are used to, hopefully you can ease a few pain points in the current system.

Make sure you get end-users involved, because the ultimate success of the system depends on them.  Explain what you are doing: “I’ll bet you are tired of getting systems thrust upon you; here’s a chance to tell us what you really need.  Help us make a better system for you.”  Not every user can do this, but every call center or sales force I’ve ever dealt with has a few users who have been extraordinarily useful with system design.  They know their jobs better than anyone else (including their manager) and want to help. 

Get the users off the road or off the phones for an afternoon or two early in the design process, and keep in touch with these users throughout the rest of the design and implementation process.  They will be your biggest advocates in the user community, help you train the users, and help with the general dislike for new systems that is a simple part of human nature.