What to prepare before commissioning a website

Describe the brief through one buying scenario

“We need a modern website” gives little guidance on scope. A concrete journey is more useful: a purchasing manager finds the right equipment category, reads the specification and sends an enquiry naming the model. Or a visitor chooses a service, checks the terms and books a consultation.

Write down who you sell to, what they need to know and the action they should take. If you have an existing website, share its address and explain where it gets in the way. Add reference websites with comments about the feature you value: the catalogue, clear service descriptions or the mobile experience. A link without an explanation leaves too much to guess.

List constraints such as an event date, existing URLs, language versions, bookings or a CRM. Mark functions that are still under discussion. A list of possibilities does not have to become the first release scope.

Collect facts before polishing the copy

Each service needs its scope, limitations, enquiry process and pricing method. An accurate rough draft is more useful than a finished paragraph promising tailored solutions. The facts help a studio organise the pages and explain the differences between offers.

Imagine a workshop that only accepts an order after inspecting the item. Discovering this after approving a Buy now layout means changing the journey. Record what the customer sends, who reviews it and what happens next. This is a hypothetical example, not a client story.

Collect supporting materials separately: your photographs, completed work, product specifications and reviews cleared for publication. Mark what can be published, what needs approval and what is missing. Invented figures cannot fill gaps in the evidence.

Scroll the table horizontally

Explain what happens after an enquiry

“Connect the CRM” does not define the task. Specify which fields are transferred, where the enquiry goes, who receives a notification and what the visitor sees if sending fails. Provide the system name and a contact who understands its configuration.

An initial estimate needs the systems and expected behaviour, not their passwords. Share credentials separately once the work and transfer method have been agreed. API keys and real customer records should not sit in a widely shared brief.

For a catalogue, supply a small sample of actual product data. It reveals variants, units, documents and unusual specifications that an empty spreadsheet with column headings may hide.

Choose one person to approve the final version

Different specialists can review their own areas: engineering checks specifications, sales checks terms and the brand team checks identity. One person should consolidate comments and approve the result. Otherwise contradictory instructions can reach the studio at the same time.

Track materials as ready, awaiting review or still to be produced. Add an owner and an agreed delivery date. This makes the development schedule depend on when the content will actually be available.

Agree how you will check the finished website

“Everything works” is difficult to verify. Describe observable actions: someone opens a service on their phone, submits the form, sees confirmation and the responsible person receives the enquiry. An editor changes a price without a developer if that was agreed. Important old URLs lead to the appropriate new pages.

You do not need to write a technical specification alone. A list of scenarios and open questions is enough to begin. The EO Labs project brief helps introduce the task; detailed requirements follow the initial scope discussion.

• Business and audience description
• The visitor's principal action
• Services and first-release requirements
• Materials marked by readiness
• A person responsible for approval
• Acceptance scenarios before launch