
Assign one owner who can make decisions
Choose one internal owner for the redesign. That person collects evidence, resolves conflicts, controls feedback, and approves scope.
Marketing may lead the project, but the owner needs access to sales, product, IT, legal, and leadership. Each group can contribute requirements. They should not run separate versions of the project.
Write down:
- the executive sponsor;
- the day-to-day owner;
- who approves strategy, copy, design, and launch;
- who supplies technical access;
- who breaks a deadlock;
- how long each approval may take.
Avoid committees without a final decision maker. An agency cannot maintain momentum when every stakeholder can reopen an approved choice.
Define the commercial problem
Start with what the current site prevents the business or buyer from doing.
Name observable problems. Buyers may struggle to understand the offer. Sales may rely on decks because the site lacks product detail or proof. Marketing may need developers for routine page changes. The CMS may fail to support regional teams or structured product content. Tracking may stop at form submission without connecting to lead routing.
Then define the actions the new site should support. Examples include:
- help a buyer choose the right product or service;
- answer technical and commercial objections;
- route qualified prospects to the right team;
- give sales useful pages to share after calls;
- let marketing publish without breaking layout, SEO, or tracking.
Set priorities. A redesign cannot optimize every audience and action at once. Give the agency a ranked list so it can shape information architecture, page strategy, and conversion paths around the work that matters most.
Collect buyer and sales evidence
Bring evidence from the people closest to revenue. Discovery improves when the agency can inspect real questions and objections instead of relying on generic persona labels.
Collect:
- sales call notes or approved transcript excerpts;
- common objections and lost-deal reasons;
- support questions that appear before purchase;
- product comparisons buyers request;
- pages and PDFs sales sends during the buying process;
- search terms and landing pages that show relevant demand;
- form submissions or CRM fields that reveal lead intent.
Protect customer and prospect information. Remove private details before sharing files with an outside partner.
For each buyer group, explain the trigger that brings someone to the site, the questions they need answered, the proof they expect, and the next action they should take. A job title alone gives a designer little useful direction.
Audit content and page types
An agency needs to understand both page volume and content structure.
Export the current URLs. Group them by page type: product, solution, industry, resource, case study, company, legal, campaign, and utility pages. Mark each URL as keep, rewrite, merge, archive, or undecided.
Count templates apart from pages. Two hundred articles may use one template. Eight product pages may need shared data, comparison modules, integration records, and distinct conversion paths. Those structures affect strategy, CMS architecture, development, and migration.
Record who owns:
| Workstream | Decision to make |
|---|---|
| Information architecture | Who approves the sitemap and page purpose? |
| Copy | Who writes, edits, and approves each page type? |
| Media | Who supplies photography, diagrams, video, and product images? |
| Migration | Which content moves by script and which needs manual work? |
| SEO | Who approves redirects, metadata, canonicals, and indexation rules? |
| Entry | Who loads final content into the CMS? |
If your team cannot complete the audit, ask the agency to include it as a named discovery deliverable. Do not hide it under “content support.”
Map CMS workflows and governance
Talk to the people who publish the site. Ask what they create, how often they publish, where approvals stall, and which changes require developer help.
Document:
- content types and reusable fields;
- page-building flexibility;
- preview and draft workflows;
- roles and permissions;
- scheduled publishing;
- localization and regional variants;
- asset management;
- search and filtering needs;
- legal or compliance approvals;
- archival and deletion rules.
Identify repeated information. Product names, pricing language, feature descriptions, author details, and calls to action can drift when editors copy them across rich-text pages. A custom content model can give the team one controlled source for each shared item.
Set boundaries for editors. Decide who may change navigation, create templates, edit global components, publish legal text, or add scripts. Those rules affect the CMS design and the training plan.
Document integrations and access
List every system the website sends data to or receives data from. “HubSpot integration” or “analytics setup” does not define the work.
For each system, record:
- account and internal owner;
- data sent in each direction;
- forms, fields, validation, and routing rules;
- authentication method;
- test environment or sandbox;
- consent and privacy behavior;
- failure handling;
- person who grants access and accepts the result.
Include CRM, marketing automation, analytics, consent management, customer data, search, recruiting, support, event, documentation, and account-portal systems where they touch the site.
Test access before kickoff. A missing admin, expired vendor contract, or unavailable sandbox can hold the schedule hostage while the website team waits.
Define measurement before the build
Choose the actions your team needs to measure and the systems that consume the data.
List primary conversions, secondary actions, form success states, campaign attribution needs, CRM fields, consent behavior, cross-domain tracking, internal-traffic rules, and reporting owners.
Ask the agency to scope:
- event naming and data-layer specifications;
- tag and consent configuration;
- form and CRM validation;
- test cases for success, error, and duplicate submission;
- handoff documentation;
- post-launch verification.
Separate the website agency’s work from any analytics partner’s work. Assign one owner to each boundary. Otherwise both teams can finish their piece while the full conversion path remains untested.
Set quality and compliance constraints
Give the agency testable standards for accessibility, performance, SEO, security, and privacy.
For accessibility, name the standard your company follows, the page and component coverage, the testing method, and who fixes content issues such as alternative text, captions, headings, and link labels.
For performance, identify critical page types, target devices, network assumptions, required third-party scripts, and the production test process. A clean demo page tells you little about a production site carrying consent tools, analytics, video, and marketing embeds.
For SEO, identify URL changes, redirect ownership, metadata, canonical rules, structured data, sitemaps, robots controls, internal links, staging protection, and launch monitoring.
For security and privacy, list hosting restrictions, data residency, vendor review, cookie requirements, retention rules, vulnerability testing, and incident contacts. Tell the agency about procurement reviews before they set the schedule.
Clarify the design-system scope
Inventory the brand assets your team can supply: guidelines, fonts, logos, photography, illustration, icons, diagrams, and product interface files.
List the page types and reusable components the site needs. Include responsive behavior, interaction states, forms, errors, empty states, and CMS editing needs. A homepage concept does not define a maintainable website system.
Share reference sites with notes about the useful quality. Explain that a product page handles technical proof well or that a resource library makes filtering clear. A folder of screenshots without commentary pushes the agency toward imitation.
Define review rounds and feedback rules. Require one consolidated response from your team at each milestone. The project owner should resolve internal disagreements before the agency starts revisions.
Expose schedule, budget, and dependencies
Give the agency the real launch constraint. Name events, campaigns, rebrands, product releases, procurement reviews, legal checks, content freezes, and internal vacations that affect delivery.
Share a working budget range when you have one. The agency can allocate effort across strategy, content, design, development, migration, integrations, and support with fewer hidden assumptions. A budget ceiling does not remove the need for scope detail, but silence forces every bidder to invent a different project.
List client-side dependencies with owners and dates. Include content delivery, asset production, integration access, security review, stakeholder approvals, and domain or hosting control.
Decide what can move after launch. Separate launch blockers from backlog items. Teams lose weeks when they treat every late idea as a release requirement.
Package the discovery output
Your pre-agency discovery package should give bidders one source of truth:
- A one-page project brief with goals, priorities, owner, budget range, and launch window.
- Buyer and sales evidence with private details removed.
- A URL and content inventory.
- CMS workflow and governance requirements.
- An integration and access register.
- A measurement plan with conversion events and owners.
- Quality, compliance, and technical constraints.
- A stakeholder and approval map.
- Known dependencies, risks, and open questions.
Label unknowns. Ask the agency to price the work needed to resolve them during discovery. Honest uncertainty gives both sides more control than a confident guess.
The finished package should let an agency explain its approach, team, phases, deliverables, assumptions, and fee against the same facts. You can then compare how each agency thinks instead of comparing totals for different scopes.
Frequently asked questions
How much discovery should we complete before hiring an agency?
Complete enough work to define the business problem, priorities, owners, known systems, content condition, constraints, and open questions. Leave information architecture, experience strategy, visual direction, and technical recommendations open for the agency to shape with you.
Who should attend website discovery sessions?
Include the project owner and the people who control revenue insight, content, product facts, technical systems, compliance, and final approval. Invite each person to the sessions where their decisions matter instead of filling every meeting with the full committee.
Should the agency audit the current website?
Yes. Ask the agency to review content, UX, conversion paths, CMS structure, analytics, SEO, accessibility, performance, and technical constraints at the depth required by the scope. Define the audit outputs so “audit” does not become an unbounded line item.
What should discovery produce?
Discovery should produce approved priorities, audience and journey decisions, a sitemap or information-architecture direction, content and CMS requirements, integration and measurement specifications, a delivery plan, and a documented scope with assumptions and responsibilities.
Prepare the redesign before pixels move
Virdis helps B2B teams turn commercial goals, content, and technical constraints into a custom website system that marketing can operate. If your discovery inputs still have gaps, we can structure the work before design starts and carry the decisions through development and launch.
