gokubi.com

Volunteer events are outreach activities. The goal is to further the mission by getting donations of time from constituents. Another goal is to engage constituents in the work the organization is doing. You get the donation of work from the volunteer, and you also get to interact with them, and deepen the value of the relationship for both parties.

In trying to model volunteer events in Salesforce.com, the best match for this type of activity is the Campaign object. It allows you to track interactions with people, some of which will attend the event. It also rolls up all the donations that result from the event. Those donations can be volunteer hours, and cash donations.

There are a couple drawbacks to modeling volunteer events this way. You can store a lot of information about the event, but you can’t store custom information about the act of attending. You basically get a Status field, and that’s it. If you have complex volunteer roles, or other data you must capture, this probably will be lacking for you.

The other big drawback is that it’s not easy to turn volunteer event attendance into donations of time. After you have the event, you don’t want to have to hand create Opportunities for each attendee. This, it turns out, is a really easy problem to solve using a custom S-Control (of course).

With this S-Control as a custom link off of a Campaign, you can one-click create volunteer hour Opportunities for all members of a volunteer Campaign. The volunteer hours reside in Salesforce.com as Opportunities, which is what they are–donations to your organization. You can easily report on volunteer hours together separate from all the other donations that come to your organization. Here’s a look at a sample report:

You can also look at volunteer hours in combination with all other donations to your organization, and get a single picture of a constituent’s contribution to your org:

Think about the end-of-year thank you letter you could crank out with this data in a Word mail merge…

I’m up to my neck in process right now. I’ve spent 6 hours talking with a customer about how they work. Donor management, membership, volunteer trips, a film festival, and retail sales. They work with govenment agencies, other nonprofits, grant makers, and corporate sponsors. Needless to say I’m a bit overwhelmed.

What I’m trying to do is take in all they can tell me about what they do, ask as many questions as possible to elicit more information, and capture all the detail. After I’ve sucked the life out of them, I take all that info home for analysis.

Analysis consists of taking those processes and figuring out the best way to support them with technology, in this case Salesforce.com. What data tables do I have to work with? How can I string them together into a workflow that matches how the customer works? Where can a little bit of custom code get around holes in the technology support of the process?

It’s mind-numbing, and also really fun. It’s all about understanding two sets of constraints, the customer’s needs and the technology’s limitations, and bringing those together in a good design. Like doing a 3 dimensional puzzle…

In the next couple days I’ll share some work I did today to get Salesforce.com to support volunteer events, in this case land cleanup. I’m pretty psyched because it’s coming together pretty tightly.

In September I took my organization through a process to migrate from ebase (a filemaker pro database) to Salesforce.com for CRM. Much like Dr. Jeckyll, we thought it a good idea to experiment on ourselves. Unlike with Dr. Jeckyll, it did not end badly.
We have been using Salesforce.com for over two months now. I’ll talk about using Salesforce.com and how it’s changing the way we work in a later post. In this post, I’ll run through the general steps of the process I took us through in our move to Salesforce.com.

1. Process Reivew Meetings
   1. We talked a lot about what currently stunk about the way we did CRM, what the ideal would be, and what unintended consequences might come out of it.
   2. I spent 6 hours with key staff here to understand how they work. Once their process for working was laid out, I could then identify the data and workflow necessary to support that.
   3. We identified necessary reports, and sources of data that we should bring into CRM.
2. Customization
   1. I went off with this information and decided how to modify the application to support the identified processes.
   2. I created custom fields, built some custom objects (data tables), set up permissions, and created some custom code to make data entry easier.
   3. I set up the reports we needed. We didn’t have many reports because we had really been limited in our reporting ability by ebase. I’ll be creating more reports as we get used to being able to create them!
3. Data Migration
   1. I got to spend lots and lots of time with ebase and filemaker. Real fun. I recommend it.
   2. I got our data out of ebase and into Salesforce.com in the right format
4. Integration
   1. We didn’t integrate into any outside systems in this first project.
5. Training
   1. I worked with key staff and showed them how to use Salesforce.com to do their work.
   2. We skimped a little on this because I sit in the office and can answer training questions on short notice…
6. Launch
7. Follow Up
   1. Since our launch I’ve been adding new fields, changing page layouts, changing permissions, creating reports, and giving training.
   2. I also have had to do some data cleaning because of mistakes I made during the data migration process

Overall the process worked pretty well. I have to get better at being exhaustive in the requirements gathering because I won’t have the luxury of walking across the hall to ask for more info. And my clients won’t be as forgiving as we are, because as we like to say, we have a very high pain tollerance when it comes to technology.

I learned a lot during this work, and have made a lot of changes. I’m now testing the process on two real-world projects. I’ve fully disclosed that I’m not really sure what the heck I’m doing here, and they’re game. I’ll let you know how it goes.

I’ve talked a lot about the great features of Salesforce.com, but every software choice has drawbacks. You know someone who thinks one software platform is the one to solve all your problems, doesn’t have any major drawbacks, and can wash and wax your car, 100% guaranteed (this is not a guarantee)? Turn and run.

