Before you hire a B2B web design agency, answer these 9 questions

If you are deciding how to choose a web design agency for a B2B site, compare each option by its fit with the desired outcome, the scope behind the proposal, the accountable team, the evidence for its approach, and the treatment of risk and commercial terms. You can define most of that before the first agency call.

Answer the nine questions below and turn them into a one-page brief. Ask each agency to clarify the same proposal details, then score the offers against priorities you chose in advance: prepare first, normalize second, score last. This order keeps a polished portfolio or an attractive total from dominating the comparison.

Question 1: What outcome should this site actually drive?

“We need a redesign” only describes a deliverable. The agency still needs to know what the website should help a visitor do and why the project matters to the business.

Choose one primary website action and, if useful, one supporting action. Depending on the product and buying model, that could mean:

• requesting a demo for a particular service or product;
• starting a trial or a self-serve signup;
• finding the proof needed for an enterprise evaluation;
• understanding the company well enough to continue an investor or recruiting conversation;
• reaching a high-value product, comparison, or contact page from organic search.

Then write down the best reliable baseline you have. An existing site may have analytics, CRM events, search data, sales-call notes, or user feedback. A new site will need explicit assumptions and a plan for measuring the action after launch. If no reliable baseline exists, leave the field blank and assign the work needed to establish one.

Your answer should include five things:

1. Primary action: What should the visitor do?
2. Supporting action: What useful step can come before it?
3. Current evidence: What do you know today, and where did it come from?
4. Target direction: What should improve, without inventing a number you cannot defend?
5. Owner and decision date: Who will review the evidence, and when will they decide what to change?

Keep website signals separate from closed-won revenue. A form submission or trial start happens on the site. Revenue depends on the offer, sales process, pricing, competition, and quite a few other people doing their jobs. Your agency should know which layer it can influence and how that layer will be reviewed.

Question 2: Who exactly is the buyer, and which version of them are you designing for?

Calling the audience “decision-makers” leaves a copywriter with almost nothing to work with. Name the specific person, their situation, the decision they face, and the evidence they need.

A B2B website may serve several people in the same deal:

• the day-to-day user who wants to understand the workflow;
• the economic buyer who cares about business fit and risk;
• the technical or security reviewer who needs implementation details;
• an internal champion who has to explain the choice to everyone else.

Choose a primary buyer for the main route through the site. Secondary buyers can have their own routes and supporting proof. For each audience, record the buying stage, the job or question that brought them to the page, the proof they need, and the next action you want to make available.

RapidDev is a useful example, since its website needed distinct paths for project services and templates, plus clearer navigation and a reusable visual system. Merge's live case describes a multi-page Webflow redesign built around those routes. It does not report a measured conversion or revenue result, so the lesson here is about audience and information structure.

Once the primary buyer is clear, the brief can state which message comes first, which proof deserves space, and which path can sit one level deeper.

Question 3: What does your analytics actually say today?

Use the strongest reliable baseline available. The useful period depends on traffic, seasonality, campaign activity, tracking quality, and whether the current site has been live long enough to produce a representative sample. There is no magic 30-day rule that fixes those conditions.

For an existing site, gather the evidence that can guide an investigation:

• traffic and meaningful events by landing page and channel;
• the routes people use before completing a key action;
• high-exit or abandoned journeys worth examining;
• organic landing pages and queries that already bring relevant visitors;
• qualitative feedback from sales calls, support, usability work, or customer interviews;
• known measurement gaps, broken events, consent limitations, and unexplained changes.

Analytics can show where something unusual happens. It rarely explains the reason on its own. A page with a high exit rate may be confusing, or it may simply answer the visitor's question. Pair the number with the page, the audience, and whatever qualitative evidence you can collect.

If this is a new site with no analytics

Then record the assumptions the team is making about audiences, acquisition channels, important routes, and conversion events. Add any comparable evidence you genuinely have, such as sales questions or product research, and label its limits. Finally, document the launch measurement plan: events, dashboards, owners, quality checks, and the first review date.

For a redesign, include migration responsibilities in the brief as well. Someone must own the URL map, redirects, canonical tags, analytics and tag setup, search verification, and post-launch checks. These tasks need named owners even when the agency is not responsible for every one of them.

Question 4: What success signals will you review after launch?

Choose a small set of signals that match the outcome from Question 1. Give each one a baseline, data source, owner, and review cadence. This makes the post-launch conversation specific enough to act on.

Organize the review into three layers:

The layers serve different purposes, and their timing differs. For example, a rise in demo requests can be visible before the sales team knows whether the requests are qualified. A redesign can also improve one action while introducing a migration or form problem elsewhere. Guardrails help you catch that tradeoff.

