Choosing Nonprofit Software: RFP Template and Evaluation Guide

The most expensive technology mistake a nonprofit can make is choosing the wrong platform. The second most expensive is choosing it the wrong way — through a single vendor demo, a board member's recommendation, or a peer endorsement without any structured evaluation.

A nonprofit software RFP (Request for Proposal) is a structured document that defines your requirements, invites vendor responses, and creates an objective framework for comparing solutions. Using one will not guarantee you choose the right platform. But it will dramatically reduce the probability of choosing the wrong one — and it makes the decision defensible to your board, your auditors, and your staff.

This guide provides a complete software selection framework: needs assessment, RFP structure, vendor evaluation scorecard, demo best practices, reference check questions, and contract negotiation guidance.

Why Most Nonprofit Software Selections Go Wrong

Most nonprofit software selection processes fail for one of three reasons:

Feature fixation. The team focuses on features that look impressive in demos rather than workflows they actually need to solve. A beautiful donor dashboard is compelling in a presentation. Whether the platform correctly handles restricted fund release accounting is not visible unless you ask specifically.

Inadequate user involvement. Software selected by the executive director without meaningful input from daily users — the Controller, development coordinator, program managers — produces resentment and low adoption.

Insufficient requirements definition. Organizations that cannot clearly articulate their current pain points cannot evaluate whether a vendor addresses them. The result is a selection based on general impressions rather than specific capability assessment.

A structured RFP process addresses all three failure modes.

Phase 1: Needs Assessment (Weeks 1–2)

Before writing an RFP, document your current state honestly.

Current Technology Stack Inventory

For each tool currently in use, document:

• What it is and what it does
• Who uses it
• What it does well
• What it cannot do
• How much staff time it consumes per month

Pain Point Identification

Ask your team:

• What is the single workflow that consumes the most time relative to its importance?
• Where do you most frequently encounter data quality problems?
• What reports or analyses do you need that you currently cannot produce?
• What compliance requirements are most difficult to meet?
• What information do board members request that you struggle to provide?

The answers define your primary selection criteria. A vendor who solves your top three pain points is more valuable than one with more features overall.

Translate Pain Points Into Selection Goals

• "Eliminate monthly gift reconciliation between CRM and accounting" → requires unified donor and accounting database
• "Produce board-ready reports in under two hours" → requires automated reporting with narrative capability
• "Track grant spending against budget in real time" → requires grant management integrated with the general ledger
• "Identify at-risk donors before they lapse" → requires segmentation and engagement scoring

Phase 2: Requirements Definition (Week 2)

Organize requirements by functional area. For each requirement, note whether it is a Must-have (M), Important (I), or Nice-to-have (N).

Fund Accounting

• Fund accounting with multi-fund tracking — M
• FASB ASC 958-compliant financial statements — M
• Grant management with budget-versus-actual — M
• Functional expense allocation with documented methodology — M
• Restriction release transaction management — M
• Bank reconciliation with automatic matching — I
• Budget management and variance reporting — I
• Audit trail across all accounting transactions — M
• Year-end close with period locking — I

Donor Management

• Giving history with full transaction detail — M
• Year-end giving statement bulk generation — M
• Donor segmentation and dynamic list building — I
• LYBUNT/SYBUNT report generation — I
• Unified constituent records (donor, volunteer, board) — I
• Duplicate detection and merge — I
• Automated gift acknowledgments — I
• Major gift pipeline management — N
• Engagement scoring — N

Communications

• Email campaign creation and delivery — I
• Donation page creation and management — I
• Pledge management — I
• Automation journeys triggered by donor behavior — N
• Campaign attribution and ROI tracking — N

Reporting

• Standard FASB financial statements, auto-generated — M
• Budget-versus-actual by fund, program, and grant — M
• Donor retention rate calculation — I
• Board-level dashboard with configurable KPIs — I
• Scheduled report delivery to defined audiences — N

Technical and Security

• Role-based access with granular permission controls — M
• SOC 2 Type II certification or equivalent — M
• Two-factor authentication — M
• Data export in standard formats — M
• Documented backup and disaster recovery — M
• Browser-based access, no local installation — I

Phase 3: The RFP Document (Week 3)

A well-structured nonprofit software RFP contains these sections:

Section 1: Organization Overview

One to two paragraphs describing your size (budget, staff, donors), program areas, fund structure complexity, and the primary users of the software. Vendors use this to assess fit.

Section 2: Current Technology and Migration

Describe your current systems, what data needs to be migrated, and any integration requirements. Be specific about data volume: approximate donor count, active grant count, and years of history to migrate.

Section 3: Functional Requirements

Present your requirements matrix. Ask vendors to respond to each requirement with: Included in base product / Available as add-on / Available with customization / Not available.

Section 4: Technical Requirements

Security certifications, uptime SLA, backup frequency, data export capabilities, and integration requirements.

Section 5: Implementation and Support

• Implementation process and timeline
• Data migration approach and responsibility
• Training included with onboarding
• Ongoing support model (hours, channels, response time SLA)

