I'm having a lot of discussions about CRM systems these days. What is CRM? To hear many talk about it, it's some magical program you buy and suddenly you start getting more business. It seems like many people think you have to go with something established and expensive -- and if you can get a non-profit deal for using SalesForce for free, why that's certainly the best, right?
Not necessarily.
CRM originally stood for "Customer Relationship Management," though now clever CRM sales people have substituted other Cs -- constituents, contacts, candidates, cat. At it's core, it's simply a glorified address book with some functionality to help you keep track of your contacts, whoever they may be.
You already have relationships with your customers, right? You are already doing CRM, if you have any customers. It might be all in your head. It might be business cards and a tickler file. For a couple years I used a magnetic dry erase-board to keep track of sales leads in various stages, with 3x5 cards I could organized based on where they were in our discussions.
Where's the pain?
If you're shopping for a CRM system, the very first thing you should be thinking about is: Where are you feeling the most pain, when it comes to managing your customer list?
For one client, their biggest current pain is the fact that now that they have a nice event and conference management site where users can keep their own contact info up to date, they now have two different data repositories, and their old Act database is no longer always the correct one.
Moving from Act to a new CRM system isn't going to solve that problem -- for a time, it's going to exacerbate it, adding a third database.
In fact, that's a huge pain many, many organizations face as they move more of their management online: the old tools don't allow customers to manage their information, and so they end up with multiple islands of data that all get out of sync.
If you have this pain, you have basically 3 choices:
- Limp along copying data between multiple systems.
- Add all of the functionality you currently need to do in other systems into your primary web-based one.
- Set up data synchronization between the primary web-based system and the other systems you need to use.
Obviously, option #1 sucks. Option #2 represents a big change for your employees, and carries some security risk. #3 can get very complex and expensive.
What should you do?
Make your CRM successful
Take a hard look at what you currently have to do in your sales process. Going in, I ask:
- How do you currently get new customers? Where do they come from? Where do you want them to come from?
- Once you have a new lead on a potential customer, where does their contact information go? Who enters and manages it?
- What is your sales process? Who follows up on new customer leads? What supporting sales material do you have available? How do you get it to your customers?
- Once you have made a sale, how do you interact with your customers? How do you identify your best customers? What sorts of activities do you do to get repeat business? How long are people typically customers?
- What other kinds of contacts do you need to manage? Sponsors? Speakers? Pet Owners? Students? Faculty? Vendors? Partners? Suppliers? Volunteers? How do the lifecycles of interactions with each kind vary?
Grow your CRM over time
You could go get a big CRM system, spend weeks setting it up to match your ideal structure, spend months getting data flowing through the other applications you use, and years getting people to adopt it. And end up trading one pain for another.
I think that's a huge mistake.
If you already have a Drupal site, you already have a CRM system. You just need to set up the functionality you need to make it work for you. Let's run down some of the CRM functionality you might need.
User directory
If all of your customers interact through your web site, giving them a profile of some kind lets you build the most basic part of a CRM: a user directory. In Drupal 6, the Content Profile module makes it easy for each user to have a profile. For Drupal 7, Profile 2 does the trick. Add some views configure permissions appropriately and you have your user directory -- and a lot of other information about your users are automatically linked -- order history, event attendance, page visits, and more.
What if your customer base extends beyond web site users? You basically have three choices:
- Create a new user account for each customer
- Create an arbitrary content type not associated with a user
- Use one of the CRM options in Drupal 7 designed to associate profile information with a non-user
Activity Log
The first thing that differentiates a CRM system from a directory is some sort of activity log. This could be as simple as enabling comments on your directory entries, and making them only visible to staff.
I prefer making a new type of content, an "Activity", so you can attach a future date for activities you want to complete in the future, a "completed" flag to mark when it's done, and more.
Use an entity reference or node reference to link an activity to its contact.
Engagement Scoring
Here's one place Drupal wins: helping you identify your best customers, if part of "best" has anything to do with your web site. For the kinds of event management sites we're doing, "best" means people who regularly attend events.
Event registration sites keep track of registrations, obviously. One interesting thing you can do with some of the Drupal CRM offerings is provide a weighted value for different kinds of activities. Is this dollars spent in your store? Number of times they tweeted with a link to you? Events attended? Amount of time spent reading your web site?
Where this starts to get powerful for CRM purposes are for finding people highly interested in your organization, but not yet a customer.
Search
Have a slow day? You might be able to get a list of people who have spent more than 15 minutes on your site, signed up for a user account, added an event to their cart, and not checked out. Get them on the phone and ask if they had any trouble, or why they didn't go through with it?
Or pull up a list of volunteers from 2 years ago who have not volunteered in the past year.
Or search your membership data for a person from a particular kind of firm with a particular kind of expertise who might be interested in speaking at an event.
Here's one key area Drupal shines for a CRM system: Search. Of course there's Views, which allows you to build a set of filters to find things in your system. But what really gets me excited is applying a faceted search to your CRM results, which Apache Solr makes easy.
Customer access
If your CRM is done on your web site, is there value allowing your customers to access some subset of the data? For most businesses, the answer is probably not. But for many non-profits, associations, schools, etc. having a directory of members can be the single biggest reason to have a CRM, and allowing the public or members to access a directory of other members might be the single biggest reason to make your web site your primary CRM system. Because otherwise you've got that data island problem.
Data import
Most CRM systems have lead capture forms you can embed on your main web site. If your main web site is your CRM, this can be a regular form that feeds your system directly!
If you want to have a separate CRM system from your web site, Drupal actually poses some problems, because of its security features -- you cannot just embed a Drupal form on another site and have it work. One relatively straightforward way around this is the Mailhandler module -- set up an email box that receives your form, and Mailhandler will convert the form post into a lead in your system.
This is tremendously useful for interacting with the system, as well -- you can simply CC or BCC your CRM address to get an email into your system. You do need to script out what you want done with these emails, but it's a very easy way to get data into your shiny new Drupal CRM.
The Feeds module also makes it easy to import data from CSV and other kinds of files, a great way of getting your data there in the first place.
For more complex migrations, the Migrate is becoming the de-facto way of migrating data into Drupal.
Email templates
Here's a core CRM function that many businesses already do long before getting into some big CRM system: mail merges, newsletters, and boilerplate sales messages. All of these can be done in Drupal.
Mail merges are among the simplest things to do, once you have a directory in place. With Views, you can set up filters to find the people you want to email (you did create fields that will allow you to find the groups to email when you planned your directory, right?). You can either download a CSV of matching contacts and do a mail merge in Word, or if you learn the syntax of Drupal tokens, you can use Views Bulk Operations to send a mail merged email straight to your customers.
We like the Boilerplate module for creating canned messages we can easily send to a customer. Create the template emails in one place, then select that template when creating a new "email" activity, and edit to add the personal notes you've gleaned from talking with your prospect.
Newsletters get a bit trickier, mainly because sending bulk email can cause a lot of problems tagging you as a spammer. The easiest thing to do is use a mail service like Campaign Monitor, Mail Chimp, Constant Contact, or any of a number of other services. Many of these have integrations with Drupal, allowing subscription data to get attached to a user account.
If you want to do newsletters yourself, check out the SimpleNews module. We're exploring using Amazon's email service combined with this to eliminate that other data island of subscriptions in another mail service.
Workflow
So far we've discussed the fundamental building blocks of a CRM. Now we're getting to more advanced functionality -- automation.
Some things, like membership expirations, are extremely easy to add to a Drupal directory using Rules, Ubercart Roles, and similar systems.
For more advanced routing of sales leads, there are some really cool modules like Maestro.
We haven't (yet) had any workflow rules that needed something that sophisticated -- Rules and VBO are usually enough to script out most of what we want a system to do, perhaps combined with some custom actions.
Dashboards, Analytics
What's the first thing you see when you log into the CRM system? That's what everybody wants to know. It's really sexy to see a bunch of interactive pie charts, tree maps, bar and line graphs. But does that tell you what you need to do today?
Perhaps. Perhaps not.
Personally, I want a list of the activities I need to do next. That's the most critical thing. Having a chart outlining size and quantity of sales leads at various stages can also help determine where to spend time -- if the top of your funnel is small, you need more marketing to get more leads. If the bottom of your tunnel is small, you probably need to work on your sales process to get more of the leads from your initial contact down to actually becoming customers. And if you're losing customers, you had better look at your service.
These kinds of analytics are easy. Figure out the question, and we can probably give you a block to put on your dashboard that has up-to-date data at your fingertips, and the ability to drill-down to individual customers.
More mature platforms might offer more sophisticated analytics, help you answer questions like how many customers from New Orleans bought things from you in December 5 years ago, versus last year. You can get totally lost in data, slicing it up and using "Business Intelligence" tools to try to identify trends, types of customers, marketing activities that were successful, etc.
Why use another CRM?
In a future post, I'll go through some of the pain points of using Drupal for CRM. But I'm really struggling to see what value we could gain using another CRM system that would be worth the cost of yet another island of data.
"Business Intelligence" is one of those weaker areas -- still totally possible to do in Drupal, but using the tools to come up with these kinds of reports requires a better understanding of database functionality and possibly some programming ability to get your answers.
But this level of analytics to me seems counter-productive anyway, and a bit creepy. There's a problem with trying to predict the decisions and actions of an individual based on the actions of others. Patterns of volunteer activities might be similar across a group of volunteers, but that doesn't help you predict the engagement of an individual volunteer -- we are not numbers, we are human beings.
So my final thought on the matter, for now: Use CRM systems to help develop positive relationships with your contacts as individuals, not as faceless numbers. Analytics are not important -- results are. Use analytics as far as they help you identify your own failures, but no farther.
Add new comment