Website Redesign RFP Template for B2B Teams

1. Project summary

Open with a short description of the company, the website, and the reason for the redesign. Give agencies enough business context to understand the stakes.

Include:

• Company name, market, offer, and primary customer groups
• Current website URL and platform
• Internal project owner and executive sponsor
• Reason for the redesign
• Target launch window
• Approved budget range or procurement constraint
• RFP schedule and selection date

Write the reason in commercial terms. A dated visual style may matter, but it does not explain the full project. Name the problems your team sees: unclear positioning, weak conversion paths, slow publishing, rigid templates, fragmented analytics, difficult maintenance, or a platform that no longer supports the company.

Copy-ready prompt

> [Company] is seeking a web design and development partner to redesign and rebuild [website]. The current site creates problems with [business, audience, content, conversion, or technical issues]. We want the new site to support [commercial and operational goals]. Our target launch window is [date or range], and our approved investment range is [range or procurement note].

2. Business goals and success measures

Tell agencies what the website must help the business accomplish. Separate the goals from the features you think will achieve them.

Useful goals may include:

• Help qualified buyers understand the offer and choose a next step
• Support a new positioning or product structure
• Give marketing more control over page creation and updates
• Improve the quality of demo, contact, or consultation paths
• Consolidate regional or product sites
• Reduce dependence on one developer for routine content work
• Create a maintainable system for future campaigns and pages

Define how your team will judge the project. Use measures you already track or can establish before launch. Examples include form completion quality, route-to-lead accuracy, content publishing time, page engagement, search visibility for priority topics, accessibility conformance, and performance thresholds.

Do not invent a target because an RFP template asks for one. If your baseline is missing, say the selected agency must help create the measurement plan during discovery.

3. Audiences and buying journeys

List the people the website serves and the decisions they need to make. Avoid broad labels without context.

For each audience, include:

• Role or buying responsibility
• Company type or segment
• Problem that brings the person to the site
• Information needed to evaluate the offer
• Objections or risks the site must address
• Desired next step

A B2B website may serve buyers, technical evaluators, partners, candidates, customers, and investors. Rank them. An agency cannot give every audience equal weight without weakening the navigation and message hierarchy.

Share approved research, sales-call themes, search data, CRM findings, or support insights when available. Label assumptions as assumptions.

4. Current website and known problems

Give agencies access to the evidence behind the RFP. A short problem list helps them prepare a better response than a request to “make the site modern.”

Cover:

• Current platform, hosting, and repository ownership
• Page count and content types
• Traffic sources and priority landing pages
• Current forms, CRM routes, and integrations
• CMS pain points and publishing constraints
• Performance, accessibility, SEO, or security concerns
• Known code, plugin, or infrastructure debt
• Regional, language, product, or permission complexity

Provide view access to analytics or technical systems during the finalist stage when your security rules allow it. If you cannot provide access, include exports or screenshots with private information removed.

State which findings your team has confirmed and which require agency validation. You want a partner to test the diagnosis, not repeat it.

5. Scope of work

Organize the scope by responsibility. Agencies need to know what they own, what your team owns, and what another vendor will deliver.

Strategy and discovery

Specify whether the engagement includes stakeholder interviews, audience research, analytics review, content audit, technical discovery, positioning work, sitemap development, conversion planning, or measurement design.

Ask each agency to name the decisions its discovery phase will produce. Workshops alone are not an outcome.

UX and visual design

Define the expected design work, including information architecture, wireframes, user flows, visual direction, page designs, responsive states, component design, prototyping, and design-system documentation.

State whether brand identity work sits inside the project. A website redesign cannot absorb an undefined rebrand without changing the scope.

Content

Name who will inventory, write, edit, approve, enter, and verify content. Include page estimates by type when possible. Identify legal, product, localization, or executive reviews that affect approval.

If the agency will write content, explain the subject-matter access it will receive. If your team will write it, ask the agency to define content deadlines and the effect of missed dates.

Development and CMS

Describe the capabilities the site needs instead of prescribing tools without cause. Include reusable page structures, structured content, preview, publishing roles, forms, search, resource libraries, localization, personalization, gated content, and campaign workflows.

Ask the agency to explain:

• Proposed architecture and why it fits the requirements
• What editors can change without development
• How components protect design consistency
• Hosting, deployment, monitoring, and rollback
• Repository, account, and code ownership
• Documentation, training, and handoff
• Expected maintenance and third-party costs

Integrations and data

List every known system that exchanges data with the website. Common examples include a CRM, marketing automation platform, consent manager, analytics tools, customer-data platform, applicant tracking system, product database, search service, and translation workflow.

For each integration, provide the owner, available documentation, environment access, data direction, authentication constraints, and acceptance criteria. “Integrate HubSpot” does not define forms, field mapping, routing, lifecycle updates, error handling, or consent behavior.

Migration, SEO, and redirects

Include the content inventory, assets, metadata, URL structure, redirect requirements, structured data, sitemap, robots rules, and search-console ownership. State whether the agency must migrate content or provide tools and instructions for your team.

Ask how the agency will verify migration completeness, redirect coverage, canonicals, metadata, and indexation controls before launch.

Quality assurance and launch

Require a test plan that names environments, devices, browsers, accessibility checks, performance checks, integrations, analytics, content review, security responsibilities, acceptance owners, launch steps, rollback, and post-launch support.

Define the accessibility target if your organization has one. Ask the agency to explain its design, development, and manual testing responsibilities rather than promising an undefined accessible website.

6. Deliverables and acceptance

Turn the scope into a deliverable list. Each item needs an owner, review method, and acceptance point.

