A Website Brief Checklist for Local Service Companies

Start with the outcome, not a list of features

To help a supplier propose a suitable website, explain what the business needs to change or enable and how customers should get from finding you to receiving the service. Start with the outcome, not a preferred platform or a list of features.

Use these prompts to describe what success would make possible. For each item, mark it essential for launch, desirable if scope allows or not needed.

• What should customers be able to do on the website: understand which service they need, check whether you cover their area, request a quote or arrange a visit?
• What should staff be able to handle more clearly, such as receiving the right details, deciding who follows up or keeping track of an enquiry?
• What information do customers need before they contact you, so they can make an informed enquiry?
• What would a successful project make possible? Describe an intended change you can assess, such as fewer enquiries missing key details or a clearer hand-off from enquiry to quote.
• Which parts of the current process should stay as they are, and which need to change?

Be specific without assuming the answer. For example, “help customers send the details we need to decide whether to quote” gives a supplier more to work with than “get more leads”. A standard website connected to tools you already use may be enough; online booking, payment, a customer portal or a tailored system are options to discuss only if they solve a real business need.

Describe the business, its customers and its service area

Once the outcomes are clear, give the supplier enough context to explain the right work to the right customers. Keep the answers specific: a short, accurate description is more useful than a broad claim that the business does everything.

• Business summary: What do you do, and what should a new customer understand about the way you work? Note your business name, base or main location, and any important distinction between the business and its service area.
• Services: List the services the website should explain. For each one, note whether it is available on its own or as part of another service, whether you first need to assess the job, and what you do not offer. For example, say if a customer needs to arrange an inspection before receiving a quote.
• Customers: Identify the groups you serve, such as householders, landlords, businesses or managing agents. Explain where their needs differ. A landlord may need to arrange access through a tenant, while a householder may contact you directly. Include only distinctions that affect the information or next step the website should provide.
• Coverage: Describe where you take work: named towns or areas, a radius from your base, or another clear boundary. Note any meaningful differences in availability, travel or services by area. If coverage is straightforward, say so; a separate page for every place is not automatically necessary.
• Hours and availability: State when customers can contact you and whether the hours differ from when work is carried out. Note any differences by service or area, such as work you only accept on certain days.

Use these answers to help the supplier decide what customers need to see before they enquire. A service list and a clear coverage description may be enough; only ask for separate service or area pages where the information genuinely differs or helps a customer choose what to do next. Mark the requirements using the priority labels established earlier.

Explain how the work is delivered

Explain how a job moves from the first customer contact to the work itself. This helps the supplier shape the information and actions the website needs to support.

• Where is the work carried out: at your premises, at the customer’s site, across a mobile service area, or another location?
• Which types of work do you handle: emergency call-outs, booked appointments, repeat visits, one-off jobs or longer projects?
• What affects whether or how you can take a job, such as needing to inspect it before quoting or only offering call-outs in certain areas?
• For each point, mark it essential, desirable or not needed. Note any differences between services that change what customers need to know before contacting you.

Set out customer groups and coverage

Mark each prompt essential, desirable or not needed. Use this section to identify suitability details that are distinct from customer groups and coverage.

• Suitability checks: what should a potential customer know before contacting you, such as the types of property or job you take on, or any access requirements?

Map the customer journey for each type of work

Map the customer-facing route from first finding a service to knowing the next step. Focus on what customers need to see or do at each stage; document information collection, internal ownership, follow-up and enquiry routing in s4 and s4a, rather than repeating those operating procedures here. Mark each customer-facing prompt as essential, desirable or not needed.

• Start of the journey: How do customers usually hear about this service or arrive at its website page? What are they trying to find out first?
• Understanding the service: What must a customer know to decide whether the service suits their situation? Note common questions about the work, who it is for, how it is delivered and any relevant limits. Do not assume every service needs the same explanation.
• Choosing the next step: Should the customer call, send an enquiry, request a booking, ask for an estimate or arrange a discussion? Say which customer-facing action is appropriate for each type of work.
• Information needed from the customer: If a form or booking request is part of the journey, identify only the information customers must provide to complete that step. Record what your team needs to assess an enquiry in s4 and s4a.
• What happens next: What should customers see after a call, form submission or booking request, such as a confirmation or guidance on the next step? Record who reviews an enquiry and how your team follows it up in s4 and s4a.
• Different routes through the business: Does the customer-facing journey differ for another service, customer group, location or level of urgency? Set out the differences so a supplier can see whether one clear route is enough or separate pages and actions would help. Record how enquiries are assigned or routed in s4 and s4a.
• Explain or enable: Decide whether the website only needs to explain the process and provide contact details, or should actively support it with a form, booking request or another function. Describe the task the function must handle; do not specify a feature just because it sounds useful.