Section 6: Pricing

Request: base subscription pricing for your organization size, implementation and onboarding fees, training fees if separate, any add-on costs for must-have features, and historical price increase information.

Section 7: References

Three references from organizations of similar size and complexity, on the platform for at least 18 months.

Phase 4: Vendor Evaluation Scorecard

After receiving responses, score each vendor using a weighted scorecard. Suggested weights:

Category	Weight	Score (1–5)	Weighted Score
Must-have requirements met	35%
Important requirements met	20%
Total cost of ownership (3-year)	15%
Implementation and onboarding quality	10%
Reference check results	10%
Vendor stability and roadmap	10%

Any vendor who cannot meet all Must-have requirements should be disqualified before weighted scoring.

Phase 5: Demo Best Practices

Standard vendor demos are designed to impress, not to reveal. To get useful information from demos:

Provide your own scenarios in advance. Send the vendor two to three specific workflows you need to evaluate before the demo. Ask them to demonstrate those exact workflows using data similar to yours — not generic sample data.

Require demonstration of specific requirements. For each must-have requirement, ask to see it in action. "Show me how a restricted gift is recorded and released" will tell you more than any feature presentation.

Ask about limitations. "What can your platform not do?" A vendor who cannot answer this question honestly is not a vendor you want to trust with your financial data.

Include daily users in the demo. The Controller and development coordinator should participate in the demo and ask operational questions. Their assessment of usability matters as much as executive judgment about strategic fit.

Schedule two rounds. Initial demos (all vendors) — 60 minutes, general overview. Finalist demos (top 2–3) — 90 minutes, your specific scenarios and deep dives.

Phase 6: Reference Checks

Reference checks are one of the most underutilized steps in the selection process. When checking references:

Ask about the implementation experience:

• How long did implementation actually take vs. the vendor's estimate?
• What was the most difficult part of the transition?
• What would you do differently?

Ask about day-to-day operations:

• Which features do you use every day and find genuinely valuable?
• Which features have disappointed relative to the demo?
• How responsive is support when you have a problem?

Ask about value:

• Has the platform delivered the ROI you expected?
• What has changed in how your team operates since implementing?
• Would you choose this platform again?

Talk to at least two references per finalist vendor. If a vendor's references are all enthusiastic with no criticisms, probe harder — perfect references are a red flag, not a green one.

Phase 7: Contract Negotiation

Key items to negotiate:

Price lock. Request a contractual commitment to no price increases for two to three years. Most vendors will negotiate this.

Implementation timeline and milestones. The contract should specify what the vendor delivers by when, and what happens if they miss milestones.

Data portability. Confirm in writing that you own your data and can export it at any time in standard formats. This matters if you ever need to change platforms.

Service level agreement. Uptime guarantee, response time for critical issues, and escalation path for unresolved problems.

Termination clause. What happens if you need to terminate before the contract end? What are the data migration obligations of the vendor?

Positioning sherbertOSOS in Your RFP

When you apply this evaluation framework, the criteria that most differentiate platforms are:

Data unification: Does the platform share a single database across fund accounting, donor management, and communications — or does it integrate separate systems? Integration and unification are not the same thing. Integrations break; a unified data model does not.

Fund accounting depth: Can it produce FASB-compliant statements automatically? Can it manage restriction releases, multi-fund reporting, and grant budget-versus-actual without manual workarounds?

Report automation: Are reports generated from live data, or do they require manual assembly from exports?

sherbertOSOS maps to every must-have requirement in this guide within its base product. Fund accounting, FASB financial statements, grant management, unified CRM, automated acknowledgments, and role-based access are all included — not add-ons, not integrations, not customizations.

Frequently Asked Questions

Q: How long should a software selection process take?

Eight to twelve weeks from needs assessment through vendor selection. Rushing leads to regret. Dragging beyond twelve weeks leads to decision fatigue and usually results in no decision at all.

Q: What should be in a nonprofit software RFP?

Organization overview, functional requirements by department (with must-have and important distinctions), technical requirements, implementation expectations, pricing format, and evaluation criteria with weights.

Q: How many vendors should be included in the initial RFP?

Four to six vendors in the initial RFP. Narrow to two to three finalists for detailed demos and reference checks. More than six is unmanageable; fewer than four risks missing the right option.

Q: Should I include price as a primary selection criterion?

Price should be evaluated as total three-year cost of ownership — including subscription, implementation, training, and any add-ons required to meet your must-have requirements. A platform that appears cheaper but requires three add-ons to meet your needs may cost more. Weight price at 15% or less; capability at 55% or more.

Q: What is the single most important question to ask a vendor?

"What can your platform not do?" A vendor who answers honestly and specifically is demonstrating the transparency you want in a long-term partner. A vendor who says "nothing" is telling you something important about how they will handle support issues.

---

sherbertOSOS meets every must-have requirement in this guide within its base product: fund accounting, FASB statements, grant management, unified CRM, automated acknowledgments, role-based access, and full audit trail. Download the evaluation checklist or request a demo to see how sherbertOS maps to your specific requirements.