A Website Brief Checklist for Independent Estate Agents

Give suppliers a clear brief before discussing design

A useful estate agency website brief sets out the agency’s branches and service areas, whether it handles sales, lettings or both, and what visitors should be able to do. It should also explain how property details are maintained, where enquiries need to go, which existing systems must connect, and who will supply and approve content.

Before discussing design, work through this checklist with the people who manage branches, listings and enquiries. For each point, mark it as agreed, to confirm with a supplier, or not needed.

• Business context: List your branches, the areas they serve and the services each offers. Check that the proposed structure can represent your branches and coverage.
• Audiences and outcomes: Name the people the site serves and the actions they should be able to take, such as finding a property, registering interest or contacting a branch. Decide which actions matter most.
• Properties and search: Summarise the property information visitors need, the search options they need, and how listings are added, changed and removed. Confirm who maintains listing data and how updates reach the website.
• Systems and providers: List your current website, domain, CRM, property portal feeds and analytics tools. Ask each provider what information can be shared, how it is transferred and who can confirm the available options.
• Enquiries and follow-up: Explain which branch or person should receive each type of enquiry, what information they need, and how staff will follow up. Check whether current systems can support the intended routing.
• Pages and content: Identify required pages, brand assets and who will write, supply and approve content. State your accessibility expectations and any content needs specific to your services or locations.
• Ownership and acceptance: Record who should own relevant accounts and access, what support is needed, and how you will check the finished website against the brief.

The following sections expand each area, including the questions to resolve with your existing system or portal providers.

Describe your branches, audiences and website goals

Describe how the agency operates before specifying what the website should look like. This helps a supplier distinguish a shared website journey from requirements that differ by branch or service.

• Branches and coverage: List each branch, its location, the areas it serves and whether it handles sales, lettings or both. Note any areas covered by more than one branch and which team should take responsibility for them.
• Audiences: Identify the people the site needs to serve, such as buyers, renters, landlords and vendors. For each, note the main task: for example, a renter finding suitable properties, a landlord asking about management, or a vendor requesting a valuation. Include any audience that needs a different contact route.
• Priority journeys: Write a short description of the steps a visitor should be able to take. For a buyer, this might be to browse properties, narrow the results, open a listing and contact the team handling it. For a landlord, it might be to understand the agency’s service and send an enquiry to lettings. State what information the visitor should provide and what should happen after submission.
• Branch hand-offs: Explain how to route a request when the visitor’s location, selected property or chosen service points to different branches. For instance, say whether an enquiry about a property should go to the branch managing that listing, even if the visitor selected another branch, and who should deal with enquiries that do not match a particular area.
• Outcomes and priorities: Name the outcomes the agency will use to judge whether the website is doing its job, such as making listings easier to find or directing enquiries to the appropriate team. Separate what must work at launch from improvements that could be considered later. This gives the supplier room to propose a suitable scope rather than treating every requested feature as essential.

Ask the branch managers and the people who handle sales and lettings enquiries to review these answers. Differences in how teams work are easier to resolve in the brief than after the supplier has designed a journey around the wrong hand-off.

Specify property information, search and listing updates

Describe what a customer should see on a property page, how they should find suitable properties and how listing changes reach the website. Use real sales and lettings records to define the requirements, then ask your CRM and portal suppliers to confirm what data and connections are available.

• Property details: List the information required for each sales and lettings listing, such as the description, price or rent, location, key features and current status. Note where the information differs between sales and lettings, and whether a branch needs to add local contact details or other branch-specific information. Check with your CRM supplier which fields are stored, which are mandatory and whether the website can receive them.
• Search and filters: Describe the searches customers need to make, using your actual property records and common customer journeys as prompts. For example, identify which distinctions matter to your customers, such as sales versus lettings or properties linked to a particular branch. Separate essential filters from optional ones. Ask whether the underlying property data is consistent enough to support each filter, and how the supplier proposes to handle missing or inconsistent values.
• Photographs and other media: Specify which materials should appear on a listing, such as photographs, floor plans or other property media. Record who supplies them, who approves them and who updates or removes them when a property changes. Confirm with your CRM or media provider what can be passed to the website, and whether any preparation or manual handling is needed.
• Listing changes: Map the steps from a property being added to the system through to amendments, a change in availability and removal from the website. Name the person or role responsible for each step, including who checks that a change has reached the website. Ask the CRM and portal suppliers which system is authoritative for each listing field, how updates are sent, and what happens if a feed or connection fails.
• Descriptions and marketing information: State who drafts and checks listing descriptions and other information before publication, and who can correct it if an error is found. Traders are responsible for deciding what information an average consumer needs to make an informed decision under the Digital Markets, Competition and Consumers Act 2024. ¹ Make the approval and correction process clear to the supplier; do not assume that a website connection replaces your internal checks.
• Supplier dependencies: List the CRM, portal or other systems involved in creating and distributing listings. Ask each provider what data the website supplier can access, what compatibility requirements apply, and which party is responsible for resolving feed or data issues. Mark answers still to be confirmed, rather than letting an assumed connection shape the proposal.