Write each journey in order, using the customer’s actions and the information they see. For example: customer finds the service page, checks whether the work is suitable, sends the details requested, then sees confirmation of the next step. Use a separate outline where the customer-facing route differs. This gives a supplier a practical basis for proposing a suitable website and helps distinguish clear information from a function that needs to be built.

For urgent or call-out work

For urgent work, tell the supplier how customers should reach you and what you need to know before deciding whether you can take the job. Mark each item as essential, desirable or not needed.

• When you accept requests: State the hours when urgent work is considered and what customers should do outside them.
• How customers contact you: Say whether urgent requests should go by phone, an online form or a different route depending on the situation.
• What you need to know: Identify useful details, such as the type of problem and where the work is needed.
• What happens next: Explain who reviews a request and how the customer will hear whether you can help.
• What the website promises: Avoid implying availability or a response time unless you can substantiate and maintain it.

For appointments and recurring visits

For each prompt, mark it essential, desirable or not needed.

• Say whether customers request a visit for you to confirm, or choose from available times. Note who confirms and how the customer is told.
• For recurring work, describe the service options and visit frequency customers need to understand, and how they request changes to an existing arrangement.
• List what you need to judge whether a visit is suitable, such as the address, property type, work required, access details or preferred days.
• Describe what happens after a request: who checks availability, who follows up and what tells the customer the booking is confirmed.
• Name the scheduling process or tool you use now. Say whether it should stay separate or connect to the website, and what information needs to pass between them.

For quotes and longer projects

For quotes and longer projects, include these prompts in the brief:

• Project outline: What should a customer provide about the work, its location and the outcome they want?
• Assessment: Do you need photographs, plans, a site visit or a conversation before deciding whether the project is suitable? Who reviews this information?
• Next steps: What happens after an enquiry, such as a clarification call, site visit, proposal or agreement to proceed? What should the website explain about these stages?
• Type of request: Is the customer asking for an initial discussion or a firm quote? If it is a quote request, what information do you need to assess the work and its scope?

Mark each item essential, desirable or not needed, and distinguish an enquiry from an agreed scope of work.

Specify enquiry handling and existing tools

Show what happens after a customer gets in touch: who receives their details, how the business decides what to do next and which tools are involved. For each prompt, mark it essential, desirable or not needed so the supplier can distinguish the working process from optional ideas.

• Contact routes: Which routes should the website offer: telephone, email, an enquiry form or a booking request? Say when customers should use each route, and whether some services need a different route.
• Information to collect: What does someone need to know to assess and direct an enquiry to the right person? This might include the service requested, location, preferred contact method or a suitable time to respond. Ask only for information that has a clear purpose at this stage; note anything that can be collected later.
• Receiving and following up: Who receives each type of enquiry, who decides the next action and who follows up? Describe where the details should go, how the person handling them knows what to do, and what should happen if the usual contact is unavailable.
• Bookings and confirmations: If a customer requests a visit, explain whether the website should record a request for someone to confirm or show available times for the customer to choose. Describe what needs to be confirmed and who is responsible for doing it.
• Tools in use: Name the scheduling, customer-management, job-management, payment or other tools involved. For each, say what the business uses it for and where information is entered, updated and checked today.
• Information hand-offs: Identify what should pass between the website and an existing tool, who needs to see it and what they do with it. Ask the supplier how they would confirm that a proposed connection is possible; naming a product alone does not establish that it can connect.
• When something goes wrong: Ask what staff should do if an enquiry or booking does not reach the right place, a connection fails or information needs correcting. Clarify who would notice and resolve the problem.

Ask whether the current tools can support the process without custom development. A clear description of the hand-offs helps the supplier compare that option with a tailored connection, explain the practical implications and identify what needs deciding before the work is scoped.

Define what an enquiry needs to capture

Specify only the information staff need to understand a request and decide what happens next. Treat the following fields as examples to assess, and mark each essential only where it is needed for your process; otherwise mark it desirable or not needed.

