Assistant Handover Checklist (Meeting History, Templates, Logs + Access Audit)

An assistant handover works when the next person can run meetings, follow decisions, and find files on day one without guessing. Use the checklist below to pass on meeting history, templates, action and decision logs, and to complete an access audit so links, permissions, and archives work before you call the handover “done.”

This guide gives you a complete handover packet structure, a meeting history handover checklist, a first-week takeover plan, and a short risk list (confidentiality, approvals, and distribution rules) to prevent continuity errors.

Primary keyword: assistant handover checklist

Key takeaways

• Hand over systems (where work lives and how it flows), not just documents.
• Include three “source of truth” logs: recurring meetings, an action log, and a decision repository.
• Make folder structure, naming conventions, and template locations explicit so the next assistant can move fast.
• Do an access audit and verify permissions and archive links before you consider the handover complete.
• Give a first-week takeover plan with daily priorities and stakeholder touchpoints.

What to include in an assistant handover packet (the minimum viable set)

A good assistant handover packet answers four questions: what happens repeatedly, who matters, what is in motion, and where everything is stored. If you only hand over notes and a calendar, the incoming assistant will still need days to rebuild context.

Use this simple packet structure so the new assistant can navigate it quickly.

• 01_ReadMe (start here): one-page overview, how to use this packet, and what to verify first.
• 02_Recurring meetings: meeting list, purpose, attendees, cadence, agendas, and last 3–5 key notes.
• 03_Stakeholder map: org chart slice, preferences, and working rules.
• 04_Action log: open items, owners, due dates, and status definitions.
• 05_Decision repository: major decisions, date, approver, and where the evidence lives.
• 06_Folders + naming conventions: where files live, how they are named, and retention/archiving rules.
• 07_Template library: links to templates plus when to use each one.
• 08_Access audit: system list, permissions, shared drives, distribution lists, and archive link checks.

Meeting history handover checklist (recurring meetings that run the business)

Meeting history is the fastest way for a new assistant to learn what “good” looks like in your executive’s operating rhythm. Instead of dumping long transcripts, give structured summaries and direct links to the right artifacts.

Capture each recurring meeting as a single card or row in a tracker so it is scannable.

1) Build a master list of recurring meetings

• Meeting name (exact calendar title) and cadence (weekly, biweekly, monthly).
• Purpose: what decision or output the meeting exists to produce.
• Owner: who runs it and who sets the agenda.
• Required attendees vs optional attendees.
• Prep expectations: what must be ready 24–48 hours prior.
• Standard agenda (bullets) and timeboxes.
• Outputs: notes, action items, decisions, deck, status update, or follow-up email.

2) Include the last “known good” run of each meeting

• Link to the last 3–5 sets of notes (or a single summary doc with links).
• List recurring action items that always come out of the meeting.
• List decisions in play (what is pending approval, what is blocked, what is sensitive).
• Point to the source files (slides, doc, dashboard) used in the meeting.

3) Spell out scheduling and etiquette rules

• Time-zone rules (who anchors the time, what cannot move).
• Reschedule rules: who can move it, what notice is required, and who must be asked first.
• Agenda deadline: who contributes and when the agenda is “locked.”
• Notes ownership: who takes notes, where notes live, and how they get distributed.

4) Add a “meeting triage” guide for exceptions

• When the exec is late: what to tell the room and how long to hold.
• When a critical attendee is missing: whether to proceed or reschedule.
• When the agenda is overloaded: which topics can defer and who decides.

Stakeholder map (who to protect time for, and how to work with each person)

A stakeholder map prevents social and process mistakes, like missing an approver or sending the wrong version to the wrong audience. Keep it short and specific so it stays updated.

Use a table or bullets for each stakeholder group.

What to capture for each stakeholder

• Name, role, and team (include executive assistant partners).
• Relationship to your exec: decision-maker, influencer, subject matter owner, gatekeeper.
• Preferred channel: email, chat, calendar invite, or meeting note.
• Response expectations: same-day, 24 hours, only urgent matters.
• Working preferences: likes pre-reads, hates last-minute moves, wants bullets not paragraphs.
• Approval authority: what they can approve and what they cannot.
• Sensitive topics: areas that require extra discretion or limited distribution.

Quick win: add “who to ask when”

• Scheduling conflicts: who can override calendar rules.
• Travel and expenses: who approves, who books, and who holds policy.
• Comms and announcements: who reviews wording and distribution lists.

