Again, a little peak at what I’ve been up to, reading, and thinking about. You can also see what I’ve been reading by looking at my shared items on my google profile.
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
Tomorrow morning, I’ll be leaving on a jet plane, to Atlanta, Georgia, for the 2010 Nonprofit Technology Conference. This will be my 7th NTC since 2001 (or, more accurately, my 5th. I went to two Circuit Rider Roundups.)
I’m looking forward to it. I’m speaking in two sessions: “Collaborative Problem Solving for Consultants” organized by Robert Weiner, and “Earth to Cloud” part of the fabulous Tech Track organized by Peter Campbell. I’m looking forward to the Unconference on Open Data organized by NetSquared, and getting to see lots of old colleagues. I’ll probably be using FourSquare to check in to places (I’m still experimenting with that one.)
Tagged as:
10ntc,
nptech,
nten
As most of you know, I’m a very long time veteran of web application building. I’ve been involved in web application development basically since they started – when a cgi-bin folder with some perl scripts to process simple forms was the norm. Until just a few years ago, there was very little sophistication about the user experience in web applications – what mattered most was functionality. and to make sure there weren’t too many errors when users did unexpected things.
I’ve considered myself pretty successful at both helping clients navigate the tough waters of web development projects, as well as accomplishing web projects for them. Recently, though, I had two projects that ended up, for wont of a better term, clusterfracks. And I’ve spent a lot of time lately trying to figure out what lessons I need to learn from those projects – what can I take away from them so I don’t make the same mistakes again. They were both custom web applications, both projects that I was a strategic, rather than engineering, partner on. Both projects were attempting to accomplish pretty sophisticated database functionality (such as case management). Functionality I knew how to get done, because I’d accomplished it before – so I had a very good feeling for what kind of code it would take to accomplish the task (and, ergo cost and time.) But what I hadn’t taken into consideration is how slick, AJAXy, easy to navigate, and easy to understand user interfaces people have gotten used to in the last few years. And, frankly, have come to expect. And how unwilling people are to sacrifice that for raw functionality.
I did a lot of self-examination: where did I go wrong? What could I have done differently? Was it the client? The developers? Me? I realized a fairly simple truth. It was all three. In reality, I should have looked at the budgets of those projects, and looked at the clients straight in the eye and said, “double, or triple the budget at least, or don’t do the project.” And walked away if they insisted. The vendors should have bid triple what they did, and had more user interface expertise on board. The clients should not have expected to get slick 2009 functionality for a mid 5-figure budget.
The easier a user interface is to use, the more money and time it took to create. It’s that simple. What most nonprofit decision makers don’t completely realize is that the interfaces they work in every day when they shop, or tweet and facebook, or use other online tools, are the product of millions and millions of dollars of venture capital, or, in some cases, hundreds of thousands of person hours of work in open source projects (or some combination of both.) Ground-up custom applications, even when written in great frameworks like Ruby on Rails or CakePHP, which save all sorts of development time, just are not going to have the user experience people are getting more and more used to without very serious investment of time and expertise. In addition, most small development shops don’t have the user interface expertise on hand to accomplish that task, even with a hefty budget.
So the lessons:
1) If you are embarking on a custom development project (such as a case management, for example) exhaust every possible option of using and customizing/modifying existing tools (Salesforce, CiviCRM, SugarCRM, other open source tools) before you begin to consider custom development from scratch.
2) If you have a budget of less than $100,000, go back, and stay, at step 1. I know this is high, but I’m serious. Obviously, simpler projects won’t need a budget of this sort. But simpler projects generally don’t need custom databases.
3) If you’ve got the cash to spend, and have exhausted all other options, when choosing a vendor, make sure the vendor you choose has UE expertise on hand. Look at other custom database work they’ve done. Dig in. Make sure it has the ease of user experience that you are expecting.
4) Remember the mantra: the easier it is to use, the more expensive it is to build.
Tagged as:
Consulting,
Development,
opensource,
user experience
The reason I post these is because 1) I think they might be helpful resources, and 2) you can get a feeling for what I’m working on, or thinking about (or wishing for.) For instance, the reason there are so many links about Amazon is that we are now beginning a project that uses amazon in earnest, with some others possibly on the way.
Although it’s not often used in nonprofit settings, the Drupal module (or, more correctly, a large suite of modules) called “Ubercart” is a pretty amazing tool if you need to create a shopping cart system. We’ve implemented it for organizations that want to sell fees for events, sell items, and take donations. It doesn’t have many of the strengths of CiviCRM, but it has a lot of useful features if you want to sell things, or combine selling things with taking donations, memberships and selling event tickets.
A while back, I’d heard of the Ubercore initiative – a group of developers working to bring Ubercart to Drupal 7 (there was quite a delay between the release of Drupal 6 and the availability of Ubercart for Drupal 6.) That initiative is now called “Drupal Commerce. (other site here.)” It is basically meant to be a rewrite of Ubercart for Drupal 7. It looks to be something to watch. Gregory Heller of CivicActions wrote an interesting conceptual piece on the integration of Drupal Commerce and CiviCRM that’s worth a read. (By the way, there is a module done by DharmaTech that integrates CiviCRM and the current Ubercart.)
Tagged as:
civicrm,
CMS,
drupal,
drupal7,
ubercart
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
One of the great things about the nonprofit technology field is the collection of nonprofit organizations that provide what is often called “Intermediary” services to other nonprofits: information and resources that help nonprofit organizations do the work they do in the world, by helping them make good technology decisions.
I’ve been involved in one way or another with a number of these intermediary organizations. One of them, Idealware, is an organization whose goal is to provide the sector with unbiased, analytically developed reviews and information about software that nonprofits use in their everyday work. This is incredibly important stuff, and it’s darned hard work – I know, I’ve been involved in doing a bit of research for Idealware.
If we don’t have this sort of research in our sector, nonprofits won’t have the kind of analytical approach to software available – it is much needed. As you might imagine, funding this sort of work doesn’t come easy – they need our help to be able to continue to provide great research.
Tagged as:
idealware,
nptech
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