Nonprofit Drupal Support RFP Requirements and SLAs: A Guide
An RFP that asks for "ongoing support" without naming hours, ticket volume, or resolution targets leaves every bidder to assume a different scope. The lowest price wins, and the friction starts the month after signing.
Key Takeaways
- Weak RFPs are missing numbers, not requirements. Unquantified scope produces proposals that all look compliant and none comparable.
- Separate three components: proactive maintenance, reactive support, and growth work. Most RFPs describe only the first.
- Response time says when a provider acknowledges. Resolution time and monthly hours decide whether it gets fixed.
- Require a website audit before takeover. It regularly finds problems the RFP never mentioned.
A nonprofit Drupal support RFP should quantify expected engagement: urgent-ticket response time, monthly support hours, and 12-month ticket history. It should separate ongoing maintenance, reactive support, and growth work into distinct requirements, disclose hosting and team structure, define resolution targets by severity, require a pre-takeover website audit, and vet bidders on Drupal Association partnership level and NGO references.
Why Nonprofit Drupal Support Is a Distinct Procurement Problem
Drupal carries unusual weight in the nonprofit sector. Among large NGOs and UN agencies, these are rarely brochure sites.
The Drupal Association's nonprofit industry page cites UNHCR's global donation platform, built by Vardot, which has processed more than $67 million across 35+ markets.
When a platform takes donations, runs campaigns in multiple languages, and serves audiences across time zones, support is not an IT line item. It is operational continuity.
That is why the procurement document matters so much: it is the only mechanism a nonprofit has to make competing proposals genuinely comparable before committing to a multi-year relationship.
What Support Agreements Actually Contain
In our experience responding to nonprofit RFPs, a Drupal support and maintenance agreement has three distinct components, and some RFPs only clearly describe one of them:
1. Ongoing maintenance
The proactive behind-the-scenes work: Drupal core and module updates, security patches, and proactive monitoring.
2. Support
Help when something breaks or when editors need assistance using the CMS: content update, bug fixing, governed by defined response times and resolution times.
3. Growth and continuous development
Design tweaks, new integrations, new features, and new languages.
RFPs that conflate these three buckets, or describe only the maintenance layer, leave bidders guessing about the other two. The guess usually lands wherever it makes the proposal cheapest.
Where RFPs Go Wrong: The Quantification Gap
The requirement nonprofits most often leave out is the level of their previous engagement. Before we bid, we routinely have to send the questions the RFP should have answered:
- What SLA do you expect? One hour for urgent tickets? Four? Eight?
- How many hours per month of support and maintenance do you anticipate needing?
- How many tickets have you filed in the past 12 months?
- Will we work with a single team on your side, or multiple teams?
- What is the size of the platform and the complexity of integration?
- How often is the content being updated?
For website takeovers, we also request three reports from the current Drupal build so the proposal reflects the actual system rather than an idealized one:
Field list report
Content types, entities, and all fields, at /admin/reports/fields.
Available updates report
Module names, versions, and pending updates, at /admin/reports/update.
Status report
Overall site status, exact PHP version, and Drupal version, at /admin/reports/status.
In total, we typically send 10 to 20 clarifying questions before bidding.
Here is why the gap is costly: when engagement is not quantified, proposals cannot be compared on substance.
A bidder with less nonprofit experience can treat a donation platform like a regular website, commit fewer hours, and undercut every serious proposal on price.
If the organization selects that bid, the consequences surface after signature: long turnaround times, an engagement level below what the platform needs, and a partner relationship that starts in dispute.
For a nonprofit running a donation platform, getting this right is what keeps a donation platform running through your busiest campaigns.
These platforms are mission-critical, and in our experience, the SLA detail nonprofits fixate on, fast ticket turnaround and 24/7 availability, is necessary but not sufficient. Response time tells you when the provider acknowledges the problem. Resolution time, allocated monthly hours, and hosting-dependent service eligibility determine whether the problem actually gets fixed within the window your donors notice.
Where We Land: Weak RFPs Are Missing Numbers, Not Requirements
Our view, formed across years of nonprofit conversations and bids, is that the weakest RFPs are not missing requirements. They are missing numbers. An RFP that lists "support, maintenance, and SLA" as requirements but quantifies none of them produces proposals that all look compliant, and none of which are comparable.
The document creates the illusion of a fair competition while structurally favoring whoever assumed the least work.
This is also why we treat the website audit as non-negotiable before any takeover. We describe it internally as an X-ray of the website: a thorough examination of configuration, existing bugs, and issues that need fixing.
The audit regularly uncovers problems that were never in the RFP because the client did not know about them. Ignoring those issues is not neutral; building new features on top of them is how enhancements break.
A consequence of this view: we maintain tiered customizable support plans rather than one-size offers, ranging from a monitoring-only plan up to standard, professional, and enterprise tiers, each with its own response time, SLA, service hours window, and engagement level. Hosting matters here.
A site hosted on a Drupal-optimized platform-as-a-Service (PaaS) such as Acquia, Pantheon, or Upsun qualifies for our standard tiers; a site on generic infrastructure needs the professional or enterprise level, because the provider is absorbing platform risk that the hosting would otherwise handle.
We make that eligibility explicit rather than discovering it mid-contract, and where hosting is the constraint, we open the conversation about whether the organization is willing to migrate rather than deciding for them.
A Step-by-Step RFP Framework for Nonprofit Drupal Support
Use this sequence when drafting the support and maintenance section of your next RFP.
Step 1: Quantify Your Current Engagement
State your ticket volume for the past 12 months, your expected monthly support hours, and your urgent-ticket response expectation in hours. If you do not have this data, say so explicitly and ask bidders to propose a sizing methodology.
Step 2: Separate the Three Components
Write distinct requirements for ongoing proactive maintenance (updates, patches, monitoring), support (bug fixing, editor assistance, response and resolution times), and growth work (integrations, features, languages), each with its own scope.
Step 3: Disclose Your Environment
Name your hosting platform, your traffic profile, your team composition and working languages, and whether the vendor will face one team or several. Attach three reports from your Drupal admin: the Field list report (/admin/reports/fields), the Available updates report (/admin/reports/update), and the Status report (/admin/reports/status). Copying each page into a spreadsheet is enough.
Step 4: Specify the SLA Beyond Response Time
Define resolution targets by severity, the service hours window, and what 24/7 coverage means for a donation platform in your time zones. Include accessibility maintenance against the current W3C WCAG 2.2 recommendation if your audiences or funders require it.
Step 5: State Your Enhancement and Development Horizon
If a new market, currency, language, or CRM change is plausible within the contract term, say so now. Pricing that arrives blind to your roadmap will not survive it.
Step 6: Require an Audit Before Takeover
Make a documented website audit a condition of transition, and ask bidders to describe their audit methodology.
Step 7: Vet for a Partner, Not a Vendor
Nonprofit support relationships run for years. Require a proven track record with NGO and donation platforms, the bidder's partnership level with the Drupal Association, comparable project references, and case studies. As a Drupal Diamond Certified Partner, this is the standard we hold ourselves to.
Writing the RFP Is the First Act of the Partnership
An RFP that quantifies engagement, separates care components, and demands an audit does more than filter bidders. It signals to every serious Drupal partner that your organization understands what it is buying, which changes the quality of the proposals you receive.
Want a second set of eyes on your RFP or a structured audit before you go to market?
FAQs
A nonprofit Drupal support RFP should quantify expected engagement (monthly hours, 12-month ticket history, urgent-ticket SLA), separate requirements for maintenance, reactive support, and growth work, disclose the hosting platform and team structure, define resolution times by severity, state planned enhancements such as new languages or CRM changes, and require a website audit before transition.
Nonprofits should define response time for urgent tickets (commonly one, four, or eight hours), resolution targets by severity level, the service hours window, and availability expectations. For donation platforms, which are mission critical, 24/7 coverage matters, but resolution time and allocated monthly hours determine whether issues are actually fixed, not just acknowledged.
A Drupal support and maintenance agreement typically has three components: ongoing maintenance (core and module updates, security patches, proactive monitoring), reactive support (bug fixing and CMS assistance governed by response and resolution times), and growth work (design changes, new integrations, features, and languages). RFPs should scope and quantify each component separately.
Evaluate Drupal support partners on proven track record with NGOs and donation platforms, their partnership level with the Drupal Association, the number of comparable projects completed, client references, and published case studies. Nonprofit support relationships typically run for years, so vet for a long-term partner rather than a transactional vendor.