Current action log + decision repository (your continuity backbone)

A handover fails when work moves to private inboxes and the new assistant cannot see what is open or why choices were made. An action log and decision repository keep context in one place.

Keep both lightweight, but treat them as sources of truth.

Action log checklist (what “current” means)

• Single location: one sheet, one database, or one tracker link.
• Clear status: Not started, In progress, Blocked, Waiting on others, Done.
• Owner (one person) and due date (real or “TBD” with next check-in date).
• Next step: the very next action, not the final goal.
• Last updated date and who updated it.
• Links to supporting docs, emails, tickets, or meeting notes.

Decision repository checklist (what to log)

• Decision statement in one sentence.
• Date and decision owner (who made the call).
• Approvers and any required sign-offs.
• Context: what problem it solved and what tradeoff it accepted.
• Where the proof lives: link to the doc, deck, or notes that explain it.
• Distribution rule: internal only, need-to-know, or shareable.

Highlights section (the “read this first” view)

• Top 10 current priorities with deadlines and blockers.
• Top 10 recent decisions that affect schedules, budgets, or stakeholders.
• Known upcoming crunch points: board meetings, audits, launches, travel weeks.

Folder structure, naming conventions, and template library (so nothing gets lost)

The new assistant should not have to guess where to save a file or how to name it. A clear structure also reduces duplicate versions and accidental sharing.

Document the system you actually use, not the one you wish you used.

Folder structure checklist (include links)

• Top-level folders: Meetings, Projects, People, Admin, Travel, Finance, Comms.
• Per-meeting folders: agenda, notes, pre-reads, and recordings (if used).
• Per-project folders: scope, timeline, working docs, final docs, approvals.
• Archive: what gets archived, where it lives, and when to archive it.
• Shared vs private: what must never live in a shared drive.

Naming conventions that prevent version chaos

• Date format: choose one (example: YYYY-MM-DD) and use it everywhere.
• Meeting notes: YYYY-MM-DD_MeetingName_Notes.
• Decks: YYYY-MM-DD_Project_Topic_v1, v2, FINAL (or better, v1.0, v1.1).
• Approvals: add “APPROVED” only after sign-off, with date and approver initials if allowed.

Template library checklist (what to include)

• Meeting agenda template (with standard sections and timing).
• Meeting notes template (decisions, actions, risks, parking lot).
• Weekly update template (bullets, metrics, key asks).
• Scheduling email templates (intro, reschedule, decline, delegate).
• Decision memo template (problem, options, recommendation, approvers).
• Stakeholder briefing template (who, what changed, what you need from them).

If your team uses recorded meetings, store the transcript link next to the notes and decisions so context stays searchable. If you need a fast first draft transcript for internal use, consider automated transcription and then update the parts that feed decisions and action items.

Access audit checklist (the handover is not complete until links work)

Most handovers break because of access gaps, not because of missing information. A new assistant cannot support an executive if they cannot open calendars, shared drives, distribution lists, or archives.

Run an access audit and require a “verified” check before sign-off.

Systems to verify (typical list)

• Email and calendar: delegated access, shared calendars, resource calendars (rooms).
• File storage: shared drives, team sites, private folders, archives.
• Chat and collaboration: channels, groups, and private message rules.
• Task tools: action log system, project boards, ticketing tools.
• Video meetings: host rights, recording permissions, webinar tools.
• Distribution lists: who can send, who can edit membership, moderation rules.
• Vendors: travel portals, expense tools, event platforms, courier accounts.

Access audit steps (practical and fast)

• Open test: the incoming assistant opens each “key link” from the ReadMe.
• Create test: create a draft calendar invite and save a file to the right folder (then delete if needed).
• Send test: send a test message to a low-risk internal list if policy allows.
• Recordings and archives: open at least 3 archived meeting links and 3 older project folders.
• Permissions: confirm read vs edit access, and note any “request access” workflows.
• Recovery: confirm who to contact for access issues and the expected turnaround time.

What to document when access fails

• What link failed (paste the URL or path) and what error appeared.
• Who owns the system and how to request access.
• Workaround if needed (example: alternate folder, alternate list, alternate report).

For widely shared content like captions or transcripts, access also affects accessibility compliance and team distribution. If you publish video externally, it can help to keep caption and transcript files in a standard place, such as a “Deliverables” folder, alongside your publishing checklist.

First-week takeover plan (day-by-day so nothing drops)

