How to Write a Website RFP That Good Agencies Actually Want to Respond To

Written by Kathy Kassera Mrozek

If you’re planning a website redesign, at some point someone will suggest writing an RFP. A website RFP—request for proposal—is the document you send to one or more agencies describing the project and asking how they’d approach it and what it would cost. Used well, it’s how you turn a vague “we need a new website” into proposals you can actually compare.

Companies issue website redesign RFPs for sensible reasons: the project is a meaningful investment, several stakeholders need to weigh in, and a written brief feels like the responsible way to get apples-to-apples bids. Done right, that’s exactly what it does.

Done wrong—and lately, more and more are—an RFP quietly works against you. The common mistakes are the same ones we see over and over: prescribing the solution instead of describing the problem, demanding free strategy work up front, dictating the agency’s process, hiding the budget, and burying the few things that matter under pages of boilerplate. The result is a document that reads like a procurement contract and gets the strongest agencies to pass.

AI is making this worse. Reaching for a chatbot to draft a request for proposal for a website redesign is a completely reasonable instinct—a busy marketing manager is stretched across a dozen priorities, and “write me a website RFP” sounds like a sensible shortcut. But these tools tend to produce overly complex, overly prescriptive requirements, modeled on the longest and most restrictive RFPs they can find on the public web. What comes back looks thorough but lands as onerous.

Here’s the thesis of this whole guide: a good website RFP helps an agency understand your business challenge. It should not try to prescribe every step of the solution. Get that balance right and you’ll attract stronger partners and better proposals. Get it wrong and you’ll screen out the very firms you most want.

What is a website RFP?

A website RFP is a formal document an organization sends to prospective agencies, outlining a website project and inviting them to respond with their recommended approach, team, timeline, and pricing. You’ll also see the same thing called an RFI (request for information) or RFQ (request for quote); for our purposes, we’ll treat them all as “RFPs.” Each one does the same job—it outlines your needs and asks an outside firm to respond.

The purpose is straightforward: communicate what you’re trying to accomplish, give agencies enough context to propose a real approach, and give yourself a basis for comparison. The best ones do one more thing—they signal what kind of relationship you’re after.

That part is worth pausing on. A long, prescriptive RFP reads as if you’re shopping for a vendor to take instructions, someone to execute a spec you’ve already written. A focused one reads as if you’re looking for a consultative partner whose expertise you want shaping the work. For a complex, technical website, the second relationship is where the value is—and the document you send sets that tone before anyone has spoken.

The labels also get used loosely, so it’s worth separating three related things:

  • A website RFP is outward-facing—sent to agencies to solicit proposals and compare them.
  • A website creative strategy brief is your an articulation of goals, audience, and requirements. This is something that we create early in the strategy & planning process of a website project. You can create and share a simplified version of this with an agency; it’s less procurement-flavored and easier to keep lightweight.
  • A website strategic plan is the broader marketing-strategy layer—positioning, KPIs, critical actions, and how the site works alongside your other channels. This format can also be used for sharing your goals with an agency.

In practice, most companies are better served by a clear brief than a heavy RFP. The information an agency needs is nearly identical; the format is what differs.

When should you create a website redesign RFP?

An RFP makes the most sense when a project is big enough, or involves enough people, that a shared written reference genuinely helps. That usually means:

  • A complete website redesign, where scope spans strategy, design, content, and development.
  • A CMS migration—moving off a platform that’s limiting your SEO, your security, or your team’s ability to edit.
  • A rebranding project, where new visual identity and messaging have to carry through the site.
  • A large content restructuring effort, where information architecture and dozens of pages need rethinking.
  • A complex technical integration project—tying the site to a CRM, marketing automation platform, ERP, or similar systems.

In each of these, several stakeholders typically need to weigh in, and a written outline keeps everyone aligned.

There’s a flip side, though. Not every project needs a formal document. If your scope is smaller, if you already have an agency you trust, or—most commonly—if you can’t yet articulate detailed requirements, a discovery conversation will get you there faster than an RFP. Some of our best projects have started with nothing more than a form submission that said, in effect, “I need help redesigning my website.” From there, a good agency draws out the essentials in a single, simple conversation. If writing the RFP is harder than having that conversation, skip the RFP.

How to write a website RFP

If an RFP is the right tool, keep it focused on the things only you can explain—your business, your challenges, your goals, and your constraints. Here’s what each section should cover.

Company overview

Give agencies enough to understand who you are: a short business description, your products and services, the industries you serve, and your geographic markets. A sentence or two on what makes customers choose you over the alternatives goes a long way. If you’ve already mapped your ideal customer profile or your top competitors, share that too.

Current website challenges

Be candid about what isn’t working. The usual suspects: poor lead generation, an outdated design that undersells you, a CMS that’s painful for your team to update, technical limitations, or content that’s gone stale. The clearer you are about the problems, the better the recommendations you’ll get back.

