# First business website: fictional worked brief

**Fictional planning exercise.** Cedar Relay Operations, its buyers, documents, proposed website and decisions below are invented to demonstrate the record. Nothing here describes a real client, verified demand, a completed build or a measured result. The companion `website-page-plan-worked.csv` labels every row Fictional example.

Read this beside `website-brief-blank.md`, which contains the instructions and page-plan field definitions. Copy the blank pair for your own project. This exercise records intended work and unresolved decisions; no page is approved for publication.

## Record details

- Business / project: Fictional Cedar Relay Operations, first website.
- Proposed domain: `cedarrelay.example`, an illustration only, not a registered or tested site.
- Prepared by / date / version: Fictional business lead; undated teaching exercise; version 1.
- Business decision-maker: Fictional business lead.
- Delivery contact: Not appointed. “Proposed delivery writer” below is a role to agree before scope approval.
- Current stage: Preparing for scope discussion.
- Next decision point: Review the proposed pages and questions Q1 to Q5 with a delivery partner before agreeing scope.

## 1. Buyer and purpose

The invented business proposes client-onboarding process support for small B2B service firms. The intended buyer is an operations lead whose team hands new clients between sales and delivery without a consistent checklist or named responsibilities.

The website should explain the onboarding work, boundaries and information needed for an initial conversation. Its proposed next step is a short enquiry describing the business and the handoff problem. The fictional business lead would review fit and arrange a conversation. No reply-time promise has been agreed.

The exercise assumes this buyer situation; it contains no interview evidence. Before finalizing the page questions, the fictional business lead would compare them with actual buyer conversations. No website baseline is available because this is a first-site exercise. A useful enquiry would concern onboarding process work within the agreed service boundaries; received enquiries would be reviewed manually after launch, separately from website usage.

## 2. First-release scope

The proposed launch pages are Home, Client onboarding, About, Contact and Privacy information. The Privacy information page remains dependent on confirming actual data handling and the appropriate review; no compliant wording is supplied or claimed by this exercise.

The page plan also records two decisions outside launch:

- **Ongoing operations support, Later:** the business has not defined the work, capacity or response commitments. Reconsider after the business lead approves those boundaries. No teaser page or customer promise is planned meanwhile.
- **Insights / blog, Exclude:** no publishing owner or maintenance commitment exists. Reconsider only when a specific buyer question, an owner and a publishing plan justify the work.

The proposed initial function is an enquiry form. Booking, payment, a customer portal, multiple languages and historical-content migration are excluded. Branding beyond supplied assets, ongoing content production and support terms still need discussion rather than being assumed included.

## 3. Facts, writing and proof

In this fictional scenario, the business lead can supply service notes, a proposed onboarding sequence and a biography requiring fact review. A delivery writer would turn agreed inputs into copy if that responsibility is included in the quote. The business lead would approve facts and wording, with specialist review where needed for data-handling information.

**Q1 is a publication dependency:** the exercise posits a previous project whose client permission has not been obtained. The project name, logo, testimonial and claimed results must remain withheld. The plan does not assume that removing the name grants permission to publish confidential details.

The alternative proposed input is a newly prepared illustrative handoff sample. It must be labelled as an illustration and contain no client data. It has not been created or approved in this exercise. It can explain the service process; it cannot support a claim of customer results. Rows P01, P02 and P03 retain this gap.

## 4. Visitor actions and ongoing editing

The proposed form asks for a name, reply email, business and a short description of the onboarding need. The required fields and justification remain to be reviewed under Q3. The confirmation should explain the actual next step without an unagreed response-time claim.

No real mailbox is supplied. Q3 requires the business lead to name the recipient, agree the data flow and confirm the necessary notices with the appropriate reviewer. The delivery partner would later verify a test submission, visitor feedback and actual receipt, retaining evidence. No test has been run in this exercise, and an analytics event would not establish delivery.

**Q2 is an editing decision:** the business lead expects occasional biography and service-detail changes but has not decided between direct editing and requesting changes from a provider. Before scope approval, the partner should demonstrate the proposed workflow and confirm access, training, support and any effect on scope. No platform or included editing entitlement is assumed.

## 5. Ownership, support and accessibility

**Q4 covers accounts and handover.** The intended arrangement is business-controlled domain registration and accounts, with the provider receiving the access needed for the agreed work. The example domain is reserved for illustration; domain availability, purchase and account creation have not been checked or performed.

