B2B Website Redesign RFP Requirements: What Agencies Need to Scope the Work

Start with the commercial problem

Open with the reason the business needs a new website. Skip the company history unless it changes the work.

Name the problems your team can observe:

• Buyers struggle to understand the offer or choose the right path.
• Marketing cannot launch pages without developer support.
• Sales sends prospects to PDFs because the site lacks useful proof or product detail.
• The CMS cannot support regions, products, campaigns, or structured content.
• Analytics cannot connect website actions to the funnel stages your team uses.
• Slow approvals and fragile components make routine updates risky.

Then state the decisions the website should help visitors make. A B2B site may need buyers to identify a use case, compare products, assess technical fit, trust the company, or request a conversation. These jobs give the agency a stronger basis for information architecture and page strategy than a request for a “modern look.”

Document the business constraints beside the goals. Include the target launch window, fixed events, compliance reviews, contract deadlines, internal freezes, and dependencies on a rebrand or product release.

Define audiences by buying context

A list of job titles gives an agency little to work with. Explain what each audience needs from the site and what blocks its decision.

For each audience, provide:

• the problem or trigger that brings the person to the site;
• the questions that person needs answered;
• the proof required to trust the answer;
• the action that person should take;
• any role in the buying committee or approval process.

A technical evaluator and an executive sponsor may visit the same product page with different concerns. The evaluator wants implementation details, security information, and integration fit. The sponsor wants the commercial case and the cost of delay. Your requirements should help the agency design paths for both without cloning the site into separate experiences.

Include current sales objections, common support questions, and the materials your sales team sends after calls. Those sources reveal missing website content faster than a demographic persona deck.

Inventory the pages and content systems

Agencies need page volume, page types, and content condition to estimate strategy, design, migration, and CMS work.

Provide a current URL inventory if one exists. Group the pages by type, such as product, solution, industry, resource, case study, legal, campaign, and company pages. Mark pages your team plans to keep, rewrite, merge, archive, or create.

Separate page count from template count. Fifty articles may use one template. Six product pages may need shared sections with product-specific data. That distinction affects the content model and development scope.

State who owns each part of the content work:

If your team has not completed the inventory, say so. Ask agencies to price discovery and inventory work as a named phase rather than hiding it inside a general strategy line.

Describe CMS and publishing requirements

Ask editors what they need to publish, not which CMS interface they like.

Document the content types, reusable fields, approval steps, preview needs, scheduled publishing, localization, permissions, and asset handling. Name the people who will maintain the system and their technical comfort. Include the expected publishing frequency and any campaign spikes.

A B2B marketing team may need structured product data to appear across product pages, comparison pages, resource calls to action, and sales enablement pages. If editors copy that data into several rich-text fields, updates drift. The RFP should identify the reuse requirement so the agency can design the content model around it.

Cover governance too. State who may create templates, edit global navigation, publish legal copy, change conversion events, or add third-party scripts. Maintainability depends on those permissions as much as the CMS vendor.

Avoid locking the RFP to a platform unless your company has a firm reason. A security policy, current enterprise contract, internal development standard, or required integration may justify the constraint. Give agencies the requirements and ask them to defend their recommendation when no firm constraint exists.

List integrations with owners and data flows

“Integrate with HubSpot” does not define a scope. Name the forms, records, fields, consent rules, routing logic, and failure behavior involved.

For each integration, document:

• the system and account owner;
• the data sent in each direction;
• required fields and validation rules;
• authentication or security constraints;
• environments available for testing;
• error handling and monitoring;
• the person who can grant access and approve the result.

Common website integrations include CRM, marketing automation, consent management, analytics, customer data platforms, search, recruiting, support, event registration, account portals, and product documentation.

Flag systems that lack a sandbox or a responsive internal owner. They can control the schedule even when the website work stays on track.

Define conversion and analytics requirements

List the actions the business values and the information needed to evaluate them. Do not reduce the requirement to “install GA4.”

Your measurement section should name:

• primary and secondary conversion events;
• form types and success states;
• campaign and source attribution requirements;
• CRM fields needed for lead routing or reporting;
• consent behavior by region;
• cross-domain or subdomain tracking;
• internal traffic and test-traffic controls;
• the dashboards or teams that consume the data.

Ask the agency to describe its event naming, data-layer plan, quality checks, and handoff documentation. If another partner owns analytics, define the boundary between the website agency and that partner. Someone must own the browser implementation, tag configuration, consent behavior, and end-to-end test.

Set accessibility, performance, SEO, and security expectations

Turn broad quality goals into testable requirements.

For accessibility, identify the standard and target level your organization uses, the page and component coverage, the testing method, and the process for fixing issues. Include content responsibilities such as alternative text, heading structure, captions, and link labels. Accessibility work spans design, development, content, and governance.

