How to write a project brief an agency can use

State why the project exists now. The current site may be difficult to update, the company may be entering a new market, or appointment requests may be getting lost across messaging channels. Describe the observable problem before suggesting a feature list.

Then name the action the new surface should support. Examples include requesting a trade quote, booking an available time, finding a local dealer, or managing incoming leads. "Look more modern" can be a valid preference, but it does not tell a team what the website must help someone accomplish.

If several actions matter, rank them. That priority will affect navigation, page order, data requirements, and the first release.

Identify who makes the decision and what they need to know first. Include the market and language where relevant. A US trade buyer, a local appointment customer, and an internal operations user bring different vocabulary and expectations to the interface.

List what already exists: brand files, copy, photography, product data, customer records, domain access, analytics, and any current system that must connect to the new work. Missing material affects timing as much as development does.

Write the constraints plainly. Include the desired release window, budget range if available, legal or compliance requirements, required integrations, internal approval process, and people responsible for decisions. Hiding a constraint does not make it disappear; it only moves the conversation to a more expensive stage.

References are useful when each one comes with a reason. Point to the navigation of one site, the editorial pace of another, or the way a third presents technical specifications. A folder of unexplained screenshots asks the agency to guess which qualities matter.

Include counterexamples as well. Explain which patterns feel wrong for the brand or create problems for users. Specific rejection is useful: "the text becomes too small on mobile" gives the team more direction than "this does not feel premium."

References should inform the project rather than prescribe a copy. The final interface still needs to respond to your content, audience, and operating constraints.

During scope, convert the brief into pages, functions, responsibilities, exclusions, and approval points. Each later review can then return to the original decision: does this work support the intended user action under the agreed constraints?

Update the document when an approved change affects that decision. Keep changes visible instead of allowing them to enter through scattered messages. This gives the team a current reference and makes the effect on timing or cost easier to discuss.

A compact example might read: "We are replacing our dealer website so US trade buyers can review cabinet lines and request a quote. We have approved brand files and product photography. The sales director approves content. Launch is planned before the autumn trade event. CRM replacement is outside this project."

Before sending the brief, ask someone outside the project to read it once. If they can identify the business problem, intended user, required action, and approval owner without extra context, an agency has enough to begin a useful scope discussion.