The NGO's Salesforce Adoption Playbook.

Getting the ten free Salesforce licenses is the easy part. Most NGOs that qualify never get past a blank org, because nobody told them what to do next. A fresh Salesforce instance is not a system. It is an empty warehouse with very good shelving. This playbook is the plan for filling it: what to build, what to leave out, how to move your existing records in without carrying the mess with them, and how to get your team using it every day inside three months.

It is written for a small organisation. Say five to twenty staff, one person who will own the system, and a few thousand records currently living in Google Sheets and paper. If that is you, you do not need a consultant and you do not need to spend anything on setup. You need a short, honest sequence, and the discipline to build less than you think you need. Everything below is what we do with the NGOs we set up, in the order we do it.

What this playbook assumes

You have already been approved for the Salesforce Power of Us programme and have your ten free Enterprise licenses. If you have not, start with the Salesforce tool guide on this site, which walks through eligibility and the application. Come back here once your org is live and you can log in.

It also assumes one named person will own the system. Not a committee. One person, with a few hours a week, who decides what goes in and keeps it tidy. Call them the systems owner. Every NGO that succeeds with Salesforce has one. Every NGO that abandons it split the responsibility across everyone, which means nobody.

Week zero: decide before you build

Before you create a single field, answer three questions on one page. Who are the people you track, and what do you call them. What is the one activity you most need to prove to a funder. And what does a good week look like in numbers. Your whole system is an answer to those three questions, so write the answers down first. Most NGOs skip this and end up building fields they never fill.

A youth-training NGO might answer: we track trainees and the organisations we place them with; we most need to prove placements and completions; a good week is five new trainees enrolled and two placed. That is enough to design the whole thing. Resist the urge to also track volunteers, donors, events, alumni, and inventory in week zero. You can add any of those later in an afternoon. Adding them now is how you end up with forty empty fields and a team that finds the system confusing.

Choosing your data model

Salesforce gives nonprofits two starting points, and the choice trips people up because both are free and both are called "nonprofit". Keep it simple.

Nonprofit Cloud is the current, Salesforce-built package for nonprofits and the one new orgs are steered toward. The older Nonprofit Success Pack (NPSP) is still widely used and has years of community documentation behind it, which matters when you are learning by searching for answers. For a brand-new small NGO in 2026, either works. If your org was provisioned with one already installed, use that and do not migrate. If you have a genuine choice, pick Nonprofit Cloud for a fresh build and keep NPSP in mind only if most of the tutorials you find online assume it.

The one decision that actually matters is the Household or account model, and the default is fine. A person is a Contact. The organisation they belong to is an Account. That is the backbone. Do not fight it, do not invent your own structure on top of it, and do not turn people into Accounts because it feels tidier. Contacts are people, Accounts are organisations, and every report you will ever run depends on that line staying clean.

The objects a small NGO actually needs

You will see dozens of objects in the menu. A small NGO needs five to start, and can ignore the rest until a real need appears.

• →Contacts: every individual you work with. Trainees, beneficiaries, partner staff, applicants. One person, one Contact record, forever.
• →Accounts: the organisations. Partner NGOs, placement hosts, funders, your own organisation. A Contact links to the Account they belong to.
• →Your core activity object: the one thing your programme produces. Placements, enrolments, cases, distributions, whatever it is for you. This is usually a custom object and it is the heart of your system.
• →Campaigns or Program Engagements: how you group people into a cohort, an intake, or an outreach. This is what lets you say "the March 2026 cohort" and get a number back.
• →Tasks and Events: the follow-ups. A call to make, a form to collect, a visit to log. Cheap to use, and the thing that keeps records from going stale.

That is it. Five objects will carry a small NGO for a year or more. When you genuinely outgrow them, adding a sixth takes an afternoon. Building all twelve on day one takes a month and teaches your team that Salesforce is complicated.

Migrating your spreadsheets without importing the mess

Your data is in Google Sheets and on paper. The instinct is to dump all of it into Salesforce as fast as possible. Do not. A migration is the one chance you get to clean your data, and importing the mess just moves the mess to a more expensive place.

