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.