Here are the top 5 drawbacks I see in using Salesforce.com as a nonprofit. You , not me, you have to decide if they outweigh the benefits for you.

5. Salesforce.com is lacking some key functionality

• It doesn’t do households well–there’s not a great way to say that a couple lives together and send one thank you letter to them for the total amount the two of them have donated.
• It can’t do complex reporting like, “show me everyone who signed up for our newsletter and showed up for our volunteer event last month.”

4. The USA PATRIOT Act sucks

• The US Government can compell a hosting service like Salesforce.com to show them your data if they decide you are a terrorist. Salesforce.com can’t tell you about it.
• You really need another point here? That’s not bad enough?

3. You are reliant on the Internet to get to your CRM data

• You have to be online to use Salesforce.com’s full functionality

2. You’re too big

• Salesforce.com is more than happy to donate 10 licenses (you need one for each named user) to qualifying nonprofits, but if you want more than 10 licenses you may or may not get them

1. Getting Rent Donated has its own risks

• Salesforce.com is a service not software, so you don’t buy, you rent.
• Donated rent is great, but if the donation stops you either have to find the money to pay the rent or find another place to live. Moving on short notice is never fun.

So there’s the dirt, the secrets you don’t learn until after you’ve signed the deal. Hopefully it will help you make a good decision for your nonprofit.

Last night I was reading Natural Capitalism, a great book about the future of industry and design. I highly recommend it to anyone building or buying anything–that’s everyone, by the way. On page 100, there’s this great quote from Stewart Brand:

Every building is a forecast. Every forecast is wrong.

As we design technology and human systems to meet our current needs, if we’re not thinking about how those needs will change we’re doomed to fail. Needs absolutely will change, and the things we’ve built will be asked to meet those new needs. They’ll do it gracefully or kicking and screaming, depending on how we designed the original system.

When you’re choosing and customizing a technology system to meet your needs today, consider how hard it will be to modify it to meet your needs tomorrow. Be kind to the person who someday will be tweaking your system to meet new needs–it may be you.

I’ve talked about how we’ve decided my job is to implement CRM, not create databases. What we’re trying to do is help groups make the shift to “customer centric” relationships–focusing on the value they provide for their constituents, and thereby increasing the value of that relationship for both parties. We think CRM can be the technology support groups need to make this change, and lack of good CRM is one of the main reasons groups are doing this more effectively right now.

To papaphrase the president, CRM is hard work. It’s hard because for it to be helpful it has to very closely match the way you work. What often happens with CRM is that it doesn’t support the way you sign up volunteers, or it doesn’t let you manage mebership renewals–it doesn’t support you in the way you work. And if it doesn’t support you in the way you work, you’re either going to stop using it, or hate working with it. Either way, CRM has failed.

I’m currently working with my first customer to understand how they work so I can design the CRM to meet their needs. I just had a two hour conversation with them about:

1. What currently sucks with their database, and with the way they work?
2. If there were no limits, how would they want CRM to change the way they work?
3. What unintended negative consequences could using CRM gring about?
4. What measureable things will we look to in the future to determine if CRM is in fact helping?

The weird thing is, we both had fun going through these points. It was somewhat cathartic for them to tell me all the stinks with the way they work now, lifing the weight of small chunks of time lost to repetitive process added up over months. And I can’t get enough of raw process inputs into my crazed, analytic head, constantly fitting them to patterns I know that exist in the technology, and thinking of new things to invent to solve new problems. But it was fun, and after I spend a few hours analyzing the results, we’ll be back at it again for a few more hours getting more in depth about how they handle major donors and memberships from start to finish. The great thing is that after this process not only will we have a better shot at making CRM successful, they’ll better understand the way they currently work, and will be more able to change because of that.

In Salesforce.com, you can create an Opportunity by clicking the “New” button on the Contact’s Opportunity related list. You are taken to a blank Opportunity form, and when you save it a Contact Role is set for that Contact. There are a few suboptimal things about the process:

I have to pick the correct record type

We have multiple Opportunity record types, so I have to go in and select Gift each time I create a new Opportunity

The Opportunity name is blank

We have a standard naming convention for Opportunities. Steve Andersen 2005 Donation is how a gift from me would look. We have to type that in every time we create a new Opportunity

The Contact Role is blank when the Opportunity is created

We use Contact Roles for acknowledgement on the gift. If I make a donation, I’m set as the Donor role. When we report, we can total up all the Opportunities on which a Contact was a Donor, and that’s their total giving. We have other Roles, like Soft Credit, that we use for thanking folks, but not giving the same credit as Donor. Because the system sets the Role to blank, I have to go in and change that after I save the Opportunity.

So, I created an S-Control and installed it as a Custom Link on the Contact page layout. When I want to create a new Opportunity, I click that Custom Link. An Opportunity is created with the correct name based on my naming convention, and the Contact Role is set correctly. I land on the edit page for this new Opportunity, and I can change anything that I need to.

There are no custom fields necessary to use this S-Control, all you have to do is change the record type id in the S-Control code to match the id you want to use for gifts. Install the S-Control in a similar fashion to what I showed in the earlier walk-through, but create a new Custom Link under Customize | Contact instead of a Web Tab. Whiz-bang easy…

