A charity should write a Salesforce CRM brief around the outcomes it needs to achieve, the people and processes the system must support, the information it holds and the problems with its current way of working. It should explain the organisation clearly without attempting to design the technical solution before speaking to a Salesforce partner.
A good brief gives potential partners enough information to understand the project while leaving room for discovery. It does not need to contain a complete Salesforce specification.
Why does a charity need a CRM brief?
A CRM brief helps a charity explain what needs to change and gives potential Salesforce partners a consistent basis for their recommendations.
Without one, different partners may make different assumptions about the scope. One proposal might include data migration, integrations and training, while another covers little more than the initial Salesforce configuration. Those proposals will be difficult to compare because they are not answering the same question.
The process of writing the brief is also valuable internally. It encourages teams to agree:
- Why the project is needed
- What is not working now
- Who will use the system
- Which processes matter most
- What information needs to be connected
- What success should look like
The brief does not have to answer every technical question. Those answers should develop through discovery with the selected partner. If the organisation has not yet decided who should support the project, SPT’s guide to what a UK nonprofit should look for in a Salesforce partner provides a useful starting point.
Should the brief begin with Salesforce functionality?
No. The brief should begin with the organisation and the outcomes it wants to achieve.
Instead of asking for a long list of Salesforce features, explain the practical changes the charity needs. For example:
- Fundraisers need a reliable view of each supporter
- Volunteer coordinators need to understand availability, skills and activity
- Finance teams need donation and Gift Aid information to reconcile correctly
- Service teams need appropriate access to beneficiary or programme information
- Leaders and trustees need dependable reporting
- Employees need to spend less time transferring information between systems
This helps prospective partners recommend the right combination of configuration, automation and integration. It also reduces the risk of creating an unnecessarily complicated system.
Sweet Potato Tec’s Salesforce implementation approach begins by understanding how an organisation works, where people are losing time and what needs to improve before technology is configured. A good brief should give a potential partner the information needed to begin that conversation.
What organisational information should be included?
Provide enough context for the partner to understand how the charity operates.
Useful information includes:
- The charity’s mission and principal activities
- Approximate size and structure
- Number and location of employees
- Number of expected Salesforce users
- Key audiences, such as donors, volunteers, members, beneficiaries and funders
- Fundraising and service-delivery models
- Internal teams involved in the project
- Current technical and administrative capacity
- Any important deadlines or organisational changes
A partner that genuinely understands charities should use this information to shape its questions and recommendations. The organisation should not have to translate every charitable activity into commercial Salesforce terminology before the first conversation.
SPT’s work with charities and nonprofit organisations focuses on making Salesforce and connected technology support the charity’s mission, rather than asking the organisation to reshape itself around the platform.
How should a charity explain its current problems?
Describe the effect of each problem, not simply the technology involved.
For example, “our databases do not integrate” is useful, but it does not explain the operational consequence. A clearer description might be:
Online donations are processed through our website, but the fundraising team manually imports the information into our CRM. This delays acknowledgements, creates duplicate records and makes campaign reporting difficult.
Other examples could include:
- Volunteer applications sitting in shared inboxes
- Employees maintaining separate spreadsheets because they do not trust the CRM
- Supporter preferences being held in several places
- Reporting taking days to compile
- Membership renewals being tracked manually
- Teams having different versions of the same information
- Senior leaders lacking a reliable view of fundraising, services or impact
This gives the Salesforce partner a better basis for understanding the required outcome.
Which users and processes should the brief cover?
List the teams and groups that will use the system, then describe their most important processes.
These could include:
- Fundraising and regular giving
- Supporter care
- Volunteer applications and coordination
- Membership
- Events
- Grants
- Programme and service delivery
- Case or beneficiary management
- Communications and consent
- Gift Aid
- Impact measurement
- Finance and reconciliation
- Trustee and funder reporting
Do not assume that every process needs to enter the first phase. Identifying priorities helps the partner recommend a realistic implementation plan rather than trying to transform the entire organisation at once.
What systems and data sources should be listed?
Include every significant place where relevant information is currently stored or processed. This may include:
- An existing CRM or fundraising database
- Volunteer-management software
- Website forms
- Donation and payment platforms
- Email-marketing systems
- Event platforms
- Finance software
- Shared drives and spreadsheets
- Membership systems
- Case-management tools
- Reporting platforms
The brief should also highlight known issues such as duplicated records, inconsistent fields, missing consent information or data that has not been reviewed for years.
Data migration and integration can represent a substantial part of a Salesforce project. Giving potential partners an honest view helps them make more realistic recommendations. SPT’s guide to preparing a charity for a Salesforce data migration explains the decisions around data sources, cleansing, mapping, validation and ongoing ownership in more detail.
If the project also involves online donations, website forms or payment systems, the brief should document the complete journey rather than simply asking for “a website integration”. The guide to integrating a charity website and donation platform with Salesforce shows the questions that need to be considered around supporter matching, Gift Aid, recurring payments, consent, attribution and reconciliation.
Should a charity state its budget?
Providing a budget range can help potential partners propose an appropriate approach.
A charity does not need to reveal the maximum it could possibly spend. However, withholding all budget information can result in proposals built on completely different assumptions.
The brief should clarify whether the available budget needs to cover:
- Discovery
- Salesforce licences
- Implementation
- Data preparation and migration
- Integrations
- Testing
- Training
- Change management
- Ongoing support
Donated or discounted Salesforce licences do not remove the work required to create and maintain a useful CRM. SPT’s guide to whether Salesforce’s free nonprofit licences are really free explains the wider investment charities should consider.
How should success be defined?
Success measures should relate to organisational improvement rather than simply whether Salesforce launches on time.
Depending on the project, success might include:
- Reducing manual data entry
- Reducing duplicate supporter records
- Improving the speed of reporting
- Increasing user adoption
- Processing donations or applications more quickly
- Providing a single view of supporters
- Improving Gift Aid administration
- Giving leaders more reliable information
- Connecting fundraising, volunteering and service delivery
- Giving employees more time for mission-focused work
Agreeing these measures early makes it easier to evaluate proposals and hold the eventual project to account.
What should the brief ask potential partners to provide?
Ask each partner to explain:
- Its understanding of the charity’s objectives
- Its recommended approach
- What is included and excluded
- Key assumptions
- Proposed phases
- Indicative timescales
- Project roles and responsibilities
- Data-migration approach
- Integration approach
- Testing and quality assurance
- Training and change management
- Relevant nonprofit experience
- Ongoing support options
- Costs and potential additional costs
- Principal risks and dependencies
This produces proposals that are easier to compare and exposes important differences that might otherwise remain hidden.
What should not be included in a charity CRM brief?
Avoid prescribing a detailed technical solution unless the charity has already completed independent discovery and has the expertise to do so. Over-specifying the platform can prevent potential partners from recommending a simpler or more effective approach.
Also avoid:
- Presenting every internal request as equally important
- Understating known data problems
- Assuming integrations will be straightforward
- Treating training as something that happens once at the end
- Setting a launch date without considering internal availability
- Focusing entirely on implementation and ignoring ongoing ownership
A useful brief is clear about the problem while remaining open about the solution.
What happens after the brief is issued?
Shortlisted partners should be given the opportunity to ask questions and meet relevant stakeholders. This is important because a written document cannot reveal every dependency, concern or difference between teams.
The charity can then assess which partner:
- Understands the organisation most clearly
- Challenges assumptions constructively
- Explains complexity in accessible language
- Identifies risks rather than hiding them
- Proposes an achievable scope
- Can show relevant nonprofit experience
- Has considered adoption and long-term value
The next step is to compare the resulting proposals on a like-for-like basis, looking beyond the headline price to understand the scope, assumptions and long-term value behind each recommendation.
FAQs
Does a charity need a consultant to write its Salesforce brief?
Not necessarily. An internal team can produce the brief if it understands the organisation’s objectives, processes, data and constraints. External support may help when requirements are complex or internal teams disagree about priorities.
How long should the brief be?
It should be detailed enough to explain the organisation and project without becoming a complete technical specification. Clarity matters more than length.
Should every department contribute?
Every materially affected team should have an opportunity to contribute. That does not mean every requested feature must be included in the first phase.
Should the brief name Salesforce?
If the charity has already decided that Salesforce is the preferred platform, yes. If it is still assessing its options, the brief should focus more heavily on requirements and outcomes.
Should data migration be included?
Yes. Explain which systems hold relevant information, the approximate scale of the data and any known quality problems. More detailed assessment can follow during discovery.
Give potential partners the right problem to solve
A strong Salesforce brief does not need to contain all the answers. It needs to explain the charity, the people it supports, the problems it is experiencing and the outcomes it wants to achieve.
That gives potential partners the opportunity to show whether they understand the organisation, not simply whether they know how to configure Salesforce.
If your charity is preparing a Salesforce project, Sweet Potato Tec can help clarify the requirements, assess the current environment and determine an appropriate next step through its nonprofit Salesforce services.