This detail helps suppliers distinguish a website that displays existing property data from work that may require changes to your systems or listing process. Keep the requested information and search functions tied to actual records and customer needs, rather than specifying features without confirming the data can support them.

Map CRM, portal feeds and branch systems

List the systems that currently hold property, branch and customer information, then describe what each one needs to send or receive. Ask the relevant suppliers to confirm what is compatible before treating a connection as part of the website scope.

• Name each system. Record the CRM, property portals and any other tools that affect listing details, branch information or enquiries. Note which branches and services use each system, and who can answer questions about it.
• Describe the information flow. For each proposed connection, state what information should move and in which direction. For example, identify whether property details should move from the CRM to the website, or whether a website enquiry should be recorded in the CRM. Ask which system is the source of truth if information differs.
• Explain what should happen when records change. Specify the expected result when staff add, edit, withdraw or relist a property, or change branch details. Clarify whether a staff member needs to approve an update and how they will know it has appeared in the right place.
• Check portal feed requirements. Ask each portal supplier what information and feed arrangements it requires, and ask the website supplier to confirm whether it can support them. For UK sales and lettings feeds, Rightmove expects the Send property, Remove property and Get branch property list calls to be fully tested and available. ² Confirm who will arrange and carry out those tests.
• Agree responsibility for errors. Ask how staff or suppliers will identify a failed or incomplete feed, who investigates it, and how the agency will be told that listings may be missing or out of date. Clarify who can correct the source record and who checks that the correction has reached the website or portal.
• Resolve open questions before scope is agreed. Record the question, the provider who needs to answer it and the decision it affects. Ask the CRM, portal and website suppliers to confirm compatibility, responsibilities and testing arrangements. Avoid prescribing a technical method until the suppliers have confirmed what is supported.

These answers help distinguish a straightforward connection to existing tools from a requirement that needs further investigation. If a provider cannot confirm the expected information flow or testing responsibility, keep that point open in the brief rather than assuming the integration is available.

Explain how enquiries should reach the right people

Write down what should happen from the moment someone submits an enquiry until a member of staff takes responsibility for it. This gives the supplier a workflow to scope, rather than leaving routing and follow-up to be decided during design.

• List the enquiry routes. Specify whether the website needs separate forms for a property enquiry, a general sales enquiry, a lettings enquiry and a request to contact a branch. Note where each route appears, such as on a property listing or a branch page. Check: confirm with the relevant branch managers which routes they use and whether any should go directly to a shared team.
• Define the routing rules. For each route, state whether an enquiry goes to the property’s branch, a named team, or a central inbox, and whether the property or enquiry type changes the destination. Explain what should happen if the usual recipient is unavailable, including who provides cover. Check: ask the CRM or website supplier whether the proposed rules can be supported and where they are configured.
• Specify the information staff need. For each form, list the details needed to respond to the initial enquiry, such as the property being asked about and a way to contact the enquirer. Explain the purpose of any additional field so the supplier can distinguish necessary information from optional detail. The ICO advises that a website enquiry form should collect only the personal data needed to handle the initial enquiry, be secure, and make the privacy notice clearly accessible. ³
• Say where the enquiry is recorded. State whether staff should receive an email, whether the enquiry should also be recorded in the CRM, and what information must be passed between the website and connected systems. Check: confirm with the CRM supplier which fields can be received, how the enquiry is matched to a property or branch, and what happens if recording fails.
• Name the follow-up owner. For each route, identify the team or role expected to review and respond, and how staff can see that an enquiry is awaiting action or has been handled. Set out any escalation or cover process your agency wants reflected in the workflow. Check: agree responsibilities with branch managers and the person who oversees the CRM, then ask suppliers to explain how the proposed setup supports them.
• Ask how the full route will be checked. Include sample scenarios for a property enquiry, a general enquiry and a branch contact request. Specify who will confirm that the right details reach the right destination and that staff can find the record in their usual system.

Where a routing or recording detail is not yet agreed, mark it as a decision to resolve with the relevant staff member or system supplier before finalising scope.

Set out pages, content, design and accessibility expectations

Give the supplier a usable content and design brief, not just a visual reference. For each page, state what it needs to tell visitors, what action they should be able to take and who will provide and approve the material.

