Jonathon's AI Wiki

How Anthropic's Own Marketing Operations Team Uses Claude Cowork

10 min read

Source: ai-research/claude-blog-marketing-ops-cowork-automation.md — Anthropic first-party blog post, claude.com/blog/how-anthropics-marketing-operations-team-uses-claude-cowork-to-automate-reporting-and-campaign-builds, by-lined to Ian Chan and Annabel Custer, both on Anthropic’s own marketing operations team.

Anthropic’s marketing operations team dogfoods Claude Cowork on its own reporting and campaign-build workflows, and this post is the first-party account of exactly how. Two named case studies — a weekly metrics report and an event-build pipeline — each turned a multi-day manual grind into a 2-hour review cycle, and both are built the same way: connectors to the underlying martech/data tools, plus a small number of custom skills the team owns and edits continually. It joins the wiki’s existing cluster of Anthropic-internal-practices posts alongside Self-Service Data Analytics and How We Contain Claude — all first-party accounts of Anthropic running its own operations on Claude, not just selling it.

Key Takeaways

  • Both case studies compress days into hours. Ian Chan’s weekly marketing metrics report went from “one to two days a week” to “up to two hours.” Annabel Custer’s event-build sequence went from a fully manual, one-request-at-a-time Slack workflow to an automated pipeline she mostly reviews rather than executes.
  • The architecture is the same in both cases: connectors + a small set of owned, continually-edited skills — not one giant prompt. Ian runs three skills; Annabel runs a dispatcher skill plus five specialist skills. Neither team member describes “prompting harder” as the lever — it’s skill design and maintenance.
  • A genuinely new multi-agent pattern: dispatcher -> specialist -> audit -> manager. Annabel’s setup separates routing (a dispatcher skill that reads an intake channel once an hour, picks the most urgent request, and stamps it to prevent duplicate work) from execution (one of five specialist skills, e.g. the event-build skill that runs CRM + marketing-automation + event-platform setup end to end) from verification (a fresh audit agent with zero prior context that submits a live test registration and checks the confirmation email) from incident response (a standing “manager” agent she opens only when a run misfires, to diagnose and propose a fix). Keeping routing separate from execution means she can improve one specialist skill without touching the dispatcher.
  • Claude flags data mismatches instead of guessing. When a sales-team reorg broke the correspondence between marketing’s and sales’s numbers, Claude surfaced the discrepancy and asked Ian how to handle it rather than silently reconciling or picking a side.
  • The skill-maintenance loop is a deliberate ritual, not an afterthought. At the end of every weekly session, Ian asks Claude to summarize what should go back into the skills — new org structures, corrections he made, new ways he wanted headlines framed. This is the same “keep the skill doc current or accuracy rots” discipline documented in Self-Service Data Analytics (where skipping it cost 30 points of eval accuracy in a month).
  • The motivation for Annabel’s automation was quality, not just time. Marketers cloning event-landing-page templates by hand produced real bugs (wrong city name in a confirmation email, broken pages). The automated pipeline’s value proposition was consistency at scale first, hours saved second.
  • Human review stays load-bearing in both workflows. Ian confirms narrative focus before Claude expands the report; Annabel reviews every audited event build before it ships. Neither workflow is presented as fire-and-forget.

The weekly metrics report (Ian Chan)

The problem: some metrics live in a dashboard, some haven’t made it from the warehouse to the dashboard yet, some haven’t reached the warehouse at all, and some exist only in a Slack message or a call transcript. Ian used to spend one to two days a week just tracking down and validating numbers.

The workflow:

  1. Sunday evening scheduled task. Claude reads the previous week’s review and the latest meeting transcript, checks Slack for what sales is focused on, queries the data warehouse, and leaves a folder with the numbers plus a few suggested focus areas. This is the same scheduled-task primitive documented elsewhere in the wiki, applied to a business-operations workflow instead of a dev workflow.
  2. Monday morning review. Ian opens Cowork, reviews the metrics tables and suggested headlines, confirms or redirects the narrative focus, then tells Claude to expand with supporting detail. At quarter turns, he instead feeds the quarterly review doc and has Claude lead with quarterly plans.
  3. Leadership slide generation. Claude produces the leadership slide from the same data and narrative — what changed, why, what teams are doing about it. Follow-ups become Asana tasks automatically.
  4. Mismatch handling. When numbers don’t reconcile (e.g., post-reorg), Claude flags the gap and asks rather than guessing.
  5. End-of-session skill update. Ian has Claude summarize what should be written back into the three skills that drive the whole process.

Net effect: two days of manual data-hunting collapsed to a two-hour review-and-narrate pass. The freed time went to helping other marketers frame their own Claude questions, plus deeper work ensuring Claude’s interpretation of metrics/definitions/regional structure matches the warehouse’s.

