Executive operations admin workflow review

On 8 of 10 business days, April handled scheduling changes as a multi-step repair loop across Gmail, Google Calendar, and Slack. The same meeting often required an initial request, an availability check, a reschedule update, and one or more follow-up confirmations before the change was actually closed.

Evidence

This can be built without replacing any system April already uses.

• Input: Gmail label for schedule requests, Calendar events, and optional Slack alerts for same-day changes.
• Build: Apps Script creates a `Schedule Queue` sheet row, drafts the reply, and batches unresolved changes into one morning digest.
• Human role: April approves the proposed slot or chooses from 2-3 options instead of rebuilding context manually.
• Implementation path: 1 sheet, 1 Gmail label, 3 email templates, 1 Calendar watcher, 1 daily digest.
• Downstream recovery: about 1.1h / week comes from fewer requester follow-ups and fewer same-day conflict fixes.

Confidence

Approval work was fragmented across Gmail, Slack, calendar reminders, and a follow-up tracker. The biggest tax was not writing the request. It was reconstructing which requests were still open, who owned the next step, and whether a reminder had already been sent.

Evidence

The fix is not a new approval platform. It is one lightweight ledger and one daily digest inside the tools already in use.

• Input: Gmail label `approval-needed`, Slack channel or DMs, and the existing follow-up sheet.
• Build: Apps Script parses labeled emails, creates or updates an `Approval Ledger`, posts one digest to Slack, and drafts one reminder email when due dates slip.
• Human role: April handles exceptions and escalations instead of repeatedly checking whether someone replied.
• Implementation path: 1 sheet, 1 parser, 1 Slack webhook, 1 digest schedule, simple status values (`open`, `waiting`, `done`).
• Downstream recovery: about 2.2h / week comes from decision-makers spending less time being re-chased and less time clarifying stale requests.

Confidence

The reporting work itself was not the problem. The tax came from pulling the same numbers, exports, attachments, and summary language into the same packet structure over and over again. The packet had a recognizable shape, but the assembly steps still restarted from zero.

Evidence

This is a templating and assembly problem, not a software replacement problem.

• Input: Source sheets, recurring export files, Drive attachments, and one standard Google Docs packet template.
• Build: A packet assembler script copies the template, pulls the current values from Sheets, links the latest attachments from Drive, and drafts the send email.
• Human role: April checks exceptions, commentary, and final send order instead of rebuilding the shell.
• Implementation path: 1 source map tab, 1 Docs template, 1 Drive destination folder, 1 Gmail draft generator.
• Downstream recovery: about 1.4h / week comes from leadership and finance spending less time asking where the latest version or attachment is.

Confidence

Onboarding, vendor, and recurring admin packets shared a stable checklist: gather the right docs, create the same folder structure, route signature requests, and send a standard set of follow-ups. The work changed names, but not shape.

Evidence

The packet looks bespoke, but the launch path is consistent enough to standardize in the tools already being used.

• Input: Google Form or sheet intake, Drive folder templates, Gmail drafts, and DocuSign templates.
• Build: A launcher creates the folder, copies the right docs, opens the DocuSign template, and drafts the first employee/vendor message.
• Human role: April reviews the packet and resolves missing information instead of rebuilding the same shell every time.
• Implementation path: 1 intake form, 4 packet templates, 1 folder map, DocuSign placeholders, and standard chase rules.
• Downstream recovery: about 0.9h / week comes from employees and vendors getting a cleaner first packet and fewer missing-document loops.

Confidence