A guide for businesses
How to brief a business website project
A practical guide to briefing a business website: clarify goals, audience, content, features, SEO, budget, ownership, and launch requirements.
A brief need not be long or read like a finished specification. It should explain why the site is needed, who it serves, what must be prepared, and which decisions remain open.
Write in your own words. Mark unknowns as questions to resolve together; that is better than detailed assumptions that may prove wrong.
1. Start with the business goal
Describe what should change because of the new site. Should customers find the offer more easily, send more inquiries, understand a complex service, book a consultation, or use a catalogue? Choose the main goal and add any supporting goals.
Describe where the customer journey breaks down today. Instead of “the site should look modern”, record an observation: customers often ask for information missing from the offer. That gives the project a real problem to solve.
- The most important action you want a visitor to take.
- A problem with the current site or a missing capability.
- A signal that will tell you the new site is doing its job.
2. Describe the audience and their questions
You do not need elaborate personas. Describe the main customer groups, what they seek, how they choose a provider, and what might stop them getting in touch. Note whether one person or a whole team makes the decision.
For local work, name the service area and customer locations; for wider sales, note the markets and languages. Collect real questions from conversations, email, and customer support.
- Main customer groups and what they need.
- Questions, concerns, and reasons they might delay a decision.
- Locations or markets and the languages the site needs.
3. List the pages and content you need
Make a first list of pages, such as home, services, projects, about, FAQ, and contact. Use it to check what a customer needs to know before taking action.
For each page, name the content and its owner: copy, photos, pricing, documents, technical details, or project stories. Mark what exists, what needs updating, and who will approve new material.
- A first page list and the main purpose of each page.
- Available copy, photos, brand assets, and documents.
- People responsible for preparing and approving content.
4. Separate essential features from future ideas
List what the site should do: collect inquiries, take bookings, provide a catalogue, accept payments, or support several languages. For each feature, name its user and the process it should improve.
Add integrations such as a CRM, email marketing, maps, payments, or analytics. Name the service and access owner. Mark ideas as optional so their value can be weighed against cost.
- Features required on launch day.
- Integrations and processes the site should support.
- Optional ideas that can wait for a later phase.
5. Decide who will update the site and how often
If services, products, or news change often, say who will update the site and whether they need user roles, approval steps, or several languages.
Note whether the business already has a content system, who will run it, and whether training is needed. Clarify which updates staff will handle and where they expect support.
6. Protect search visibility, the domain, and existing URLs
If a site already exists, share its address and important pages or content. Decide which URLs to keep, combine, or redirect, and provide analytics access if available.
Describe the service area, services, and topics customers search for. Local businesses should list locations served and accurate contact details. Clarify who owns the domain, hosting, and third-party accounts.
- The current website address and important existing pages.
- Available analytics and priority topics or locations.
- The owner of the domain, hosting, and connected accounts.
7. Define scope, constraints, and decisions
Separate launch requirements from items that can wait. Include brand guidelines, legal constraints, accessibility needs, existing tools, and provider dependencies. Distinguish requirements from preferences.
Share a budget or range if possible; it helps shape scope and phases. Name the decision-maker, reviewers, and approval time. One person coordinating feedback helps avoid conflicting directions.
- Launch scope and ideas for later.
- Budget, constraints, and dependencies on other providers.
- Decision-maker, reviewers, and how feedback will be collected.
8. Describe timing and acceptance
Say whether the date depends on an event, season, campaign, or current provider. Note ready materials and open decisions that might affect timing.
Define acceptance: review copy, forms, mobile layout, links, redirects, analytics, accessibility, and access handoff. Decide who reports issues and maintains the site after launch.
- The reason for the launch date and how flexible it is.
- Ready materials, open decisions, and dependencies.
- A test list, the person accepting the work, and handoff plans.
What should you send to start the conversation?
For a first conversation, bring a short brief with goals, audience, pages, features, timing, and budget or constraints. Include your current site, references, and brand materials. You do not need to choose technology or design screens.
When sharing references, say what works - the way an offer is presented or the simple navigation - rather than only what you like. Explore selected projects and get in touch with your brief.