A 90-day review can be a useful checkpoint when the product's traffic and buying cycle make it meaningful. But it should be more of a scheduled look at the evidence and not a deadline by which the website must prove a business result. Some signals appear sooner, while others need a longer and cleaner comparison window.

Question 5: Which references and anti-references show the right direction?

If you can point to a site and say, “Yes, this is the energy,” fair enough. Now write down why. The agency needs the reason behind that reaction.

Bring two or three references and one or two anti-references. For each one, name the decision it should inform:

• Density: Does the page feel focused, detailed, spacious, or compact?
• Motion: Which interaction helps explain the product, and which one merely attracts attention?
• Hierarchy: What becomes clear in the first screen and after the first scroll?
• Tone: Does the writing feel technical, warm, direct, playful, restrained, or something else?
• Navigation: Which audience or product routes are easy to understand?
• Visual direction: What do the typography, color, imagery, and interface graphics communicate?

Add one sentence about what the team must not copy. A reference can clarify a navigation pattern without authorizing the agency to recreate the visual design. On the contrary, an anti-reference can expose a useful boundary: perhaps you dislike dense motion, vague headlines, tiny product screenshots, or a homepage that asks every audience to follow the same route.

Visual preference does not prove that a reference site performs well. Use the reference to specify a design decision, and record that decision in the brief.

Question 6: What are your tech, CMS, integration, and ownership constraints?

Write the constraints down before proposals arrive. Otherwise, two agencies can appear to quote the same website while assuming different systems and responsibilities.

Cover the following:

• CMS and editing roles: Who will publish, edit, review, and approve content? Which reusable sections do they need?
• Current stack: What stays, what may change, and what technical debt is already known?
• Forms and integrations: CRM, marketing automation, scheduling, analytics, consent, customer data, gated content, and any product connection.
• Migration: Pages, assets, structured content, redirects, metadata, analytics, and search checks.
• Accounts and access: Domain, DNS, hosting, repositories, CMS, analytics, tag manager, plugins, and third-party services.
• Accessibility, security, and compliance: Which requirements apply, who defines acceptance, and who verifies the finished work?
• Localization: Languages, regional content, translation workflow, and local approval.
• Performance acceptance: Which pages and devices will be tested, with what method, and who owns fixes?
• Build ownership: Who turns approved designs into the live site, handles QA and launch, and resolves post-launch bugs?

Platform names alone do not answer these questions. Webflow, HubSpot, WordPress, a headless CMS, and a custom stack can each fit a particular team. Editing needs, integrations, migration effort, technical ownership, and build constraints determine the sensible choice.

Afterward, use these constraints to check compatibility before work begins. An agency may still be a good design partner when another team owns a required integration or the build, but the proposal should name that handoff and its owner.

Question 7: How much content will actually be ready on launch day?

Walk through the sitemap and asset list. Mark each item as ready, needs editing, or needs creation, then add an owner and date. Treat a collective owner such as “the team” as unresolved.

Use a table like this:

Then compare the inventory with each proposal. Does the agency include copy strategy, copywriting, editing, illustration, motion, migration, SEO support, and CMS upload? Which inputs remain client dependencies? If six case studies are planned and only one has an approved quote, the schedule should reflect the one you can actually publish.

Content affects page structure, design states, development, review, and launch. Making its readiness visible gives the agency a realistic critical path and gives your internal team a list of decisions to finish.

Question 8: Who decides, how fast, and how are changes approved?

It's better to only name one decision owner for the project. Contributors can review work in their areas, but someone needs authority to resolve conflicts and approve the next step.

Document:

• the decision owner and required contributors;
• the expected review turnaround for each milestone;
• the meeting and async-review cadence;
• the place where feedback is collected and consolidated;
• the revisions included in the agreed scope;
• the change-request path, estimate method, approval evidence, and rates;
• the escalation route when a decision or dependency misses its date.

Give the agency one resolved set of feedback for each review, then resolve conflicting comments internally and preserve the final approval in the agreed review tool.

New information will, of course, appear during the project. When it changes an approved requirement, the team should record the request, its effect on scope and timing, the price or tradeoff, and the person who approved it. That process gives you control over scope changes, but it cannot promise that no change will ever occur.

Acceptance criteria matter here, too. Define what must be true for a sitemap, design, build, migration, or launch milestone to be approved. “Looks good” is too vague when the phrase will govern a contract.

Question 9: What's your real budget range and launch window?

Give agencies an investment range and explain what it must cover. A proposal produced without that context can look polished and still solve a different-sized problem.

Ask each agency to show:

• the work included in the fee;
• optional items and exclusions;
• client dependencies and assumptions;
• third-party software, fonts, stock assets, licenses, hosting, and support costs;
• applicable tax and payment schedule;
• change-request rates or estimation rules;
• the comparable total cost for the scope you intend to buy.

