Writing a request for proposals is easier when you know what vendors need to see. Vague requests bring vague responses that are hard to compare. Use the twelve areas below as a starting outline, then adapt them to your organization’s rules and your board’s expectations.
Areas one to three: the organization, the audiences and the problem
Start with who you are, who the site is for and what is not working today. Name your audiences, such as donors, program participants, volunteers or partners. Say what you want the site to help each of them do, for example "find the next volunteer orientation date and sign up" or "give monthly without creating an account".
Include the current address, the platform it runs on if you know it, and any pain points like slow pages, out-of-date content or trouble updating text.
Areas four to seven: scope items to state
- ✓Number and type of pages — list the key sections, such as programs, events, get involved and about
- ✓Features — donation, events, forms, newsletter links
- ✓Integrations — name the exact tools you already use and want to keep
- ✓Content — who writes it, who supplies photos and who approves the final text
How to describe features without designing the site
Vendors respond better to outcomes than to solutions you have already picked. "We need a page builder with drag and drop" invites arguments about tools. "Two staff members with no web experience need to update event dates and add a news post each month" tells a vendor what to solve and lets you compare their answers.
Do the same for donations: say which donation provider you use, whether recurring gifts matter and whether you want donors to stay on your site or move to a hosted form. That is enough for a vendor to scope it properly.
Areas eight to ten: operations and terms
Be clear about who will own the domain, content and design files at the end. Ask how hosting, backups and security updates are handled and what ongoing support costs. Ask how many revision rounds are included.
State your timeline, decision dates and how you will evaluate responses. Give a budget range if you can, since it helps vendors say whether they fit.
Questions to put to every vendor
- ✓Who owns what at the end — domain, files, content
- ✓What happens after launch — hosting, care, edits
- ✓Who does the work — team and subcontractors
- ✓What is excluded — features or content not covered
Areas eleven and twelve: evaluation and the response format
Tell vendors how you will score responses and in what format you want them. A short weighting, for example how much matters for understanding of your audiences, sample work, ongoing support and cost, keeps your committee consistent and helps vendors focus on what you care about.
Ask for responses in a fixed order that mirrors your sections. When every proposal follows the same structure, comparing them on a single table becomes simple, and gaps stand out instead of hiding in long narrative answers.
Common gaps that slow an RFP down
- ✓No question deadline — vendors guess, and responses drift apart
- ✓Accessibility named without detail — describe the outcomes you want and let your counsel set any formal standard
- ✓Content migration left vague — say whether old pages, news posts or files must move
- ✓Unclear decision maker — name who approves the final choice and the launch
Where we come in
We are a small vendor and respond to scoped requests that match what we build. If you are drafting an RFP, you can talk it through with us before issuing it, as long as your rules allow those early conversations. We will say honestly whether your scope suits a small business-style build.
What to expect, honestly
- ✓This is a checklist, not legal advice — your counsel reviews procurement rules
- ✓We respond only when scope fits — we say so early
- ✓Every organization’s rules differ — adapt as needed
One example of what your site could look like
This is one sample we designed. Yours is built around your business, your photos and your words, and we have more examples if you want to compare directions.
How it works
1. Consultation
We learn your services, customers and goals, in English or Spanish.
2. We write and design
We draft the words and build the site around your business.
3. 10 revision rounds
You review and request changes until it is right.
4. Launch and care
We launch, then Website Care keeps it hosted, backed up, checked weekly and A/B tested.
Keep reading
How we handle RFPs · What a nonprofit site should include · Nonprofit redesign checklist · Who owns your website
