A website brief is a decision document

A polished proposal can make a corporate website project feel settled before the important work has begun. It is not. The design phase only succeeds when the commercial, operational, and technical decisions behind it are clear enough to guide daily choices. Before you compare agency concepts, use these ten decisions to turn a hopeful brief into a workable agreement.

They are also a useful way to assess a proposed web design and development engagement. A capable agency should be able to explain each decision, name the owner, and show where it appears in the scope. If an answer remains vague before signature, it tends to become an expensive change request once production is underway.

1. Define the business outcome and the measurement plan

Agree on the job the site must do: qualify enquiries, support a sales conversation, attract talent, reduce support queries, launch a new category, or give the brand a credible home. Then specify the evidence. That might include qualified form submissions, booked consultations, newsletter sign-ups, demo requests, or completion of a key task. Record the baseline where one exists, the reporting cadence, the analytics platform, and who will interpret the results.

This prevents the familiar failure mode in which launch day becomes the finish line. Without agreed outcomes, the project is judged by subjective reactions to the homepage, and no one can tell whether the website improved the business problem it was commissioned to solve.

Set the foundation your team will control

2. Choose the CMS around real publishing work

Ask which pages, collections, forms, and integrations must be editable after launch, and by whom. A CMS decision is not a vote for the most recognisable platform; it is a workflow choice. A lean marketing site may benefit from a visual system with structured collections, while a complex editorial operation may need stronger roles, approval paths, and content modelling. Discuss licenses, hosting, limits, custom code, and the cost of a future platform change.

The scope should state whether the CMS configuration, component library, and source files transfer to your company. That prevents a site that looks easy to edit in a demo but requires the original agency for every campaign page, field change, or new content type. If you are weighing platforms, our comparison of the platform trade-offs can help frame the operational trade-offs.

3. Put domains, analytics, and key accounts in your name

Your company should own the domain registration, DNS access, analytics property, tag manager, search console property, paid-service subscriptions, and key social or email integrations. Give the agency the least access necessary and document the administrator account, recovery method, renewal dates, and billing owner. Hosting can be agency-managed, but control and an exit path should still be explicit.

This prevents a handover from turning into an account-recovery exercise. It also protects continuity when people change roles or a supplier relationship ends. Ownership is not mistrust; it is basic business resilience.

Make content and markets part of the scope

4. Assign content responsibility page by page

A sitemap is not content. For each page template, decide who supplies subject-matter inputs, who writes or edits the copy, who sources imagery, who checks claims and legal language, and who gives final approval. Set word-count ranges, required assets, review rounds, turnaround times, and a method for handling late material. For product, service, and leadership pages, identify a named client-side owner rather than assigning the work to a department.

This prevents the project from stalling at the point where beautiful approved layouts need real information. It also avoids placeholder copy reaching launch because nobody realised that content production was outside the original fee.

5. Decide which languages and markets exist on day one

If the business serves more than one market, specify the launch languages, priority pages, translation workflow, reviewer, URL pattern, and currency or regulatory variations before design begins. Translation is rarely a final production step: navigation length, form fields, imagery, typography, and page hierarchy may all change by market. Make room for content that is adapted rather than mechanically translated.

This prevents a single-language design from becoming an awkward multilingual retrofit. It also protects search visibility by making language and regional targeting deliberate; see our guide to international SEO and hreflang for the implementation questions a brief should anticipate.

Protect demand while improving the experience

6. Treat SEO migration as a launch workstream

A redesign should begin with an inventory of existing URLs, traffic-driving pages, rankings, backlinks, metadata, downloadable assets, and conversion paths. Agree which pages are retained, consolidated, retired, or redirected. The launch plan should include a redirect map, staging review, crawl checks, analytics verification, XML sitemap update, search console monitoring, and a period for resolving post-launch issues.

This prevents a new corporate website from quietly discarding the pages and signals that earned organic demand. The design may be new, but search engines and referral links still need a coherent path to the new structure. Our detailed guide to redesigning without losing SEO explains why this work cannot wait until the final week.

7. Write a performance budget, not a vague speed promise

Ask the agency to define measurable page-weight and loading targets for the templates that matter most, especially mobile entry pages. Cover image formats and dimensions, font use, video strategy, motion, third-party scripts, cookie tooling, embedded forms, caching, and monitoring. A performance budget gives the team a way to make trade-offs when a new animation, tracking pixel, or hero video is proposed.

This prevents a launch that looks impressive on a fast office connection yet loads slowly for prospective customers. It also means marketing can add tools responsibly after launch. For a useful explanation of the signals involved, read our Core Web Vitals and site speed guide.

Plan for inclusive, independent operation

8. Set the accessibility standard and acceptance checks

Accessibility should be a build requirement, not a late visual review. Agree the standard the project is working toward, the templates and interactions included, and how it will be tested. That conversation should cover keyboard operation, focus states, semantic structure, form labels and errors, colour contrast, responsive reflow, captions where relevant, and content-editor guidance.

This prevents accessibility work from being reduced to a last-minute automated scan, which cannot assess many real user journeys. It also helps your team preserve the standard when it publishes new pages, images, and campaigns.

9. Specify the handover, training, and documentation

The launch deliverable should include more than a live URL. Ask for role-based CMS training, recordings or written guides, component usage rules, credentials inventory, form and integration documentation, design assets, source-code access where applicable, and a short list of actions your team can safely perform. Schedule training against a site populated with your actual content, not an abstract demo.

This prevents an operational dependency that emerges only when a campaign needs to go live quickly. A good handover turns the site into a tool your marketing team can use with confidence, while making clear which changes need specialist support.

Agree how the site will be cared for after launch

10. Choose a maintenance model with clear boundaries

Decide whether the agency provides a fixed support window, a monthly retainer, a bank of hours, or an on-demand arrangement. Define response targets, what counts as a defect versus a new request, security and platform updates, backup ownership, uptime monitoring, dependency renewals, reporting, and escalation contacts. Include a process for small experiments and conversion improvements so the website keeps learning after launch.

This prevents support expectations from becoming a source of friction just when the site is most visible. It also makes the long-term investment predictable. The right corporate website development partner will help you distinguish essential upkeep from planned evolution and will connect both back to the success measures you chose first.

Use these decisions as a pre-signature checklist, then attach the answers to the statement of work. You do not need every detail solved before kickoff, but each open question needs an owner, a deadline, and a decision path. That is how a website project remains accountable from the first workshop through the months after launch.