Website Proposal Briefs: Give the Agency a Clear Basis for Scope

You ask an agency for a corporate website. Its proposal includes design and development, but does not establish who writes service copy, how many English pages are included or whether existing articles will move. After work begins, each becomes another decision and another scope question. A website proposal brief makes those uncertainties visible before interface production starts.

A useful brief need not be lengthy. It should answer the relevant questions, identify missing information and explain the assumptions under which proposals are requested. This guide uses a hypothetical consultancy preparing a new site. A team without technical-specification experience can still provide a strong starting point; the implementation approach can then be developed with the agency.

Describe the problem through the present situation

“Look more modern” is understandable but does not establish what should change. Are services difficult to distinguish, updates awkward or enquiries poorly matched? Use concrete observations and include an address or task where helpful. Do not present unsupported interpretations as established results.

Suppose the example consultancy’s three services are confused on one page. The brief might state that suitability and deliverable differences need clear independent explanations. That defines a problem without prescribing every design solution. The agency can explain its recommendation against the need. An acceptance task also follows: can a visitor recognise the service relevant to their situation?

Define the audience through decisions and information needs

An industry label alone may not explain a service website’s readers. A purchasing manager assessing suppliers, a specialist checking technical fit and an owner learning about the offer may require different detail. Describe the situations that matter rather than expecting a broad demographic category to direct the content.

Write the essential question for each group and the appropriate next step, such as a conversation, document review or enquiry. Asking every visitor to do everything at once obscures priorities. Rank the principal and secondary tasks. Where goals conflict, identify the decision still needed. The brief does not have to pretend that every problem has already been resolved; it needs to show which ones the project is expected to address.

Separate page inventory from template requirements

List expected principal pages and service details, including purpose, language and content status. “A blog” can mean categories, listings, detail pages and search, each requiring assessment. Projects and team sections also involve content types and presentation choices. Make those expectations visible enough for comparable estimates.

Page count is not design count

Ten service pages can share a template, while a smaller site may require more distinct functions. Separate content quantity, layouts and custom components. Where the brief cannot establish that distinction yet, ask candidates to state their assumptions. This exposes scope differences hidden under a common label. Testing each template with genuine content can also form part of the acceptance plan instead of assuming short sample copy represents every page.

State content status and ownership

Are texts complete, being rewritten or awaiting only editing? Are image permissions available? Who translates and who approves? These questions affect the schedule directly. If customer-supplied content is assumed, define the expected format and review owner rather than leaving the agency to infer them.

Treating unfinished material as ready may speed up estimation while increasing later uncertainty. A simple status register can show existing product photographs, draft service explanations and missing English content. Collect approved examples in an appropriate location. Avoid including restricted or irrelevant documents. Content responsibility should remain an explicit project decision rather than an assumption hidden inside a technical estimate.

Describe functions through scenarios

Labels such as contact form, membership and integration are not complete specifications. What does the form collect, where does it send information and who responds? What does membership enable? Which data moves through an integration, in which direction? Short answers make development needs more concrete.

For each function, describe the starting situation, action and expected outcome. A service enquiry might reach the designated team in an agreed record. Consider missing fields and failed submission too. Unknown technical details can remain research questions, with an agency proposing the necessary discovery. In a web design and development brief, separating uncertainty from supposedly finished requirements creates a more realistic basis for scope.

Explain why a design reference is useful

An example website does not reveal which feature matters. Is it navigation, information order, typography or photography? Add a short reason. The reference then communicates a relationship to solve rather than an instruction to reproduce another design.

Prioritise conflicting examples. A dense information interface and an expansive brand presentation may serve different needs. Provide approved identity files, the intended logo version and visual direction separately. Leave undecided areas open enough for proposals. The brief should tell the agency where advice is expected while defining the boundaries the business genuinely needs to preserve. This supports design judgement without making essential constraints invisible.

Describe the technical environment using known facts

Domain, hosting, current management tools and integration information can affect the work. Technical fluency is not required to collect verified facts from the existing provider. Mark unknown areas for investigation. Credentials should not be written into a widely shared proposal document; use an appropriate protected method when access is actually needed.

