EkaterinaKrivova

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.

Client
Independent project
Role
Content Operations Lead
Period
2026
Industry
FinTech · regulated content
Scope
Content operations · governance · Claude automation · multi-channel

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:

  1. Intake. The request is logged and gets an owner, an expert, a risk level and a due date.
  2. 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.
  3. QA and approval. The draft passes a Definition of Done and a QA checklist. High-risk content also needs a compliance sign-off.
  4. Publish. A person publishes it on the calendar date and checks it live.
  5. 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

RiskWhat falls hereReviewersReview cycle
HighFees, deposits and withdrawals, leverage and margin, risk warnings, entity-specific legal terms, anything that promises time or moneyExpert and ComplianceEvery 3 months and on any rule change
MediumAccount types, platform how-tos, product descriptions, onboarding emailsExpertEvery 6 months
LowGlossary, navigation copy, general educationPeer reviewEvery 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

AutomationTriggerHuman gate
Request intakeAn email or Slack message is forwardedContent Ops confirms owner and priority
Tagging and metadataA new item or a bulk migrationSpot-check of 10%
Pre-review QAThe item moves to Ready for reviewThe author fixes, the expert reviews
Content auditEvery quarter, or a CMS exportContent Ops and owners decide
Change impact searchA rule, fee or process changesThe owner confirms the scope
Weekly digestEvery Monday at 08:45Content Ops sends the reminders
Feature test feedbackRaw test notes are pasted inContent Ops reviews before sharing
Monthly health reportThe 1st of every monthShared 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.

ChannelJobFormat
Help CenterHelp me finish the task correctlyStep-by-step article, 300–700 words
Landing pageHelp me understand what to do and move forwardH1, a short value line, 3 steps, support link
EmailTell me what I need to do nextSubject of 30–50 characters, body of 80–180 words
Short socialGive me the key point fastHook, 1–2 sentences, call to action
PushPrompt me to do one thing nowTitle and one line
In-appGuide me at the moment I can actHeadline, 1–2 lines, a button of 2–4 words
FAQAnswer one question40–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.