Project goals and success metrics

Say what success looks like, and how you’ll measure it. Goals tend to fall into a few buckets: more qualified leads, a better user experience, support for recruiting, or easier content management. Name your top few and the metrics that matter—lead quality and quantity, engagement, conversions—so an agency can design toward outcomes rather than guesses.

Technical requirements

List the systems the site has to work with: CMS preferences, CRM integrations, marketing automation platforms, ERP integrations, and any specific accessibility requirements (for example, WCAG 2.2 Level AA). This is information only you can supply, and getting it down early saves everyone weeks.

Stakeholders and approval process

Tell agencies who’s involved and how decisions get made—who owns the project day to day, who signs off, and how many rounds of review you anticipate. A clear approval path is one of the biggest predictors of whether a project stays on schedule.

Budget range

Share a working budget range. You don’t have to publish a precise number in the document, but a range and a sense of fit will need to come up early. Keeping budget a secret tends to backfire: it produces proposals aimed at the wrong target and wastes everyone’s time, including yours. A good partner uses your range to recommend the right scope, not to spend every dollar. (If you’re not sure what’s realistic, our pricing page is a starting point.)

Timeline

Note your ideal timeline and whether any launch date is a hard requirement or a goal—and how much flexibility exists if an agency’s recommended schedule differs. Tying a launch to a real event, like a trade show or a product release, is useful context. An arbitrary deadline with no slack is a likely red flag.

Notice the through-line: every section above gives an agency the context to make a useful recommendation, and none of it tells the agency how to do its job. That’s the line a good RFP walks—rich on the problem, light on the prescription. Agencies need realistic context precisely so they can come back with realistic recommendations.

What to include in a website development RFP

If you want a quick reference, here’s the short list of what a useful website development RFP contains. Cover these and you’re done—anything beyond them is usually noise:

  • Company background — who you are, what you sell, who you serve.
  • Current website URL — so agencies can see the starting point for themselves.
  • Project goals — the outcomes you’re after, with metrics where you have them.
  • Existing challenges — what’s broken or underperforming today.
  • Technical requirements — CMS, CRM, marketing automation, ERP, accessibility, and integrations.
  • Budget range — a working range, even if not a fixed figure.
  • Timeline goals — target dates, and which are firm versus aspirational.
  • Key stakeholders — who’s involved and how decisions get made.
  • Proposal requirements — what you’d like agencies to send back (approach, relevant work, team, timeline, and pricing), kept reasonable.

What not to include in a website RFP

Just as important is what to leave out. These are the additions that turn a helpful document into an onerous one—and the reason experienced agencies often decline otherwise-good opportunities. They tend to be inherited from a procurement template or an AI draft rather than chosen on purpose.

Detailed solution requirements

Resist the urge to specify the solution—the exact page templates, the precise feature set, the technical architecture. You’re hiring an agency for that thinking. Describe the problem and the outcome you want, and let them propose how to get there. Over-specifying locks in decisions before discovery has even happened.

Requests for free strategy

This is the single biggest deterrent. The heaviest RFPs ask agencies to do the actual strategy and planning work up front—detailed explanations of exactly how they’d solve your problem, multi-page competitor teardowns, full sitemaps—just to be considered. That’s the thinking that normally happens after intake, inside a paid engagement. Asking for it on spec turns responding into a days-long project done for free, and the busiest, best agencies simply won’t.

We saw this recently in an otherwise excellent RFP from a good company we’d have loved to work with. Two very different bodies of work had to be bid together as one fixed package, and just submitting required a multi-page teardown of six competitor sites plus a fully itemized budget. The background material was genuinely great. The terms of responding were the only thing in the way.

Prescriptive agency processes

Don’t dictate the agency’s methodology—the exact phases, the revision-round counts, the week-by-week schedule. A capable firm already has a process refined across dozens of projects. Prescribing a different one doesn’t reduce risk; it introduces friction into a system that works precisely because it isn’t reinvented each time. Give the destination, not turn-by-turn directions.

Unrealistic timelines

A deadline with no slack—especially one set before anyone has scoped the work—signals trouble. Good agencies would rather tell you what’s realistic than promise a date they’ll have to miss. Share your real constraints and leave room for the agency to tell you what’s feasible.

Fixed pricing before discovery

Asking for a firm, itemized price without any discovery or conversation forces agencies to guess or pad, particularly for open-ended work that can’t be pinned to a clear specification until the gaps are known. A range and a scoping conversation get you to an honest number faster than a fixed bid demanded up front.

None of these is about giving the agency information; they’re about control. And they’re why a strong agency, choosing between two similar projects, will pick the one that reads like an invitation to collaborate over the one that reads like a contract to comply with.

Website RFP template

