So while I’ve been off twitter, I’ve had time to research social CRM (funny, that.) And what I’ve found is pretty interesting.
CRM stands for “Customer Relationship Management” (not to be confused with “Cause Related Marketing”- it came from the for-profit space. In the nonprofit world we use this acronym to mean “Constituent Relationship Management”, generally. From Wikipedia:
Customer relationship management is a broadly recognized, widely-implemented strategy for managing and nurturing a company’s interactions with clients and sales prospects. It involves using technology to organize, automate, and synchronize business processes—principally sales activities, but also those for marketing, customer service, and technical support. The overall goals are to find, attract, and win new clients, nurture and retain those the company already has, entice former clients back into the fold, and reduce the costs of marketing and client service.
Now we could easily translate that into “managing and nurturing an organizations’ interactions with donors and constituents.” and “overall goals are to find, attract and win new donors, nurture and retain those donors the organization already has, entice former donors back into the fold, and reduce the costs of fundraising.” (I’ve never been convinced that CRM and Donation management are very different beasts, even though many argue differently.)
Anyway, you all know this stuff, and know the tools we all use to do this – Salesforce, CiviCRM, Raiser’s Edge, etc. And these tools are great at doing CRM with the standard communications methods – email, phone, snail mail, in person contact. But what about social media as another form of communication? That was the question I cam to this issue with.
There are good arguments for why social media will radically change standard CRM practices. You should definitely read the report I mentioned in my earlier post. But in the Social CRM space, there seems to be a lot more attention paid to what I would call “metrics” - useful for attracting new donors, and understanding the “emotional state of conversations” rather than relationships that are trackable to “nurture and retain those donors the organization already has.”
I don’t mean to downplay metrics – metrics are hugely important – but I think mixing up metrics and CRM might make it harder to really do either well.
Example – in Jeremiah Owyang’s report, of the 18 use cases for Social CRM he uses, 7 or 8 of them are really use cases for metrics. Example “Social Campaign Tracking” and “Social Sales Insights.”
In this series, I’m going to talk a fair bit about both, although I’m going to lean more heavily on the CRM side of things than the Metrics side, since that’s more my bailiwick anyway. And I welcome any comments.
Tagged as:
CRM,
web2.0
It’s taken me a while to write this blog post, mostly because I have been working hard at various things (like building a business and building new websites.) This is the last installment in my CRM/CMS integration series, that started almost a year ago (wow!) And I’m skipping Joomla/Salesforce Integration because there isn’t any publicly available documentation or code about the integration that PICnet did with Joomla and Salesforce, called J!Salesforce. [update: see Ryan's comment below.]
So what is the state of Drupal/Salesforce Integration? It’s not as mature as the Plone/Salesforce integration, for sure, but it is coming along nicely. There are several contributed modules:
- salesforce – main module, with API, node, and user integration possibilities. This module provides the basic salesforce API connection (via SOAP), and includes field mapping, and basic import/export
- sf_webform – Makes integration with webforms in Drupal fairly easy. Web-to-lead is quite nice and flexible with this module.
- uc_salesforce – Provides integration with ubercart orders
- parser-salesforce – Integration with FeedAPI – pulling data from salesforce into drupal nodes via FeedAPI (I hope to start maintaining this module)
- sf_import – Import Salesforce objects into Drupal nodes (will be folded into the main salesforce module)
All of these modules are in alpha or beta, although I know for a fact that some of them (or versions of them) are working in production sites. There are a fair number of bugs that need to be fixed before there is a stable release. There are a bunch of outstanding issues that need a lot of work (like caching, for instance). There are two other modules that are related, but don’t use the main salesforce api module – one for ubercart, and one for web-to-lead (called salesforcewebform). That module has a stable release, but only provides the ability to integrate between Webforms and leads, not other objects.
Right now, the salesforce module allows for integration of contact, lead and campaign objects only. so that’s another big area that could use some work.
There is a good screencast done by one of the folks (Jeff Miccolis from Development Seed) who has worked a lot on this project.
I’d say that in a year, we’ll have a good solid module release, providing lots of features for integration between Drupal and Salesforce.com.
Tagged as:
CMS,
CRM,
drupal,
integration,
nptech,
salesforce
Yesterday, I spent the day in Manhattan, at the UNICEF building, with a bunch of folks passionate about the technology in mobile phones, and the ways to use that technology for good. I’ve been a very long time cell phone user (had one since 1998), but I haven’t been involved in implementing a mobile system for an organization, so I had a lot to learn.
The place to find reports on what happend is on the wiki. Also, check out the twitter stream for the #omc09 hashtag.
I was especially interested in the issue of mobile data collection. (I was so interested, I facilitated a session.) And, even more specifically, I’m interested in how to leverage CiviCRM and mobile devices for a range of interesting applications. There are a number of ways to get data from mobile phones into a CRM – and all have advantages and disadvantages, depending on a lot of things.
- Globally, what you can basically depend on is SMS. Smartphones haven’t made it into most of the developing world, nor have 3G networks. So how do you get SMS data into a database system like CiviCRM? You need an SMS gateway, and systems such as RapidSMS to gather data
- Use J2ME to write applications for mobile phones, and send the data via SMS to a central database.
- A tool such as EpiCollect, which is an Android app.
- A slimmed-down, simplified webform to be used on mobile browsers.
One thing that would facilitate this would be a more robust API system in CiviCRM – access to the data via REST or JSON, which would allow CiviCRM to talk with some of the tools out there like Mesh4X.
I learned a ton. Thanks to MobileActive.org and the Open Mobile Consortium for a fabulous event.
Tagged as:
civicrm,
CRM,
Mobile,
nptech,
opensource
Not so long ago, nonprofit organizations had software tools, that dealt with specific parts of their organizational process. They had fundraising tools, client management tools, volunteer management tools, HR tools, accounting tools, etc. And the data in these varied tools were siloed – there was no way for one tool to talk to another without:
- painstaking manual entry
- painstaking export/import processes
- tools written by the same vendor designed to talk to each other (which meant that they were generally exceedingly expensive)
Although many nonprofit organizations still find themselves in this situation, there are increasing numbers of tools available to help them out of it. And as more and more organizational processes become web-based (whether “in the cloud” or self-hosted), and as more and more nonprofit-focused software includes open APIs (with some unfortunate exceptions,) nonprofit data is looking less and less siloed, and more and more like an ecosystem – many different software parts talking to others.
NTEN is trying to get a bit of a handle on this with the Data Ecosystem Survey.
I’m very much looking forward to the result – looking to see where this new set of tools that can talk freely to each other is working … and where it isn’t – where there is still work to be done. Please take time to fill it out!
Tagged as:
CRM,
Data,
nptech,
nten,
openapi
I got to spend one day at CiviCRM developer camp this week. Unfortunately, it came after 4 long days of conferencing, after many exhausting days of work, so I wasn’t at my peak. But I learned a lot, and thought I’d share some of what I took away from that day.
First, the core team shared some of the new stuff coming out in version 2.3, and it is awe-some. One of the major reasons CiviCRM gets dinged as a CRM/DMS is that it doesn’t have reports. Well, that problem is about to go away with the release of CiviReport in 2.3. There will be a number of canned reports, and some really nice ways to create reports. Plus charts! Yay! There were some pie charts, and regular bar charts. I don’t have the new svn trunk of CiviCRM installed, otherwise, I’d show some screenshots, but it looked really nice. (I’ll be installing CiviCRM from svn in the next week, and I’ll probably blog more as 2.3 develops.)
There are some really nice usability improvements coming up in 2.3 as well – to make the basic contact pages much easier to navigate. And there is a new menu system, which will make things a lot easier. And, for Drupal users, some sweet Views 2 and CCK integration.
CiviEvent is getting waiting lists, registration approval, and user-modifiable registrations, and some other improvements.
The Alpha of 2.3 should be out by July.
I also learned about CiviCase, which is actually present in 2.2. I saw the example of it used for the Physician Health Program in Canada. It’s quite good, and there are some useful docs to see it at work on the CiviCRM wiki. I’d love to find an organization, such as a small human services organization, in need of case management software, that could use CiviCase – it would be a great, and relatively inexpensive alternative to current offerings out there. And more organizations using CiviCRM for case management would help CiviCase get even better.
I also dug into some of the internals and code of CiviCRM, and feel better equipped to start contributing more than ideas and feedback to the project.
Tagged as:
civicrm,
CRM,
nptech,
opensource
Third to last in my series on CMS and CRM integration (next up, Joomla and Salesforce, followed by Drupal and Salesforce) is using web forms.
I wanted to talk about this because it is arguably the most common form of “integration” between CRM and CMS that’s out there (besides the manual kind). You’ve got a CMS, and you’ve got a CRM somewhere else, and you need some way for data from users to make it to your CRM. Of course, it’s not really integration – there is no sharing of data between the CMS and the CRM in any useful way. But webforms can really help you get things done. Here are some examples of things I’ve done and seen done:
- A custom donation page that’s sitting on a service like Network for Good that is linked from the website, or framed within it
- The HTML for a “Web to Lead” form from Salesforce.com pasted into a CMS page
- The HTML for a event registration form or donation form that goes to a hosted service
In the first option, the form isn’t hosted at all on your site. In this option you have the least control over look and feel – the vendor controls the look and the behavior. An example of this I’ve run into is when an organization uses Blackbaud’s Raiser’s Edge, and wants to have online donations via NetSolutions, their older (and much cheaper) “integration” tool. They provide a page, which hooks directly into the users RE installation. But you can’t customize the page in any useful way, so if you’ve just designed a brand-spanking new site, this page is gonna look like crap. (Luckily, at least Network For Good’s donation pages look snappy and nice, but are going to look a lot different than your website.)
The other options are much better for look and feel – you can take the HTML, and, in most instances, style it to look like your site. You can even sometimes include Javascript for validation or other functionality. But this is still strictly one-way communication – the form data goes directly to the service (and does not pass go.) You don’t get any of it.
This is a great start to integration, if your budget doesn’t allow for true, deep, two-way integration between CRM and CMS. And it’s a great way to get your feet wet in thinking about what you might want to do with CRM and CMS. And, in some instances, depending on both CRM and CMS, it might be your only option.
Tagged as:
CMS,
CRM,
integration,
nptech
I have some exciting news. For the last few months, I have been working on a new collaboration called OpenIssue, which is a growing, diverse, self-reflective and constantly-learning team. We are focused on delivering quality web technology solutions to nonprofit organizations and social enterprises.
As you know, I have built a long-time expertise in open source software and web applications, particularly Content Management Systems (CMS) and online database systems, including CRM. Thomas Groden, my new business partner, has expertise in Software-as-a-Service Constituent Relationship Management Systems (CRM), as well as much more broad expertise in technology infrastructure.
All technology implementors have to choose their tools (unless they run a very large shop) and we have decided to focus on implementation of both Salesforce.com and CiviCRM as CRMs, and Drupal as a CMS. We are keenly interested in building on our expertise to integrate these open platforms in really rich ways, to allow organizations to create great online applications.
I’m excited to be a part of a team – I’ve been a soloist for a while, and it’s nice to build collaborations, and work together with people with shared ideals on larger projects than I’d be able to take on alone. And I’m really excited by the set of technologies we’re working on, and the kinds of applications we’ll be building with these technologies.
And you can follow us on twitter.
Tagged as:
civcrm,
CMS,
Consulting,
convio commonground,
CRM,
drupal,
nptech,
salesforce
Today, I was reading up on what the Plone community has done with integrating their CMS with Salesforce.com. I am thinking that this might be a good model for how we can do it with Drupal, but that’s a subject for another post.
(from Plone/SF Integration group)
There’s a good overview of the integration on the developerforce wiki. There are 5 components to the integration:
- a couple of toolkits that provide the basic back-and-forth between Plone and Salesforce.com (they talk to Python and Zope)
- an auth plug-in that allows for Salesforce.com objects to be Plone users, credential checking, caching of user data, and syncing of data from Salesforce.com and Plone
- an integration of PloneFormGen with Salesforce.com for web-to-lead forms, etc.
- an event management product that connects with Salesforce.com
- A PayPal integration product
This is a pretty robust set of channels for data to move back and forth from Salesforce.com to Plone. There is a Plone/Salesforce.com Integration group, that keeps working on this, and a number of organization, including ONE/Northwest, have invested huge amounts of time and resources to working on this integration.
This is, for sure, one of the most robust open source CMS to CRM integrations out there, and one that seems to be getting pretty close to providing very powerful integration “out-of-the-box” – instead of having to piece things together and do customized code, which is more common than not.
I haven’t gotten my hands on this to try (not being a Plone person, I doubt I will), but folks might want to talk in comments about how straightforward the integration is, given differences in data for different instances of Salesforce.com. I don’t know how much code tweaking is required to really get this going. But in any event, it’s great that it exists, and it’s a great benchmark for CMS/CRM integration.
Tagged as:
CMS,
CRM,
plone,
salesforce
This morning, I looked at both Salesforce.com, with the second nonprofit template, and CiviCRM with a small group of colleagues. All of us implement, or have used, one or both of the systems. But each of us has expertise in only one of the systems.(I’m one of the CiviCRM folks).
It’s pretty interesting to compare them. The nonprofit template has certainly helped to make it easier for nonprofits to do the brain surgery required to use a for-profit sales tool for nonprofit CRM purposes. Salesforce.com is, of course, much more sleek and polished. And the power behind the application is pretty unassailable. And, there is a huge ecosystem of add-ons available for Salesforce.com that doesn’t exist yet for CiviCRM. But there are significant modifications, both in the way nonprofits think about data, as well as the way data is manipulated, that have to take place in order for organizations to use Salesforce.com. CiviCRM is really intuitive for organizations to use out of the box.
Donation pages, and event registration are built in to CiviCRM, but have to be added into Salesforce.com. It’s way easier to create relationships in CiviCRM – you can create any kinds of relationships you want. Can create groups and smart groups easily in CiviCRM. This is harder in Salesforce.com, and smart groups don’t exist in Salesforce.com.
Anyway, there’s lots more, and you’ll be hearing lots more about both of these tools from me in the coming months.
Tagged as:
civicrm,
CRM,
nptech,
salesforce