Reading time: 19 min read
Tips for writing a successful RFP for your CMS / DXP project
Website RFP advice from the other side.
TL;DR - tips for writing CMS and DXP RFPs
Most RFP guides tell you to add more sections, more questions, more requirements. I think that's backwards. After years of responding to (and winning) RFPs for major website and CMS projects, here's what I think actually works.
Get pricing aligned before anyone invests. Use an RFI to get ballpark pricing from comparable work. Confirm you're in the same universe before the heavy lifting starts.
Partner over platform. The right team on a decent platform will outperform the wrong team on a perfect one. Let partners recommend the technology and tell you why. That's where real differentiation shows up.
Ask fewer, better questions. Open-ended questions that invite real answers will tell you more than a hundred checkboxes. And break the process into phases. Smaller decisions made faster beat one massive evaluation that stalls under its own weight.
A playbook for finding the right partner, built from years of responding to and winning RFPs. And if you need help building your RFP or want a partner's perspective, invite Fishtank to respond to your next RFP.
A CMS RFP guide built from experience
I see a lot of RFPs. At Fishtank, we respond to RFPs for major website and digital platform projects regularly, and honestly, we do well in them. I'm not complaining. But after seeing about 100 of these come across my desk - some brilliant, some painful. I've developed some strong opinions about what makes an RFP process actually work.
Regardless of what you call it - a website project, a CMS selection, a DXP evaluation, a digital platform initiative - this is something most organizations do rarely. Once every four or five years. Maybe the team has never done it before. And it's genuinely difficult to ask the right questions in the right way to get the answers you actually need.
Speaking from experience
I think there are some approaches that can genuinely improve the RFP process, for the organizations running them and the partners responding.
If this resonates, we'd love to hear from you. Invite Fishtank to respond to your next RFP.
The RFP is about finding the right partner - not defining the entire project
Here's something I've seen play out more times than I can count: an organization tries to fully define a project before issuing the RFP. They want a complete spec, a locked scope, a detailed requirements document, and the RFP stalls. Sometimes it never goes out at all.
The problem is that some projects are too big, too complex, or too organizationally tangled to define upfront. There's internal misalignment. Budget is unclear. Stakeholders need convincing. And organizations freeze because they think they need to have it all figured out before they can go to market.
They don't.
The real purpose of an RFP is to find the right partner - someone who can work through the project with you, not just bid on a finished spec. If you can't fully define the project yet, that's OK. That's actually normal for large website and platform initiatives. What you need is a partner who's been through this before and can help you figure it out.
Internal alignment matters, and I'll talk about stakeholders later. But the RFP shouldn't wait until everything is perfect internally. Orient it toward finding the people who will work alongside you. The rest gets figured out together.
Get pricing off the table before your RFP starts
Let's be honest about something: no matter how much work goes into an RFP - the thoughtful questions, the carefully weighted scoring criteria - everyone is scrolling straight to the price.
Straight. To. How. Much.
Even when the scoring criteria says "price is 20% of the evaluation" or "price is 30%," there's still a hard limit. However you weight it in your scoring criteria, price at some level is pass/fail. There's a number you won't exceed, and that's true whether you say so in the RFP or not.
So what happens?
Organizations and their potential partners waste enormous amounts of time dancing around pricing in a low-information environment. Partners assemble 50-page, sometimes 100-page RFP responses, and then get disqualified on price. Or worse: partners who aren't sure if they're even in the right ballpark submit half-hearted replies because they can't justify investing serious effort when the core input driving the outcome is uncertain.
"I don't even know if we're a player for this. Let's not even bother replying."
That's a lot of wasted energy on both sides.
The kind of pricing you actually need doesn't happen in an RFP
The kind of discovery that produces accurate, detailed pricing doesn't happen during an RFP process. At Fishtank, we always try to price sharply - accurately, informed, competitive - but RFPs mean we're operating with limited information. We're scoping based on other projects we've completed and a rough understanding of your requirements. That's it. That's the reality.
A question-and-answer period doesn't fix this. It's not fluid, it's not probing, and it's not the kind of two-way conversation you need to truly understand scope and complexity. You don't get the conversational "but what if..." follow-ups. You can't dive into something that feels off. You're getting written answers to written questions. It's just not a discovery.
Align on budget before anyone picks up a pen
Here's an idea for your website RFP that essentially no one does, but I would love to see them start.
Run a two-phase process leading with costs. Start with a brief RFI phase before the full RFP. In that RFI, simply ask for ballpark pricing based on previous work.
| What you ask in the RFI | What you learn |
|---|---|
| Based on our website and comparable projects you've delivered, provide a price range for those projects including implementation services and platform. | Real market pricing grounded in actual comparable work, not guesswork |
| Provide a brief overview of your organization, your relevant experience, and the platform you would recommend for this project. | A first look at who these partners are, what they're best at, and how they think about your business |
| Highlight two to three projects most relevant to ours - include scope, timeline, and outcome. | Concrete evidence of delivery at a similar scale, in a similar context |
| Describe the value proposition you believe your organization brings to a project like this. | Early signal on how well they understand your business and what they choose to lead with |
That's it.
A couple pages from each respondent. Get a sense of whether everyone's in the same ballpark before asking anyone to invest in a full RFP response.
Get a sense of whether everyone's in the same ballpark before asking anyone to invest in a full RFP response.
You don't have to reveal your exact budget. But let everyone submit with genuine interest and get a sniff of whether there's alignment before the heavy lifting starts.
If companies have experience in your vertical with similar projects, it's a small ask. If they don't have that, would they be a strong candidate?
This simple step would allow everyone to put their responses together with more confidence and higher quality, and make sure you're aligned on critical decision-making factors before anyone commits weeks of effort.
If price ranges work, invite the partner to the proper RFP. You'll have alignment and buy-in, and the quality of the responses you get back will be significantly higher.
Tips for approaching pricing early
If there's one thing to take away from this section, it's this: don't let pricing be the thing that derails your process after everyone has already invested.
- Use an RFI phase to get aligned. Confirm you're in the same ballpark before anyone invests in a full response.
- Filter by budget tier from the start. Don't waste anyone's time - yours or theirs - on misaligned pricing.
- Build some flexibility into your range. Don't set your ceiling so tight that a strong option gets filtered out before you even see it. You're setting a filter, not a final number.
The RFI concept here is actually the first phase of a broader approach. I'll lay out a full phased model later that turns the entire RFP into a series of faster, more focused decisions.
Your partner will make or break your website - not the platform
This is probably my most strongly held opinion: partner > platform.
The right partner - one who truly understands your business and can execute at a high level - is more important than the platform you choose. That's the lead. It doesn't matter how great your technology is if you've chosen the wrong partner.
It doesn't matter how great your technology is if you've chosen the wrong partner.
If you're set on a specific CMS or DXP, great, find the best implementation partner for that platform. But if you're unsure? Evaluate the partner and the platform together, and weight the partner more heavily. A great Sitecore team can build you a great website on Sitecore. A great WordPress team can do the same on WordPress. The outcome you're after comes from the people, not the product.
There are real differences between DXP platforms. But within a tier - enterprise, mid-market, entry-level - the feature sets overlap more than vendors want to admit.
The partner is what makes the platform successful. Platforms don't intrinsically solve your business problems. Successful implementations do.
Let your partner pick the platform - and tell you why
This is the most important idea in this section. Instead of choosing a platform and then finding a partner, ask each partner to recommend the one technology they believe is right for your organization, and explain why.
When you do this, you get something far more valuable than a list of checkboxes. You get each partner leading with their strongest story: the technology they know best, the approach they've proven, and a vision for your success that's grounded in real experience. That's where genuine differentiation happens.
Have it be a presentation. Let them show you what they see for your organization - their company, their platform, their approach to your success.
What to actually evaluate in a partner
Don't just look at portfolios and credentials. Here's what actually predicts success:
| What to evaluate | Why it matters |
|---|---|
| Demonstrated success on the platform | Not "we can do this." Show me where you've done it, for organizations like mine. Real projects, real outcomes. |
| Vision from the start | The right partner should almost be able to see your finished website from the beginning. They know the platform, they've worked in your vertical, they know what worked and what didn't. |
| Understand the future of your business | They understand the future of the platform, have insights into your vertical, and are always thinking about what's next for you. |
| A strong point of view | Pick partners who are passionate, who have a clear position, who believe in your success. Strong partners with strong stories. That's what wins. |
| The actual team working on your project | Who are these people? What have they built? Organizational knowledge and team-level expertise will define your experience more than any platform feature. |
If they say they're good at everything, they're probably good at nothing
A partner who says "we're great at everything" across multiple CMS platforms is probably just hedging, wanting to keep the door open and lacking conviction in what platform is best for your organization. While I do say the partner is more important than the platform, I don't believe you'll find a strong partner to deliver ROI to your organization without a strong point-of-view regarding the right technology. They are a package.
At Fishtank, we work incredibly hard to be the best at Sitecore, and I know how hard that is. The sheer force of will it takes from the executive level down to be truly excellent on a single platform is enormous. And there's still always room to improve.
Pick someone with focus and depth. Someone who has delivered at the level you need and can prove it.
Be open to spending more to get what you need
All-in cost matters. I won't pretend it doesn't. But think of it like buying a house: you start with a budget, and sometimes you need to stretch a little to get the right one.
If the right platform and partner cost $50,000 more than you were expecting in licensing and hosting, but it's an amazing team, with great experience and strong platform, that delta pays for itself through effective delivery, faster execution, and increased long-term value from the platform.
Don't let a marginal cost difference cost you the right partnership. If you've done the pricing alignment work upfront and you're comparing finalists who are all in the right range, the decision should come down to who's going to deliver the best outcome, not who shaved $10K off the bottom line.
Final words on partner vs. platform
The platform matters, but not as much as the people behind it. Here's what I'd keep in mind.
- Partner > platform. The right partner on a decent platform will outperform the wrong partner on a perfect platform. Every time.
- Let partners lead with their best. Ask them to recommend the platform and tell you why. Don't constrain them to your guess.
- Look for depth, not breadth. A partner who's genuinely excellent on one platform will deliver more than one who claims to be good at everything.
If you're evaluating partners for your next project, check out Fishtank's deep expertise across industries, and consider inviting us to respond.
Stop leading the witness - ask fewer RFP questions, get better answers
Most RFP advice tells you to be thorough - include everything, cover every requirement, ask about every capability. I think that approach actively undermines the process.
Don't give them your playbook
The more questions you ask, the more you're answering your own questions.
The more questions you ask, the more you're answering your own questions. You're giving partners a roadmap to tell you exactly what you want to hear, which directly undermines the differentiation you're trying to surface.
For example, if you ask "What's your security procedure for dynamic application system testing?" you're going to get answers about their security procedure whether they have one or not. You're better off asking broad questions and evaluating the answers on merit to see the maturity with which they approach topics.
The materiality test
Here's a question I ask internally when reviewing an RFP for a website project: "Would the answer to this question materially change our reply, either in direction or in price?"
Most of the time, the honest answer is no, so we don't ask. There are exceptions - analytics requirements that might drive CMS platform pricing, or high-level integrations that introduce real complexity. But for the vast majority of checklist-style questions, the answers don't change anything meaningful.
See who is replying
As I've alluded to already, asking fewer more open questions allows you to see who your potential partners are much clearer. They'll lean into their own perspective and tell you where they can provide value.
You still might not be asking the right questions
For all the amazing questions you can ask in an RFP, we still may miss asking the important ones. Sometimes we'll look at an RFP and wonder, "where can we tell them about an accelerator for their vertical?" or "where can we tell them about the transformational impact we've had on operations team?"
It's important to be open to finding partners who might be delivering beyond what you're looking for.
RFP questions that actually reveal who your partner is
This is where it gets practical. These are the questions that hit on the critical factors while leaving respondents enough room to show you who they actually are. They're open-ended by design. They invite real answers grounded in real experience. And they're the kind of questions that will genuinely differentiate one partner from another in a way that a hundred yes/no checkboxes never will.
Vision, differentiation, and track record
- Give us an overview of your company, its history, and where you're headed.
- Provide an executive overview of your proposed solution alongside a technical breakdown.
- What are the differentiating factors and advantages you feel you bring to our organization?
- Highlight previous customers you feel are relevant to us - in our vertical or in related work - and tell us why.
- What are the differentiating features of the technology you're presenting?
- Based on our website and your current understanding of our traffic (which we'll provide), give us a brief assessment.
Process, people, and how the work actually gets done
- Tell us about your discovery process for a project like this.
- Walk us through your UX design process.
- Tell us about the key individuals who would work on our project - their background and what they've delivered.
- How does your testing process work - the people, the tools, the integration?
- Describe your approach to training and user enablement.
Honesty, risk, and how they handle adversity
- What are the risks we might face in a project like this?
- Tell us about the reasons your last projects went over budget or experienced delays.
That second question is one of my favorites. It's fair. It's not prejudicial. Every large project hits obstacles, and the bigger the project, the more likely you are to encounter roadblocks. What it reveals is how a partner communicates, how self-aware they are, and whether you'd have an open, forward-facing working relationship. If you're going to collaborate in the future, you want to see that kind of honesty now.
Capabilities - ask for point of view, not feature lists
- Tell us your point of view on website performance and how you approach it.
- What's your experience with personalization?
- How do you approach content architecture for an organization like ours?
- Tell us about your experience with accessibility.
The principle here is simple: don't ask "can you do this?" That gets you a yes from everyone. Ask for their point of view and let them show you what they know. The depth and specificity of their answer will tell you everything.
Forward-looking questions that reveal maturity
- Where is your organization positioning itself with AI? How do you see it affecting our business in the near term?
- Describe your support and operations model. How do your customers succeed long-term?
- How do you stay current with platform evolution?
AI is worth asking about. It's 2026, and understanding whether a partner's vision aligns with your corporate attitude is genuinely valuable. I wouldn't make it a deal-breaker either way, but it tells you a lot.
Support and operations sits near the line. Everyone has a support model, but how they describe it is incredibly revealing. If this is a longer-term relationship, this is where you'll see who's built for it.
Use RFP answer limits to signal what actually matters to you
This is a tactical tip, but it's effective.
Set suggested word limits for each answer. This protects you from massive, difficult-to-parse responses that slow down your evaluation. It also helps respondents focus and avoid overwriting in ways that are hard to read.
But here's the smarter play - use limits as a signal for importance:
| Format | What it signals to the respondent |
|---|---|
| Limited to 200 words | This is straightforward. Give us the facts, keep it concise. |
| Limited to 500 words | I want some depth here, but don't overdo it. |
| Unlimited | This is important to us. Give us your best. Tell us everything you think we need to know. |
When some answers are capped and others are wide open, you're cueing respondents about where you want depth and where you just need the basics. It's a simple way to communicate priority and manage the volume of what comes back to you.
This also helps you spend your evaluation time where it matters most. Shorter limits on straightforward questions mean less to read, less to score, and more of your attention reserved for the answers that actually differentiate one partner from another. Which ties directly into the next point.
Respect everyone's time - including your own
Evaluating and scoring RFP responses will take more of your time than most teams plan for. This is an additional job layered on top of everyone's existing responsibilities, and it adds up fast.
Every question you include is a question you have to read, score, and compare across multiple vendors. So it's worth asking: among all those questions and scoring spreadsheets, which ones are actually going to help you make a better decision? Which ones are genuinely differentiating, and which ones are just there because someone in the room thought they should be?
Design your RFP to produce the right amount of information to make a great decision. Not the maximum amount of information.
Design your RFP to produce the right amount of information to make a great decision. Not the maximum amount of information.
And one more thing: stick to the timeline you commit to. Or at the very least, communicate any delays immediately and transparently. RFPs are a lot of work, for you and for the partners responding. Respect that effort by setting a realistic evaluation timeline and actually delivering on it. If your process slips by months, the teams that were proposed get reassigned and the momentum dies. Set yourself up to make a decision and move forward.
Break RFPs into phases - make smaller decisions faster
Remember the RFI approach from the pricing section? That's the first phase of a bigger picture. Instead of one massive RFP that tries to answer every question at once, break your entire process into a series of shorter phases, each with a clear purpose and a quick decision at the end.
It might look something like this:
- Phase 1 - RFI: Confirm fit and price alignment. Filter down to partners who are in the right ballpark. One to two pages, a few days to evaluate.
- Phase 2 - RFP: Ask your shortlisted partners for conceptual pitches. How do they see your project? What's their approach, their platform, their vision? This is where differentiation happens.
- Phase 3 - Presentations: Meet the finalists. Let them pitch in person. See the people, hear the story, ask the hard questions face-to-face. This is where you get a real feel for who these organizations are.
- Phase 4 - Compliance and validation: You've already made your decision, conditionally. Now run the security review, the infrastructure validation, the legal and procurement checks. These are material yes-or-no questions, and they belong here, not at the top of the funnel.
This kind of staged process has a few real advantages:
- Easier to bring the right stakeholders in at each phase. You're asking a smaller group to make a focused decision, not asking everyone to digest a 100-page submission.
- Incremental reveal of information helps your team align and build confidence as you go, rather than trying to absorb everything at once.
- A series of small, quick decisions is almost always faster than one enormous evaluation that bogs down under its own weight.
The alternative - asking partners to submit everything upfront and then trying to evaluate it all in one pass - tends to create exactly the kind of organizational glut that stalls decisions. Too much information, too many stakeholders, too many competing priorities, and suddenly your timeline has slipped by months.
Who needs to be in the room for your RFP (and who doesn't)
The organizations that run the smoothest RFP processes are the ones who think carefully about who's involved, and when. Not every stakeholder needs to be in every meeting. But every stakeholder who could become a gatekeeper later needs to be aware of and aligned with the process from the start.
The key is matching involvement to the phase where each group adds the most value. Here is a hypothetical breakdown:
| Stakeholder | RFI / early alignment | RFP evaluation | Shortlist / presentations | Post-selection |
|---|---|---|---|---|
| Marketing / business owners | Define goals, shape requirements | Lead evaluation of vision, approach, and fit | Primary evaluators in partner presentations | Day-to-day relationship with the partner |
| Technology | Input on integration and architecture constraints | Evaluate technical approach and feasibility | Technical deep-dive with shortlisted partners | Architecture and implementation oversight |
| Executive sponsor | Confirm budget range and strategic alignment | Briefed on progress, available for decisions | Final decision-making authority | Escalation path and organizational champion |
| Security & infrastructure | High-level awareness only | Review security posture, hosting, and platform requirements | Validate shortlisted partners on security and infrastructure | Full security review, deployment planning, and sign-off |
| Procurement & legal | Structure the process, set timelines, flag regulatory constraints | Manage fairness, compliance, and process | Contract review and commercial negotiation | Agreement finalization and ongoing vendor management |
The pattern here is straightforward: marketing, technology, and your executive sponsor are your core evaluation team throughout the process. Procurement and legal keep things structured and compliant. Security and infrastructure are informed early so nothing comes as a surprise, but they do their heaviest work after you've narrowed the field.
Don't front-load an 80-page security questionnaire inside the RFP when a focused security review with your two finalists will be far more effective. Same with deep infrastructure validation. Bring the right expertise to bear at the right time. It's better for everyone.
RFP takeaways
The goal of an RFP isn't to select the cheapest vendor or even the "best" CMS. It's to find the partner who will make your organization successful. That's a fundamentally different question, and it should shape every part of how you design your process.
- Lead with pricing. Use an RFI to get ballpark pricing before anyone invests in a full response. Don't let pricing derail the process after everyone has already invested.
- Partner over platform. The right partner on a decent platform beats the wrong partner on a perfect one. Every time.
- Ask fewer, better questions. Open-ended questions differentiate partners in ways checklists never will.
- Break it into phases. RFI, then RFP, then presentations, then compliance. Smaller decisions, faster momentum.
If you're getting ready to issue an RFP for a website, CMS, or digital platform, talk to Fishtank about your next RFP. I'd encourage you to consider us as a respondent. We've been winning these for a long time and we'd love the chance to show you why. Browse our latest thinking on digital strategy and CMS, or let's get the conversation started.