# Filled Website Handover Example

> Fictional example only. Harbor Loop Garden, its website, roles, and decisions below are invented for demonstration. Do not treat this as a real client result or copy its service choices without checking your own project.

## Project record

- **Website:** Harbor Loop Garden
- **Public address:** `harborloop.example.test`
- **Delivery date:** 18 September 2026
- **Delivered:** Homepage, growing calendar, volunteer form, visit page, contact page, selected logo, and approved instruction images.
- **Purpose:** Enable the volunteer coordinator to publish seasonal updates and events using the agreed content pattern.

## Roles and ownership

- **Client owner — Garden committee:** Approves major content and maintains the organisation's supplier relationships.
- **Content editor — Volunteer coordinator:** Drafts and publishes calendar entries, seasonal notices, and approved photos.
- **Domain and hosting owner — Operations contact:** Receives supplier notices and uses the supplier's support route to request access.
- **Website support — Project studio:** Investigates reproducible defects from delivery through **18 October 2026**. New pages, integrations, and design work require a new scope.

No passwords, API keys, recovery codes, or private project notes are included in this handover.

## Agreed website decisions

- Navigation is Home, Calendar, Visit, Volunteer, and Contact.
- Calendar entries have a title, date, short description, and one call to action.
- Past events are archived when the committee wants to keep a public record.
- Feature images use the supplied landscape crop. The editor checks the page after replacing an image.
- The contact form forwards to the shared inbox selected by the client. Recipient changes are managed by the access owner.

## Routine editing

### Publish a calendar entry

1. Sign in through the site's normal administration route.
2. Create a draft with the agreed event fields.
3. Check the public preview for date, copy, and image crop.
4. Publish after the committee approves the wording.

### Replace a feature image

Use an image the organisation is entitled to use. Keep the landscape crop where possible, add meaningful alternative text, and inspect the published page. A change to layout, navigation, form behaviour, or another integration is a change request rather than a routine edit.

## Support boundary

A useful defect report includes the public page URL, what happened, browser and device, and a screenshot when helpful. In this fictional example, the project studio investigates reproducible defects reported from delivery on 18 September 2026 through 18 October 2026. New pages, integrations, migration work, copywriting, photography, policy decisions, and supplier-account administration are outside that period. After 18 October, the Garden committee decides whether to request a new scoped piece of work.

## Open issues

- **Autumn workshop date:** Owner: Volunteer coordinator. Action: provide final date and ticket wording by 25 September 2026 before publication.
- **Photo permissions:** Owner: Garden committee. Action: confirm the approved gallery image list by 30 September 2026.
- **Supplier renewal contact:** Owner: Operations contact. Action: confirm the organisation inbox for supplier notices by 22 September 2026.

These are open decisions, not confirmation that the website is broken.

## Client package and acceptance

The client receives the following selected fictional files: `harbor-loop-handover.md` (this handbook), `harbor-loop-checklist.csv` (the honest completion list), `event-card-image-guide.png` (a landscape-crop and alternative-text reminder), and the selected logo file. The private working project and internal comments remain separate. The client confirms receipt by naming any missing item; that acknowledgement confirms package receipt.

For a local tool that helps select client sections and attachments before export, see Relayfolio: /tools/relayfolio/.