Tasks placed on their Due Date. Weekend due dates fold back to the previous Friday. Overdue tasks lift into today's cell. No-due-date tasks land in Needs Assignment below the grid.
Per-operator daily cap = 6. Targets 10 campaigns/week per operator; 6/day allows a heavy day without crossing into pileup territory. The red badge above a day number fires when any single operator exceeds 6 on that day.
Cell heatmap: 0 = bare · 1-3 = low blue tint · 7-12 = amber · 13+ = red.
The banner above the calendar reads the same scheduled placements and checks them against a team daily line = team weekly target ÷ 5 working days (≈18/day at a 90/week target; falls back to roster size × 6). It returns one of three verdicts: Balanced (load is even), Uneven (peak day is 1.8× the even spread), or Over capacity (a day exceeds the daily line). When over, it counts the campaigns above the line and names the lightest open days to pull them into, so a 19-today / 1-tomorrow pile-up is visible and actionable rather than buried.
Each calendar card and bench card carries a note affordance (the 📝 glyph; amber when a note exists). Click it to log why a campaign is blocked or delayed. Notes save to the Task Hub GTME Note field and show inline. The edit appears immediately in-session; it lands in the snapshot on the next refresh.
Load = count of tasks currently at 80 - Needs Approval with Last Modified in current Mon–Sun. Target = 10 campaigns/week. Zones: green <80% · amber 80–100% · red >100%.
Behind-pace pill: from Wed onward, shown when shipped < target × (days_elapsed / 5). An early-warning signal that the operator needs to accelerate to hit the week's target.
Caveat: Last Modified bumps on any field edit. Real-world impact is low.
Open task = 01 - TO DO or 50 - In Progress. Overdue — Due Date < today · 2W — within next 14 days · W3 — 15–21 days out.
Status filter: toggles between Open (default — TO DO + In Progress) and Needs Approval (trailing 30 days of Last Modified). The capacity bar above is strictly this week.
Tasks: Due Date in [today − 3w, today + 3w]. Snapshots are written by a GitHub Actions cron and served as static JSON. Refresh all reloads the latest snapshot in place. The Refresh button on the Proposals tab triggers a workflow_dispatch to rebuild the snapshot.
Saturday shift: the 14-day window resets each Saturday morning so the new view captures Friday's completed work and looks forward into the next two weeks. Sun–Fri the window stays anchored on the current Sunday; on Saturday it rolls forward to the next Sunday.
inbound_messages, excludes Out-Of-Office / Auto-Reply / Wrong-Person), real positives, and bounce. State, KPI, and benchmark coloring mirror the client health dashboard ↗. High bounce or sending heavy with zero real signal reads as Needs Attention, not "ramping."Owners = distinct operators currently assigned to this client's open tasks, with task count per operator.
Total = open tasks (status 01 - TO DO or 50 - In Progress) for this client.
Assigned = tasks with a GTME owner. Unassigned = tasks with no owner.
Week 1 / Week 2 = scheduled into the upcoming two-week calendar by the same scheduler the Weekly Plan tab uses. Unassigned tasks live in Needs Assignment, not on date cells.
No Brief = tasks with no External Campaign Brief link.
Tier is read directly from the Airtable Clients table (Priority Tier field), 6h cache. B is the default fallback when null.
Campaign Creation Request deliverables that moved to status 100 - Done within the window.Source: Airtable Management View ↗, the Pipeline Steps Log (Activity) table behind the interface page the team treats as the source of truth. A campaign counts as shipped when its deliverable moved to a terminal 100 - Done status, its Task Type is Campaign Creation Request, and that transition was logged inside the selected window. Keying off the logged ship moment (not the Campaigns table's often-blank Target Launch Date) means the count never silently undercounts.
Per-operator: owner from Task Owner on the activity row. Multi-owner campaigns credit each operator.
Per-client: resolved via the Clients link against the in-scope client map. The headline total counts every shipped campaign regardless of client resolution; the per-client breakdown only buckets rows whose client link resolves.
One campaign = one unit. A Campaign Creation Request is a single multi-channel campaign; its email and LinkedIn arms count once together, not as two rows. Re-completions of the same deliverable are de-duplicated, so a campaign reworked and re-shipped still counts once.
Windows: Last Week = the prior completed Mon-Sun (the honest baseline for the in-flight week). This Week = current Mon-Sun. Month / Quarter = calendar to date.
13-week trend: same shipped-campaign source bucketed by ship week (the logged 100 - Done transition). Each operator's own trend line sits on their card in the By Operator section.
Cache: snapshot is rebuilt by the GitHub Actions cron. Refresh all in the header reloads the snapshot.
Campaign QA tab — owned by the QA dashboard session.
Their handler at /gtme/campaigns-snapshot.json will populate this panel with the four-level disclosure (Client → Campaign → Settings + Sequence → Step) from their existing mock at scripts/campaign-qa-dashboard/mock.html.
Shared client filter above scopes both tabs.