As I’ve been writing, Salesforce.com is being used as CRM in the nonprofit setting. It’s a flexible platform that can be molded to meet nonprofit business practices pretty well. But there is one major underlying architecture issue that causes some problems:

Salesforce.com is designed to support relationship development between businesses, not between businesses and people. To use current lingo, Salesforce.com is B2B (business to business) not B2C (business to consumer).

To get Salesforce.com to work for nonprofits, who cultivate individual donors, members, and volunteers in the B2C model, we have to use one of two work arounds:

Pretend each individual in the database is a company

For each individual in Salesforce.com, you create a company with the same name. In Salesforce.com you interact with the company, which is really the individual

Benefits:

• B2B is what Salesforce.com does best, so you can leverage all the power of the system
• This is the likely direction that Salesforce.com will go to address this problem in future releases
• Might be able to handle householding by using existing account hierarchy functionality

Drawbacks:

• Double data entry for every individual
• Each individual can only be connected to one company, so if you associate an individual with their own company, you can’t associate them with a real company, like their employer
• Hard to do things like soft credits and memorials

Create a bogus company where all your individuals reside

One fake company called “Individual” is created. Every individual donor is associated with that company.

Benefits:

• Flexibility to associate users with employer
• Easy to do soft credits and memorials

Drawbacks:

• You miss out on some of the features that rely on accounts
• Have to use custom objects to do householding
• You can end up with a bazillion individuals in that one account

I’ve chosen to roll out my org in the second model primarily because we do a lot of work with nonprofits in the B2B model in addition to our B2C work. I think most nonprofits fit into this hybrid model: every group I’ve seen gets grants from foundations. That’s a pretty clear B2B process.

This is definitely my least favorite current work around in Salesforce.com. So, I’m going to try to spend some more time looking at the first scenario, and see if there aren’t some relatively easy customizations I could build to eliminate the data entry problem.

I did a screen capture walk-through of using the process and S-Control I created for online donation importing into Salesforce.com.

We’re experimenting with this technology as a way to do trainings and best-practices work. As my first attempt, this is pretty unpolished, but gets the point across. Take a look and let me know what you think!

[Update]

Here is a screen capture walking through the steps to get this up and running in your Salesforce.com instance.

As I mentioned yesterday, I’ve been working on an AJAX S-Control to import online donations into Salesforce.com. Well, version 0.1b of the Online Donation Importer is ready for sharing. But before we get to the S-Control, let me talk a bit about the overall process I came up with for importing online donations.

Nonprofits that want to take online donations can subscribe to services that authorize credit card donations via the web, and then transfer the funds to the nonprofit’s bank account. Small nonprofits aren’t in the position to build this type of functionality themselves, so most rent it from providers like PayPal, Auctionpay, or Network for Good.

What the nonoprofit gets from these services is money in the bank (hopefully) and a comma separated values (CSV) file of their donations. What to do with that CSV is where a lot of groups get stuck. Hand transfering that data to a donor management system is common. Problem is that many donor management systems aren’t very good at importing data like this. Others have explicit import routines for some online donors, that may cost money, or may not support the service that the nonprofit wants to use.

I wanted to try to create a process that could import data from any online donation provider to Salesforce.com. Since I work with smaller nonprofits, I was OK with some manual steps. If the donor was new, I wanted to create a new Contact and associate the online donation Opportunity with that Contact. If the donor already existed as a Contact, I didn’t want to create a new one.

Here’s what I came up with–I import the online donations as a special Lead type, and then find all the Contacts in Salesforce.com that are potential matches. The user then decides if the new donor is really one already in Salesforce.com, or a should be a new Contact.

Here are the steps:

1. CSV of donations is dowloaded from online donation service
2. LeadRecordType and Status fields with appropriate values are added to each line of the CSV
3. CSV is imported to Leads via Sforce Data Loader
4. Online Donations tab (an S-Control web tab) allows User to pick from a list of suggested matches for each Lead, or choose to create a new Contact
5. Opportunity is created and Contact is created if necessary. Opportunity is correctly associated with Contact

Here’s what the S-Control does:

1. The S-Control lists all the Leads of the online donation Record Type. When a Lead is selected by the user, the code searches for Contacts that share the email address with the lead.
2. If none are found, it searches for Contacts with the same last name.
3. It then presents the list of potential matches with an option to create a new contact.
4. The user chooses from this list.
5. If the User chooses to create a new Contact, one is created with a default account.
6. An Opportunity is then created for the donation. The values of close date and amount are set correctly, the Opportunity is related to the Account of the Contact, and the OpportunityContactRole for the Contact is set to Donor. The Opportunity is marked as Closed Won.
7. The User is presented with links to the Contact and Opportunity

It’s a semi-manual process, but because of the inherent fuzzy matching here, I don’t think it’s a process that can be fully automated. But, it could save a decent amount of data entry.

Take a look at the code, it’s fairly well commented, and would be easy to extend with new fields, different attempts at matching to Contacts, etc. Feel free to use it, and if you do I’ d love to hear about it.