Work one sheet at a time. For each, delete the columns you have not used in a year, fix the obvious duplicates, and standardise the values that should match but do not, for example "Complete", "complete", and "completed" that all mean the same status. Split full names into first and last if your sheet keeps them in one column, because Salesforce wants them separate. Then, and only then, map each column to a Salesforce field and import with the Data Import Wizard, which is built in and free. Import Accounts first, then Contacts, then your activity records, because each layer references the one before it. A Contact needs its Account to exist first, and a placement needs both the trainee and the host to exist first.

Give every record an external identifier from the source sheet before you import. A simple row number or existing ID in a column you map to an "External ID" field. This is the single trick that saves you: if an import goes wrong, you can find and fix exactly those records instead of guessing, and you can re-run an import without creating duplicates.

The migration checklist

Run this once per data source. Tick every box before you move to the next sheet.

• →Backed up the original sheet somewhere untouched, so you always have the raw version.
• →Deleted columns not used in the last twelve months.
• →Standardised spelling and casing for locations, regions, statuses, and any picklist value.
• →Split names, phone numbers, and addresses into the fields Salesforce expects.
• →Removed obvious duplicate rows.
• →Added an External ID column that uniquely identifies each row.
• →Mapped every remaining column to a specific Salesforce field, and noted any column with no home.
• →Imported in order: Accounts, then Contacts, then activity records.
• →Spot-checked twenty records in Salesforce against the original sheet.
• →Confirmed the record counts match, or know exactly why they do not.

Your first three dashboards

A dashboard is what turns Salesforce from a filing cabinet into something leadership opens on a Monday. Build three, no more, and build them from the funder questions you already dread. If a funder asks it, it should be one click, not one Friday night.

• →The programme dashboard: how many people you served this month and this quarter, split the way your funders ask for it, usually by location, age band, and gender. If you can answer a disaggregation request in a screenshot, you have already paid for the whole system.
• →The pipeline dashboard: who is in progress. Applications received, in review, enrolled, placed, completed. This is the one your systems owner watches daily to see what is stuck.
• →The activity dashboard: what the team actually did. Calls made, visits logged, follow-ups overdue. This is how you spot records going cold before a funder does.

Every chart on these dashboards must trace back to a report, and every report to real records your team enters. If a number cannot be trusted because nobody keeps that field current, take the chart down. A dashboard with three true numbers beats one with twelve you have to caveat.

The 90-day training rhythm

A system nobody uses is worth less than the spreadsheet it replaced, because at least everyone knew the spreadsheet. Adoption is a training problem, not a software problem, and it runs on a rhythm. Here is the one that works for a small team.

Days 1 to 30, one workflow. Pick the single most common thing your team does, for example enrolling a new person, and get everyone doing only that in Salesforce. Nothing else. One workflow done by everyone beats ten workflows done by one person. Hold a short weekly check-in where the systems owner watches two people actually do it and fixes what confuses them.

Days 31 to 60, add the reporting loop. Now that data is going in, start pulling it out. The systems owner builds the three dashboards and, most importantly, uses them in the real Monday meeting instead of the old spreadsheet. When the team sees leadership reading the system, the system becomes real. Add a second workflow only once the first is habitual.

Days 61 to 90, hand over and prove it. The systems owner should now be able to add a field, build a report, and fix a bad record without help. Produce a one-page before-and-after: hours saved on your monthly report, how long a disaggregation request now takes, how many records are current. That page is what you attach to your next funder update, and it is the proof that the adoption stuck.

The mistakes that stall adoption

Most abandoned Salesforce orgs failed for the same few reasons, and all of them are avoidable. Building too much in week one, so the team meets a complicated system instead of a simple one. Splitting ownership across everyone, so no one keeps it tidy. Importing dirty data, so people stop trusting the numbers. Making people track things no report ever uses, so data entry feels like pointless admin. And going quiet after launch, when adoption actually needs a weekly nudge for the first three months. Build less, own it clearly, clean before you import, track only what you report, and keep showing up for ninety days.

Where SF Fellows GH fits

We help qualifying NGOs get set up on Salesforce at no cost, and we place a trained Fellow with you for six months to be the systems owner while your team learns. The Fellow runs week zero, the migration, and the 90-day rhythm above, and leaves your staff able to keep it going. The full 25-page playbook, with the field lists, import templates, and dashboard recipes, is on the pipeline for Q3 2026. If you want the setup itself sooner, book a fifteen-minute call and we will tell you honestly what you qualify for and what would ship in your first thirty days.