Async AI Delivery OS: A Field Guide to Running Client Projects Across Time Zones (Without Slack Chaos)

Async-first doesn’t mean slower. It means work moves continuously without you being the router. The model:

• Single source of truth: decisions and work live in your project workspace (e.g., Notion), not Slack.
• Pipeline: intake → scoping → assignment → execution → QA → delivery → documentation/close‑out.
• Cadence: weekly, written, client‑local status at 09:00 (their time). No standing status calls.
• AI-first, human-final: AI drafts routine artifacts (status, QA checklists, recap packs); a human does the judgment pass before anything ships.
• Ownership: each task has a DRI (directly responsible individual) and due date. Each project has a decision log with “why we chose A over B.”

Success criteria to aim for by Week 3:

• ≤60 seconds from form submit → task created/assigned/acknowledged (low‑code) or ≤10 seconds (code‑first under light load).
• Clients get Tuesday 09:00 local updates every week without reminders.
• You can be offline 24 hours without blocking any deliverable.

Use this when you want speed to working automation with tools you probably already have.

Components and baseline cost (illustrative for a small team):

• Forms: Tally Pro (budget) or Typeform.
• Work hub: Notion (Plus or Business).
• Comms: Slack Pro.
• Automation: Zapier Professional (instant webhooks).

Architecture flow:

1. Client submits a Tally form.
2. Zapier catches the webhook instantly, creates/updates a Notion Project and creates scoped subtasks.
3. Assignment logic routes work to a contractor based on skill tags and timezone window.
4. Slack notifies the assignee and posts a client‑visible acknowledgement.
5. A scheduled Zap (or Slack’s scheduler) sends weekly status at client‑local 09:00.

Minimum viable setup:

• Notion databases:
• Projects: Name, Client, Status (Green/Yellow/Red), DRI [Person], Timezone [IANA], SlackChannelID [Text], LastUpdate [Date], DecisionLog [Relation].
• Tasks: Name, Project [Relation], Owner [Person], Status [Status], Priority [Select], ETA [Date], Loom [URL], DeliverableURL [URL].
• Decisions: Project [Relation], Title, Date, Context [Rich text], OptionChosen [Select], Why [Rich text], LinkToWork [URL].
• Slack channels:
• #client‑[name] (external‑facing or shared channel)
• #delivery‑[client] (internal)
• #ops‑alerts (automation failures)
• Zapier zaps (starter set):
• Intake → Notion: Tally webhook → Formatter (normalize fields) → Notion: Find/Create Project → Create Child Tasks → Slack: Post in #delivery‑[client].
• Weekly Status: Schedule (every Monday UTC) → Notion: Query last 7 days → OpenAI/LLM: Draft summary → Slack: Schedule message to #client‑[name] for Tue 09:00 client‑local.
• Decision logger: Slack emoji reaction (e.g., :decision:) on a message → Create Decision in Notion with permalink.

Gotchas and fixes:

• Notion API limit is modest. Add retries with exponential backoff and, for bursts, queue writes.
• Slack scheduling caps exist. Spread scheduled messages across channels or time windows.
• Always keep a manual fallback: a Notion template for status that you can paste to Slack if automation pauses.

Use this when you’re running 10+ active clients, want deterministic scheduling, or need richer error handling.

Components and baseline cost:

• Orchestration: n8n self‑hosted on a small VPS.
• Data store: Supabase (auth + Postgres + storage for artifacts).
• Work hub & comms: Notion + Slack (as in Stack A).

Architecture flow:

1. Form submit (Tally or a custom Supabase form) → n8n webhook.
2. n8n writes to Supabase, creates/updates Notion Project/Tasks, and evaluates assignment rules.
3. n8n posts internal Slack notifications and schedules the client‑visible Tuesday 09:00 update via Slack’s scheduler.
4. A separate error workflow catches any node failure, retries with backoff, and alerts #ops‑alerts with a re‑auth link if needed.

Blueprint details:

