Digital strategy
B2B website redesign brief: complete template and acceptance criteria
A B2B website redesign brief becomes useful when it makes proposals and acceptance comparable. A wish list — modern, fast, intuitive — cannot determine whether the delivered result is acceptable.
This method connects every critical requirement to five fields: expected outcome, acceptance criterion, evidence, owner and blocking status. The eight-page DOCX template is available without a form.
Short answer
A useful website redesign brief does more than describe the future website. It makes every important commitment verifiable.
When framing a B2B website redesign, do not ask only for a modern homepage, a fast website or a form connected to the CRM. For every material requirement, state the expected outcome, the acceptance criterion, the evidence to provide, the owner and whether it blocks launch.
This structure turns a list of intentions into a decision tool. It makes proposals easier to compare, limits grey areas during delivery and allows acceptance to be based on observed facts rather than impressions.
The accompanying editable DOCX template is eight pages long and deliberately independent of any CMS or agency.
Requirement · acceptance criterion · expected evidence · owner · blocking status.
Purpose of the brief
Define the problem and the decision rules without inventing the technical solution too early.
France Num presents a website brief as a way to formalise needs, compare providers, manage delivery and frame the working relationship. In a B2B redesign, its most useful role is to separate the decisions the organisation must make from the recommendations the provider must justify.
| The organisation decides | The provider recommends | The proposal must state |
|---|---|---|
| Business objectives, priority audiences, operational constraints, internal owners, budget envelope and fixed deadlines. | Architecture, journeys, design method, technical foundation, measurement approach and migration sequence. | Assumptions, inclusions, exclusions, dependencies, deliverables, approvals, ownership, maintenance and change conditions. |
Describe administration needs, roles, integrations, portability and security constraints. Then ask each provider to justify its solution. A technology name is neither a user need nor an acceptance criterion.
Verifiable structure
Replace adjectives with observable conditions.
“Fast”, “intuitive”, “secure” and “SEO-ready” are intentions. They do not say what will be tested, by whom or against which expected result. The table below turns vague requests into controllable requirements.
| Requirement | Acceptance criterion | Expected evidence | Owner | Blocking |
|---|---|---|---|---|
| Lead form | A valid submission creates the expected contact, displays a clear confirmation and triggers the planned notification. Errors are announced and associated with their fields. | Time-stamped acceptance scenarios and the test contact visible in the target system. | Agency + CRM owner | Yes |
| Administration | An authorised editor can create, preview, correct and publish a representative content item without technical intervention. | Back-office user test and delivered operating guide. | Agency + content editor | Yes |
| Content and templates | For every template declared priority and launch-critical, the agreed required fields, display rules, evidence, call to action, editorial owner and update rule are present. | Template inventory, integrated test content and editorial review of representative pages. | Agency + content owners | Conditional |
| Internal search | When internal search belongs to a declared critical journey, the agreed query set returns relevant results, the empty state offers a useful next step and the journey remains keyboard-operable. | Dated query set, observed results, defects and confirmation after correction. | Agency + subject owner | Conditional |
| Accessibility | Scope, standard and version, sample, testing method and target level are defined before acceptance. Any defect classified as blocking by the agreed protocol prevents launch until corrected or covered by a documented exception. | Test report, classified defects, corrections and confirmation testing. | Named assessor | Conditional |
| Performance | Pages, test conditions and contractual thresholds are fixed. Thresholds that determine go/no-go are named before measurement. A single Lighthouse score is not the only evidence. | Repeatable report, stated environment and field data once sufficient data exists. | Agency | Conditional |
| SEO migration | Every critical legacy URL receives a documented decision: retain, direct 301/308, consolidate or return 404/410. | Approved matrix, acceptance crawl, HTTP status and final destination. | Agency + content owner | Yes |
| Measurement and consent | Authorised events are received with the expected parameters. No tracker that requires consent fires before the user’s choice. | Measurement plan, test log and browser inspection before and after consent. | Agency + DPO or adviser | Yes |
| Security and recovery | Roles, backups, recovery time, maximum accepted data loss and incident procedure are defined, then an agreed recovery scenario is replayed. Blocking applies to scenarios declared critical before acceptance. | Recovery test log, observed duration, gaps, corrections and escalation owners. | Host + agency + security owner | Conditional |
| Ownership and portability | Repositories, accounts, data, domains, licences and agreed deliverables are owned or transferable under the written proposal. | Handover inventory, tested access, open exports and a transfer procedure tested on the agreed scope. | Client leadership + agency | Yes |
The “Blocking” column accepts only three values: Yes, No or Conditional. When a requirement is conditional, the condition belongs in the acceptance criterion, never in the status. “No” means the requirement remains testable but failure does not prevent launch. Thresholds and obligations must still be adapted to the project and written into the selected proposal.
Complete structure
The eight sections of an operational B2B website redesign brief.
Context and current state
Describe the organisation, the current website’s role and known constraints.
Offers, markets, languages, governance, technology, hosting, connected tools, known debt, available access and reasons for redesign.
Objectives and baseline
Prioritise desired outcomes and preserve the pre-redesign state.
Qualified enquiries, usage, downloads, visibility, administration cost, current data, calculation method and comparison window.
Audiences and B2B journeys
Name decision-makers, users, influencers and objections that shape the journey.
Research context, maturity, information needs, expected evidence, next action and accessibility or language constraints.
Content and scope
Inventory content, templates and editorial responsibilities.
Pages retained, consolidated, removed or created, languages, media, evidence, authors, approval, migration and volume by type.
Functions and integrations
Describe business scenarios and connected systems, not only a module list.
Forms, search, private areas, CRM, ERP, recruitment, newsletters, consent, roles, errors, security and inbound or outbound data.
Quality and compliance
Define how UX, accessibility, performance, security and privacy will be tested.
Name standards and versions, samples, devices, browsers, tools, human tests, thresholds, blocking defects, evidence and approval owners. If a national framework applies, include a review clause for changes that may occur before delivery; for French projects extending into 2027, this may include the announced RGAA 5 transition.
Visibility and measurement
Prepare SEO, AI citability, migration, structured data and analytics before final development.
URL inventory, mapping, canonicals, hreflang, internal links, metadata, structured data, crawler access, sitemaps, events and dashboards.
Delivery and post-launch
Set deliverables, actors, approvals, ownership, budget, schedule, maintenance and portability.
Milestones, client availability, response times, deliverable formats, acceptance, corrections, access transfer, documentation and post-launch responsibilities.
Reference state
No claim of improvement is interpretable without a pre-redesign baseline.
An objective such as “increase qualified enquiries” remains incomplete unless the project preserves the definition of a qualified enquiry, the reference period, the data sources and the events actually measured. The brief must require this state to be recorded before the current website is replaced.
| Dimension | State to preserve | Limitation to document |
|---|---|---|
| Commercial | Forms started and submitted, meetings, downloads, identifiable calls and manual lead qualification. | Definition, consent, duplicates, seasonality and unattributable activity. |
| Content | Pages, templates, owners, dates, evidence, inbound links, usage and migration decisions. | Incomplete inventory, missing data or off-site content. |
| Search | Impressions, clicks, queries, pages, indexability, canonicals, links and sitemaps. | Window, aggregation, reporting delay and canonical changes. |
| Experience and quality | Tested journeys, known friction, available field performance, accessibility defects and incidents. | Sample, devices, network, insufficient traffic and tests that cannot be replayed. |
Compare proposals
Ask every agency to use the same response structure without creating a misleading total score.
A score out of 20 gives heterogeneous decisions a false appearance of precision. Use three pass/fail gates first, then review documentary completeness. Price becomes comparable only when assumptions, dependencies and exclusions are comparable too.
| Gate | Minimum expected answer | Stop signal |
|---|---|---|
| Ownership and portability | Who owns code, content, domains, accounts, data and access, and in which formats they are handed over. | Undisclosed dependency or essential access held without a transfer procedure. |
| Acceptance and migration | Acceptance criteria, responsibilities, URL matrix, test environment, defect handling and the launch decision. | Launch treated as a visual check or migration deferred until after development. |
| Scope and responsibilities | Deliverables, actual team, client dependencies, exclusions, options and change procedure. | Broad wording that cannot be attached to a deliverable or owner. |
Edikka is a website redesign agency, so this framework is not presented as an independent agency ranking. Our offer page documents publicly the deliverable families, method, accessible projects and first-conversation process. Budget, detailed schedule, named team, acceptance thresholds, responsibilities and exclusions belong in each proposal. The technical foundation and exact criteria depend on the diagnosis.
Useful limits
Five requests that should not become blind obligations.
| Fragile request | More useful wording |
|---|---|
| “Lighthouse 100 everywhere” | Define pages, devices, conditions, metrics, thresholds and evidence required for real use. |
| “First position in Google” | Require controllable SEO deliverables and checks; no provider controls a ranking. |
| “Cited by AI systems” | Require technical access, sourced answers, evidence, dated monitoring and attribution limits; no citation is guaranteed. |
| “Pixel-perfect design before discovery” | Set objectives, content, components, brand principles, journeys and approval stages. |
| “Redirect every old URL to the homepage” | Decide URL by URL according to intent equivalence: retain, redirect, consolidate or remove correctly. |
Open template
Download the editable brief or inspect its public Markdown version.
The DOCX is an eight-page working document. Remove irrelevant sections, keep unknown decisions visible as open questions and ask providers to distinguish clearly between included, optional, excluded and client-dependent work.
The DOCX template and Markdown version are released under a Creative Commons Attribution 4.0 International licence. You may adapt and redistribute them, including commercially, provided you credit Edikka and link to this article’s canonical URL.
Deliberate limitation
This template is not a contract, a legal audit or a guarantee of results.
The document helps frame a consultation. Applicable obligations for accessibility, personal data, security, intellectual property or retention depend on the organisation, audiences, data and services concerned. Competent specialists must validate them before they are incorporated into contractual documents.
The example criteria support repeatable acceptance. They do not prove a before-and-after gain and do not guarantee conversion, search ranking or citation by an AI service.
Reference sources
External guidance used to construct the framework.
- France Num — Building a website brief for your organisation, published 20 March 2026 and updated 23 March 2026, in French.
- France Num — Website brief templates, updated 7 May 2026, in French.
- Google Search Central — Site moves and migrations, for preparation, URL mapping, redirects and monitoring.
- W3C — Web Content Accessibility Guidelines 2.2, W3C Recommendation of 12 December 2024.
- DINUM — A new RGAA version planned for late 2026, in French, to support a contractual review clause without presuming applicability.
- European Data Protection Board — Guidelines 05/2020 on consent under Regulation 2016/679.
Conclusion
The best brief reduces ambiguity without preventing expert advice.
A successful B2B redesign is not the mechanical execution of a page list. It is a sequence of decisions about objectives, journeys, content, functions, quality, migration and post-launch ownership. The brief must make those decisions visible, assigned and verifiable.
Edikka’s website redesign method combines strategy, UX/UI, development and SEO/GEO in one delivery scope. You may use the template before contacting us, including to compare Edikka with other agencies.
Edikka’s position
A strong brief reduces ambiguity without preventing expert advice.
It fixes objectives, constraints and decision rules, then asks each agency to justify its method and proposed solution.
Prioritise the need
Objectives, audiences, constraints and exclusions become visible before the solution.
Name the owners
Every deliverable, approval, dependency and decision belongs to an identified person.
Prove acceptance
Expected criteria and evidence replace adjectives that cannot be tested.
Go further on this topic
Additional answers to clarify the key points covered in this article.