A deliverable schedule may include:

Do not demand a complete project plan before discovery. Ask for the proposed phases, decision gates, dependencies, and client responsibilities. The selected team can build the detailed plan after it validates the assumptions.

7. Technical and operational requirements

Put hard constraints in one section so agencies do not discover them after selection.

Include requirements for:

• Security review, authentication, and data handling
• Hosting region, uptime, backup, or disaster recovery
• Browser and device support
• Accessibility standard
• Performance targets
• Privacy, consent, and legal review
• Internal technology standards
• Source-code, design-file, domain, and account ownership
• Documentation and staff training
• Warranty and support

Separate a requirement from a preference. If your IT team mandates a service, state the owner and reason. If marketing prefers a CMS because it knows the interface, ask agencies to evaluate that preference against the full workflow.

8. Budget and commercial response

Give agencies a budget range when your procurement policy permits it. A range helps them recommend the right scope, team, and sequence. Without one, you may receive proposals for different classes of project.

Require each commercial response to show:

• Total fee and payment schedule
• Fees by phase or workstream
• Assumptions behind the price
• Client responsibilities
• Exclusions
• Optional work
• Third-party software, hosting, and service costs
• Rate or method for approved changes
• Tax and travel treatment when relevant
• Proposal validity period

Ask agencies to flag scope they consider incompatible with the budget. That answer carries more value than a low total supported by quiet exclusions.

9. Timeline and decision process

Publish one schedule for every bidder.

Include:

• RFP issue date
• Deadline for agency questions
• Date your team will share answers
• Proposal deadline
• Finalist interview window
• Reference-check period
• Selection and contracting dates
• Desired kickoff and launch window

Name the dates that come from a business event and the dates your team can adjust. Ask agencies to identify dependencies, decision deadlines, and the client staffing needed to hold the schedule.

Keep bidder answers available to every participant unless a question contains confidential agency information. Shared facts reduce accidental advantages.

10. Agency response format

Give each agency the same response structure. You will spend less time hunting through pitch decks and more time comparing the work.

Request:

1. Understanding of the business problem
2. Proposed approach and phases
3. Scope, deliverables, and exclusions
4. Project team, roles, location, and availability
5. Relevant work with context the agency can substantiate
6. Technical and CMS recommendation
7. Content, migration, analytics, and QA approach
8. Project governance, feedback, and change control
9. Timeline, dependencies, and client responsibilities
10. Fees, assumptions, options, and recurring costs
11. Handoff, maintenance, and support
12. References your team may contact

Set page or presentation limits where procurement requires them, but do not reward compression that hides assumptions. Permit an appendix for technical detail.

11. Evaluation criteria

Tell bidders how your team will score the proposals. The criteria should reflect project risk, not procurement habit.

A practical scorecard may cover:

• Quality of diagnosis and strategic approach
• Fit between the proposed scope and business goals
• UX, design, development, and CMS judgment
• Content, migration, integration, and analytics plan
• Delivery team and governance
• QA, accessibility, launch, and maintenance plan
• Commercial clarity and value
• Relevant experience and references

Assign weights before proposals arrive. Have reviewers score alone before the committee discussion. Keep proposal, interview, reference, and commercial findings visible so a polished presentation does not erase a weak delivery plan.

12. Appendices

Move detailed evidence into appendices. Useful attachments include:

• Current sitemap or crawl export
• Page and content-type inventory
• Analytics summary
• Integration list and architecture notes
• Brand guidelines
• Accessibility findings
• SEO and redirect data
• Technical constraints
• Procurement terms
• Required contract language

Remove private customer, employee, and credential data before distribution. Give every bidder access to the same package.

Copy-ready RFP outline

Use this outline as the document shell:

1. Company and project summary
2. Business goals and success measures
3. Priority audiences and journeys
4. Current website and known problems
5. Scope of work
6. Deliverables and acceptance criteria
7. Technical and operational requirements
8. Budget and commercial response
9. Timeline and procurement process
10. Required agency response format
11. Evaluation criteria
12. Terms, confidentiality, and conflicts
13. Appendices

Before sending it, ask the internal owners of marketing, content, technology, sales operations, legal, and procurement to review the sections they will own. Remove requirements nobody can explain or accept.

Frequently asked questions

How long should a website redesign RFP be?

Make it long enough to define the commercial problem, scope boundaries, requirements, decision process, and response format. Move inventories and detailed technical material into appendices so agencies can find the facts without searching through narrative.

Should a website redesign RFP include a budget?

Include an approved range or ceiling when you have one. It lets agencies recommend a responsible scope and keeps each proposal on the same commercial basis. If procurement prevents disclosure, state that and require agencies to list assumptions, options, and exclusions with the price.

Should the RFP name a CMS or technology stack?

Name required technology when a valid business, security, integration, or internal capability constraint exists. Otherwise describe editorial workflows, integrations, governance, performance, and maintenance needs, then ask agencies to recommend the architecture.

How many agencies should receive the RFP?

Send it to a focused group that fits the project and can receive the same information. A short list gives your team enough contrast without creating a review burden that weakens interviews, reference checks, and proposal evaluation.

Make the RFP earn comparable proposals

A good RFP does not remove uncertainty from a website redesign. It shows bidders where the uncertainty sits, who owns the decisions, and how each agency should account for it.

Virdis helps B2B teams plan and deliver custom website redesigns across strategy, design, development, CMS architecture, integrations, analytics, migration, and launch. If your RFP still leaves major scope boundaries unresolved, settle those boundaries before you compare agency totals.