Start with the decision your company needs to make
Three redesign proposals can describe three different projects under the same heading. One agency may quote a visual refresh. Another may include positioning, content strategy, custom development, CMS modeling, analytics, migration, and launch support. A third may leave those items behind a line marked “as needed.”
A price comparison will mislead you until you normalize the scope.
Build a scorecard before the review meeting. Use the goals, requirements, and constraints your team gave each agency. If your brief left gaps, record them as unresolved questions instead of rewarding the proposal that made the most convenient assumptions.
Disqualify proposals that hide the work
Remove a proposal from consideration when the agency cannot explain the project in enough detail for you to manage the risk.
Watch for:
- deliverables named as “website design” or “development” without boundaries
- no named project team or unclear reliance on contractors
- a page count with no component, template, or CMS definition
- accessibility, analytics, SEO migration, or QA treated as optional cleanup
- no content responsibilities or approval process
- unlimited revision language that hides a weak decision process
- no statement of assumptions, exclusions, or change-control terms
- no ownership terms for code, design files, content, accounts, or data
- a launch milestone with no warranty, training, or maintenance plan
A good proposal reduces ambiguity. It does not need to predict every discovery decision, but it should identify what discovery will resolve and how those findings can affect scope.
Use a weighted scorecard
Assign weights before your team sees agency pricing. The weights should reflect the consequences of a bad decision for your company.
| Evaluation area | Suggested weight | What to score |
|---|---|---|
| Business and conversion strategy | 15% | Goals, buyer paths, positioning, conversion actions, success criteria |
| Scope completeness | 15% | Deliverables, assumptions, exclusions, dependencies, acceptance criteria |
| UX and content approach | 10% | Research, information architecture, page strategy, content responsibilities |
| Visual and design-system approach | 10% | Custom direction, component states, responsive rules, design-system depth |
| Development and CMS | 15% | Architecture, CMS model, integrations, code quality, editor experience |
| SEO, analytics, and migration | 10% | Redirects, metadata, tracking, consent, validation, launch protection |
| Accessibility, performance, and QA | 10% | Standards, test methods, browser coverage, performance ownership |
| Team and delivery plan | 10% | Named team, senior involvement, milestones, communication, risk management |
| Handoff and maintenance | 5% | Training, documentation, ownership, warranty, ongoing support |
Use a five-point scale for each area:
- Missing or unacceptable
- Mentioned with weak detail
- Adequate and credible
- Strong, specific, and testable
- Strong enough to reduce delivery risk
Calculate each weighted score. Require reviewers to cite the proposal page or agency answer behind every score. A number without evidence turns the meeting into a contest between opinions.
Score the business and conversion strategy
A redesign should support a commercial job. Ask each agency to state the job in its own words.
The proposal should connect the website to specific buyer actions, such as requesting a consultation, starting a product conversation, evaluating a service, or moving from educational content to a sales page. It should explain how research, positioning, navigation, page hierarchy, proof, and forms support those actions.
Look for a plan to resolve questions. Agencies cannot know your buyers from an RFP alone. They can show how they will interview stakeholders, review analytics, inspect search demand, map buyer paths, and turn findings into decisions.
Lower the score when the proposal substitutes visual language for a business argument. A mood board cannot settle weak positioning or an unclear conversion path.
Normalize scope before comparing price
Create one comparison sheet with a row for every material deliverable. Mark each proposal as included, excluded, optional, or unclear.
Cover at least:
- discovery and stakeholder research
- analytics and search review
- positioning or messaging work
- sitemap and information architecture
- wireframes and content requirements
- copywriting, editing, and content entry
- visual direction and responsive design
- design system and coded components
- CMS schemas, previews, and editor training
- forms, CRM, scheduling, or product integrations
- analytics events and consent controls
- redirect mapping and SEO migration
- accessibility and browser testing
- performance testing
- launch, monitoring, warranty, and maintenance
Ask the agency to price any unclear item before final selection. You want the budget difference now, not after the team assumes the scope covers a missing task.
Inspect the design and content process
Portfolio quality shows taste. The proposal should show how the agency will reach an appropriate result for your company.
Ask how the team will:
- turn strategy into page hierarchy and content requirements
- test navigation and conversion paths before visual design
- use real content during design
- handle responsive states and long or missing content
- define component variants and prevent one-off sections
- involve your reviewers without turning each meeting into art direction by committee
- document decisions for development and future publishing
Check who creates the content. “Client to provide copy” can mean your team must write every page before design starts. It can also mean the agency supplies structure and editing while your subject-matter experts provide raw material. Those scopes carry different workloads and risks.
Examine development and CMS decisions
The technology section should explain how the finished site will operate. A list of tools tells you little without ownership, architecture, and publishing details.
Ask each agency to show:
- how design components map to production code
- how page patterns map to CMS fields
- which controls editors receive
- which layout combinations the CMS blocks
- how preview, drafts, roles, and approvals work
- how the site handles integrations and failed requests
- how developers test components and releases
- how your team can change vendors without rebuilding the site
Favor the proposal that gives marketers useful publishing control while protecting hierarchy, accessibility, and performance. A blank-canvas page builder can transfer design decisions to every editor. A rigid CMS can make routine campaigns dependent on developers. Your operating model should decide the balance.
Require a launch-protection plan
Redesign risk concentrates near migration and launch. Make the agency describe the checks, owners, and rollback path.
The proposal should cover redirects, metadata, canonical URLs, sitemaps, robots rules, analytics events, forms, CRM handoffs, consent behavior, performance, accessibility, responsive layouts, and browser coverage. It should identify who signs off on each area.
Ask how the team will verify production after deployment. Staging approval does not confirm that production analytics, forms, redirects, caching, and third-party services work.
Evaluate the people who will deliver the project
Meet the working team before you sign. Sales chemistry does not guarantee delivery quality.
Confirm:
- who owns strategy, design, development, content, and project delivery
- how much senior staff participate after kickoff
- which work the agency subcontracts
- who can make decisions when a risk appears
- how often your team reviews work
- what the agency needs from your stakeholders
- how missed client approvals affect the schedule
Give a higher score to a smaller credible team with clear ownership than to a large roster with vague allocation. You need accountable people, not an impressive org chart.
Compare assumptions, exclusions, and change control
Read these sections before the case studies. They tell you how the project will behave when reality changes.
List each assumption that can affect cost or schedule: page volume, copy readiness, migration volume, integrations, data quality, stakeholder availability, legal review, translations, and technical access. Ask the agency how it validates each one.
A practical change process should define who documents the request, how the agency estimates the effect, who approves it, and whether the work changes a milestone. Avoid both open-ended billing and contracts that pretend scope never changes.
Run a proposal interview with the same questions
Give every finalist the same questions and the same preparation time:
- Which part of our brief carries the most delivery risk?
- Which assumption could change your fee or timeline?
- Which work have you excluded that buyers often expect?
- How will you connect strategy, content, design, CMS, and code?
- How will you test the main conversion paths?
- How will you protect search visibility and measurement during launch?
- Who will do the work we reviewed today?
- What will our team own and maintain after launch?
- Show one project decision you changed after research or testing.
- Describe how you handle a disagreement with a client stakeholder.
Score the answers. Do not award points for confidence when the agency avoids the question.
Check references against the proposed team and scope
Ask references about work comparable to your project. Confirm which proposed team members worked on it.
Useful questions include:
- Did the agency identify risks before they became change requests?
- Did the delivered CMS match the promised editor workflow?
- Did senior staff remain involved?
- Did the team document decisions and ownership?
- How did the agency handle missed approvals or new requirements?
- Did launch support match the contract?
- Could the client maintain the site after handoff?
Treat testimonials in a deck as supplied marketing material. A direct reference call lets you test the claims that matter to your scope.
Make the final decision on risk-adjusted value
Price matters. Compare it after you align scope and score delivery risk.
A lower fee can represent an efficient team. It can also omit content, migration, analytics, accessibility, testing, or post-launch support. A higher fee can fund deeper work, or it can fund overhead that does not improve your website. The scorecard forces each difference into view.
Choose the agency that gives you the strongest credible path from business problem to maintained production system. Record the reasons, unresolved risks, contract changes, and reference findings before approval. That record will help your internal owner manage the project after selection.
Frequently asked questions
Should we share our website redesign budget with agencies?
Share a credible range and the outcomes it needs to cover. Agencies can shape the scope around real constraints and tell you when the range cannot support the requirements. Withholding the budget often produces proposals for different projects, which makes comparison harder.
How many website redesign proposals should we request?
Invite enough qualified agencies to create a real comparison without exhausting your team. Three strong proposals often reveal meaningful differences in approach and scope. A long list rewards shallow sales work and creates more evaluation noise.
Should the lowest-priced website redesign proposal lose points?
Score scope and delivery risk before price. A lower-priced proposal should not lose points when it covers the requirements with a credible team and plan. It should lose points when the fee depends on omissions, vague assumptions, or client work that your team cannot complete.
What should we ask an agency to clarify before signing?
Clarify deliverables, assumptions, exclusions, named team members, client responsibilities, acceptance criteria, change control, ownership, launch support, warranty, and maintenance. Attach material answers to the contract or statement of work.
Turn proposal differences into a decision
Virdis plans, designs, and develops custom B2B websites as connected systems. Strategy, content, conversion paths, components, CMS structure, analytics, testing, and maintenance share one scope. If your proposals describe different projects, Virdis can help you normalize the work and identify the decisions that should reach the contract.
