Two agencies propose a B2B website relaunch. Both mention “20 pages”, design and a CMS. One may mean twenty populated pages; the other may mean developing the templates, with translation, content entry and CRM integration still to come. You can compare their prices once you know what each supplier will actually deliver.
A useful website brief therefore describes tasks, quantities, responsibilities and acceptance. You do not need to design the database or choose a CMS first. You need to explain what visitors and editors should be able to do, which content supports those tasks and who resolves open decisions.
This guide provides an open template, a worked page inventory and a matrix for supplier questions. You can use the material with another delivery partner too.
Download the editable website brief as a text file — no registration. Save a copy and replace the prompts. The worked example below shows how to make the scope countable.
The three illustrations are AI-generated symbolic images. The company, proposals and prices in the worked example are fictional. They do not represent a client engagement or H-Studio's pricing.
Jump to the working materials:
- The twelve sections of the website brief
- Worked example and page inventory
- Compare proposals: the scope matrix
- Acceptance tasks
Is a brief enough, or is the business decision still missing?
A relaunch makes sense when an evidenced problem cannot reasonably be solved within the existing website. A wish for a new appearance does not by itself explain why the CMS, URLs and all content need replacing at the same time.
Start with three specific observations. Perhaps prospects cannot distinguish two services, editors need a developer to publish case studies, or form enquiries reach sales unreliably. Record the basis for each observation: interviews, support incidents, a test or measurements with known tracking coverage.
If the audience, offer or sales process remains unclear, a business decision is missing. Resolve that first. If only a technical dependency is uncertain, a bounded investigation may be enough: check whether the existing CRM offers suitable access and a test environment, for example. That does not have to become a months-long strategy project.
Allow a supplier to explain why improving the existing website would suffice. Our comparison of WordPress and Next.js with a headless CMS can help clarify publishing requirements. Put the editing workflow in the brief; justify any preferred framework separately.
Twelve sections for a website relaunch brief
A short, consistent document is more useful than many pages of general wishes. “Modern, fast and SEO-optimised” leaves almost every delivery detail open. These questions give suppliers a firmer basis for a proposal.
| Area | What to write down |
|---|---|
| 1. Starting point | Current URL, specific problems, available evidence and what already works and should stay. |
| 2. Visitors and tasks | Who uses the website? Which two or three journeys matter most: understand a service, review relevant evidence, send an enquiry? |
| 3. Page inventory | Page types, content items per type, languages and known exceptions. Keep an inventory of existing URLs separately. |
| 4. Content and approval | Who writes, edits, translates, sources images and approves accuracy? Which usable materials already exist? |
| 5. Editing and CMS | What should staff publish independently? Describe roles, previews, approval and language relationships through an example. |
| 6. Forms and systems | Fields, recipients, CRM, evidence of receipt and failure behaviour. Add file uploads only where needed. |
| 7. Search and existing URLs | Important landing pages, URL mapping, redirects, metadata, internal links and checks after launch. |
| 8. Design and media | Existing design guidance, new design work, image rights and references with an explanation of what is relevant. |
| 9. Usability and requirements | Devices, browsers, keyboard operation, agreed accessibility standard and the person responsible for applicable legal requirements. |
| 10. Budget and timing | Budget range, external costs, firm dates and their reasons, content and approval dependencies. |
| 11. Acceptance | Specific test tasks, responsible reviewers, test materials, approval process and treatment of outstanding defects. |
| 12. Operation and handover | Account ownership, hosting, recurring costs, documentation, training, updates, recovery and support scope. |
Mark unresolved items explicitly as known, assumed or an open question with an owner. “CRM integration included” is not a resolved requirement until the system, data and failure case are understood.
Worked example: eight templates do not mean eight pages
Consider a fictional industrial B2B service business. It sells six services, has four publishable case studies and five expert articles. Its website needs German and English versions. Prospects should be able to assess a service, find relevant evidence and make an enquiry.
The marketing lead wants to publish case studies independently. Sales needs enquiries in an existing CRM. An online shop, customer login and custom product configurators are outside this project.
A countable page inventory
| Page type | Content items per language | Shared template |
|---|---|---|
| Homepage | 1 | Homepage |
| Service overview | 1 | Service overview |
| Service detail | 6 | Service detail |
| Case-study overview | 1 | Case-study overview |
| Case-study detail | 4 | Case-study detail |
| Knowledge overview | 1 | Knowledge overview |
| Expert article | 5 | Article |
| Contact | 1 | Contact |
| Total | 20 per language | 8 templates |
20 content items × 2 languages = 40 editorial URLs. Both languages use the eight templates. This does not mean that every page has identical copy or every module has the same content length.
Legal notices, privacy information, error pages and any confirmation page need a separate inventory. They remain part of the project even if they do not require another editorial template. Existing PDFs and media also need accounting for where they will remain available or be replaced. “20 pages” now describes something that can be checked.
Content ownership, the enquiry journey and one open dependency
For this example, the brief makes the following allocation:
- Content: The client supplies approved German source copy and licensed images. The agency edits the six service pages and populates all 40 editorial pages. A separately appointed translator supplies English copy; the agency enters it. The client approves subject-matter accuracy.
- Editing: A marketing employee can create a case study, add an image and alt text, link the relevant service, associate its translation, review a preview and publish after approval.
- Enquiries: The form collects the agreed information. A success message requires durable acceptance by the responsible backend. Delivery into the CRM has traceable confirmation; a failure creates a visible item for an assigned operator to resolve.
- Open dependency: The CRM owner provides test access. Field mapping, duplicate handling and retries remain assumptions until the interface is checked. The proposal states which investigation is included and what happens if the available access is unsuitable.
Text responsibility is no longer hidden behind “client supplies content”. “Bilingual” now defines delivered work rather than merely a language switch.
Compare proposals: resolve omissions before comparing totals
Imagine two purely illustrative proposals of €28,000 and €42,000, excluding VAT. These figures explain the comparison. They are neither market benchmarks nor recommendations for an appropriate project price.
The first proposal describes a website that the client largely populates afterwards. The second includes more work towards a populated, handed-over system. This matrix illustrates possible scope differences; it does not rank suppliers by price.
| Deliverable | Proposal A: €28,000 | Proposal B: €42,000 |
|---|---|---|
| Design and development | 8 templates, 1 revision round | 8 templates, 2 revision rounds |
| German copy | Client supplies publish-ready text | Editing of the 6 service pages included |
| English | Language functionality; client enters content | Agency enters the translation commissioned by the client |
| Content population | 2 example pages; client completes the rest | All 40 editorial pages |
| CRM | Form sends email; CRM integration excluded | Interface investigation and agreed CRM delivery included |
| Existing URLs | “SEO basics”; mapping unspecified | URL inventory, mapping and redirect checks |
| Editing and handover | Credentials and a short introduction | Task-based training, documentation and joint handover |
| After launch | Defect correction and ongoing support not separately described | Two weeks of agreed launch assistance; later support priced separately |
The €14,000 difference is not yet a premium for the same work. First establish which tasks your team would own under proposal A and which omissions the supplier can price. With proposal B, check whether you need the additional work and whether it is defined precisely enough.
Ask both suppliers to answer in the same format:
- Included: Which quantity, result and number of revision rounds?
- Excluded: Who does the work instead, and what internal effort should be allowed for?
- Unresolved: What information is missing, who supplies it and by when?
- Price consequence: Which omission gets a fixed price, which needs a bounded investigation, and which requires a later decision?
You can then compare the proposal plus missing external services, realistic internal effort and recurring costs over the same period. Do not enter unknown items as zero. Equally, a simple website does not need every conceivable integration or approval workflow just in case.
For rights, repository access, actual team allocation and exit arrangements, use the twelve questions before signing with an agency. Those supplier questions complement the quantities and tasks in the website brief.
Turn “finished” into observable acceptance
Agree acceptance before development begins, using representative tasks. “Looks good” or “Lighthouse is green” does not verify editing, enquiry delivery or redirects. Our example could use the following checks:
| Test task | Expected evidence |
|---|---|
| Find a service on a phone and open a relevant case study | Understandable journey, usable navigation and working links on agreed devices |
| Create, translate and publish a case study without a developer | Approved copy and images appear at the correct DE/EN URLs; drafts remain protected |
| Submit the form with test data | Backend acceptance and a traceable CRM record; a click or outgoing email alone does not prove receipt by sales |
| Make the CRM unavailable during a test submission | The enquiry is preserved; an assigned operator can identify the failure and retry without creating a duplicate enquiry |
| Open an important old service URL | A relevant successor is reached directly; deliberately removed pages return an appropriate status rather than a blanket redirect to the homepage |
| Complete the form by keyboard and submit invalid input | Labels, focus, error messages and correction work within the agreed test scope |
| Rehearse handover | Client owners can locate accounts, source code, content export, operating guidance and the documented recovery procedure |
Accessibility needs an agreed assessment scope, suitable expertise and a decision about the requirements that actually apply. A line saying “accessibility included” is neither a complete specification nor proof of legal conformity.
Record who tests each task, in which environment and against which version. Agree who can approve launch with outstanding defects and which failures prevent launch. Technical approval also remains separate from subject-matter or legal approval of the copy.
Give existing visibility its own workstream
“SEO included” does not explain what happens to old URLs. The brief should require an existing-page inventory and ownership of the decisions about those pages. Useful content, external links or a role in the buying process can make a page valuable even if it recently received little search traffic.
Each affected URL needs a deliberate decision: retain, improve, consolidate into a relevant successor or remove. A removed page should not automatically redirect to the homepage. Google explicitly warns against irrelevant redirects during site moves. Its Search Central migration guidance covers URL mapping, redirects and monitoring after the move.
Inventory, mapping, implementation, internal-link updates and post-launch checks should each have an owner in the proposal. They belong in the migration scope, even when design is quoted separately. This work cannot guarantee stable rankings.
What to send a supplier first
For a useful initial conversation, send the public website, a completed brief with open questions marked and a first page inventory. Add the budget range, the reason for the target date and the internal decision owner. Competitor examples help when you explain their relevance: navigation, service presentation or the enquiry journey, for instance.
Do not include passwords, personal CRM exports or confidential customer data in that first message. If an investigation later requires access, agree the purpose, limited permissions and an appropriate access route.
A useful response accurately restates the scope, exposes assumptions and names the decisions that come next. A long list of technologies cannot do that on its own.
If you need a delivery partner, contact H-Studio through our B2B website relaunch service. The public URL and brief give us a basis to assess whether a rebuild, a targeted improvement or clarification of a dependency should come first.