• Examples to assess: customer name, preferred contact method, location or postcode, service needed and a short description of the problem or job.
• Optional: preferred visit times, access details, relevant measurements or product details, and a budget range where it helps assess a quote. Say why each would be useful.
• Supporting information: note whether customers should send photographs or documents, how they can do so, and whether these are needed before staff can respond.
• After submission: specify who should receive each type of enquiry, how staff will know it has arrived, and what confirmation or next-step message the customer should see.

Ask the supplier how the proposed route will work when the usual contact is unavailable.

Describe tools and hand-offs already in use

• Enquiry handling: Summarise a typical enquiry from receipt to action: the tools used, information passed on, staff hand-offs and points where details are re-entered or requests lose track.
• Integration-specific questions: Ask the supplier to check what access and connection methods are available, whether a connection would address a stated workflow problem, how information would flow and who would maintain it.
• Manual alternative: Say whether a clear manual hand-off using existing tools would be acceptable if a connection is unnecessary or unsuitable.

Mark each option essential, desirable or not needed. Do not add a connection simply to add a feature.

List the content and evidence the website needs

Give the supplier an inventory of the information and materials available, and identify what still needs to be created. Focus on what helps a customer understand the service, decide whether it suits them and take the right next step.

• Service information: What clear descriptions can you provide for each service, including what is included, any important exclusions and what a customer should prepare? Priority: essential / desirable / not needed.
• Practical details: Which operating hours, response arrangements, visit or project processes should the website explain? Note information that can change and who will keep it current. Priority: essential / desirable / not needed.
• Customer questions: What do customers commonly ask before they proceed? Include what happens after they contact you, what information or access they may need to provide, and any relevant preparation. Priority: essential / desirable / not needed.
• Photographs and examples: What usable images, examples of completed work or other supporting material do you have? Note what each item shows, whether it is suitable for publication and any permission that still needs checking. Priority: essential / desirable / not needed.
• Company information: Which details about the business and the people customers may deal with will help explain who provides the service? Identify any biographies, team photographs or other material available. Priority: essential / desirable / not needed.
• Claims and evidence: List any credentials, qualifications, customer feedback or results you want to publish, and who will check that each statement is accurate and can be supported. Do not include claims that have not been verified. Priority: essential / desirable / not needed.
• Content responsibilities: Name who will draft, review and approve each type of content. Say whether you expect the supplier to organise or produce any material, and flag gaps that need resolving before work begins. Priority: essential / desirable / not needed.
• Keep the scope useful: Prioritise content that answers real customer questions over a large page count. Mark additional pages or materials as optional unless they serve a clear customer need. Priority: essential / desirable / not needed.

Set practical expectations for use and ownership

Record how the site will be used in day-to-day work, who will look after it and what the supplier is expected to provide. For each prompt, mark it essential, desirable or not needed, and add a short note where the answer depends on the service.

• Use while away from the office: What must customers or staff be able to find or do easily on a phone, perhaps while travelling or at a job? For example, this might be checking whether a service covers an area, finding contact details or sending an enquiry. Note which information needs to be prominent and what should happen if staff cannot respond immediately.
• Accessibility: Are there specific accessibility needs the supplier should consider in the design, content or way people navigate the site? Describe the need in practical terms and ask the supplier how it will be addressed; this brief is not a substitute for checking applicable requirements with an appropriate adviser.
• Languages: Do customers need information in more than one language? If so, identify which pages or customer instructions need translation and who will provide and check the translated content.
• Staff updates: What should staff be able to change themselves, such as service details, opening information or photographs? Identify who will make those updates and whether they need guidance to do so.
• Ownership and access: Who should own and have access to the domain, hosting, website, content, design files and relevant accounts? Name the responsible person and make clear how access will be handed over if staff or suppliers change.
• After launch: Who will handle routine content updates, technical maintenance and further changes? Ask the supplier to explain what each arrangement includes, what remains your responsibility and how requests will be managed.

Clear answers help the supplier propose a site staff can manage and customers can use in real working conditions, without assuming every task needs a new feature.

Separate launch essentials from later options

Keep the brief focused by separating what the website must do at launch from ideas that can wait. For every requirement, mark it Essential, Desirable or Not needed, and give the business reason for anything essential. This helps a supplier explain trade-offs instead of treating every idea as part of the same scope.

