Most nonprofits track relationships in a spreadsheet nobody trusts, or buy a CRM that costs more attention than it ever saves. Asana already holds your work, your team and your comments, so adding relationships to it costs no new tool, no new login and no migration. Asana's own CRM templates start from a commercial sales pipeline. This pattern is that idea rebuilt for nonprofits, and it is the setup we run at Moral Fabric. Start by deciding what a "customer" is for you. Ours are the nonprofits we do operations work for. Yours might be donors, funders, partners, members, schools or participants. The structure below holds either way — the words are yours.
Four projects, one relationship model:
- (we call it CRM: Customers) — one task per organisation
- (CRM: Engagements) — one task per deal, linked to the organisation. Skip this project if your relationships never produce more than one deal; add it the moment one does.
- (CRM: Funders) — one task per organisation
- (CRM: Contacts) — one task per person
Five rules make this a CRM rather than a task list:
One per organisation, one per person, one per deal. Never a task per email or per meeting.
The contact carries Organisation; the organisation carries Contacts and Engagements; the deal carries Organisation. Asana reference fields are what turn four projects into a relational database.
Board sections drift out of sync the moment someone drags a card, and rules and reporting cannot read them. Keep a Deal stage field as the single source of truth and group the board by that field.
The organisation record says what is true about them; the deal says what you expect, how sure you are and when. Put value, confidence and dates on the organisation instead and the second deal has nowhere to go.
on the organisation task. That is the log — and the part you can automate later.
Organisations you serve:
- prospect, active, past
- multi-select of what they need from you
- , and (references), and a free-text for your read on the fit
Deals:
- Targeted, Initial contact, Qualification, Meeting, Proposal to be made, Proposal sent, Closed: won, Closed: lost, Closed: no match from our side
- (reference),
- A signed retainer is a deal that runs, so dates are what separate past, current and future work on one board
- new, renewal, extra work
Funders:
- grant-making foundation, philanthropist, family fund, angel investor, VC investor, wealth advisory
- (reference)
- Which they fund (reference): this is what makes a funder record useful to more than one team
People:
- founder or owner, operations, connector
- (reference),
One word per group, agreed by the team. Split into separate projects only when the fields genuinely differ — funders need a funder type, deals need a stage and a value, organisations need neither. Same fields means one project with a Type field.
as workspace-level custom fields, so Contacts and Website mean the same thing everywhere and stay comparable.
Board grouped by stage on the deals project for the pipeline, list view sorted by organisation for contacts, and a saved view filtered to your own records.
before you load real data. Fixing this later is manual work.
Start from today. Old context arrives naturally the first time someone touches a record.
Asana holds relationships and pipeline, not transactions. Mass mailing, donation processing, recurring giving history and formal donor reporting belong in a mailing tool or a donor database. If you find yourself building a task per donation, you have outgrown this pattern. It also will not total a customer's open deals back onto their record, so report on the deals project rather than copying the number across.
Contact records are personal data under the GDPR. Keep the CRM projects private to the team that needs them, write down why you hold the data and how long you keep it, and never put special-category data — health, religion, political views — in a task. People can ask to see or delete their record.
Record your entity words, your stage list, who owns which relationship, where the weekly review happens, and your retention rule.