• Supabase tables:
• clients(id, name, timezone, slackchannelid, notionprojectdb_id)
• requests(id, clientid, title, description, duedate, priority, status, created_at)
• assignments(id, requestid, contractorid, skillmatchscore, scheduled_at)
• n8n workflows (minimum):
• intake_pipeline: Webhook → Function (normalize) → Supabase (insert) → Notion (project/tasks) → Slack (notify) → Branch (QA needed?) → Queue for QA.
• weeklystatus: Cron (client TZ) → Notion (query) → LLM (summarize) → Slack (schedule) → Supabase (log messageid).
• errorhandler: On error → If (rate limit) retry + delay; If (401/invalidgrant) pause + alert with reconnect URL; push the payload to a dead‑letter table.
• Timezone handling:
• Store all client timezones as IANA strings (e.g., "America/New_York").
• Set workflow or instance timezone explicitly. Never compute DST by hand—use a library (e.g., Luxon) or the platform’s cron with TZ.

Deployment checklist:

• Lock down n8n and Supabase credentials; never hardcode tokens in nodes.
• Health checks: uptime monitor for n8n URL; alert if queue/dead‑letter grows; weekly “dry run” status job that posts to a private channel.
• Backups: daily DB snapshot; export n8n workflows to git after each change.

Make the form your only door for new work. The form must capture enough context to auto‑scope 80% of requests.

Required form fields (Tally/Typeform):

• Who are you? [Client contact]
• Project reference [Dropdown of active projects]
• What do you need? [Short text]
• Why now? [Multiple choice: launch, bug, optimization, experiment]
• Definition of done [Long text]
• Links & data [URLs]
• Priority [Low/Med/High]
• Target date [Date]

Auto‑scoping map (Zapier or n8n):

• If “What do you need?” contains keywords (e.g., “prompt,” “dashboard,” “data ingestion”), create a standard task bundle:
• Example: “New AI workflow” → Tasks: Design Spec, Build, Test, Loom Walkthrough, Deploy, Post‑deploy QA.
• Set defaults per task: ETA window, checklist, required artifacts (e.g., Loom link), and QA owner.
• Assignment rule: Choose contractor where skill tag matches AND local time overlaps next 12–24 hours of client’s morning window.

Notion task template example (paste into database template):

• Required artifacts: [Deliverable URL], [Loom], [Screenshots]
• QA checklist:
• Repro steps documented
• Edge cases covered
• Links accessible to client
• Status reason (Green/Yellow/Red) noted

Acceptance criteria:

• 100% of new work enters via form within 7 days.
• No task without DRI, due date, and definition of done.
• Assignee gets a Slack ping with context and links in under 60 seconds (low‑code) or under 10 seconds (code‑first, typical).

Default to written, predictable, and client‑local.

Response tiers to publish in your contract and onboarding:

• Tier 1 (Emergency: production down): 4‑hour response during business days.
• Tier 2 (Blocking clarification): 24‑hour response.
• Tier 3 (Everything else): 48–72‑hour response.

Weekly cadence:

• Status pack every Tuesday at 09:00 in the client’s timezone.
• Contents: Overall status (Green/Yellow/Red + 1‑sentence reason), 3–5 shipped items (links), top risks/blockers, next steps/asks.
• Rule: If status is Red two weeks in a row, auto‑offer two sync slots within client business hours.

Decision hygiene:

• Each notable choice gets a Decision entry: context, alternatives, chosen option, why, link to the work.
• Link each decision to its project and tag the DRI.

Availability norms:

• Use “vacation/offline mode” in your tools and let clients know how to escalate Tier 1 only.
• Add your SLA to email signature and the top of the shared Notion project page.

Your goal is near‑zero marginal time per client while keeping tone and nuance.

Inputs the LLM needs:

• Completed tasks last 7 days: title, owner, link.
• New decisions: title, short why, link.
• Loom or deliverable links.

