Website Handover Example: A Filled Client Package

Fictional example: Harbor Loop Garden

This is a fictional example, not a real client result. Harbor Loop Garden is an imaginary neighbourhood gardening group with a five-page public website at harborloop.example.test. The package is dated 18 September 2026 and covers the homepage, growing calendar, volunteer form, visit page, and contact page. It is a day-to-day editing record, not a site audit.

The client asked for a small site that lets a volunteer coordinator publish dates and seasonal updates without changing the visual structure. The project team chose one content pattern for event cards, one image ratio for feature images, and a plain contact form that sends enquiries to the organisation's shared inbox. Those are product decisions for this fictional site, not universal rules for every website.

Named roles and agreed decisions

Roles

• Client owner — Garden committee: approves major content and pays for services in the organisation's name.
• Content editor — Volunteer coordinator: drafts and publishes calendar entries, seasonal notices, and approved photos.
• Domain and hosting owner — Operations contact: receives supplier notices and requests access through the relevant service's support route.
• Website support — Project studio: investigates reproducible defect reports from delivery through 18 October 2026. New features are quoted separately.

Decisions recorded in the package

• The main navigation is Home, Calendar, Visit, Volunteer, and Contact. Adding a section needs a content and navigation decision before it is built.
• Calendar entries use a title, date, short description, and one call to action. Past entries are archived rather than deleted when the committee wants to keep a record.
• Feature images use the supplied landscape crop. The editor checks the page after replacing an image because different source photos can need a different crop.
• The contact form forwards to the shared inbox selected by the client. Changes to recipients are handled by the access owner, not written into this handbook as credentials.

Editing notes and support boundary

Routine editing

To publish a calendar entry, the content editor signs in through the site's normal administration route, creates a draft using the agreed event fields, checks the public preview for date and image crop, and publishes when the committee has approved the wording. To replace a feature image, the editor uses an approved image owned by the organisation, keeps the landscape crop where possible, adds meaningful alternative text, and checks the published page. If the edit changes layout, navigation, form behaviour, or another system integration, it is a change request rather than a routine content update.

Support boundary

The project studio investigates reproducible defects reported between delivery on 18 September 2026 and 18 October 2026. A useful report includes the public page URL, a short description, browser and device, and a screenshot when helpful. New pages, integrations, migration work, copywriting, photography, policy decisions, and supplier-account administration are outside this example support period. After 18 October, the garden committee decides whether to request a new scoped piece of work.

Open issues, acceptance, and client files

Open issues

• Autumn workshop date: owner: Volunteer coordinator. Next action: supply the final date and ticket wording by 25 September 2026 before the calendar entry is published.
• Photo permissions: owner: Garden committee. Next action: confirm the approved gallery image list by 30 September 2026.
• Supplier renewal contact: owner: Operations contact. Next action: confirm the organisation inbox for supplier notices by 22 September 2026.

These are open decisions, not evidence of a broken website. They remain visible in the checklist until the named role completes the next action.

What the client receives

• harbor-loop-handover.md: the client-facing handbook with roles, delivered pages, editing notes, open issues, and support boundary.
• harbor-loop-checklist.csv: the completion list, with open and completed items kept distinct.
• event-card-image-guide.png: the selected instruction image showing the landscape crop and alternative-text reminder for calendar cards.
• The selected logo file. The private project and internal comments are not part of this fictional package.

The client accepts receipt by replying that the listed files arrived and naming any missing item. That acknowledgement confirms receipt of the selected package. Use the companion website handover checklist to build your own version, or see Relayfolio for a local tool that helps select client sections and attachments before export.