# First business website: blank project brief

Use this record to discuss a first website with any delivery partner. It is preparation for agreeing scope, not a contract or approval to build. Short notes are enough; completing every field is optional before an initial conversation.

Copy this file into your own document. Complete the companion `website-page-plan-blank.csv` only for pages you are considering. The worked Markdown and CSV files show one fictional exercise, not a required site structure.

This file and the CSV are static. They do not scan a website, submit your answers or assess readiness automatically. Keep private source material in your own workspace. Use references to supporting files rather than passwords, customer personal data or confidential documents in a widely shared brief.

## Record details

- Business / project:
- First website or an existing site to retain:
- Prepared by / date / version:
- Business decision-maker:
- Delivery contact, if appointed:
- Current stage: Preparing for scope discussion
- Next discussion / decision point:

If an existing site has useful pages, links or enquiry routes, inventory them separately before replacement. This first-site brief does not cover migration or launch verification.

## 1. Buyer and purpose

- Who needs the service, and what prompts the search for help?
- What does the business actually provide? What is outside its service scope?
- What should a suitable visitor understand before making contact?
- What should the visitor do next, and what happens afterwards?
- What do buyer conversations or other sources support? List the source and its limits.
- What are assumptions that still need checking? Who will check them?
- What would count as a useful enquiry for the business? How will someone review received enquiries after launch?

For a first site, write “No website baseline available” if applicable. Do not invent traffic, conversion rates, customer history or targets that have not been agreed.

## 2. First-release scope

- Services and buying questions to cover:
- Proposed pages, recorded in the companion page plan:
- Functions required at launch, such as enquiry or booking:
- Languages and audience locations, if relevant:
- Explicit exclusions from this project:
- Work deferred, and the condition for reconsidering it:
- Assumptions the quote must confirm:

Use Launch, Later or Exclude for each page. Launch means proposed inclusion in the first release; it does not mean the content is approved. Choose a separate content-readiness status.

## 3. Facts, writing and proof

- Business fact sources and person able to confirm them:
- Person supplying notes and source material:
- Person writing the website copy, subject to the agreed scope:
- Person approving accuracy and wording:
- Brand, images and files available; owner and usage rights:
- Evidence supporting each proposed claim; source and permission to publish:
- Missing assets or facts; next action and decision point:
- Claims or assets withheld until accuracy or permission is confirmed:

Use the page plan to assign these responsibilities page by page. “We have a case study” is not the same as “We have permission to publish this client's name, words and result.” Label illustrative samples clearly. Do not present them as completed customer work.

## 4. Visitor actions and ongoing editing

- Enquiry fields and why each is needed:
- Intended enquiry destination and person responding:
- What the visitor sees after submission:
- External tools or steps, their account owner and dependencies:
- What data will be collected, where it will go and who must confirm the handling and required notices:
- Who will verify a test enquiry reaches the intended recipient, and retain the result:
- Exact editing tasks the business needs after handover:
- Who should perform those tasks; access, training and support to agree:

Describe tasks before selecting a platform. Mark integrations or editing access “To discuss” where the provider has not confirmed them. A form event in analytics is not a record of an enquiry being received or answered.

## 5. Ownership, support and accessibility

For each account or asset, record these details without credentials: intended holder, administrator, recovery route, renewal or maintenance owner, expected handover, and any unresolved terms. Cover the domain, hosting, platform, measurement, booking or other third-party services as applicable. Record content, design, code and license terms separately.

- Account and asset record / secure reference:
- Responsibilities during delivery:
- Responsibilities after launch, including support and renewals:
- Accessibility needs and agreed target, if known:
- Evaluation scope, responsible person and evidence expected:
- Training and handover materials needed:
- Ownership, transfer, licensing or support questions still open:

A requested accessibility target is not evidence of conformance. Agree how it will be evaluated during delivery. Keep any need for specialist advice visible.

## 6. Budget, schedule and acceptance

- Budget guidance or “To discuss”:
- Requested timing and business reason:
- Inputs required before work or a specific phase can begin:
- Reviewers and expected review turnaround, to agree:
- Consequence of delayed content, access or decisions, to agree:
- Expected review rounds and how changes to scope are handled:
- Recurring services, renewals or support that need separate terms:
- Checks the proposal must include: factual approval, usable buyer routes, mobile and keyboard use, enquiry receipt, editing where agreed, accessibility evaluation and account handover:
- Who can approve scope; who can approve content; who can authorize launch:

Do not mark these checks passed in a planning brief. This record agrees what evidence will be needed later. Website delivery and qualified enquiries are different outcomes.

## 7. Open questions and decisions

Copy this block for each unresolved question:

- Question ID:
- Question and why it matters:
- Owner:
- Next action:
- Decision point or due milestone:
- Effect on page, scope, cost or schedule if unresolved:
- Current status: Open
- Decision / date / evidence reference, when resolved:

Record changes to an earlier decision separately:

- Change / requested by / date:
- Earlier decision and proposed replacement:
- Affected pages or functions:
- Cost or schedule effect, confirmed by whom:
- Agreed by / date, or “Awaiting agreement”:

## 8. Discussion handoff

- Current conclusion:
- Scope assumptions to confirm with the delivery partner:
- Questions that must be resolved before scope approval:
- Content that must remain unpublished until checked:
- Next action / responsible person / decision point:

Use a conclusion such as “Ready for a scope discussion, with [questions] unresolved.” Do not use this wording as approval of a quote, build, launch or commercial result.

## Page-plan field guide

Import the CSV as UTF-8 and treat columns as text. It has no formulas. Duplicate the blank row for every candidate page, including Later and Exclude decisions. Replace the placeholder page ID with a unique value. Keep one row per proposed page and maintain the same IDs when the plan changes.

| Field | What to enter |
| --- | --- |
| record_kind | Use Working plan for your own entries. Every supplied worked row says Fictional example. |
| page_id | A stable reference, such as P01. |
| planned_path | Proposed page address, or To discuss. It does not assert that a page or domain exists. |
| buyer_question | The visitor's question or practical task. |
| scope_phase | Launch, Later or Exclude. Blank means not decided. |
| scope_reason | Why the page belongs in that phase, including the condition for reconsidering a Later or Exclude decision. |
| required_inputs | Facts, images, documents or functional details needed to prepare it. |
| facts_owner | Person or role supplying and confirming the business facts. |
| writer | Person or role writing the copy. Use To agree if no appointment exists. |
| approver | Person or role approving accuracy, wording and permission to publish. Specify separate reviewers if needed. |
| evidence_and_permission | Supporting source and permission status; distinguish available, missing and withheld material. |
| dependency | An open-question ID or a specific prerequisite; use None identified only after review. |
| content_readiness | Not started, Inputs needed, Ready for drafting, Draft for review, Approved for publication or Not in launch. These are manually assigned content states, not launch test results. |
| next_action | A concrete action with an owner and decision point. For deferred work, include when to reconsider it. |

“Approved for publication” requires the named approval and its reference in your supporting record. It does not mean the website passed its technical or launch checks. When using a spreadsheet, import entries as text and review pasted material that begins with formula characters before sharing it.