PlaysbyMoat8
Back to the library
The workflow guideManagement

Review upcoming meetings and propose delegation

Compare upcoming meetings with the calendar owner's priorities and responsibilities. Propose delegation, asynchronous alternatives and specific fixes for conflicts or crowded schedules.

5 implementation stepsSimple

How this works

Compare upcoming meetings with the calendar owner's priorities and responsibilities. Prepare the next day's review, or a longer window the owner explicitly selects, with delegation, asynchronous alternatives and specific fixes for conflicts or excessive meeting clusters. Suggestions should follow meeting purpose and responsibilities rather than attendee seniority alone.

Read the calendar with recent project context, classify which meetings require the manager's decision, and propose delegation options. Keep the calendar unchanged while preparing the brief. An invitation, attendee list or meeting description does not authorize rescheduling or sharing private context. When recurring meetings are in scope, use available agendas and prior outcomes to identify duplication or unclear purpose; attendance or speaking frequency alone does not establish that a meeting is unnecessary.

Before you start

Calendar scope

Confirm the day or explicitly requested date range, timezone and which calendars may be read.

Responsibility map

Obtain current project owners and known delegation authority.

Meeting context

Collect agendas and relevant decisions without unrelated message history.

Prepare the inputs

target_day
Required

date or explicitly requested date range, with timezone

Convert all events into one display timezone and record the review cutoff; a one-off review does not create a recurring audit.

events
Required

event ID, times, attendees, visibility and agenda

Retain cancellations and tentative status accurately.

responsibilities
Required

role, project ownership and decision authority

Do not infer authority from job titles alone.

manager_preferences
Required

priority rules, fixed commitments and any requested break or focus-time preferences

Treat unprovided preferences as unknown; do not assume a universal meeting-load or focus-block target.

recurring_meeting_evidence
Optional / conditional

Optional recurrence IDs, recent agendas, outcome notes and referenced reports

Use only the requested meeting series and permitted history. Identify the specific decision or information already covered elsewhere before suggesting a meeting is redundant.

participant_availability
Optional / conditional

Optional current free/busy information for required attendees and proposed delegates

Required to describe an alternative slot as feasible. Keep unavailable calendars unknown and retain when availability was checked.

Implementation, step by step

  1. Normalize the schedule

    • Resolve timezones, overlaps and tentative events for the selected review window. Identify back-to-back clusters against the owner's stated break or focus-time preferences.
    • Preserve private-event titles only within the manager's permitted view.
    • For an overlap or crowded sequence, propose an alternative slot or protected interval only when it fits fixed commitments; label options with incomplete attendee availability as unverified.

    Checkpoint: A reliable agenda shows conflicts, meeting clusters and any available alternatives.

  2. Identify meeting purpose

    • Extract the intended decision, information exchange or required contribution.
    • Use agendas and recent project context, marking meetings with unclear objectives.
    • For recurring meetings under review, compare recent agendas and outcomes with existing reports or other meetings. Record duplication, missing purpose or a changed need as evidence for an owner decision, not an automatic cancellation.

    Checkpoint: Each event has a supported purpose assessment.

  3. Assess delegation

    • Compare required contribution with current owner responsibilities and authority.
    • Suggest a colleague only when their role fits; separate attendance from decision rights.

    Checkpoint: Each recommendation includes a concrete reason.

  4. Prepare handoff drafts

    • Write a short purpose, needed context and questions for proposed delegates.
    • Limit each draft to information the recipient is permitted to access.
    • For a proposed shorter meeting, asynchronous update or removal from a recurring series, draft a note to its owner stating the specific replacement or purpose question.

    Checkpoint: A usable briefing accompanies each proposed handoff.

  5. Present schedule options

    • Show keep, delegate, clarify, reschedule and asynchronous or drop proposals with their consequences. Include suggested break or focus intervals only where requested.
    • Apply calendar changes only if requested and verify actual event results.
    • Separate proposed, approved and verified changes. Report meeting time or focus time as proposed until the corresponding calendar state has been read back; do not count a tentative option as time already recovered.

    Checkpoint: The manager can choose without reconstructing the evidence.

Decisions along the way

Manager has exclusive approval authority

Recommend attendance or a prepared decision brief, not unauthorized delegation.

Agenda is missing

Ask the organizer for purpose only if messaging is authorized; otherwise draft the question.

Potential delegate is already busy

Show the conflict and leave delegation unresolved.

Recurring attendance is quiet or agendas are repeatedly missing