You don’t need a 30-page document or a downloadable form. A useful website RFP template is really just a short outline—fill each section with a few honest sentences and you’re done:

  • Company overview — who you are and who you serve.
  • Project background — why you’re doing this now, and what’s not working.
  • Website goals — the outcomes you want, with metrics where possible.
  • Technical requirements — systems, integrations, and accessibility needs.
  • Stakeholders — who’s involved and how decisions get made.
  • Budget — a working range.
  • Timeline — target dates, and which are firm.
  • Proposal submission requirements — what you’d like to see back, kept reasonable.

That’s the whole template. We’ve deliberately not turned it into a downloadable file, because the goal isn’t to hand you a form to fill in—it’s to help you think clearly about the project. These eight prompts will get you a document an agency can actually work with, and a better starting point than any generic template. If you’d like AI’s help, point it at organizing your notes into this outline, not at generating a “complete” RFP from scratch.

Signs your website RFP may be too restrictive

How do you know if your RFP has crossed from helpful to onerous? A few reliable signs:

  • It runs more than 5 pages. Length usually means prescription has crept in. The information an agency truly needs fits comfortably in a few pages.
  • It dictates the agency’s process. Mandated phases, deliverable orders, and methodologies tell the expert how to work.
  • It requires deliverables before discovery. Sitemaps, detailed approaches, or competitor teardowns demanded just to respond are unpaid strategy work.
  • It omits the budget. A range is context an agency needs; withholding it produces mismatched proposals.
  • It focuses on outputs rather than outcomes. Long lists of required features and pages, with little about the business result you’re chasing.

This is where AI deserves a closer look. Over the past year, more of the RFPs we receive show exactly these signs, and we think AI is part of the reason. In our own inbound, formal RFPs went from roughly one in 20 of our qualified website leads in 2025 to about one in eight so far in 2026—and the documents have gotten heavier.

The core problem is signal versus noise. Ask a chatbot to “write me a website RFP” from a few bullet points, and it will faithfully expand them into a complete-looking document modeled on the most exhaustive examples it can find. You can end up with an 18-page RFP where maybe two pages carry your actual priorities and the rest is scaffolding the tool assumed you needed—diluting the things that matter most.

There’s a better way to use the same tool. Sort your notes into must-have, should-have, and nice-to-have, then ask AI to organize them rather than invent them:

  • Instead of: “Create an RFP based on these inputs.”
  • Try: “Take these notes, which I’ve sorted into must-have, should-have, and nice-to-have, and organize them into a clear, concise list of goals and requirements to send a potential website partner.”

We’ve watched a too-restrictive RFP get fixed in real time. One prospect—anonymized—sent two versions. The first read like a compliance audit: “all of the following must be addressed,” “firms that cannot satisfy every requirement will not advance,” “all ten questions must be answered in order.” The underlying requirements were perfectly reasonable, and real thought had clearly gone into it; the tone and the response burden were the problem. Then a rewrite arrived that disclosed a budget range, cut the mandatory sections, replaced a complicated scoring rubric with four simple questions, and invited a conversation. Same company, same project—but the second version is one we actually wanted to answer.

The best website redesign projects start with a conversation

Strip everything else away and the principle is simple: you’re hiring an agency for expertise, and expertise needs room to work. The strongest website projects start as conversations, not procurement events.

And to be clear—we’re glad when companies reach out. There’s a real difference between an RFP blasted to a long list of agencies and one sent to a short, hand-picked group. If you’ve shortlisted us because you see a genuine fit, we’re happy to review whatever you’ve put together. We may push back on parts of it. That isn’t us being difficult; it’s us doing the job you’d be hiring us for. Part of a consultative partner’s value is seeing what’s hard to see from the inside and saying so early. You’d want an agency that does that, rather than one that quietly fills out its response, says yes to everything indiscriminately, and keeps its concerns to itself.

A good RFP creates clarity, not constraints. It aligns everyone on the problem and the outcome, then trusts the partner you’ve chosen to chart the route. That’s the difference between alignment and procurement theater—and, more often than not, the difference between a website project that struggles and one that succeeds.

The bottom line on writing a website RFP

A successful website redesign RFP communicates the essentials—your goals, your challenges, your stakeholders, your technical requirements, your budget, and your timeline—and stops there. The best ones are clear, concise, and focused on business outcomes rather than prescribing every detail of the solution.

Get that right and the payoff is real: better proposals, stronger agency partners, and a far better starting point for the redesign itself. If you’d like an example of the type of strategy brief we’d create as we work together on a project, our creative strategy brief guide includes a framework for the brief, and our strategic plan guide covers the strategy layer behind it. And because we focus exclusively on B2B industrial and technical companies, we’re glad to look at your brief—or just talk through the project—before you send anything anywhere.

What are your top goals for improving your website and marketing?

Let's Talk