Want to use Salesforce, but don’t follow a Business to Business sales structure?
Salesforce was originally designed to serve companies that sell to other companies, and the standard Account-Contact data model most easily serves a Business to Business (B2B) mindset. But that doesn’t mean that other types of businesses, as well as charities, governments and other not for profits, need to miss out.

There are some tricks to help organisations that focus more on individuals get the most out of Salesforce. Whether you focus on individuals for fundraising, sales, service delivery or marketing, accounts can be troublesome to deal with when really you only care about the contact record.

One way to address this is with the Non-Profit Success Pack (NPSP). Don’t be fooled by the name, there’s a whole bundle of great functionality in here and many businesses use some or all of the NPSP toolkit simply to change the focus of their Salesforce database from organisations (accounts) to individuals (contacts).

Are households required at all?
The NPSP introduces a data model that rebrands accounts as being either an organisation record, or a household record. Contacts are connected directly to a household record if they are part of that household, whether because they are a family unit or because they live together as housemates.

But do you always need a household record when dealing with individuals that aren’t related to a business? For example, job candidates without a current job probably don’t need households as there are unlikely to be multiple candidates in one household, and marketing doesn’t proceed in a way that needs to be conscious of other household members.

However, as soon as you start engaging multiple people at the same address, whether through marketing, fundraising or sales, households become necessary.

Household accounts or household custom object?
So the first question isn’t whether households or bucket accounts (where all contacts are connected to a generic, place-holder account called something like ‘Individuals’) are a better option, the question is whether households are needed at all. If they are, the choice is either to use a custom household object or use accounts to represent the household.

Early iterations of the NPSP used either a one to one (a shadow account automatically created for every contact record) or bucket account data model and used a custom object for households. This caused quite a few issues, the biggest probably being that very few apps on the AppExchange were flexible enough to support these data models.

Using accounts to represent households is much closer to a standard Salesforce account-contact model, opening up the AppExchange for organisations using the NPSP. It’s also much easier to administer as the user experience of individuals and households doesn’t hide the account object and pretend it doesn’t exist. It’s difficult to support users if the front end looks quite different from the back end.

Data management
One of the big benefits of having a household record is that it gives you a single place to update details of all members of a household. Obviously this means the address of the household, but it can also include home phone number, and other shared information. The NPSP also includes functionality for managing households that regularly spend significant amounts of time in different places, like a holiday home. Changing the address of four household members twice a year would quickly get tedious, but being able to manage this automatically through the household makes for cleaner, quicker processes.

It also ends up being better customer service. Donors and customers expect to tell you once that their address has changed; they do not want all members of the household to have to tell you about the change of address in order to stop mail going to the wrong place. You can also control the naming convention of communication sent to the household. Some families might want to be called simply ‘The Jones Family’ and some households might want to include their dog in their donation receipts (thanks to Lesley, Sam and Bonny the Wonder Dog for your donation!). The household naming functionality gives you the flexibility to cater for the more whimsical families you work with.

Many organisations also have security requirements to authenticate a caller before providing any information. Being able to easily see how individuals fit together in a household record can make this process simpler for everyone involved.

Data Analysis
Because the account-contact relationship is standard Salesforce, lots of data naturally rolls up to the household, like activity history. It can be very handy to see how often a household has been communicated with, for customer service and analytical reasons.

Apart from standard Salesforce rollups, the account-contact relationship also gives you the ability to roll up any other information you might find useful, such as total volunteering hours of all household members, total donations, and total fundraised.

NPSP functionality in general
The NPSP has plenty of additional functionality that makes the Household Account model attractive, including automatic naming of accounts, plenty of customisable roll-ups, and address automation. Definitely worth checking out the documentation to find out more:

https://powerofus.force.com/articles/Resource/NPSP-Documentation

So if you communicate with individuals independent of their workplaces or businesses, and it would be useful to be aware of who else is in the household, either for marketing, customer service or data management reasons, the NPSP household contact model is a very functional solution to managing customer-centric business models.