• Pages and purpose: List the pages the agency needs, such as branch pages, sales and lettings services, property listings and contact routes. For each, note its audience, essential information and next step. Verify: Check which branch details and service information are current, and who can confirm them.
• Brand and tone: Describe the agency’s existing identity, preferred tone and any design qualities that matter. Identify the calls to action visitors should notice, such as viewing a property or contacting a branch. Share relevant brand guidelines, existing copy, photography and examples of current materials for the supplier to review. Verify: Confirm that you have permission to use any supplied images and that the material represents the agency accurately.
• Content responsibilities: Name who will write or supply each kind of content, including branch information, service descriptions and property-related copy. Identify who checks factual accuracy, who gives final approval and who makes the decision if branch or management views differ. Verify: Agree how missing or late content will be flagged and who can make a decision to keep the work moving.
• Mobile use: Describe the tasks customers should be able to complete on a mobile device, such as finding a property, viewing its details and contacting the relevant branch. Tell the supplier about any specific difficulties customers or staff have encountered with the current site. Verify: Ask how the supplier will review those journeys on mobile, including forms, navigation and property information.
• Accessibility expectations: State the accessibility needs the agency wants addressed, rather than assuming the supplier will infer them from the design brief. WCAG 2.2 is a W3C Recommendation that provides recommendations for making web content more accessible.⁴ Ask the supplier how accessibility will inform design and content decisions and how it will be checked. The standard can help frame the conversation, but it does not replace describing the agency’s particular needs. Verify: Agree what will be reviewed, who will take part and how any issues found will be recorded and resolved.

Agree ownership, support and how the work will be checked

Before comparing proposals, agree who will control the website and its connected accounts, who will keep its information current, and how you will decide whether the completed work meets the brief. Use this checklist to make responsibilities and sign-off clear.

• Accounts and access: List the domain, hosting, analytics, CRM and any other accounts the website depends on. For each, record who owns it, who can grant access and which supplier or agency staff need access to do their work. Ask how access will be provided securely and what happens to it when a supplier relationship ends.
• Content and assets: Name the person responsible for property-related information, branch details, staff profiles, fees or other approved content. Confirm who supplies copy, photographs, logos and other assets, who checks them before publication, and who can make routine changes after launch. Ask what training or handover is proposed so updates do not rely on the original supplier for every small change.
• Maintenance and support: Describe the help you expect after launch, such as assistance with faults, routine changes or connected services. Ask the supplier to set out what is covered, what is excluded, how to raise a request, who will assess it and how any additional work is agreed. Check whether you or the supplier is responsible for renewals, backups, software updates and monitoring, where relevant to the proposed solution.
• Acceptance checks: Turn each essential requirement into an observable check. For example, ask a branch representative to test a property journey from search results through to the listing and enquiry route; check that the agreed branch contact details appear in the right places; and verify the feed behaviour agreed with the relevant system supplier. Record expected outcomes rather than relying on a general statement that a feature is complete.
• Review and issue handling: Name who will review the work and who can approve it for the agency. Agree what will be demonstrated or documented, how reviewers will record issues, who will decide whether each issue is a defect or a change to scope, and how unresolved points affect sign-off.
• Shared record: Keep decisions, exclusions, assumptions, dependencies and responsibilities in the final brief. Ask each supplier to identify any points it has interpreted differently, so proposals can be compared against the same agreed requirements.

Hand over the brief and choose the right level of solution

Before sending the brief, check that a supplier can see what the agency needs to do, which existing tools are involved and how you will decide whether the proposed solution works. Include:

• Agency context: branches covered, sales and lettings services, audiences and priority website journeys.
• Property and search: the information and media required, how listings should be searched, who updates them and what should happen when a listing changes.
• Systems and enquiries: CRM and portal connections to investigate, how enquiries should be routed, who follows them up and what needs to be recorded.
• Content and ownership: who supplies and approves copy, images and branch details, and who manages the website and support after launch.
• Acceptance: the essential tasks to check, such as whether a listing update appears as expected and an enquiry reaches the intended team.

Attach or describe examples of current property records, branch information and enquiry journeys. Use them to explain what needs to work, not as an instruction to reproduce every current process. Ask the relevant CRM, portal or other system providers to confirm any uncertain connection or limitation before agreeing scope.

A standard website connected to existing tools may be enough if those tools support the required listing updates and enquiry workflows, and you do not need additional behaviour. If distinct branch, sales or lettings workflows are not supported, confirm the gap with the providers before considering a more tailored solution. Where the setup is broadly suitable, targeted improvements or clearer working practices may be a better fit than replacement.