How to explain your website or digital project to a supplier

Start with one clear problem

Describe what happens today. Perhaps patients cannot find the right service, staff retype enquiries between systems or different locations publish conflicting information. Include an example and explain the effect on patients or staff.

For an illustrative practice with several locations, enquiries might arrive through different websites and be forwarded repeatedly. The first problem to solve is who receives and owns each request. A new website could be part of the answer, but the team arrangement matters too.

Explain the whole task

Follow the visitor from their first question to the point where the practice has completed its response. Include the work behind the screen. A callback button needs a receiving team; an appointment request needs someone to handle it; a service leaflet needs someone to keep it accurate.

List the tools and suppliers already involved. You do not need to decide how they will connect, but a prospective supplier should know they exist. Ask them to explain what they would change and how that addresses the problem.

Set a manageable first stage

Write down the people and services included, the important tasks to support and what can wait. State the budget or constraints you can share and any dates that genuinely matter. Explain who will provide content, approve decisions and answer questions.

Keep confirmed facts separate from assumptions. If another supplier has not agreed access to a system, identify that as a question to resolve. It should not quietly become a promise in the project plan.

A brief outline you can copy into an email

Use these prompts to prepare a first conversation. A short, honest answer is enough; write “not yet confirmed” where you need the supplier to investigate. Keep real patient details and account passwords out of the brief.

• Our organisation: services and locations involved, the existing website address and who can approve decisions.
• The problem today: one task patients or staff struggle with, an anonymised example and how we know it happens.
• The result we need: what someone should be able to complete and what the receiving team needs to do next.
• First stage: the pages, services and locations included now; the ideas we are deliberately leaving for later.
• Existing arrangements: booking, payment, email or practice systems involved and the supplier responsible for each. We will arrange access securely when needed.
• Our contribution: who supplies current facts, checks clinical wording, approves fees and makes time for testing.
• Budget and timing: the budget range we can share, any real deadline and the reason it matters.
• Proposal requested: initial and recurring costs, exclusions, dependencies, ownership, handover, support and how completion will be demonstrated.

Ask shortlisted suppliers to respond to the same brief. If one proposes an extra feature, ask which part of the stated problem it solves and whether a smaller first step would answer the uncertainty.

Agree how you will know it works

Use examples that your team can understand. Can a visitor find the correct service on a phone? Does a test enquiry reach the right person? Can reception handle a cancellation or correct a mistake? Ask for demonstrations of complete tasks.

Include training, account ownership, ongoing costs and support in the discussion. Decide who accepts the work and what happens to unresolved issues. Finish the brief with the next useful action, such as a planning session or a small prototype, rather than trying to specify every future feature.

Turn a broad aim into an acceptance example

Illustrative brief: “New patients requesting a first appointment sometimes reach the wrong branch. We need a person on a phone to identify their location and send an enquiry that reaches that branch. Reception must see which service the person asked about. We are keeping the current booking supplier for this first stage.”

An understandable acceptance check is to choose a branch, send an authorised test with fictional details and have that branch confirm receipt. Repeat with the other branch and with no location selected. The page must either ask for the missing choice or explain where the request will go. Record the expected result before testing so everyone agrees what a pass means.

Agree who resolves a failed test and who accepts the completed work. Once live, compare misdirected enquiries over similar periods, keeping the total enquiry count and any staffing or service changes alongside them. A working test establishes delivery of the agreed feature; it does not by itself establish more appointments or revenue.