For performance, name the page types, devices, network conditions, third-party scripts, and measurement tools that matter. Ask agencies to explain how they will test production builds rather than presenting a single score from a clean demo page.

For SEO, cover redirect mapping, metadata, canonicals, XML sitemaps, robots directives, structured data, internal links, staging controls, and post-launch checks. State whether URLs may change and who approves the redirect map.

For security and privacy, provide approved hosting constraints, data residency requirements, vendor review steps, cookie rules, retention policies, vulnerability testing expectations, and incident contacts. Your agency cannot price an unknown procurement process.

Make design scope concrete

Explain which brand assets exist and which ones need work. Include current guidelines, fonts, logo files, photography, illustration systems, icon sets, and product UI assets.

List the page types and reusable components you expect the design system to support. Ask for responsive states, interaction states, form states, error states, and CMS editing considerations. A desktop homepage concept does not define a production-ready design system.

State the review structure. Name the decision maker, contributors, number of review rounds, and feedback method. Require consolidated feedback from your team. Conflicting comments from five stakeholders create schedule risk that no design process can absorb for free.

Leave visual direction open enough for the agency to do its job. Share examples and explain the useful quality in each one. “We like this site” gives no guidance. “We like how this product page moves from use case to technical proof without hiding the call to action” gives the team something it can apply.

Clarify delivery, ownership, and support

Your RFP should state what the agency must hand over and who owns each artifact after final payment.

Cover:

• source design files and design-system documentation;
• code repositories, hosting accounts, and deployment access;
• CMS schemas and editor documentation;
• analytics specifications and tag-container access;
• third-party licenses and renewal responsibility;
• training sessions and recordings;
• warranty terms, support hours, and ongoing maintenance options.

Ask how the agency handles code review, testing, releases, backups, monitoring, and dependency updates. A website remains an operating system for marketing after launch. The proposal should show how your team will maintain it without relying on undocumented knowledge.

Write acceptance criteria before comparing proposals

Acceptance criteria protect both sides from a launch defined by mood.

Tie each criterion to an owner and a verification method. Examples include:

• Approved page types match the signed design and work across agreed breakpoints.
• Editors can create and update defined content types without code changes.
• Required forms send the right data to the CRM and show tested success and error states.
• Redirects return the approved destination and avoid chains.
• Consent settings control analytics and marketing tags under the agreed regional rules.
• Keyboard, screen-reader, contrast, and content checks meet the stated accessibility plan.
• Production monitoring, backups, account ownership, and documentation have named owners.

Define what counts as a defect, a content change, and a new request. Also define the launch decision: who signs off, which issues block launch, and which issues may enter a post-launch backlog.

Ask agencies to expose assumptions

Require each proposal to list inclusions, exclusions, client responsibilities, dependencies, and assumptions. Ask agencies to give each optional item its own price.

A useful pricing breakdown may separate:

• discovery and website strategy;
• information architecture and content strategy;
• copywriting and content production;
• visual design and design system;
• CMS architecture and development;
• integrations and analytics;
• content migration;
• quality assurance and launch;
• training and post-launch support.

The split lets you find missing scope before it becomes a change request. It also shows where an agency expects your team to supply labor.

Compare the proposed team, process, deliverables, ownership, and risk handling beside the fee. The cheapest total may depend on the largest block of unpriced client work. Your RFP should force that work into view.

Use a requirements matrix for proposal review

Turn the final RFP into a matrix that each agency must answer. Give every requirement an ID, priority, owner, and response field.

Use three response choices: included, excluded, or requires discovery. Ask for a note and price impact where the answer needs context. This format prevents a polished narrative from skipping a hard integration or migration requirement.

Score agencies on the factors that affect delivery:

The matrix should support a decision, not replace judgment. Strong agencies may challenge a requirement when it creates cost or maintenance without helping the buyer. Ask them to explain the tradeoff and recommend a better path.

Frequently asked questions

How detailed should a website redesign RFP be?

Define the business goals, audiences, required page types, content ownership, CMS needs, integrations, launch constraints, and acceptance criteria. Leave room for the agency to recommend the right design and technical approach.

Should an RFP specify the website platform?

Specify a platform when an existing contract, security policy, internal capability, or integration makes it a firm constraint. Without one of those constraints, document the requirements and ask each agency to justify its recommendation.

What should agencies price separately?

Ask agencies to separate core strategy, design, development, content migration, copywriting, integrations, accessibility work, analytics setup, post-launch support, and optional features. The split makes proposal gaps easier to spot.

Who should own the website redesign RFP?

Assign one internal owner who can resolve conflicts, collect stakeholder decisions, control the requirements, and approve scope. Marketing may lead, but sales, product, IT, legal, and operations should contribute where their systems or risks touch the site.

Ready to scope the redesign

Virdis helps B2B teams define, design, and build custom websites around the systems that marketing and sales need to operate. Bring us your requirements, gaps included. We will help turn them into a maintainable scope before design starts.