• Launch essentials: List the pages, enquiry routes and information customers need to choose the service and take the next step. For call-outs, make clear which contact route matters most; for recurring visits, say what customers need to request or arrange; for longer projects, prioritise the information needed to assess a potential job.
• Later options: Note features that could be considered after launch, such as more involved booking, customer accounts or automated workflows. Explain the problem each would solve, but do not assume it needs a custom build.
• People and decisions: Name who will provide and check the content, who can approve decisions, and who will review the finished website. Include any business dates that affect the work.
• Dependencies: List existing suppliers, tools or processes the website relies on, and identify what information or access the business would need to provide. Flag anything that could affect the proposed approach.
• Scope and acceptance: Ask the supplier to state what is included, what assumptions they have made, what the business must supply, and how the completed work will be reviewed and accepted. Ask how requested changes beyond the agreed scope will be handled.
• Standard tools or tailored work: Ask whether a conventional website working with tools already in use can meet the essential needs. Discuss a custom feature or business system if a specific workflow cannot be handled suitably with standard tools, and ask what extra scope and responsibilities that would introduce.
• Optional measurement or marketing tools: If these are being considered, record what the business wants to understand or achieve and ask the supplier to identify assumptions and any requirements that need checking, including who will confirm them.

The result should make the priorities, responsibilities and open decisions visible before the supplier proposes a solution. If an idea is not needed to meet a launch goal, label it accordingly rather than letting it silently expand the initial brief.

Choose what must be ready at launch

Start by listing the tasks customers and staff must be able to complete on day one, such as finding information, making an enquiry or handling an order. Include only the features needed to complete those tasks reliably.

Then rank the remaining features by what they improve and what depends on them. Defer features that can wait without blocking the main journey, and record who will handle any gaps at launch. This gives you a practical first release without treating every requested feature as essential.

Ask the supplier to make scope and responsibilities clear

Before agreeing the work, ask the supplier to make assumptions, responsibilities and boundaries explicit. For each item, mark it essential, desirable or not needed, and note who will provide the information or decision.

• Assumptions and checks: What are you assuming about the business, its current tools or the required workflow? What needs investigating before you can propose a solution?
• Responsibilities: Who will provide and approve content, arrange account access, share access to existing tools and make decisions?
• Scope: What pages, functions, integrations or migrations are included, and what is outside the proposal?
• Checking the result: How will we check the agreed requirements have been met, and who will review and approve the work?
• Standard or tailored: Which needs can an ordinary website or existing tool handle? If a tailored feature is proposed, what specific workflow need does it address?
• After launch: Who is responsible for updates, maintenance and support, and what is included?

Copy and adapt this short website brief

Copy this outline into your brief. For each line, mark one priority and explain why it matters. Share what you know; flag open questions for the supplier rather than guessing at a technical solution.

• Business and customers: What do you do, who do you serve, and what should customers understand before contacting you? Priority: essential / desirable / not needed. Why: ____.
• Services and coverage: Which jobs do you take, where do you work, and what limits affect availability? Priority: essential / desirable / not needed. Why: ____.
• Outcome: What should the website help the business or customer do? How will you recognise that it is working? Priority: essential / desirable / not needed. Why: ____.
• Customer journeys: What should happen from first visit to completed work for each type of service? Priority: essential / desirable / not needed. Why: ____.
• Enquiries: What details should customers provide, where should enquiries go, and who follows up? Priority: essential / desirable / not needed. Why: ____.
• Existing tools: What do you use for scheduling, customer records, quotes or payments? What information needs to move between tools? Priority: essential / desirable / not needed. Why: ____.
• Content and assets: What service information, images, documents or evidence can you supply, and who will check it? Priority: essential / desirable / not needed. Why: ____.
• Use and access: What needs should the website meet for mobile use, accessibility or languages? Priority: essential / desirable / not needed. Why: ____.
• Ownership and care: Who will update content and look after the website after launch? Priority: essential / desirable / not needed. Why: ____.
• Launch and later: What must be ready at launch, and what could wait? Priority: essential / desirable / not needed. Why: ____.
• Constraints and supplier questions: Note available content, staff time, existing commitments and anything uncertain. Ask the supplier to clarify scope, responsibilities, options and ongoing support. Priority: essential / desirable / not needed. Why: ____.
• Tailor the journey: Call-out firms should specify urgency and contact routes; recurring services should explain repeat visits and changes; project businesses should list what is needed before a quote or site visit. Priority: essential / desirable / not needed. Why: ____.

Once your requirements are clear, use them to guide discussions with potential suppliers.