From the category archives:

CRM

Real Social CRM

by Pearlbear on May 24, 2011

So I do have social media ennui, but I am also somewhat of a data geek, and cool ways of moving social media data into one’s nonprofit data workflow is pretty important in my most humble opinion. This post on Social CRM is not going to contain one buzz phrase. It’s going to talk about one particular, interesting example of how to move social media data into a real live CRM -the one you might even be using now – Salesforce.

This example uses an app from the Salesforce AppExchange, called “Salesforce for Facebook and Twitter.” To make things just a tad confusing, this is also called “Salesforce for Social Media” and “Salesforce for Twitter.”

There are likely many more options, but this is one I’ve seen that is pretty cool, although it has its weak spots. It definitely is geared more toward the “Service Cloud” than the “Sales Cloud.”

You can set up multiple twitter and facebook accounts, and each facebook account can have access to multiple pages. It’s all done via OAuth, which is cool. Once you set up the accounts, you can then grab conversations:

You can filter and sort, just like records in any other SF object. You can choose whether or not to send Twitter or Facebook identities to Leads, Contacts, or Person Accounts. You can choose to create cases from tweets or FB posts as well.

You can tweet or post to facebook directly from Salesforce:

And it works:

You can schedule tweets and facebook posts as well.

There is a lot more you can do – it’s a pretty cool tool. The one thing I can’t seem to find – and I don’t know whether this is in development, or they won’t ever do it – is import your social graph into salesforce – your facebook fans or your twitter followers. I’m not sure why this is, exactly. It seems a big gap to me. But then, it is the folks who engage with you who you definitely want to make sure to keep track of.

Anyway, if you are a user of either Salesforce, the Nonprofit Starter Pack, or Convio Common Ground, this is definitely a tool to know about.

{ 2 comments }

Drupal/Salesforce Integration

by Pearlbear on March 23, 2011

A bit over a year ago, I wrote a post about the status of Drupal/Salesforce Integration. I figured it was time to do an update.

At the moment, if you want to integrate Drupal and Salesforce, you have three options:

  1. Use the contributed modules (or have a developer install and configure them for you).
  2. Use Jackson River’s Springboard.
  3. Roll your own (or have a developer roll your own for you.)

I’m going to talk in much detail about #1 in a bit. I’ve not had any experience with Springboard, but it’s important to understand that it is not open source, and is only maintained by one shop. That is going to be an inherent weakness – no matter what. I don’t know enough about it to match it to the contributed modules, but it’s hard to imagine that it’s possible for it to keep up, given the nature of open source development. All of that said, it’s supposed to be an interesting all-in-one sort of option, so it’s probably worth a look.

Rolling your own is always a precarious proposition. I frankly can’t imagine much of a situation where  it would be preferable to modifying what’s available and contributing the mods back.

So what is the status of the Drupal modules? Right now, there is an alpha release for Drupal 6, which is alpha in that very humble open source sense – it’s being used in quite a number of production sites. It includes some great stuff. You can see an overview here, in the slide deck for a talk given at NTC last week, which compares the integration of Salesforce with 3 of the big open source CMS platforms, Plone, Drupal, and Joomla.

There are four major projects:

  • Salesforce Suite, which includes:
    • The API – the core module that does the communicating with the Salesforce API
    • Contrib – a module that provides support for import/export from contributed modules
    • Export Queue (experimental) for queuing exports
    • Import – importing data from SF
    • Match – for matching objects before creating new ones
    • Node – for linking Drupal nodes to SF objects
    • Notifications (experimental, sort of – it’s worked quite well for me) – allowing Drupal to handle SF outbound messages
    • User – matching users to SF objects
  • Salesforce/Ubercart – provides integration for Ubercart. Uses the Salesforce Suite API
  • Salesforce Feeds – allows for feeding SF records into Drupal via Feeds. Also uses the Salesforce Suite API
  • Salesforce Webform – Allows for passing data from a Drupal Webform to Salesforce. Currently does not use the Salesforce Suite API, and cannot be used on the same site as the Salesforce Suite, but hopefully that will change soon.

All of these modules are actively maintained, there is an active base of folks using and contributing (including me) and there are plans afoot for Drupal 7, with big improvements. Of course, there are still some snaggy spots, and it helps if you know some about Salesforce to have this work really well, but I’ve gotten good results doing two-way sync of user and node data with the Salesforce Suite, as well as used the Salesforce Feeds module some.

If you use Salesforce, want integration, and are pondering a CMS choice, definitely check out the overview slides. If you are using Drupal, want integration, and considering a CRM, definitely consider Salesforce. And if you are already using both, and looking to find ways to integrate them, drop me a line, I can either directly help you, or point you in the direction of folks who can.

 

 

{ 2 comments }

Open Source vs. Proprietary: Nonprofit CRM

by Pearlbear on March 16, 2011

