Nonprofit Drupal Support RFP Requirements and SLAs: A Step-by-Step Guide

Some nonprofit Drupal support RFPs fail before a single proposal arrives. Not because the requirements are wrong, but because they are unquantified. When an RFP for Drupal support and maintenance services for nonprofits asks for "ongoing support" without specifying expected hours, ticket volume, or resolution targets, every bidder fills the gap with their own assumptions. The lowest price wins, and the friction starts the month after the contract is signed.

This guide draws on what we see across the nonprofit RFPs that reach us and lays out how to write support requirements and SLAs that actually protect a mission-critical platform.

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:

Image

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:

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.

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.

Mohammad Azouqa is VP of Business Development at Vardot, a Drupal Diamond Certified Partner that builds and supports digital experiences for enterprise, nonprofit, higher education, and government organizations, including UNHCR and UNICEF. He helps clients protect their digital investment by matching them with the right care and support services for their goals. Mohammad holds an MBA from the New York Institute of Technology.