From the category archives:

Data

When data gets political

by Pearlbear on July 27, 2010

Most days, data is pretty straightforward to us here at OpenIssue headquarters. Names, addresses, email addresses, the pesky notes field (today’s bane of our existence.) But sometimes, data is political. Or, I guess more accurately, data models.

In most CRM systems, especially older ones, and ones that are less flexible, some fields can be points of contention for some of us. Gender is one, marital status is another.

CiviCRM, to it’s credit, allows for an arbitrary number of genders – you can define them however you like. My bet (although I could be wrong) is that it’s one of the few out there that allow that. Gender is not a standard field in Salesforce.com contact records, so if you want to add your own, you can customize it however you’d like. There was a very interesting and lively discussion about the gender field in Drupal profiles. Of course, one can always customize these things in Drupal.

For a couple of projects we’ve been working on, we’ve been getting very interested in putting together a really expanded and fleshed out data model for gender, sexual orientation, and marital status. Here’s the first draft. We’d love feedback on this (besides “this is silly/too radical/dangerous/from the antichrist/etc.”). And we also know that even for those who agree that sex and gender are different things, people will differ on how to divide these categories and make sense of it.

  • Sex: Male, Female, FTM, MTF, Intersex
  • Gender: Male, Female, Genderqueer
  • Sexuality: Gay, Lesbian, Bisexual, Queer, Questioning, Straight
  • Marital Status: Straight Marriage, MA, DC, IA, VT Domestic, CA-SF 2004, CA 2008, Canada
  • Relationship Status: Single, Partnered, Divorced, Dating, Poly  (There probably could be some field dependencies of Marital Status on Relationship Status)

And if you maybe thought that OpenIssue headquarters was in San Francisco, I’m sure this list made you sure. (Yes, we are.)

Tagged as:

{ 13 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.

Tagged as: , , , ,

{ 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.

Tagged as: , , , , ,

{ 10 comments }

CRM & CMS integration: Web pages and forms

by Pearlbear on April 15, 2009

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: , , ,

{ 2 comments }

CRM&CMS Integration: Blackbaud Raiser’s Edge and NetCommunity

by Pearlbear on February 13, 2009

What? She’s talking about Blackbaud?

Yes, it might be surprising, but I got a friendly email from fellow NTEN Board Member Steve McLaughlin, who also happens to be head of all things internet (more formally, Director, Internet Solutions) at Blackbaud. He gave me a demo and overview of their NetCommunity tool, which has been around for a while, and I figured it deserved a blog entry. It is, in fact, a great example of integration of a CMS and a CRM. Originally, I wasn’t going to cover the one vendor solutions, like this because, I believed (and, honestly, I still do) that you’re not going to get as powerful a CMS as you can as the best-in-breed CMS tools. However, it is true that Raiser’s Edge, the CRM/DMS tool that this integrates with, is inarguably one of the most important tools out there. Some call it the gold-standard. For many other CRM/DMS vendors, it’s the red spot at the center of the dartboard in their office.

The demo was pretty cool. But you know me, I fall for shiny, especially when it comes to data. The integration between the web front end and the RE back end is bi-directional and sweet. There were a lot of things you could do, including accept donations, track personal donation pages, and the like. and a lot of different ways to track what your donors and constituents did, both online and off, and have those show up in really interesting ways. It is, in many ways, the kind of CRM/CMS integration that lots of organizations want and need. Organizations can get this package in three different ways: On premises – installed inside the firewall, hosted, or SaaS. Their SaaS offering is called “NC Grow”, which provides sets of fairly simple CMS templates to start with, designed for organizations that, in their words, “are ready to reap the benefits of richer online marketing and communications, but may not have the resources or expertise in place to make such a website come to life”

The big kicker, pretty much as always with Blackbaud, is the price tag. There is a $10K license fee that you have to pay if you use the On premise or hosted versions. Expect a $35-45K price tag for development and integration. Their SaaS offering, NC Grow has a $20K/year price tag. This all is, of course, above and beyond the megabucks you’re already paying for Rasier’s Edge.

I didn’t get a very close look at the CMS (I’m wishing in retrospect that I had), but the little bit I did see of it suggested to me that it was somewhat more limited than CMS systems such as Drupal or Plone. Even if, perchance, it’s not, you still don’t get the vibrant community of developers making cool modules and add-ons to do just about anything you can imagine – you’ll have to either wait for Blackbaud to do it, or, perhaps (I’m not even sure if this is possible, but correct me if I’m wrong in comments) have someone custom develop special custom features for you. And, you’ll have an automatic $10K price tag tacked on that you won’t pay with the open source tools. I have a hard time believing that that translates to $10K worth of feature value (one could argue it’s $10K worth of integration value, though, but I’m not sure about that.)

Bottom line: If you are an organization which has Raiser’s Edge, and is committed to keeping it, and you want to do sophisticated integration between it and a web front end, then NetCommunity is probably your best solution. But before you jump in, make sure that the CMS is going to have the sophistication and power you need. And know that because RE doesn’t have open APIs, you are unlikely to be able to create the kind of sophisticated integrations with a different CMS that NetCommunity provides with RE.

But, if you are not a RE user, or are considering migrating off of RE, I don’t think that the combination of RE and NC is especially cost-effective. You can get this level of integration with Drupal/CiviCRM for sure, and likely Plone/Salesforce, and Drupal/Salesforce (with a bit more work.) More on those later.

Tagged as: , , , ,

{ 28 comments }

CiviCRM and Drupal (& Joomla)

by Pearlbear on January 26, 2009

CiviCRM was the first nonprofit-focused open source CRM (one of only two, at this moment.) It is a great tool for small to medium-sized organizations who are looking for a CRM to track members and donations, register people for events, and do mass mailings. There are also some other features, like grants management and case management that are more nascent, but promising for the future. I’ve implemented CiviCRM together with Drupal, and I’m really psyched to keep working with this great combo.

CiviCRM originally only integrated with Drupal, but recently a lot of work has been done to also integrate CiviCRM with Joomla. CiviCRM acts in Drupal like a module, and in Joomla like a component. This means that since the code sits in the same exact place,  and the databases could even be shared (or not, it’s your choice) in effect, CiviCRM is becoming part of your CMS. You install CiviCRM inside your CMS installation directory, and the CMS and CiviCRM talk to each other through PHP APIs (or “hooks”) (there are some examples of database calls across the CMS/CRM). There isn’t much work to be done by you, or by the person who implements it for you, unless you want to do customizations, and expose CRM data in new and interesting ways. Users in your CMS installation will become users in CiviCRM when you install it, and be synched going forward. You can set up web forms (for donations, event registration, etc.) and have them be menu items. It’s a very straightforward integration.

Using CiviCRM and Drupal is a great way to easily get powerful integration between your CMS and your CRM. They are both installable on pretty standard shared-hosting accounts (although shell access really helps.) It’s a really cost-effective way to get powerful features. The disadvantage of this is that you have to choose CiviCRM and Drupal (note on Joomla below).  Both have their disadvantages, and you might have a variety of reasons for not choosing one of them. Jon Stahl, in his comments on my first post in this series said: “a PHP API accessible only to other PHP apps on the same machine is simply not sufficient integration in an age of web services, where people run different apps on different machines and use languages other than PHP for building web apps.” I do agree with Jon to some extent. I do know that CiviCRM has been working on their web services APIs, but a really strong set of them would mean that people could integrate CiviCRM with more CMS, which , from my perspective, would be a Really Good Thing. That said, I do think that this combo would be a cost-effective solution for good chunks of the nonprofit community.

Note: My understanding is that there are still some snags with the CiviCRM/Joomla integration, and I’m not very familiar with it. If you already have a Joomla site (or you are about to choose Joomla) and you want to use CiviCRM, you should talk to the CiviCRM-Joomla folks, or check out the CiviCRM forums. One example: since Joomla doesn’t have granular ACLs (Access Control Lists) there must be issues with how permissions work in terms of access to specific parts of CiviCRM. If you have detailed info, please feel free to share in the comments.

Tagged as: , , , ,

{ 3 comments }

Eating my own dogfood. It sometimes tastes yucky.

by Pearlbear on July 9, 2007

So I talk a lot about both open source software, and the preciousness of one’s own data. I rail against vendors who promote lock-in. I tout the benefits of open source software. So, here is a real life example of someone with a measly 195 records in her contacts database.

As you might recall, I migrated from a Mac desktop to a Linux desktop a month and a half ago.  There are still some, shall we say, hanging chads. One big one was my address book. I used to have this great system where I used the Mac Addressbook, which would nicely sync with my cell phone. It also integrated well with Mail.app and iChat. It was great.

First problem: Linux address books … suck. I hate to be so blunt, but it is true, at least in comparison to the ones on the Mac. There are basically three options. 1) Since I’m using Thunderbird as my email client, I could use that as my addressbook. Except… it sucks. Really it does. Not enough fields, not a good ui. Ick.  2) KAddressBook. It’s not as bad as Thunderbird, except, of course, it doesn’t integrate with Thunderbird. It’s just a bit more polished. More configuration, more options, but still not good. 3) Evolution. It would mean switching my email. It might be worth it. But the last time I tried Evolution, it was a horrible experience. But, that was 4 years ago. Open source projects do get better.

Actually there is a fourth option. I could dump all my addresses into one big flat file, and use grep. Right. Errr. NOT.

So my next task is to really try out evolution, and see how it works for me. I’ll keep you posted.

But, there is more…

In order to use one of these address book options, I have to get my data out of Apple’s addressbook. Turns out, there’s no "export" menu item. Yeah, talk about lock-in! There is, luckily, a handy-dandy tool that will do it for you. Otherwise, you have to either write your own, or, worse, hand enter all those addresses again.

<Insert sound of Michelle chewing on Purina Dog Chow.>

{ 3 comments }