A first-week plan reduces mistakes because it forces early checks on calendar rhythm, approvals, and access. It also creates quick feedback loops with key stakeholders.

Adjust the timing to your exec’s schedule, but keep the intent: verify, stabilize, then improve.

Day 1: Stabilize and verify

• Review the ReadMe and open every “key link” in the packet.
• Confirm calendar rules: protected blocks, preferred meeting windows, and no-meeting days.
• Scan the recurring meetings list and confirm agendas/prep for the next 7 days.
• Review the action log and flag anything due in the next 72 hours.

Day 2: Stakeholder alignment

• Send short introductions (or reuse an approved template) to core partners.
• Confirm approvals: who signs off on travel, expenses, comms, and key documents.
• Confirm distribution rules for sensitive notes, recordings, and decision memos.

Day 3: Meeting operations

• Run at least one recurring meeting end-to-end: agenda, notes, actions, follow-up.
• Update the action log the same day and send follow-ups using the template library.
• Capture any “tribal knowledge” you discover and add it to the ReadMe.

Day 4: Clean up and standardize

• Check that folder names and file naming match the documented conventions.
• Move orphan docs into the right place and add links to the action or decision logs.
• Confirm archive locations and open older links again to ensure continuity.

Day 5: Review and confirm completion

• Review open risks and confirm mitigation steps with the executive or manager.
• Confirm the handover “definition of done”: access verified, archives open, and logs current.
• Schedule a 15-minute check-in for week two to capture gaps and improve templates.

Recurring handover risks (and how to prevent errors)

Even strong assistants can make avoidable mistakes during transitions because they inherit half-finished workflows. Use this risk list to put guardrails around confidentiality, approvals, and distribution.

Keep these rules in the ReadMe so they are visible every day.

Confidentiality risks

• Over-sharing: sending notes to a wider list than intended.
• Wrong storage: saving sensitive docs in shared folders.
• Recording leakage: meeting recordings accessible to the wrong group.

• Prevention: label sensitive meetings, define who receives notes, and document where sensitive files must live.

Approval risks

• Skipping sign-off on comms, budgets, or external messages.
• Using an old “approved” version after changes.

• Prevention: keep an approval path list, log final decisions in the decision repository, and use clear version naming.

Distribution rule risks

• Wrong list: sending to a similar-sounding distribution list.
• Reply-all storms: including the wrong people in a thread that should stay 1:1.
• External forwarding: sharing internal notes outside the organization.

• Prevention: document list owners, restrict who can send, and add a distribution note at the top of meeting notes.

Access and archive risks (the most common continuity breaker)

• Broken archive links: older notes or recordings moved or access removed.
• Permission drift: the new assistant has “view” but needs “edit.”
• Tool sprawl: key work split across inboxes, chats, and drives with no index.

• Prevention: complete the access audit, open-test archive links, and keep one index (the ReadMe) updated.

Common questions

What is the fastest way to create meeting history for a handover?

Create a recurring meeting tracker, then add the last 3–5 notes links for each meeting plus a short “what it’s for” summary. If you have recordings, link them next to the notes, not in a separate place.

How detailed should an action log be?

It should be detailed enough that a new assistant can take the next step without reading old threads. Keep each line focused on owner, due date, status, and a clear next step with links.

Do I need a separate decision repository if I already have meeting notes?

Yes, if decisions show up across many meetings or chats. A decision repository gives you one place to answer “what did we decide, when, and who approved it” without searching.

What should I do if I cannot get access to a key system before the handover date?

Document the gap in the access audit, name the system owner, and write the exact steps to request access. Add a workaround if one exists, and flag it as a Day 1 priority for the incoming assistant.

How do I prevent sending confidential notes to the wrong people?

Put distribution rules at the top of every notes template and keep a short list of “always restricted” meetings. Also document which distribution lists are approved for which types of updates.

What is a good “definition of done” for an assistant handover?

The incoming assistant can run the next week of recurring meetings, update the action log, and find the latest decision context. All key links and archive links open correctly, and permissions allow the required actions (view and edit).

Where should I store templates so they stay current?

Store templates in one shared location with edit rights for owners and view rights for everyone else. Link to that library from the ReadMe, and avoid copying templates into multiple folders.

If you expect to rely on recorded meetings, transcripts, or caption files as part of your meeting history, it helps to keep them consistent and searchable. GoTranscript provides the right solutions when you need reliable support for your documentation workflows, including professional transcription services that you can plug into your handover process.