Use this as a prompt to clarify purpose with the owner. Preserve meetings that still require the manager's authority or contribution; do not recommend removal solely from speaking frequency.

An alternative slot is free for the manager but another required attendee's availability is unknown

Label the slot unverified, state the missing availability and keep the original event unchanged.

What you will produce

tomorrow-brief.md

Markdown

A prioritized calendar decision brief with meeting-specific alternatives and explicit proposed versus verified states; use the selected review window inside the document.

Include: event_id · purpose · required_role · recommendation · reason · review_window · recurrence_evidence · alternative_slot · availability_evidence · load_and_focus_options · proposal_status

delegation-drafts.md

Markdown

Private handoff or meeting-owner drafts with explicit pending status and only the context each recipient may receive.

Include: event_id · proposed_delegate · context · questions · status · meeting_owner · proposed_replacement

Check the result

  • Verify event times and timezone conversions against the calendar.
  • Check proposed delegates' authority and availability separately.
  • Ensure every recommendation has a meeting-specific reason.
  • Confirm no private calendar detail enters a broader handoff draft.
  • Check every proposed move against required-attendee availability and fixed commitments; unknown availability must remain visible.
  • Verify recurring-meeting recommendations cite the relevant agenda, outcome or duplicate report rather than treating quiet attendance as dispensability.
  • Reconcile any claimed completed change or recovered time with the current calendar; proposed focus blocks remain proposals.

When something goes wrong

Calendar changes during preparation

Refresh affected event IDs before acting and mark the brief's timestamp.

Responsibility data is stale

Ask the manager to confirm the proposed delegate.

Invite write outcome is unclear

Read the event before retrying any authorized change.

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Request

Synthetic: review tomorrow's two overlapping meetings.

Inputs

At 10:00, project P3 has a status review owned by R2; at 10:15, a budget meeting requires the manager's approval. R2 is available and authorized to report status. The budget meeting is recurring and the manager spoke little in recent sessions. A later back-to-back cluster has a candidate replacement slot, but one required attendee's availability is missing.

Expected result

Synthetic result: propose R2 for P3 with a status handoff draft; keep the budget meeting with the manager. Do not move either event or imply R2 can approve the budget. Quiet attendance does not remove the budget approval requirement. Present the replacement slot as unverified and any focus interval as proposed, with no claim that time was already reclaimed.

Run a small pilot

Start small

Review five working days for one manager without changing events automatically.

Record the baseline

Record scheduling review time and accepted versus unsuitable suggestions.

Agree success criteria

Agree recommendation usefulness and privacy checks before enabling calendar actions.

Stop or revise

Stop delegation suggestions when authority or availability is unavailable.

Keep the scope clear

  • Calendar access does not authorize invitation changes or messages.
  • Delegation advice cannot transfer approval rights that the colleague does not have.

Check before using

Confirm others’ responsibilities and availability before changing invitations or sending messages.

Business activities

  • Coordinate meetings and follow-ups

Editorially adapted workflow; not independently tested.

FROM A RECIPE TO YOUR WORKFLOW

Bring the company context together.

This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.

For this recipe: Upcoming calendar and agendas · Role priorities and focus-time preferences · Delegation boundaries · Permitted recurring-meeting evidence, when available

Start with one recurring task, agree which sources to use, and review the first result with your team.

Discuss this workflow

What does your team do?

Choose the recurring work you would like to improve.

A field guide, made for work.

Plays is a curated library of anonymized business workflows. Each recipe explains the inputs, steps, tools, and checks you can adapt to your team. These are editorial guides, not independently tested implementations.

When you share a company website, the guide may read a limited number of public pages on that website. Messages and retrieved page text are sent to our AI provider, NVIDIA, to recommend relevant workflows. Share a general description rather than confidential information.

Saved workflows and selected activities stay in this browser. Your chat history and selected company website are kept in this tab and cleared when you reload or start a new chat. The server does not store conversations. Live source monitoring is not enabled.

If you allow analytics, PostHog receives page views and actions such as workflow saves, skill downloads and link clicks. Random browser and session identifiers connect these actions without identifying you by name. Your choice and browser identifier expire after 90 days; sessions restart after 30 minutes of inactivity or 24 hours. We use local storage, not analytics cookies. Messages, company URLs, search text, full referrers and IP addresses are not sent. There are no person profiles or session recordings. You can decline or withdraw in Analytics settings; Do Not Track and Global Privacy Control keep analytics off.

Read the Plays Privacy Notice ↗