CRM systems (which I am defining rather loosely, rather than tightly, for the purpose of this post – as the tool or set of tools used to track constituents, donations, perhaps even events and volunteers) are arguably the most important technology tools that nonprofits use. Organizations use this tool to track donors, send out newsletters, track the success of campaigns, track who is engaged with the organization in what ways, etc.

And, in my experience over the past 15 years, it’s where organizations are willing to spend the most money on technology – often more than on their website or other technology tools – for good reason. Because of this, the deck has always been stacked against open source tools in this arena. The sheer number of vendors providing this toolset for nonprofits is huge (although rapidly shrinking.) Two of them (Convio and Blackbaud) are even publicly traded companies, which says a lot about the profit potential of this vertical.

On the proprietary side, there is a wide range of available tools, from the relatively inexpensive, like Salesforce (web-based, including Convio Common Ground and the Nonprofit Starter Pack,) eTapestry (web-based, now owned by Blackbaud), Democracy in Action, and GiftWorks (desktop) to the egregiously expensive (you know which ones I mean.) Both NTEN and Idealware are the best sources for information about the range of options for this toolset – that’s out of scope for this post.

As you can tell, I’ve lumped SaaS tools like Salesforce, DIA and eTapestry in with proprietary in this post – that’s because that’s what they are – proprietary. However, Salesforce in particular has a leg up that most other proprietary tools don’t have, because of their open APIs and their incredibly robust development platform. That combination is impossible to beat if you need integration, ease of data movement, and a lot of customization. From my perspective, open data (via open APIs) can sometimes be more important to consider than whether or not a tool is open source – since integration with other tools, as well as using external tools of various sorts is critical. Closed data systems, difficult to integrate systems, or systems that require payment to get access to your data should be avoided at all cost.

On the open source side, there are a number options: you can choose an open source CRM package (designed for business), like SugarCRM, and use it or customize it for use in a nonprofit, use CiviCRM, or choose the desktop-based nonprofit CRM called MPX (built by a company called Orange Leap.) I’m excited about a new Drupal project called “Red Hen CRM” but it’s very fledgeling.

CiviCRM is a web-based open source nonprofit-focused CRM/Donation management tool. It’s been around for a while now, and is used by many organizations, some quite large (like the Wikimedia Foundation.) It is quite broad in its feature set – it has donation pages, event management, e-newsletter functionality, even a case-management system. I’ve installed, configured and administered CiviCRM many times, still work with it, and I have, like most developers, a love/hate relationship with it:

  • I love that it’s open source/free software
  • It’s got a great community of developers and users
  • I love that it’s feature rich – you cannot find the whole set of things it does in any proprietary tool that I’ve seen.
  • It is a tool that has unmatched cost-effectiveness for small organizations
  • It’s great that it integrates with both Drupal and Joomla (although the Drupal integration is by far the most solid – and it is a very nice integration – hard to get with proprietary tools.)
  • It is relatively easy to set up for most functionality

But …

  • Data migration into CiviCRM is often nightmarish (this is really where the hate lies)
  • Reporting tools are improving, but don’t match the proprietary versions
  • It can sometimes be pretty tough to handle complex issues
  • It can be tough to troubleshoot issues

MPX is a desktop tool, and although it is open source (GPLv3,) unlike CiviCRM, or SugarCRM, it is built on top of a proprietary stack (.Net/MS SQL Server.) It has primarily been used in faith-based organizations (that is Orange Leap’s primary client base.) But it’s a very full featured product, and quite mature.

So if you are a small organization that perhaps is still working with spreadsheets, CiviCRM is a great idea to check out. But in general, there are a lot choices and, sadly, few of them are open source.

 

{ 6 comments }

Salesforce as a CMS?

by Pearlbear on September 22, 2010

Salesforce is a very powerful platform onto which one can build a large variety of interesting kinds of custom applications. I’ve already talked on this blog about Salesforce integration with Drupal, Plone, and others. Today I’m going to delve into Salesforce-based CMS systems – systems built as applications on top of the Force.com platform.

First, what are the advantages and disadvantages of this approach? The disadvantage is that primarily, Salesforce was not designed as a CMS – it was designed as a Salesforce automation and customer service tool. It has become a powerful platform, and there is a lot you can do with it – but it was never designed with content or visual design in mind.

What are the advantages? If you’re running database applications (tracking donations, events, programs, clients) and want deep integration between your web content and your data, it is an approach that is hard to beat. Certainly CMS/CRM integrations can go a long way – but ultimately, using Salesforce as your CMS platform will provide a kind of power that is not easily replicable using an integration. But with that power, may come some sacrifices.