Prompt (paste and reuse):
```
Synthesize a weekly client update for [CLIENT]. Include: Overall Status (Green/Yellow/Red + 1‑sentence reason), 3–5 shipped items with links, top 3 risks (if any), and next steps/asks. Keep under 180 words. No emojis. Use a professional, concise tone.
Context provided below delimited by triple dashes.
---
[PASTE COMPLETED TASKS]
[PASTE DECISIONS]
[PASTE LOOM/DELIVERABLE LINKS]
---
```

Human‑final QA checklist (90 seconds):

• Does the color match reality? If Yellow/Red, is the reason clear and non‑defensive?
• Any sensitive items that need softer phrasing or a 1:1 note?
• Are all links accessible to the client? (Test as guest.)

Scheduling:

• Low‑code: generate on Monday UTC and schedule via Slack for Tue 09:00 client‑local.
• Code‑first: compute next Tuesday 09:00 epoch in the client’s IANA timezone and call Slack’s scheduler.

Cost sanity check:

• Even with generous token counts, weekly updates across a handful of clients cost cents, not dollars. The real value is the hour you don’t spend writing.

Design for the day something breaks.

Known limits and patterns:

• Notion API rate limiting is tight. Implement retries with exponential backoff and, for bulk writes, a queue that drains at a safe rate.
• Slack scheduling has per‑channel caps and a 120‑day max. Spread schedules across channels or stagger times by a minute.
• OAuth expires. Detect 401/invalid_grant responses, pause the primary workflow, alert #ops‑alerts with a re‑auth link, and queue the pending job for retry after reconnect.
• DST flips. Always store client timezone as IANA (e.g., Europe/Lisbon). Use a timezone‑aware library or platform cron; never hand‑roll offsets.

Monitoring and alerts:

• #ops‑alerts posts include: client, workflow, error type, next retry, human action needed.
• Weekly heartbeat: a canary job posts “Async OS healthy” to a private channel. If it doesn’t land, investigate.
• Dead‑letter queue: anything that failed N times gets logged for manual reprocessing; review weekly.

Manual fallback kit (paste‑ready):

• Notion “Weekly Status (Manual)” template.
• Email/Slack canned message: “We’re regenerating today’s automated update; here’s the manual status.”
• 20‑minute sync offer template if a project is Red two weeks straight.

Ship this in two weeks without blowing up your calendar.

Week 1 (Foundation):

• Day 1: Create the Tally form with the required fields.
• Day 2: Build Notion databases (Projects, Tasks, Decisions) and the Task template with QA checklist.
• Day 3: Zapier intake Zap (webhook → Notion) and Slack notifications. Test E2E.
• Day 4: Draft SLA section and add it to contracts/onboarding; set up #ops‑alerts.
• Day 5: Create the AI status prompt, build a one‑client weekly status job, and schedule next Tuesday at 09:00 client‑local.

Week 2 (Scale + Hardening):

• Day 6: Add assignment rules by skill + timezone; verify assignee gets context in <60s.
• Day 7: Add decision logging from Slack (emoji → Notion Decision).
• Day 8: Implement retries/backoff in Zapier or switch to n8n for error workflow if needed.
• Day 9: Add health checks and a dead‑letter queue; test an OAuth “expired” scenario.
• Day 10: Run the Lisbon Test: go offline for 24 hours. Confirm that new requests route, tasks move, and status still sends. Fix anything that required you.

“Nepal protocol” (2 weeks mostly offline):

• Pre‑generate two status packs from the project plan; schedule them.
• Set autoresponder with SLA + emergency channel for Tier 1 only.
• Delegate human‑final QA to a trusted contractor with access to links and the decision log.

When to hire help:

• If your dead‑letter queue grows week over week or you miss 2+ QA checks in a month, bring on a part‑time ops assistant in a complementary timezone.

Exit criteria:

• 100% of requests via form, 0 DM work intake.
• Tuesday 09:00 status has shipped 3 consecutive weeks for all active clients.
• You can be unreachable for 24 hours with no project slipping due to you.