My team and I build database applications for business users and, like many in the field, this means that I have spent a lot of my career taking risks and making mistakes. Mistakes and failures are great if you choose to take them as learning opportunities. But, it is really hard for me when long-held assumptions are challenged.
I’ve recently undergone a shift in how I think about business application development. This change has developed while working on several projects at the Salesforce Foundation, such as finding better ways to get sales contracts signed. Here is what it boils down to:
Users > Business Goals > Technology
Unknowingly, I’ve spent a rather long time operating with that scenario reversed in my head, most likely because I am a technologist. It is far easier for me to take the stance that technology is more important than the end user’s experience.
The faulty logic goes something like this:
- End Users of enterprise applications work for a business, so they must be in service of the business.
- The business has goals that they would like technology to assist them with, so they must adopt the technology that best meets their needs.
- Therefore, end users must learn to use the technology to help the business achieve it’s goals, regardless of how painful that experience might be.
Put another way:
End users should be in service of the application, working hard and taking any necessary steps to use it properly.
This mentality is ingrained in techie culture. Just look at the nicknames for “User Errors” in wikipedia:
- PEBCAK (“Problem Exists Between Chair and Keyboard”)
- PICNIC (“Problem In Chair Not In Computer”)
- ID-10T error (“Idiot error”)
Harsh! Instead of shouldering the burden of not providing a user experience that is intuitive and easy to use, we just blame (and poke fun at!) Users for not knowing the proper way to wave a dead chicken.
The solution, then, often leads to finding ways to prevent Users from using the app improperly. Not to pick on Salesforce Validation Rules, they can be put to good use, but they are a great example of this line of thinking. Validation Rules are put in place to prevent Users from putting bad data into the database, or force a certain pattern of behavior. When you violate a Validation Rule, you are prevented from completing your task and get a glaring error on your page letting you know just how wrong you are. No one likes being told they are wrong. There is an emotional component in play that is too often overlooked. My personal reaction is usually frustration trending toward anger if the error message doesn’t tell me how to correct the mistake. This is not the reaction I want users to have.
I think a better approach is incenting your Users to use the app the right way. A slight distinction, but this small shift in mentality can go a long way toward delighting Users. Make your app so delightful to use, so intuitive, that the rules are implied and require less intrusive enforcement.
Applications should be in service of the end user, making it easy for them to complete tasks and delivering a delightful experience.
User experience comes first. If users of your app aren’t delighted, then they aren’t getting what they need out of your application. Which probably also means they aren’t giving you or the business what you need out of the application. If people don’t or won’t use your app, technical perfection is meaningless.
This concept is all over the consumer product world, but doesn’t feel like the prevailing methodology in the enterprise business application development world.
While user experience is paramount, we must also meet business goals and maintain great data. We shouldn’t have to make a choice between proper data architecture, meeting the needs of the business, and a great user experience. So, application development teams must find ways to accomplish all of these goals.
Great applications deliver an experience that simultaneously makes the end user, the business, and the database happy.
It seems obvious to me when said that way but, admittedly, it was not how I was operating (nor, I suspect, a number of other individuals and teams building database applications).
You can’t meet business needs alone, or deliver great user experiences alone. You can’t have one without the other because, individually, they fall short of the overall goal. No matter how much value or emphasis we place on user experience, if your database is not working properly or your application is not meeting the most basic needs of your business then a great user experience is meaningless. Conversely, If you pay no attention to user experience, then the Users of your app spend their day frustrated when using your app and are most likely trying to find ways to do their work without using the application, which renders the application meaningless.
Anyone that has purchased licenses from the Salesforce Foundation has experienced, first-hand, what imbalance looks like. The contract signing process isn’t exactly frictionless, it goes something like this:
- Foundation Account Executive (AE) emails a pdf of a contract to customer
- Customer receives email
- Customer prints attached Contract
- Customer signs printed Contract
- Customer scans signed Contract
- Customer emails pdf of signed Contract back to AE
- AE receives email
- AE downloads email to local hard drive
- AE navigates to the Contract in Salesforce
- AE uploads signed contract pdf as attachment
- AE updates the database record to send it for provisioning.
This process works and, on paper, it meets the needs of the business. The Foundation can donate and discount Salesforce licenses for customers, we end up with a signed contract, and customers get their licenses provisioned. But, it’s a notoriously long process in need of an improved user experience for both the AE and the customer.
Trying to balance user experience with business goals is a great problem to be solving for, because it means your app isn’t failing. If your current app is failing, you don’t have time or energy to spend on improving the user experience. As co-conspirator Kevin Bromer put it:
Is User Experience a Right or a Privilege?
We agree that there is merit to both but, in reality, it is a privilege. You can do work and use applications in the absence of a decent User Experience (as proven by our contract signing process). And, while it has taken me a while to get here, I also believe that:
If you and your team want to be in the business of delivering great applications you must treat User Experience as a right.
If we revisit the previous example while bringing the user experience into balance with business needs, the process might look something more like this.
- Foundation Account Executive (AE) emails a link to customer
- Customer receives email and clicks link
- Customer can view the contract and optionally download a pdf
- Customer clicks “I agree” to e-sign the contract
- The database is instantly updated with a digitally signed pdf attachment and is automatically sent for provisioning
We are still meeting the needs of the business, but we are also providing a much better user experience both for the customer and for the Account Executive. It saves time for everyone involved and is more in line with our customer’s expectations for this type of transaction. This is a real feature that we have in pilot at the Salesforce Foundation thanks to some killer work and investment of time from Evan Callahan to make it happen.
Delighting Users, whether your internal business users or your customers, requires putting the user experience first in business application design. It must be in balance with the needs of the business so that work is getting done properly. By providing great experiences in business applications, users have positive emotional responses to their experiences because the application makes their lives and tasks easier rather than being a hurdle to accomplishing a task. In turn, this increases usage of the application which serves the needs of the business.
When you are doing it right, in addition to having an application that works well and meets all the requirements, you get rewarded by someone letting you know that you’ve delighted them with a great experience.
One of the recurring questions in the Salesforce for nonprofits world is about how we handle money and enter Donations/Opportunities to best track donations, grants, etc. Here, I’ll outline how I handle common scenarios in the Non Profit Starter Pack (NPSP), and how it affects the donor rollup totals. You can find more about the NPSP at http://www.nonprofitstarterpack.org.
First, let’s cover some of the basics of Salesforce and the NPSP so that we are using common terms:
Opportunity/Donation: This is the core “revenue” object in Salesforce. Many organizations rename the Opportunity object “Donation” since that is more familiar terminology. These terms can be used interchangeably.
Account/Organization: Salesforce started long ago with a business to business bias. Because of that history, this is the core object in Salesforce and is central to Salesforce functionality. It is often used to represent Corporations, Nonprofits, Government Agencies, Foundations, etc. Many organizations rename the Account object “Organization”, these terms can be used interchangeably.
***Because the Account object is central to Salesforce functionality we must have an Account for every individual Contact, even when we are indifferent to their employer. See “Account Model” below for more information about how the NPSP makes it easy to handle this requirement.
Contacts: Contacts are people; donors, board members, program participants, volunteers, constituents, etc. This requires little explanation, except to note that for Salesforce to function properly each Contact belongs to an Account.
Account Model: The NPSP has 2 “Account Models” for dealing with individuals, One-to-One and Individual Bucket. You can find more detailed information on NPSP Account Models here. The steps below work in either model.
Opportunity Contact Role: This object lets you connect many Contacts to an Opportunity to identify who influenced a gift. Examples are Donor, Household Member, Solicitor, Honoree, etc. There can only be one Contact Role marked “Primary”. Contact Roles are in a related list on the Opportunity.
Opportunity Account: There is one Account per Opportunity, whether an Organization or an Individual.
Opportunity Rollups: This is an NPSP feature that aggregates Opportunities to Accounts, Contacts, and Households to give metrics like “Total Gifts”, etc. Account rollups are based on the Opportunity Account, Contact rollups are based on the Primary Contact Role, and Households rollups are an aggregate of the Contacts in that Household.
This is a very high-level overview of the topics needed for the following discussion. You can read more about these features at https://salesforcefoundation.screenstepslive.com/s/npsp.
OK, on to the fun stuff!
Before we dig into the 3 scenarios below, I want to mention that your organization might do or define things differently than I am talking about them here. These are not static definitions, but I am trying to use some common scenarios as examples within a larger framework.
1. An Individual Contribution
This is what I would call the most common fundraising scenario. An individual person is giving you a donation from their own personal funds and will be taking the tax deduction on their income tax filings.
- Account: Either the appropriate One-to-One or Individual Bucket Account, depending on your model.
- Primary Opportunity Contact Role: The individual donor’s Contact record.
- Opportunity Contact Roles: Any other Contacts that played a role in this Opportunity, typically Household Members. Think of these as “soft credits”.
In general, the Account tells us who the “legal” giver is, which is an individual in this case. The one-to-one model will tell you specifically which individual, where the Individual Bucket model will tell you only that it is an Individual and you must refer to the Primary Contact Role to find the legal giver.
The Primary Contact Role determines which Contact will get this Donation rolled up to their giving totals. This would be desired in almost every individual giver scenario.
Additional Contact Roles are mostly informative for our records. When we look at a specific Donation, we can see exactly who played a role in this contribution. Additionally, when we look at the related list for Opportunities on a Contact Record we see all Opportunities that they played any role in.
2. A Corporate/Foundation Grant
This is another common giving scenario. This is a gift from a non-individual entity, although there are usually individuals involved in the process of getting the funds.
- Account: The Account that represents the Corporation/Foundation
- Primary Opportunity Contact Role: Usually the primary person you worked with to get this grant, but depends on your NPSP settings (see below).
- Opportunity Contact Roles: Contacts that played a role in this Opportunity, typically employees of the giving Foundation.
In this case, the Account is very straightforward, it is simply the organization that is giving the funds. These funds will rollup to the Account’s giving totals.
The Primary Contact Role is usually your point of contact at the organization making the grant. By default, because the gift is not from a one-to-one or Individual bucket account, this gift will not roll up to the Primary Contact.
- ***However, if you have “Always Rollup to Primary Contact” enabled in your NPSP settings, then this gift will be included in the Primary Contact’s totals. You do not need to mark a Contact as Primary if this setting is enabled and you do not want it included in any Contact’s totals.
The non-primary Opportunity Contact Roles are the people that influenced this grant. Typical roles here are Solicitor, Grants Manager, etc.
3. A Matching Gift
This is a bit more complex of a situation, and can depend on how your nonprofit tracks these types of gifts.
- Account: The Account that represents the matching company.
- Primary Opportunity Contact Role: Typically, the original donor that submitted the gift to their employer for a match.
- Opportunity Contact Roles: Other individuals involved in the match, the person at the company that fulfills matching gifts.
The account again is straightforward, the legal giver in this case is the company making the match.
The Primary Contact Role can behave in one of two ways. By default, as in scenario 2 above, the matching gift amount would not get rolled up to the Contact that made the original donation. However, some organizations like to include this in their donor totals. To do this, enable the “Always Rollup to Primary Contact” box in the NPSP settings tab. Be mindful that this will affect all Opportunities, and could change how you handle scenario #2.
The other Opportunity Contact Roles can be used to indicate who you worked with at the matching company to process the matching request.
Now that we’ve looked at a few specific examples, let’s talk about this in general terms so that we have a framework to deal with other giving cases.
- Account: Because there is only one Account per Opportunity, this is generally the “legal” giver whether a company/foundation/individual.
- **Note that if you use the Individual Bucket model, you must refer to the Primary Contact Role to find the “legal” giver when the Opportunity Account is the Individual Bucket Account.
- Primary Opportunity Contact Role: This is the most important Contact, usually an individual donor.
- **By default, this Contact gets the gift amount included in their rollup totals only when the gift is legally from an individual.
- ** You can change the “Always Rollup to Primary Contact” setting to change the default behavior.
- Opportunity Contact Roles: “Soft credits.” Other individuals involved in the donation where you want to see the donation on their Contact record but not in their donation totals.
This is just a primer, and not meant to cover every possible scenario. There are many legitimate ways to configure the NPSP and enter donations, but hopefully this will help you develop a framework for how you’d like to handle donations at your organization. As always, if you feel I’ve totally botched something (which is very likely), please let me know!
Happy New Year!
Salesforce recently dropped the release notes for Spring ’12 and there are several features in there that should be useful for nonprofits. Here are some of my favorites.
- Analytics Edition – this is a paid add-on (not sure about the pricing at this point), but something that every nonprofit needs to seriously consider purchasing. Joined Reports, Bucket Reporting, and Cross-Filtering (i.e. – Contacts WITHOUT Donations) each provide great value to nonprofits when reporting on their data.
- Chatter Now – Instant Messaging right inside Salesforce!
- Chatter Customer Groups – This is a big one. It’s already available, but is going to be turned on by default with Spring ’12, so start thinking about how you’ll want to use it. This is great for creating private Chatter groups for volunteers, board members, etc.
- Social Accounts and Contacts – Keep up to date with your constituents. Let’s you see their Facebook, Twitter, YouTube, Klout, and LinkedIn (for an additional fee) profiles right on the Contact page. Even if you aren’t big on social media, this let’s you add a picture to your Contacts which is great for the development team.
- Cross-object Workflow on standard objects – Finally.
- Workflow Field Updates can fire another Workflow rule – This is pretty cool, allows you to “cascade” workflow field updates.
- Cloud Flow designer GA – Killer new tool for nonprofits. Dead simple drag-and-drop creation of “wizards”. For all the orgs out there that have wanted a custom Donation entry wizard but didn’t have the resources to build one, this is your chance! Also great for creating online forms (volunteer signup, RSVP for an event, human services applications, etc.) since you can add a flow to a public Sites page with literally one line of code.
- Up to 3 filters on Filtered Dashboards – This is a HUGE improvement that allows orgs to consume and analyze relevant data in an elegant way (and will make creating dashboards much easier, not to mention that you’ll need fewer of them). Dashboards are underutilized in general, and even more so by nonprofits. I would strongly encourage admins out there to invest time in building at least one filtered dashboard for your organization.
There is a bunch of great stuff in this release for developers too, but I just wanted to call out some things that will be useful for nonprofits that don’t have developer resources. Let me know your favorites!
The thoughts behind this post came up when a colleague of mine pointed me to an “ngo-in-a-box” collection of software and my negative reaction to the Linux operating system and software that needed to be installed and configured (who has time to deal with all of that?). Then, I realized that I live in a bubble where high-speed access is ubiquitous and I can afford it. This is hardly the case in places where the world’s poorest live (like Sudan).
Even then, in my experience working in Sudan, cloud computing with limited access is more efficient for communication and getting things done than desktop software.
If cloud computing is the next big thing for nonprofits, and I truly believe that it is, then we need ISPs to step up and donate or severely discount service to nonprofits. With access to high-speed internet and donations/discounts from Google Apps and Salesforce, we remove all technological barriers to running an efficient and transparent org.
Salesforce and Google have defined corporate philanthropy for technology companies, and enjoy great admiration for their efforts. We need Comcast, et al. to step up and contribute. Massive corporations can help solve massive problems with little in the way of lost revenue and no new infrastructure requirements.
Of course, the natural extension of this is that access, at this point, should arguably be a human right. Internet access is the new gatekeeper – it holds the keys to a level playing field and all people should have the ability to open doors for themselves.
We’ll table that discussion for another day, and pick the low hanging fruit. Nonprofits are working hard to change the world for the better. They deserve to have free high-speed internet access, where it is available, at no cost. (Yes, even the ones fighting service providers for net neutrality.)
I want to give credit and thanks to mobilecitizen.org which has teamed with Clear to provide wireless broadband to education and nonprofits at a significantly reduced cost. Kudos!
If you know of any other ISPs that are providing nonprofits with free or discounted access please leave a comment!
Something that is important to HELPSudan and many of the nonprofits I work with is the ability to segment donors by their giving history. I wrote a formula that will categorize Households based on the donation rollups in the new Households package in the NPSP. I thought I’d share for anyone that would find it useful.
IF( npo02__OppAmountThisYear__c > 0, "Current Donor",
IF( npo02__OppAmountLastYear__c > 0, "LYBUNT",
IF( npo02__OppAmount2YearsAgo__c > 0, "SYBUNT (2 years ago)",
IF( npo02__TotalOppAmount__c > 0, "SYBUNT (Lapsed)", "Non Donor"))))
It can easily be modified to show different or additional statuses based on criteria relevant to your organization, or added to Accounts or Contacts as well. Once you have the formula set up, create a summary report and summarize by your new status formula field. Then, you can build a pie or funnel chart to show you how your donors break down.
One other thing… if you’ve ever wanted to know how much someone has given this year relative to this time last year, the formula is simple though not necessarily intuitive.
npo02__OppAmountLastNDays__c - npo02__OppAmountLastYear__c
You could then run reports on donors whose status is “Current Donor” from the first formula, and has a negative value from the second formula (i.e. – they’ve given less money at this time this year than at this time last year). Now, you’ve identified people that are recently engaged in giving and are likely able to give again right now! Salesforce.com formulas, reports, and dashboards are a great way to turn our existing data into actionable items.
The formulas in this post should work via copy/paste with the latest version of the Householding package for the Non Profit Starter Pack.
I hope that a couple organizations find these useful!
As Salesforce.com grows and their licensing structure and offerings change, it can be hard to keep up with what licenses give you what features. (Note to Salesforce: Please don’t become like Microsoft with your licensing. Simpler is better.)
What often gets overlooked are the free or cheaper Salesforce.com licenses. I’ve used them for a couple things recently, so figured I’d share. Prices listed are based on prices listed at Salesforce.com today. They are subject to change and if you’re a nonprofit you can likely get a discount via the Salesforce.com Foundation.
Chatter Free (free)
Not much to say about this one. If you have people at your company that aren’t Salesforce.com Users, you can give them a Chatter Free license to allow them to participate in your social network. If you’re not yet on Salesforce.com, you can sign up for free at Chatter.com. I’ve not done much with these yet, but I know some people have set it up for their family domain.
Force.com Free (free)
Salesforce.com was shouting from the rooftops about these licenses at Dreamforce 2009, yet they remain somewhat of a secret. You can get 100 Force.com Free licenses either in a new org or added to your existing org by contacting your Account Rep. Here’s what you get.
- Up to 100 users
- 1 free application
- Up to 10 database objects
- 1GB of storage
So, what can you do with this? The best thing I’ve seen so far is a brewery app that tracks the brewing process from ingredients in the door through bottling, and even generates the regulatory documents in a VF page.
Right now, I’m building an app based on Coherence to track whether what an organization thinks they are is in line with what they say they are or what people are saying about them. The app can track data from many sources and then generates a score to show how Coherent an organization is.
You also get Chatter with these licenses so even if you don’t want to build an app, you could import and Chatter about some of your existing data as well as use Salesforce.com analytics.
Chatter Plus ($15/month/User)
I discovered these before Chatter Free was around, and there are a couple key things you get with Chatter Plus that make them actually pretty useful.
- Accounts (read-only)
- Contacts (read-only)
- 10 custom objects
- 1 custom app
- Calendar and events
- Tasks and activities
As you can see, you start to get a nice set of features for a completely reasonable price (especially if you are a nonprofit). One of the biggest differences here, that you don’t get with Force.com Free, is access to the Calendar and Events.
We recently used this with a client to bring artists they contract to perform, into their Salesforce instance. Artist bookings are tracked in custom objects and the contracts are generated by Conga Composer. The contracts are then attached to the Artist’s Contact record via Chatter and approved/denied by the artist with a Chatter comment. (The security model ensures that artists only see their own contracts). The Salesforce Calendar is used by the org to track artists and resources needed at performances, and artists can see their upcoming schedule. Additionally, artists can now collaborate with the org and each other via Chatter groups.
We took a process that existed entirely outside of Salesforce and involved manually generating contracts, sending them via email, waiting for a response via email, not having a central place to track approved/rejected contracts, and managing event resources in a bad web app… and brought it all into Salesforce for a minimal license fee per artist. In addition, tons of value was added to that process by building a community within the organization that includes the artists they work with every day.
As always, I’d love to hear your thoughts and if/how you’ve used these types of licenses.