What are the options for doing CMS-like things on the Force.com platform?

  • The native capability of something called “Sites” – which is a publicly facing version of what’s called “VisualForce” – a markup language that includes HTML as well as APEX code (Force.com coding language). This requires a lot of custom code, and becomes unwieldy when you get to more than a few pages unless you write a mini-CMS yourself to handle things as a site gets more complex. But there is a lot there.
  • CMSForce – This is an “open source” (in quotes because although you can get the source code, do what you’d like with it, and contribute to the project, because it’s written on a proprietary platform, it’s not really open source.) I’ve spent quite a bit of time with this one, and more to come, I’m sure – like any open source project, there is a lot that could be done to make it more usable. But it certainly is something to evaluate, and contribute to, if you find it useful. It is written by Force.com Labs, so it’s got serious Force.com developers behind it.
  • OrchestraCMS – This is a paid app – with discounts for nonprofit organizations. I’ve taken just a test drive, but it’s pretty impressive – it has it’s own UI, and is well developed. There were a few hiccups in getting going, but I suspect it was because I only spent a little time with it. A partner we work with has done a lot of work with this application, and we’re pretty interested in it.

There are a couple of others, and I’m sure more in development. Salesforce has a rich enough data model and development platform to sustain a solid CMS – the big question is – is this the right fit in terms of integration? Salesforce-based content management is embryonic in comparison to CMS systems such as Drupal or Plone (or even WordPress for that matter) but being able to draw data directly in and out of salesforce very easily, for some organizations running Salesforce, might well be worth it.

And, it’s also possible to have one’s main site in a solid CMS, and instead of using complex integrations, have a mini-site with the same look and feel based in Salesforce, for the data needs you have. Again, it depends on what your use cases are, but that’s another way to go.

{ 6 comments }

Does Social Media Work?

by Pearlbear on September 13, 2010

I know for many of you this is old news. But since I’m not on twitter anymore, and I don’t read my RSS feeds as often as I should.

In July, Idealware published the Nonprofit Social Media Decision Guide. It’s great – chock full of good information, and some very, very interesting research. One of the most interesting tidbits of data to me was the large gap between people who “thought” social media of varied types either helped them reach new audiences, or helped them raise money, and those that really “knew” this was the case.

And further, the largest change was just an increase in website traffic (20%).  A very close second was substantive feedback and discussions (21%), and a relatively close third was to attract new members or volunteers (16%).

There are some great worksheets to help you figure out what strategies to use, and how to move forward in this space. And there is, to my mind, a lot of fodder for thought and conversation among folks thinking about  how to really measure success in social media, as well as those of us thinking about SocialCRM:  how to best capture that data – whether it be engagement metrics, or actual constituent information.

{ 1 comment }

Last 10 delicious.com links

by Pearlbear on June 21, 2010

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.

{ 1 comment }

Social CRM, part 2: Metrics vs. CRM

by Pearlbear on April 29, 2010

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.

{ 2 comments }

Social CRM, part 1

by Pearlbear on April 11, 2010

This blog series is all Beth Kanter’s fault. We (the two partners of OpenIssue) shared a cab from the Atlanta airport to the hotel when we arrived for the 2010 Nonprofit Technology Conference. We were chatting with her about what kind of work we do, and she asked “do you do social CRM?” She might not have seen the blank stares on our faces since we were in a dark cab, but I’m sure she heard the pregnant, confused silence.

As you know, I don’t blog much about social media. I use it all the time, but there are much better sources of good information on that – I’ve been sticking to writing what I know best. But I have to admit, this idea of social CRM piqued my interest. More than that. The truth is, if @kanter asks me about something that is related to social media, it must be important, so I’d better figure it out. And, of course, I’m at least a year behind the curve on this – there has been a lot going on in this space, although, frankly, in my research so far, I haven’t found a lot in the technology sphere that would immediately be helpful to nonprofits (especially small to medium-sized ones.) There’s some, and I’ll talk about that in the next posts in this series.

Beth pointed us in the direction of Jeremiah Owyang, who I’d been reading a little for a while, but had lost track of, since I don’t follow the social media space carefully. He has a great post on the use cases for Social CRM. It’s a really solid post, with an information-packed report attached, as well as some resources. This is a bit high level for me – my job in life is generally to make use cases real using technology. I’m hoping that someone (hint, hint) will write the blog post or report taking off on this work, and articulate the major nonprofit use cases for Social CRM. The report does include some technologies to look at, and I’ll be delving into those in future posts.

I’m going to take a little chunk off of this, though, and ask some leading questions. And then, I’ll do my best over the course of the next few weeks to answer how these would get accomplished via the technological tools that most nonprofits use  or can get access to.

  1. How do you know which of your Facebook fans/Causes members are also a donors (separate from donations through Causes)?
  2. How do you know how many of your twitter followers are also donors?
  3. How do you know what percentage of your donors or constituents are on social media at all (twitter, facebook, myspace, linkedin?)
  4. Can you follow the trail from tweet (or facebook status) to a donation? A tweet to a specific action (like a petition?)

If you’ve got more questions you’d like to see me address, or you’ve got some examples of how your nonprofit has answered these questions, please feel free to comment on this post.

{ 2 comments }

Drupal and Salesforce

by Pearlbear on December 31, 2009

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.

{ 10 comments }

Open Mobile Camp report

by Pearlbear on October 25, 2009

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.

{ 3 comments }