Ownership matters too. Who controls the domain, how will new accounts be handed over and who maintains the result? These questions concern business continuity as much as implementation. Explain any genuine requirement to keep existing infrastructure. If there is no constraint, avoid locking the solution solely through habit. Ask candidates to connect their proposed approach with the needs and maintenance arrangement instead of presenting a technology name as the entire rationale.

Include existing addresses and migration work

A redesign must decide what happens to current pages, imagery and documents. Which content remains, moves or is removed? Old links may need equivalent destinations. Discovering this on launch day creates avoidable uncertainty. State the approximate content inventory and available records in the brief.

Google’s URL-change guidance describes planning and mapping relocated content. A proposal should explain what is checked, which information the customer supplies and how production is verified. If migration is priced separately, its basis should be understandable. Copying files and preserving a useful visitor journey are different deliverables; content relationships need attention as well as transport.

Turn SEO expectations into identifiable work

“SEO-friendly” can mean different things in competing proposals. Title fields, descriptions, link structure, sitemaps, technical access and existing URL handling are distinct activities. Content research and ongoing optimisation should be stated separately if offered. Replace one broad label with outputs that can actually be reviewed.

Google’s SEO starter guide explains the connection between content and technical discovery. A guaranteed ranking should not become an acceptance condition. Define work within the team’s control instead: which information is entered, who reviews it and how technical checks are reported. Search performance then requires appropriate observation over time rather than being treated as proof supplied automatically by a launch checklist.

Put dependencies behind the dates

If an event or commercial deadline matters, state it. Content delivery, approvals, translation and access preparation all influence feasibility. Saying the work must finish in a month does not explain when its inputs become available. Decision-makers and feedback arrangements belong in the schedule too.

Identify required approvals between stages. Conflicting comments from several managers can delay a final decision. One owner or a clear resolution method can help. Review how scope changes affect timing in the proposal and agreement. Every later request cannot be predicted, but the method for considering it can be defined. The objective is a shared working arrangement rather than a calendar that depends on unstated assumptions.

Define acceptance and the work after launch

Which tasks should be tried before publication? Finding a service, changing language, sending a form and updating content can enter the list. Select mobile views, important browsers and failure scenarios according to scope. Approval should not be limited to whether the team likes the screen images.

Training, account transfer, documentation, corrections and continued maintenance may involve different responsibilities. Explain support scope and response arrangements. Assessing a corporate website proposal through these items makes post-launch ownership clearer. Finish by separating assumptions, open questions and approved decisions. A strong brief does not tell the agency every solution; it supplies the facts and decision boundaries needed to propose the right work.

Frequently asked questions

Can we prepare a brief without technical expertise?

Yes. Current problems, visitor tasks, content status and business workflow provide useful starting information. Mark unknown technical areas as research questions. Ask candidates to explain assumptions and investigation instead of supplying inaccurate detail simply to make the document appear complete.

How long should a proposal brief be?

Long enough to support the main scope decisions. Concentrate on purpose, pages, content and functions rather than an extensive company history. Complex work may require supporting documents. Neither brevity nor length independently proves that a brief provides the information needed for a reliable estimate.

Is linking to an example site sufficient?

Explain which feature matters: navigation, content order or visual approach, for example. Without that context the reference can be interpreted differently. It should help communicate the need rather than become an instruction to copy another organisation’s design.

Should the budget appear in the brief?

Known limits and priorities can be shared according to the business’s approach. Discuss how scope can fit them, potentially through stages. Do not present an undecided amount as a fixed commitment. The important point is that cost and proposed work are considered together rather than through incompatible assumptions.

Can proposals be requested before content is ready?

Yes, if its status is explicit. Writing, imagery and translation ownership should appear in proposal assumptions. A separate production or review stage may be needed. Describing incomplete content accurately is more useful than allowing an estimate to assume that all inputs already exist.

Can the brief change later?

New information can justify revision. Record its date and effects on scope and timing. Separate an approved decision from a proposal under discussion so everyone works from the same version. Updating the document should support controlled decisions rather than conceal unreviewed expansion.