Checklist: When a Contact is marked as "deceased"

Here's a discussion question that came up in our internal company Chatter today:

"How do clients tend to handle the marking of a deceased patron in a household when things like the Account Name, Salutations, Address Names, etc need to get updated. Workflow off the checkbox?"

We started thinking about this, and decided that a hybrid approach is the best. There are a few things that should happen automatically right away if a Contact is marked as "deceased" -- like checking "Do Not Mail" box, and changing their Email Status to "Opt-out' -- but for other things like Account Name and Salutation changes at the household level, it's probably a better idea for a human to do the work, to make sure it's right and that it's handled sensitively.

Here's a terrible example that one of our coworkers shared about what can happen if you're not handling this well:

"My friend James' Mother passed away last year, and this was the letter he received in the mail. Not only is the letter wrong, but it's causing all sorts of confusion and he'll have to call them and get it all straightened out."

"dear james, we're sorry you're dead"

But, okay, does that mean you need to train your entire staff on how to make the correct changes to fields on a record when you're checking the "deceased" box? Maybe not -- it could be that the person finding out about the deceased-ness and marking the record isn't necessarily a person who needs to be super-trained on a whole cascading list of other things to do.

Instead, let's create a workflow that does those things we mentioned above, but that also creates a task or series of tasks for particular staff members to take care of the name fields, and perhaps send a condolence card, depending on the relationship to the deceased person.

Overall, the takeaway here is: When you're thinking about new workflows for your organization, consider the difference between automatic changes that can happen in the background versus things where you want an actual human to use their brain… but don't overlook the benefit of a reminder task for the latter! Create a list of the things that should happen, assign it to the right person, and you'll be in the clear.

"But I *HAVE* already given!" -- Targeting in Fundraising Campaigns

Have you ever gotten an email (or letter) that sounds like this?

"If you've already given, we thank you."

"please forgive this email"

These are both real emails that we've received from arts organizations in the last few years. We get what they're trying to do here… but it's really not working.

"IF" we've already given?! Why don't you know whether or not we've given? If I have in fact made a donation to your organization this year, now I feel like it was a waste of time -- you don't even know that it happened, so it couldn't have been that valuable. And if I haven't made a donation yet, you're already indicating to me that maybe I shouldn't bother.

The good news is that PatronManager/Salesforce makes it easy to run reports that let you avoid having to use this awkward phrasing.

Let's say you want to send out an email message to your entire list asking them to contribute to the year-end fundraising campaign, but you want to make sure to send an appropriate message to each of them.

For this example, we've identified four groups of people:

• People who have already given to this exact campaign.
• People who have donated at all within the last 2-3 months.
• People who are major donors or prospects who need a more careful/deliberate solicitation plan.
• Everyone else.

So how do we turn that into targeted solicitation lists?

Here's how we did it:

• Start from an Accounts & Contacts report
• Make sure it has the two obvious contact filters on it that we're always going to use for email campaigns: "Email not equal to [blank]" and "Email Status equals Confirmed Opt-In"
• Exclude people who have already given to this exact campaign -- add a cross filter for "Contacts without Donations, where Primary Campaign Source equals Year-End Campaign 2015"
• Exclude people who have given within the last 2 months add a cross filter for "Contacts without Donations where Close Date is greater than 9/1/2015)

This is what we have so far:

• The last filter we want to add is one that will exclude people who are major donors or prospects -- this piece is more likely to vary based on the specific practices of your organization. (You might filter on a "Major Donor" field on the Contact or Account object directly… or on a different campaign where you're collecting prospects… or on people who have given any donations of a certain high amount… or perhaps against WealthEngine data… and so on.)

Now that all those filters are in place, we have our "Everyone Else" group, and we're ready to send them our main general solicitation email for this campaign.

And the great part is that we've also made it easy to send a targeted message to each of the other three groups, if we feel it's appropriate. We'll just take one of those filters at a time, "flip" it to give us the opposite result, keep the other filters there… and probably add a new filter to exclude everyone we just sent to, for good measure.

Here's an example of what you might say to someone who already gave this year, but who you want to make sure is aware of the current campaign:

this is why

(You might even want to explicitly suggest that they tell their friends!)

Obviously this same concept works for print mailings, not just email (you'll just filter on mailing address information instead of the email fields).

And this whole concept holds true for ticket sales too, not just fundraising! In our experience, most organizations already usually try to follow this approach in their marketing efforts, running reports to exclude current ticket-holders from emails advertising that particular show -- so this is just an encouragement to think about your fundraising campaigns in the same way.

Contact records: When it's time to let go

Just by using PatronManager/Salesforce for a while, you're constantly accumulating data -- staff members are entering new records, patrons are buying or donating online, you probably imported records from your old system, etc. Cool! Data is good, right?

Well, not ALL data is good data. Maybe you're taking over from a predecessor at your organization but there was a while when there wasn't really anyone in the "gate keeper" role; maybe you had a lot of messy data in your old systems that didn't get addressed in the import process, and you need to do some cleanup now; maybe you're just noticing that your reports seems to include a lot of "cruft". There are some relatively simple steps you can take to clean things up and take out the trash.

First, decide what your "trash" is. This is probably going to be different for different organizations, but for us, there's at least one clear line to draw: do you have Contacts without actual contact information?

If you have no way of getting in touch with someone (by phone, by email, by postal mail… nothing), do they even really count as a Contact? First Name and Last Name are nice, but unless the person has the most obviously unique name in the world, you still have to be careful about "qualifying" that contact-less Contact to a possible dupe in the database (or the world), lest you end up creating a false history for them.

So here's what we'd do if we were feeling like "data hoarders" and needed to tidy things up a bit (spoiler alert: it's alllll about running reports):

1. Start by finding Contacts where Email and Phone and (any parts of) Mailing Address are all blank.

creating these took about 20 seconds

Then add a cross filter to see whether they've ever made donations or bought tickets (or any other interaction you track in your account). Maybe there's a piece of info on there to help you track them down? Or at least you'll know they're a real person in some way.

the most classic use case for cross filters

2. If they have no history? JUST DELETE THEM. They are un-contactable. You are never ever ever getting back together.

3. If they do have a history… well, you still can't contact them, right? We might consider re-parenting that history into an "anonymous" bucket account/contact because effectively, they are anonymous now.

4. From there, we might be done, but we might want to go a bit further, looking for people with an email address but no name, or that have a phone number but it's missing a digit (oops!), or that have parts of a mailing address but it's not complete... etc. Again, just figure out if there's any way to have a real relationship with those people if you try.

In the end, the whole point is to make sure that all of your Contacts are contact-able!

Who wouldn't we delete? We'll keep anyone that has real contact information, even if they're marked as opt-out or deceased or uninterested. That's good data! If you ever get data from another source, you don't want to accidentally re-import one of those "do not contact" folks without knowing you're not supposed to contact them.

Some of this clean-up will feel weird and bad because you're getting rid of people! But there is no benefit to keeping that data and there is no downside to getting rid of them. Be free!

Spring Cleaning: Contact record fields

We have a demo account that our sales team uses to show our prospects PatronManager. It's about five years old now and showing its age -- there's lots of weird historical data, and lots of accumulated one-off customizations that weren't ever really documented because it's not a "real" account. There have been lots of users over the years, all of whom have had System Admin privileges.

Our company and our sales team is growing, so it was time for a reset. Most of the accumulated mess hadn't been a day-to-day problem, because the old-timers on the team knew how to work around the things that were messy, but as we've hired new people, they've had to get started without the same benefit of experience.

So we decided it was time to create a brand-new account. We imported a bunch of more-realistic historical data in order to be able to do better demos of reports and dashboards, and then it was time to tackle the fields and page layouts.

And then we realized that the lessons we were learning and decisions we were making applied to other scenarios as well -- like, anyone who's inherited an older Salesforce or PatronManager account that hadn't been cleaned up in a while.

Here are the facts we were working with:

• There were lots of custom fields that were sometimes nonsensical (like "Dog Person or Cat Person?"), often duplicative ("VIP" vs. "VIP?"), and frequently one-time use only (like "My New Field," created on the fly to show how easy it is to create a field! ...and then left there to rot on the page layout).
• Page layouts varied wildly and without intention -- someone would occasionally pay a bit of attention to cleaning up or reorganizing the "Individual Account" layout, for example, without taking the same care with the "Household Account" layout.
• There were custom badges of all different color schemes and styles because they'd been created at different times by different people using Da Button Factory or something similar (which is a site we love, but stylistic consistency would be nice).
• Certain contact records looked okay because they were the ones that were used all the time -- they had all their fields populated with data that made some amount of logical sense for being a "real" person… but little attention had been paid to the vast majority of other records, so many were incomplete or obviously fake.

View fullsize

Peggy Olson's contact record, before.

In short, if this were a real client account, it would be impossible for people to get anything done, which made it a pretty terrible demo situation.

We needed to fix things.

Here's how we did it:

• We designed a whole new set of badges and did a serious audit about what they all meant and how their formulas should be written. The old account had one badge field for Major Donor and a whole different badge field for Lapsed Donor -- we combined those together and added in a few more options to make a single coherent Donor Status field.
  • There were also separate badge fields for "VIP" and "Notable Patron"... we decided that was too weirdly similar so we cut the Notable Patron badge (because our users, the sales team, said they preferred to keep the VIP one).
• We found and destroyed all the one-time use fields by running reports to see if the data was ever populated anywhere… mostly it totally wasn't, and if it was, the data was meaningless.
• We reorganized all the active page layouts to help keep things organized and easier to understand at a glance, in a demo situation.
  • We made a new section specifically for fundraising data.
  • We're using a mini-Visualforce page to show donation history, so we moved that to its own section, without a header.
  • We added "blank spaces" to sections that needed more balance.
  • And we made sure to think through these changes, not just focusing on the fields that exist right now, but to make sure there will be logical places to put new fields that might get added in the future.
• We checked our work both on the frequently-used records with complete data, and also on the records with less-complete data to make sure things didn't look super weird or confusing in either case.
• All of this was done in the new, yet-unused account, so we had lots of chances to communicate with the team and show them things and get approvals.

View fullsize

Peggy's contact record, after

---

Everything looks so much cleaner and more usable now! The badges communicate the most important information about a contact, and it's easy to tell where to look to find the thing you're looking for.

We did the data evaluation work "by hand" in this case, by running reports and using our eyeballs, but we've also recommended the Field Trip app to clients who are interested in evaluating their use of fields in a more sophisticated way.

We would follow pretty much the exact process if we were working in a "real" account, with one exception: instead of doing all this work live in production, it would be done in a sandbox instead and then deployed after getting approval. (Though actually we've found that for MINOR changes to layouts, we can work directly in production -- we'll create a new Layout, and use Page Layout Assignments to assign it only to the person doing the work, and getting approvals from other stakeholders by posting screenshots to Chatter.)