The business lead would confirm account holders, administrators, recovery routes, renewal responsibility and handover. Content, design, code, licenses, transfer conditions and ongoing support need separate terms from the chosen provider. No passwords or credentials belong in the brief.

Accessibility needs, target, review scope and responsible evaluator remain to be agreed under Q5. The proposal should explain review during delivery, including keyboard use and other evaluation appropriate to the agreed scope. No conformance or legal compliance is asserted. Editing training and handover material depend on Q2 and Q4.

## 6. Budget, schedule and acceptance

- Budget: To discuss; no project price is assumed.
- Requested timing: No fixed date in this exercise. A schedule should follow agreement of scope, writing responsibility, account access and review availability.
- Dependencies: Q1 affects public evidence; Q2 affects editing and training; Q3 affects Contact and Privacy information; Q4 affects accounts and handover; Q5 affects the commercial and acceptance agreement.
- Reviewers: Business lead for service facts and ordinary copy; appropriate reviewer for data-handling information; delivery review roles to agree.
- Review rounds, change handling, recurring costs and delayed-input consequences: To agree under Q5.
- Proposed acceptance evidence: approved factual content, usable buyer routes, mobile and keyboard checks, recorded enquiry receipt, agreed accessibility evaluation, editing demonstration where included and account handover.
- Authority: The business lead is the proposed business approver. Supplier acceptance and launch authorization remain unagreed. No build, page or launch approval is recorded.

## 7. Open questions and decisions

### Q1. What proof can appear publicly?

- Owner: Fictional business lead.
- Next action: Seek explicit permission for the prior project; prepare a clearly labelled illustrative sample if permission remains unavailable.
- Decision point: Before public copy approval.
- Effect if unresolved: Withhold the prior project and any unapproved sample from P01, P02 and P03. Draft only confirmed service/process explanations.
- Current status: Open. No permission or sample approval exists in the exercise.

### Q2. How will routine content changes happen?

- Owner: Fictional business lead, with the prospective delivery partner.
- Next action: Review biography and service-change tasks; agree direct editing or a support workflow, including access and training.
- Decision point: Before scope approval.
- Effect if unresolved: Editing, platform choice, training, support and related cost or schedule effects remain unagreed.
- Current status: Open.

### Q3. Where do enquiries go, and what data handling needs review?

- Owner: Fictional business lead, with the appropriate data-handling reviewer and prospective delivery partner.
- Next action: Name the recipient; agree fields, routing, storage, any third parties, notices and later delivery checks.
- Decision point: Before scope approval for the flow; before public copy approval for notices; verify receipt during delivery before launch.
- Effect if unresolved: P04 and P05 remain inputs needed. No enquiry route is approved for launch.
- Current status: Open. No receipt test or compliance review has occurred.

### Q4. Who controls and maintains the accounts and assets?

- Owner: Fictional business lead, with the prospective delivery partner.
- Next action: Choose a real domain separately; confirm account roles, recovery, renewals, handover and asset/license terms.
- Decision point: Before scope approval for responsibilities and terms; before the relevant delivery work for account access.
- Effect if unresolved: Domain setup, delivery access and handover cannot be treated as agreed.
- Current status: Open. No domain or account checks have occurred.

### Q5. What will the quote, schedule and review cover?

- Owner: Fictional business lead, with the prospective delivery partner.
- Next action: Confirm budget, writing responsibilities, review rounds, acceptance evidence, accessibility target and evaluation, support, schedule dependencies and change handling.
- Decision point: Before scope approval.
- Effect if unresolved: No agreed project price, delivery date, acceptance terms or authorization to start.
- Current status: Open.

No later changes have been agreed in this version. Use the blank brief's change record when a decision changes; keep the earlier decision and its impact visible.

## 8. Discussion handoff

**Ready for a scope discussion, with proof permissions, editing, data handling, account responsibilities and commercial terms unresolved.**

The next action is for the fictional business lead to review P01 to P07 and Q1 to Q5 with a prospective delivery partner. Confirm scope before commissioning work. Keep unapproved evidence unpublished. All five Launch rows currently need inputs; the other two pages are outside the first release. This is a complete planning example of an incomplete project, not a completion or launch record.