The detailed pricing discussion belongs in Merge's website design cost guide. For this decision, concentrate on whether the proposals cover the same work and expose the same categories of cost.

Describe the launch window with equal care – separate a hard date from a preferred date, list any immovable event, and identify the work that sits on the client-side critical path. If timing becomes tight, decide which tradeoffs are available: fewer launch pages, reduced motion, phased integrations, later migration, or another change that fits the project.

If you accept a date without testing scope, content readiness, technical dependencies, review time, and contingency, follow up and ask for milestones and assumptions before treating it as a commitment.

Turn your nine answers into a one-page B2B website brief

The task is simple: just copy the table and keep each answer short. Link to supporting documents where needed and keep the brief focused on the information agencies need to scope and compare the work.

Keep a blank field visible so it becomes a question for the first agency call. Use the same brief as a reference when agencies make different assumptions about the project.

How to compare two web design proposals side by side

Before scoring, check whether a lower total reflects fewer pages, less senior time, no content work, or a different post-launch handoff, then normalize those differences first.

Normalize the proposals before you score them

Copy each proposal into the same table. Use Missing/unclear whenever you would have to infer the answer, then assign a person to ask the clarification question.

Clarification is part of comparison. If one proposal leaves migration or post-launch support blank, record the gap before assuming it is included or excluded.

Apply must-pass gates

Set a few conditions that every acceptable proposal must meet:

• legal, IP, source-file, account, and license ownership is acceptable;
• scope, assumptions, exclusions, and dependencies are explicit enough to manage;
• the accountable team is identified;
• required technical, accessibility, security, and compliance needs are covered;
• the schedule includes a credible critical path and client responsibilities.

If a proposal fails a gate, clarify the term or reject it deliberately. Do not let a high average override an unacceptable ownership term or a missing compliance requirement.

Add your own weights and score

Choose the weights before comparing proposal prices. Use 0 for a criterion that does not affect this decision and 5 for one of your highest priorities. Score each proposal from 1 to 5 using the same definition and record the evidence behind the score.

Use the formula weight × score = weighted result. Here is one hypothetical row:

Apply the row separately to each proposal, then total the weighted results. The weights belong to your project, so set them around your risks and priorities. The total is a decision aid. It cannot make a vague proposal precise or guarantee that the highest-scoring agency will deliver the best outcome.

When is a one-page brief enough, and when do you need an RFP?

A one-page brief is usually enough to start a focused conversation with two or three agencies when stakeholders, the desired outcome, and the broad scope are already known. Agencies can use the conversation to resolve open details before producing a scoped proposal.

A formal RFP may be useful when procurement requires standardized responses, you must compare many stakeholders or vendors, or you need documented compliance with regulated and security requirements. Keep the RFP proportional to the decision. This is practical project guidance rather than legal or procurement advice.

FAQ about hiring a B2B web design agency

How long does a B2B web design project take?

The schedule depends on scope, content readiness, integrations, feedback speed, and who owns the build. Ask each agency for milestones, client dependencies, acceptance points, and contingency. Compare those assumptions before you compare launch dates.

How much does it cost to hire a B2B web design agency?

Compare the work included, optional items, third-party costs, tax, payment schedule, and change rates. Calculate a same-scope total for the work you intend to buy. The cost guide linked in Question 9 covers pricing in more depth.

What should be in a B2B website brief?

Include the outcome and primary action, audiences, current evidence, success signals, references, technical constraints, content inventory, decision process, budget and timing, plus open questions and exclusions. The ten-field table above is designed to be copied.

Should I hire an agency or build the website in-house?

Review your ongoing internal capacity, specialist gaps, decision speed, and post-launch ownership. An in-house team may fit when you already have the skills and time, and the website needs ongoing product knowledge. An agency may fit when you need a defined cross-functional team or temporary capacity. Either way, you still need to name a post-launch owner.

How do I prevent scope creep with a web design agency?

Start with a written scope, assumptions, exclusions, dependencies, and acceptance criteria. Put the change-request and approval process in the agreement, including how additional work affects cost and timing. This gives you a controlled way to handle new information; it does not remove the possibility of change.

What is the difference between a design agency and a design-and-development agency?

The distinction comes down to ownership. Confirm who handles research, UX, visual design, implementation, QA, launch, and post-launch fixes. A design-only engagement also needs a clear handoff to the build team, while a combined engagement needs the same responsibilities and acceptance criteria written into one scope.

Choose the next conversation, not just the lowest quote

Use the nine answers to give every agency the same project context, then normalize the proposals and clarify or deliberately reject any that fail a must-pass gate. Score the remaining options with weights based on this project's priorities, and keep unresolved assumptions beside the score so the next conversation has a clear agenda.

If specialist help fits after you have filled in the brief, Merge's website design team can start from a business goal or partial brief, clarify open decisions and scope, and work toward the agreed design and handoff.