What makes a good RFP?

For most of my time at Made, I’ve been part of the team that works on preparing our project proposals. As a result, I’ve seen hundreds of requests for proposals of all different shapes, sizes, and styles. Some are fifty pages of formal requirements. Some are three paragraphs in an email. Some are a conversation we have over coffee at a conference.

Here’s what we’ve learned: The format matters much less than the content. The best RFPs help us understand what you’re trying to accomplish and why. They give us enough context about your team and organization and goals to help us meaningfully respond to your particular situation, rather than sending back a generic proposal that could be for anyone.

If you’re soliciting proposals for a new web project, from our agency-side perspective, here are some notes about what actually helps.

Tell us your why

The most important thing you can share is the organizational context behind the project. Why this work, why now? What problem are you solving, what opportunity are you pursuing? How does this project fit into your broader strategy?

Maybe your current site is built on a platform that’s being discontinued. Maybe your audience has shifted and your digital presence hasn’t kept up. Maybe you’re launching a new initiative that requires capabilities you don’t have. Maybe leadership has finally agreed to fund work that’s been needed for years.

Whatever it is, tell us. Understanding your why helps us think about the right solutions for your particular situation, and what success looks like beyond the minutiae of requirements and technical deliverables.

Don’t worry about making it formal or fancy

We’ve responded to RFPs that read like legal contracts, RFPs that were literally someone’s scattered thoughts spoken aloud on a phone call, and just about everything in between. The formal ones aren’t better.

An RFP written in the voice of the actual people at your organization who will be working on the project – people who are on the hook to get this done, and who will most directly live with the results – is always more useful than something that’s been processed through consultant-speak or written to sound impressively corporate.

We want to hear from you, not from what you think an RFP is supposed to sound like. Tell us what you need in the way you’d explain it to a colleague. That clarity is worth more than polish (and it should be easier to write, too).

Help us understand how your business works

For us to scope work meaningfully, we need to understand what your digital presence actually needs to do. Particularly if you’re selling tickets or taking donations through something like Tessitura, we need to know the footprint of what you’re asking us to build, and how it fits into your goals and systems.

What products do you sell? Single tickets, subscriptions, memberships, donations? Do you offer exchanges or refunds? (To everyone, or just some people? Do you charge a fee? What are the other rules?) Time-based entry? Recurring donations? Membership benefits that people should be able to view or redeem through the website? Which of these capabilities exist in your current system, and which are new or aspirational?

If you’re working with specific platforms or systems that will connect to the new site, tell us about them. If you have particular constraints or requirements, share those up front. If you’re unsure about something, tell us that. The more we understand about your operational reality before we start, the more useful our proposal will be.

We always start major projects with an intensive discovery period, and there will be lots of time then for us to dig into all the details. But even a high-level understanding early on helps us give you meaningful, accurate answers about scope, cost, and timeline.

Tell us about your team and stakeholders

Who will drive this project on your side? Do you have an in-house web designer or developer? A ticketing-system administrator who knows your audience and data inside and out? A digital marketing person who’ll be maintaining the site longterm?

It’s always our aim to deliver work that is built to last, and a major factor in that is making sure the system is architected to suit the resources of the organization we’re building it for. We might propose something quite different for an organization with in-house database experts than for an organization with a leaner team. Neither is better or worse – they’re just different situations that call for different approaches.

Also, we’d love to know about the broader stakeholder picture. Who needs to approve this work? Whose opinions matter? How do decisions typically get made? What’s been hard about projects like this in the past?

This isn’t about organizational politics (although if there are political realities that will affect the project, we’d like to know). It’s about understanding how we’ll actually work together and what you need from us to make this successful.

Share what you know about budget, even if it’s incomplete

I know this one can feel tricky. Maybe you don’t know your budget yet because you need our proposal to make the case to your board. Maybe you’re worried that if you name a number that’s too high, you’ll end up paying more than you need to. Or if the number is too low, you’ll close yourself off to proposals worth finding more money for.

But here’s the thing: there’s no single right way to build a website. There might be dozens of valid approaches to meeting almost any requirement, each with different trade-offs in cost, timeline, complexity, long-term maintenance, and customer experience. Without knowing your budget expectations, we’re guessing at what makes sense for your situation.

Even partial information is useful. One of the best budget disclosures I’ve seen in an RFP said something like: 

For transparency, we have $25,000 reserved for this work in this year’s budget. We realize that good-fit solutions may cost considerably more, and we may need to secure additional funding. We welcome proposals that efficiently address our needs, even if they require more investment than what we have currently budgeted.

The work they were describing could well have cost many times that budget. Having this clarity up front helped us respond in a way that laid out a few options including a fully realized version of what they were describing and a lightweight version that would stick to their budget by making some strategic compromises.

Be clear about your timeline

Do you have a hard launch deadline? Tell us what it is and why it’s hard. Is it tied to a season announcement? A campaign launch? A contract expiration? Understanding what makes a deadline immovable helps us think about phasing – how we might sequence launches to hit the critical date while still giving enough time to the other parts of the project that need it. It also lets us call out if we don’t think your deadline is a realistic or safe target so we can plan ahead and avoid surprises.

If your timeline is flexible, that’s worth knowing too. Some projects genuinely need to be done by a specific date. Others just need to be done well. Both are fine! But they’re different situations that affect how we’d approach the work.

What happens next

The best RFPs don’t feel like transactions, they feel like the start of a conversation.

We’ll read what you send us, we’ll probably have questions, and we’ll put together a proposal that lays out how we might suggest approaching your needs as we understand them. If we see multiple viable ways forward, we’ll lay those out, and give some indication of how we might suggest navigating the decision. And if we think we’re not the right fit for some reason, we’ll tell you that too, and will gladly share our thoughts and recommendations and alternative suggestions.

We want to do work that actually helps you. An RFP that helps us understand your situation is the best way to start.