Thursday, January 23, 2014

CRM Alone Won't Solve Your Problems

Customer relationship management (CRM) software is being adopted by a growing number of customers around the world.  The traditional applications for CRM are for sales force automation and customer service, but in a broader sense it is used to track other kinds of relations and other kinds of cases. 

We are seeing government agencies, higher education and non-profit organizations adopt CRM to track interactions with stakeholders and constituents as well as traditional customers.

Increased use of CRM is a good thing, and certainly welcome to companies like our who assist clients with implementing CRM -- but there is no magic in the software.  In nearly every case, the CRM initiative won't work without behavioral changes.

Here are some of the behaviors that our clients are trying to change:

1. A broader view of relationships.  A university, for instance, wants to show many types of interactions, such as prospects, applicant, students, alumni, and parents, and the ways that each department interacts with them.  Sometimes this is called a 360 degree view. 

2. Longer term perspective.  A CRM system can help you understand how relationships change over time.  You can even show what happens when one of your customers moves to another company or another town.

3. Greater accountability.  As any hotelier or airline knows, everyone who interacts with a customer shapes their experience and perception of a company.  Small things matter, and CRM can help you track these interactions.

4. Continuity.  Capturing information in a CRM system allows you to enlist more people to help with a case without asking the client to keep explaining what they need.

Successful CRM requires more than a commitment to use the software. Without a commitment to changes in behavior, the overall initiative is unlikely to achieve the goal of making customers, constituents, and others more satisfied with their experience. 


Friday, January 3, 2014

What to Include in Your RFP for Grant Management Software

Since we started work on government grants management back in the 1990s, we have read hundreds of requests for proposals from government agencies.  We do not have the privilege to write RFPs, but if we did, here are some items we would be sure to include:

1. Tell how many users you need for the system.  If there are different groups of users such as internal and external reviewers, or occasional users, try to differentiate among them.  The number of users make a big difference in the price of software licenses.

2. Tell us your budget.  I know this seems impossible, but it would save a great deal of time for the buyer and the seller.  Buyers have budgets set before they send out solicitations, and some proposals are rejected because they are outside the budgeted amount.   Even bids that are too low may be rejected as unrealistic.

3. Be specific about requirements.   Tell us the details of your particular process and especially what you think makes it unique.   Include samples of forms and documents that you use, or the manual for the system you are planning to replace.  Describe your processes and workflows step-by-step in plain English, either as use cases or in another format.

4. Describe your environment and your hardware and software standards. How strong are these preferences?

Now for some items that you should not include in an RFP:

1. Platitudes are not requirements.  If I had a nickel for every time I saw "user friendly" or "completely integrated"... These are meaningless expressions that don't help you get a better system in the end. 

2. Unless you have already chosen a vendor and the bid process is a formality, don't ask vendors to claim they have done exactly what you want with a customer exactly like you.  This may eliminate some innovative proposals that might save you time and money.

3.  Don't ask for open-ended integration.   I have seen several RFPs which ask for integration to other systems which are not even named (or the dreaded "etc.").  Integration costs cannot be estimated without detailed information on the systems to be integrated and a definition of how that integration will work.

I have seen several strong RFPs recently which included significant detail and seem likely to result in successful projects.  Perhaps the tide is turning and quality will continue to improve.