Case Study #3
Content Automation Ops
A content operations system for a regulated product: one record and one owner per content item, review depth set by risk, and 8 Claude automations that draft, tag, check and remind while people approve and publish. One source text becomes 7 channel versions.
Outcomes
1 → 7
Channel versions from one source text
8
Claude automations, each with a human gate
3 · 6 · 12
Months between reviews, by risk level
0
Live changes Claude makes on its own
Context
Product content at a financial broker lives in 5 places at once: the website, the Help Center, the app, emails and the chatbot. Much of it is regulated. Fees, withdrawals, leverage and entity-specific rules change, and every copy of an answer has to change with them.
I built a lightweight system in Notion to run that content, and connected Claude to it through the Notion connector. It has 2 parts. The operating system tracks every content item from request to retirement. The launch workspace turns one approved source text into native versions for 7 channels. The example content in both comes from the Admirals public FAQ and Help Center.
Problem
- Content sat on several platforms, and nobody had a full inventory of it.
- Reviews and approvals happened in DMs and email, so there was no audit trail.
- Regulated content went out of date without anyone noticing.
- Tags and metadata were inconsistent, so content was hard to find, reuse and audit.
1. One record and one owner for every item
Every new piece or change starts as a request. No request, no work. Every live item then has one row in the Content Inventory: owner, subject expert, platform, entity, risk level, review dates and tags. Content without an owner does not get published.
Each item moves through the same path:
- Intake. The request is logged and gets an owner, an expert, a risk level and a due date.
- Production. The author writes the brief and draft on the item’s own page, from one template: brief, draft, QA, approvals, publishing plan, change log.
- QA and approval. The draft passes a Definition of Done and a QA checklist. High-risk content also needs a compliance sign-off.
- Publish. A person publishes it on the calendar date and checks it live.
- Maintain. The next review date is set by risk level. Overdue items surface on their own. Every review ends in Keep, Update, Merge, Archive or Remove.
Every change goes into the change log: what changed, why, who approved it and when it went live.
2. Risk sets the depth of review
| Risk | What falls here | Reviewers | Review cycle |
|---|---|---|---|
| High | Fees, deposits and withdrawals, leverage and margin, risk warnings, entity-specific legal terms, anything that promises time or money | Expert and Compliance | Every 3 months and on any rule change |
| Medium | Account types, platform how-tos, product descriptions, onboarding emails | Expert | Every 6 months |
| Low | Glossary, navigation copy, general education | Peer review | Every 12 months |
The same page holds the RACI for every step, the meeting rhythm (intake triage twice a week, a Monday publishing sync, a monthly content council, a quarterly audit), the QA checklist, the style rules, the glossary and the tag taxonomy. Claude reads these pages before it acts, so changing a rule there changes what Claude does.
3. Claude prepares, people decide
| Automation | Trigger | Human gate |
|---|---|---|
| Request intake | An email or Slack message is forwarded | Content Ops confirms owner and priority |
| Tagging and metadata | A new item or a bulk migration | Spot-check of 10% |
| Pre-review QA | The item moves to Ready for review | The author fixes, the expert reviews |
| Content audit | Every quarter, or a CMS export | Content Ops and owners decide |
| Change impact search | A rule, fee or process changes | The owner confirms the scope |
| Weekly digest | Every Monday at 08:45 | Content Ops sends the reminders |
| Feature test feedback | Raw test notes are pasted in | Content Ops reviews before sharing |
| Monthly health report | The 1st of every month | Shared with stakeholders |
The change impact search does the work people forget. When a withdrawal cut-off time moves for one entity, Claude searches the inventory and every item page for content that mentions it, in the FAQ, the Help Center, chatbot answers, emails and app strings. It lists each affected sentence and opens an update request for it.
Claude never publishes, unpublishes or deletes live content. It never approves for an expert or for Compliance, and never sends a message to a stakeholder without review. When a fact is not confirmed in a source, Claude writes it under Open questions.
4. One FAQ answer, end to end
The system includes one item traced from request to live: the public FAQ answer “How quickly can I withdraw funds?”. It is high risk: it moves money, its rules differ by entity, and it makes a promise about timing.
The live answer read:
Withdrawal requests are processed on the same business day if the request is received before the cut-off time. Requests received after the cut-off time, on weekends or during holidays are processed on the next business day. The cut-off time depends on the Admirals entity that holds your account.
Claude’s pre-review QA flagged 3 problems. The answer never gives the cut-off time, so the user has to guess or contact support. It does not separate “processed” from “received”, so users read “processed today” as “the money arrives today”. And another FAQ answered the same question, so it was a candidate for a merge.
The new draft:
We process withdrawal requests on the same business day if we receive them before the cut-off time for your account.
- Before the cut-off: processed the same business day.
- After the cut-off, at weekends or on public holidays: processed the next business day.
The cut-off time depends on the Admirals company that holds your account. You can see it in the Dashboard under Withdraw.
Processing time is not the same as arrival time. Once we’ve processed your request, your bank or payment provider may need extra time to show the money in your account.
The item page then carries the approvals, a publishing plan for 4 platforms and 10 languages, the merge of the duplicate answer with a redirect, and what to watch for 30 days after release: withdrawal-timing tickets, chatbot fallbacks on that intent, and searches that end on the FAQ.
5. One source text, 7 channels
The launch workspace runs one message through a fixed path: Master Copy, Message Map, Channel Rules, drafts, QA, Final. The Master Copy holds the facts. Each channel decides how to present them, and may not add a fact, a benefit or a number that the source does not have.
| Channel | Job | Format |
|---|---|---|
| Help Center | Help me finish the task correctly | Step-by-step article, 300–700 words |
| Landing page | Help me understand what to do and move forward | H1, a short value line, 3 steps, support link |
| Tell me what I need to do next | Subject of 30–50 characters, body of 80–180 words | |
| Short social | Give me the key point fast | Hook, 1–2 sentences, call to action |
| Push | Prompt me to do one thing now | Title and one line |
| In-app | Guide me at the moment I can act | Headline, 1–2 lines, a button of 2–4 words |
| FAQ | Answer one question | 40–100 words |
The example source is a support text about downloading MetaTrader from the Dashboard. The push version reads “Download MetaTrader. Open your Dashboard, choose MT5 or MT4, and download the platform.” The in-app version names the choice and the place: “Choose MetaTrader 5 or MetaTrader 4 and download the platform from your Dashboard.”
One rule keeps the channels apart: every channel uses the same facts with a different job, opening, structure and call to action. QA checks that rule as well as accuracy. No channel may be a shortened copy of another. Claude writes and checks the drafts. Final is the version a person approved.
What the system measures
- Overdue reviews: 0% for high-risk items, under 5% overall.
- Items with complete metadata: over 95%.
- Time from request to live: 10 working days or less for high risk, 3 or less for low risk.
- Items waiting more than 5 days for approval: 0.
- Errors found after publishing: under 2 a month.
Customer signals are reviewed every quarter: support contacts on topics the content already covers, Help Center searches with no result, chatbot fallbacks per intent, and helpful votes per article.
My contribution
- Designing the content lifecycle, the statuses and the exit criteria for each status
- Writing the risk model, the RACI and the governance rhythm
- Writing the QA checklist, style rules, glossary, tag taxonomy and content type patterns
- Building the inventory, request and change-log databases in Notion
- Writing the 8 Claude automations and the human gate for each one
- Designing the 1 text, 7 channels workflow, with its channel rules and its anti-repetition QA
- Rewriting the withdrawal FAQ as the worked example
An independent project from 2026. The example content comes from the Admirals public FAQ and Help Center. IDs, dates, team names and the cut-off change in the worked example are illustrative.