An RFP should make solutions comparable
A website brief should let different vendors understand the same problem, scope, constraints, and expected outcome.
The template brings context, team, and owner together before developing the solution.
Source · Atlassian
Supported byGOV.UK: defining user needs
Uncertainty that turns into extra cost
Requesting a modern site without an inventory, integrations, or responsibilities produces proposals with hidden assumptions and expensive changes.
How to describe users, scope, and integrations
Describe outcomes and constraints with evidence. Separate mandatory, desirable, and future requirements so the scope stays comparable.
Implementation checklist
- Define business goals and user tasks.
- Inventory pages, languages, content, and migrations.
- List integrations, permissions, and technical requirements.
- Agree on deliverables, responsibilities, and acceptance criteria.
- Share the budget range and decision dates.
Owners, objectives, and dates let teams compare proposals for the same scope.
Source · Atlassian
Supported byAtlassian Team Playbook: Project Poster
Criteria for evaluating proposals
Evaluate proposal clarity, scope differences, questions received, later changes, and compliance with acceptance criteria.
Request a comparable solution
A useful brief explains the problem, users, and constraints. Requesting a page count without context invites quotes that look similar but solve different things.
Provide data access, a content inventory, and known integrations. Uncertainty does not disappear; it becomes risk margin or later change orders. Name any missing decision so bidders can state their assumptions instead of burying them in the price.
Evaluate method, team, and assumptions alongside price. A serious proposal will also state what is excluded.
Information that reduces ambiguity
- Goals and current metrics.
- Audiences and priority tasks.
- Technology and integrations.
- Scope, owners, and dates.
Supported byOWASP: Application Security Verification Standard
Quick execution map
| Element | What to review | Quality signal |
|---|---|---|
| Intent | A website brief should let different vendors understand the same problem, scope, constraints, and expected outcome. | The answer is clear within seconds. |
| Implementation | Describe outcomes and constraints with evidence. Separate mandatory, desirable, and future requirements so the scope stays comparable. | There is one concrete and assignable action. |
| Measurement | Evaluate proposal clarity, scope differences, questions received, later changes, and compliance with acceptance criteria. | The data should change a decision. A report with no action adds work. |
Frequently asked questions
What does website brief mean in practice?
A website brief should let different vendors understand the same problem, scope, constraints, and expected outcome.
What is a sensible first step for website brief?
Define business goals and user tasks. Then continue with this action: Inventory pages, languages, content, and migrations.
Which problem should website brief prevent?
Requesting a modern site without an inventory, integrations, or responsibilities produces proposals with hidden assumptions and expensive changes.
How do you measure progress with website brief?
Evaluate proposal clarity, scope differences, questions received, later changes, and compliance with acceptance criteria.
