A small business website brief you can actually use

Describe the customer and the task

Start with a sentence about the person who will use the website. “We need a modern website” leaves the hardest decisions open. “Local shop owners need to compare our maintenance packages and request a call” gives the designer a concrete audience and action.

Write the top three questions a visitor must be able to answer. For a service business, those might be what you do, whether you serve their location and how they can get a quote. These questions guide the pages, navigation and content more effectively than a long list of visual preferences.

Choose one primary action

Decide what a qualified visitor should do next: request a quote, book a consultation, place an order or try a tool. Secondary actions can exist, but they should support a clear journey rather than compete for attention.

For example, a repair service might use a short quote form asking for the problem, location and contact details. Asking for ten unnecessary fields can create more work for the visitor and for your team. State which information is genuinely required to respond.

List the content and responsibility

Make a simple page inventory. A small service site might need Home, Services, About, Contact and appropriate policy pages. For each one, record its purpose, main action and who supplies the text, photos, pricing or examples. Only include claims and testimonials you can substantiate.

If you want a blog, describe who will publish it and what a normal article needs. A practical editor might need a title, summary, body, optional image and a clear publish action. Specify how the article should look on mobile and who reviews factual claims before publication.

Name the integrations and ongoing costs

List requirements such as email delivery, a booking service, payments, analytics or a CRM. Name the provider if one is already chosen. Identify who owns each account and how credentials will be shared privately. Do not place passwords or API keys in the project brief.

Separate one-time development work from recurring hosting, subscriptions and usage-based charges. If a feature needs an AI API, define the actual user task, data handling, rate limits and expected behavior when the provider is unavailable. A free model does not remove the need for abuse controls and reliable fallback behavior.

Write acceptance checks before the quote

• A phone visitor can reach the main action and complete it without horizontal scrolling.
• Forms show useful validation, a clear success state and a helpful failure message.
• Public pages have descriptive titles, useful content and working internal links.
• The owner receives the source, deployment instructions and an explanation of how to update content.

Add your budget range, desired launch date and any fixed constraints. Mark later ideas separately so they do not silently become launch requirements. Ask for a written proposal that states deliverables, exclusions, revisions and support.

If you need help turning this brief into a build, review Gencyh's website and software services and send the project details through the contact page. Clear inputs make the scope and quote easier to assess.