Website Admin Handover Map for Community Teams

Why website admin handover matters during a role change

A volunteer steps down, a committee member is unwell, or the person who usually updates the website is suddenly unavailable. The next meeting is not about redesigning the site. It is about one concrete decision: who owns website access, and who can start recovery if the usual admin cannot help? A website admin handover map answers that in plain language. It helps a small team keep essential updates moving, find the right accounts, and avoid relying on one person’s memory.

Who this guide is for, and what a handover map is

This guide is for community organisations, clubs, charities, resident groups and small teams without a dedicated digital specialist. A website admin handover map is a continuity document for role changes. It is not a redesign brief, a full technical audit, or a supplier contract. If you need a wider site health check, use the community organisation website checklist separately so this handover task stays small.

Safety first: record where access is managed, not the secrets themselves

Before copying any template, agree the safety boundary. The map should point to approved access processes and named role holders. It should not become a shared store of secrets. Keep recovery routes organisational where possible, such as role email accounts, rather than personal inboxes that may leave with a volunteer or staff member.

At a glance: the six-part website admin handover map

Copy the six rows below into a shared internal document or spreadsheet. Fill only what your team needs to keep the website working through a role change. If an item is unknown, write “unknown” and assign someone to check it rather than guessing.

The roles, entries and review timings in these templates are examples. Replace them with your team's responsibilities and agreed check-ins.

Parts 1 and 2: access, recovery, key pages and settings

For access and recovery, separate three things: who owns the decision, where access is managed, and who can help. Record locations and routes, not secret values. For key pages and settings, list the parts of the website the team depends on: home page notices, contact pages, forms, menus, donation or booking routes, redirects, opening times, and recovery email settings. The aim is to show what must be checked first during a role change.

Parts 3 and 4: routine tasks and current requests

Routine tasks are the updates that repeat after meetings, events, seasonal changes or service changes. Current requests are the open edits, decisions and deadlines that could sit in private messages if nobody moves them into a shared place. Keep both lists short. A useful entry says what triggers the task, where the instruction lives, who does it, and who can cover it.

Parts 5 and 6: risks, dependencies, help and escalation

Record risks carefully as things to check, not unsupported conclusions. For example: “domain renewal owner unclear” is safer than “domain will be lost”. Dependencies may include hosting, forms, email, donation tools, booking systems or a supplier. Help and escalation should name internal decision makers as well as helpers. If an update involves safeguarding, consent, personal information, accessibility, tone or a public correction, agree who signs it off before it goes live. Chestnut Communities resources are self-serve; Chestnut Communities is not currently offering paid reviews, implementation, urgent support or automatic AI replies.

Common mistakes to avoid

Ownership, recovery, and keeping the map current

Use a short procedure. First, name the website owner role, such as chair, secretary, operations lead or communications lead. Second, name a backup who can start recovery. Third, confirm the recovery email and phone route still belong to the organisation or agreed role holder. Fourth, remove or update access when someone leaves. Fifth, schedule the next review. A handover conversation should walk through the map without exposing secrets. For a wider process view, adapt the admin workflow mapping template. To finish, copy the map, fill the six areas, agree an owner and backup, and set the next review date.

Frequently asked questions

What is a website admin handover map?
It is a short continuity document showing who owns website access, where key access is managed, what pages and tasks matter, what requests are open, and where to get help during a role change.

Should we write passwords in the handover map?
No. The map should record where access is managed and who can start recovery. Use an approved password manager or internal secure process for credentials.

Who should own the handover map in a small community organisation?
Choose an organisational role, not only a named individual. The owner makes decisions, the day-to-day admin updates the site, and a backup knows the recovery route.

How often should we review the handover map?
Review it at each role change, when a supplier or website tool changes, when a new form or payment route is added, and at a check-in date agreed by your team.

What if the current website admin has already left?
Start calmly with the access and recovery matrix. Check domain, hosting, platform and recovery email routes, then contact the relevant provider or agreed helper. Recovery depends on the provider's checks and the records available; record unresolved access issues and who will follow them up.

How much technical detail should a non-specialist team include?
Include enough detail for ownership, recovery and essential updates. Link to fuller notes if they exist, but do not turn the map into a developer manual.