The event-build pipeline (Annabel Custer)

The problem: every event, webinar, or integrated campaign needs setup across a CRM, a marketing-automation platform (email sequences), and an event-management platform (registration + landing page) — three different vendors with incomplete integrations between them. Annabel used to pick up each request from a Slack channel and work the sequence by hand.

The new pipeline, in order:

  1. Intake form. Requesters specify request type: event build, data import, apply-to-attend, or approval support.
  2. Dispatcher skill (hourly). Reads the intake channel, picks the most urgent request, stamps the ticket to prevent duplicate work, and hands off to one of five specialist skills. It does no event-setup work itself — its only job is routing, which lets Annabel improve individual specialist skills without touching the router.
  3. Event-build skill (for the most complex request type). Runs the full sequence end to end: CRM campaign creation, marketing-automation campaign with workflows and lists, event-platform setup, email drafting, landing-page generation, and all the integrations between them.
  4. Audit agent. A fresh agent with no prior context submits a live test registration on the just-built landing page, opens the confirmation email in Gmail, and marks the Asana task complete if everything checks out. Annabel reviews every result before it ships.
  5. Manager agent (on misfire). A separate standing agent Annabel opens specifically to diagnose what went wrong and propose an adjustment when a run fails — keeping incident-response reasoning out of the main pipeline.

This four-role split — dispatcher, specialist, audit, manager — is a concrete, named instance of the same isolation logic behind Claude Code Subagents and Agent Teams: each role gets a scoped job and a fresh or separate context, and the coordination overhead (routing, verification, incident response) is deliberately kept out of the skill that does the actual work.

Why this matters for a marketing agency

This is the clearest first-party evidence yet that Cowork’s leverage for marketing operations comes from skills you own and edit, wired to connectors, with a verification step that doesn’t trust its own output — not from a single clever prompt. For an agency running comparable workflows (client reporting, campaign/event builds across a CRM + email platform + landing-page tool), the reusable shape is:

  • A scheduled “gather” pass that pulls from every source of truth (warehouse, Slack, transcripts, prior report) before a human ever opens the tool.
  • A router skill separated from the skills that do the work, so routing logic and execution logic can be improved independently.
  • A same-day audit step that starts context-free and re-derives the answer (submit the test registration, read the confirmation email) rather than asking the building agent to grade its own work.
  • A recurring “what should go back into the skill” ritual at the end of every session — treated as part of the workflow, not a nice-to-have.

This complements Claude Cowork for Marketing’s eight-use-case tutorial (workspace setup, strategy decks, connectors, Live Artifacts, skills, browser use) with a second, independent first-party data point on the same underlying claim: the workspace/skill foundation is where the leverage lives, not the one-off prompt. It’s also a directly relevant automation-architecture reference for the AI Automation Client Acquisition Playbook — the dispatcher/specialist/audit pattern here is a production-grade version of the “package a repeatable workflow” step that playbook’s cold-outreach clients are often buying.

Try It

  1. Pick one recurring report or build that touches 3+ disconnected tools (a CRM, an email platform, a reporting dashboard) and map it to the dispatcher/specialist/audit shape above before writing any prompts.
  2. Separate routing from execution from day one. Even a single-person operation benefits from a thin “what should run next” skill kept apart from the skills that do the work — it’s what let Annabel improve specialist skills independently.
  3. Add a context-free audit step, not a self-grade. If the deliverable is a webpage or email, have a second, fresh session actually submit the test case and check the result, the way the audit agent here submits a live test registration.
  4. Institutionalize the “what goes back into the skill” question at the end of every session using the workflow, the way Ian does weekly — this is the mechanism that keeps a skill from rotting (see Self-Service Data Analytics for what happens when it’s skipped).
  5. Compare against Cowork for Marketing’s eight use cases — this case study is deeper on architecture (four-role pattern, skill-maintenance ritual) where that article is broader on breadth (strategy decks, Live Artifacts, browser use).

Open Questions

  • The “Advice for Marketing Ops teams” section did not survive extraction. The live post has this header but the content (likely an FAQ accordion) didn’t come through as markdown. Worth a re-fetch with a rendering-capable tool if the specific tips are needed.
  • Skill count and format are not fully specified. The post says “three skills” (Ian) and “five specialist skills” (Annabel) but doesn’t show their actual skill-file contents, unlike the appendix skeletons in Self-Service Data Analytics.
  • No mention of failure/error rates. Unlike the data-analytics post (which quantifies accuracy at 95% and traces a 30-point regression from skill neglect), this post doesn’t give a number for how often the audit agent catches a real problem or how often the manager agent is invoked.

Graph View

Backlinks