Opinions expressed by Entrepreneur contributors are their own.
Key Takeaways
- Define the business problem and desired outcomes before prescribing pages, templates or technology solutions.
- Separate true requirements from assumptions so agencies know where they can challenge and recommend.
- Evaluate agencies by the questions they ask, the tradeoffs they identify and the judgment they bring to the process.
I have read website Requests for Proposals (RFPs) that specify the CMS, sitemap, number of templates, integrations, design rounds, development requirements and launch date down to the smallest detail. Sometimes they are 20 or 30 pages long.
Yet after reading them, the most important question is still unanswered: What is the business actually trying to change?
This is where many website RFPs go wrong. In an effort to make the project easier to scope and proposals easier to compare, organizations define so much of the solution in advance that they leave very little room for an agency to think strategically.
At that point, the agency is no longer being asked to help solve a problem. It is being asked to price someone else’s proposed solution.
There is nothing inherently wrong with that if execution is all you need. But if you are looking for a creative agency that can challenge assumptions, uncover opportunities and help determine what the website should become, the RFP needs to create room for that kind of thinking.
Ask agencies what they would challenge
One of the most revealing questions in an RFP may be the simplest: What would you challenge about what we have asked for?
Most RFPs ask agencies to explain how they will fulfill the requirements. Far fewer ask what may be missing, which assumptions deserve validation or what the agency would change before work begins.
Ask which parts of the proposed scope they would revisit during discovery. Ask what they would prioritize if the budget or timeline became constrained. Ask what they believe should happen during the first 30 days before major design or technology decisions are made.
Those answers show you how an agency thinks when it is not simply following instructions.
A strong partner should be able to respect the organization’s knowledge while still bringing an independent perspective. If every respondent simply repeats the RFP back in slightly different language, the process may be selecting for compliance rather than judgment.
Start with what has changed in the business
To get useful answers, agencies first need enough context to understand why the project exists.
Consider a B2B company that has grown through several acquisitions. Its website now contains overlapping service categories, different terminology from different business units and pages that were added over time without reconsidering the overall structure.
A weak RFP might respond by prescribing a new 75-page website, a revised navigation and a fixed number of page templates.
A better RFP would explain that customers are having difficulty understanding how the company’s services fit together, sales teams are compensating with their own presentations and the organization needs the website to present a clearer, unified offering.
Those descriptions may eventually lead to a new sitemap, fewer pages, new templates or a different content model, but they do not determine those answers before the agency has examined the problem.
That context is far more useful than simply specifying production quantities.
Separate requirements from assumptions
Every project has legitimate constraints. An organization may need to remain on a particular CMS because of internal infrastructure or meet specific security, accessibility, compliance, integration or SEO requirements. Those should be clearly identified.
Other decisions may simply represent the organization’s current thinking. The existing sitemap, content structure, navigation, number of templates or parts of the proposed technology approach may deserve another look.
One useful distinction is to state directly: Here are our fixed requirements, and here are the areas where we are looking for recommendations.
The same applies to deliverables. Instead of only saying, “We need a new website with 75 pages,” explain what should be different when the work is finished. Perhaps customers need to understand the offering more clearly, sales needs stronger digital support or marketing needs greater publishing flexibility.
The more clearly you define the business outcome, the more room an agency has to determine the right solution.
Explain how decisions will actually be made
B2B website projects rarely belong to one department.
Marketing may lead the initiative, but IT has platform requirements, legal reviews claims, sales understands customer objections, leadership has positioning priorities, and subject-matter experts often hold the knowledge needed to create useful content.
An RFP should provide some visibility into that environment.
Who owns the project? Who needs to be consulted? Who has approval authority? Are there different business units involved? Are there decisions that still need executive alignment?
This does not require a complicated organizational chart. It simply helps an agency understand whether it is proposing a website project or helping navigate a broader organizational process.
That distinction has significant implications for scope, timing and methodology.
Give agencies enough financial context to make choices
Organizations are sometimes reluctant to include a budget because they worry every proposal will simply arrive at that number.
But withholding all financial context creates a different problem. Agencies begin designing entirely different engagements around entirely different assumptions, making the resulting proposals difficult to compare.
A $75,000 website and a $300,000 digital transformation may both be legitimate approaches to the same underlying challenge, but they are not comparable scopes.
Providing a realistic range does not mean every agency will simply price to the ceiling. It allows them to explain what they believe should fit within that investment, what they would prioritize and what they would recommend phasing until later.
That makes the differences between proposals more useful, not less.
Evaluate the thinking, not just the proposal
A polished presentation, a long capabilities list and dozens of relevant portfolio examples can all be reassuring, but they do not necessarily tell you how an agency will behave when the project becomes complicated.
Pay closer attention to the questions they ask, the assumptions they question, the risks they identify and the tradeoffs they are willing to explain.
The best RFPs provide enough structure for agencies to understand the assignment without pretending that every important decision has already been made. They establish the business problem, the genuine constraints and the desired outcomes while leaving room for expertise to influence the path forward.
If you want an order taker, write down the order. If you want a strategic partner, give them a meaningful problem to solve.
Key Takeaways
- Define the business problem and desired outcomes before prescribing pages, templates or technology solutions.
- Separate true requirements from assumptions so agencies know where they can challenge and recommend.
- Evaluate agencies by the questions they ask, the tradeoffs they identify and the judgment they bring to the process.
I have read website Requests for Proposals (RFPs) that specify the CMS, sitemap, number of templates, integrations, design rounds, development requirements and launch date down to the smallest detail. Sometimes they are 20 or 30 pages long.
Yet after reading them, the most important question is still unanswered: What is the business actually trying to change?
This is where many website RFPs go wrong. In an effort to make the project easier to scope and proposals easier to compare, organizations define so much of the solution in advance that they leave very little room for an agency to think strategically.