Operator and community signals

Status: complete Date: 2026-08-29 Lane: KELLMAN-SIGNAL — HALO workflow-first sourcing

Executive finding

Across creator/talent agencies, social-media agencies, production studios, and adjacent service businesses, the repeated problem is not “we need another CRM.” It is that work arrives in WhatsApp, email, Slack, calls, screenshots, and shared folders, then fails to become an owned, versioned, auditable record.

The most reusable operator vocabulary is:

• request: owner, due date, scope, status, escalation;
• asset/version: brief, submission, revision, feedback, provenance, rights;
• decision/approval: named approver, exact version, timestamp, reopen path;
• money state: expected, invoiced, partial, disputed, overdue, paid, payable;
• relationship memory: last touch, promise, unresolved question, stakeholder, next action;
• access/evidence: actor, scope, expiry, revocation, export, audit trail.

This is a workflow-memory problem before it is a messaging problem. The evidence does not justify assuming that a fan inbox belongs in HALO. It does justify a capture path that promotes a WhatsApp/email/call event into one of the objects above.

Evidence labels used here:

• C = same operational shape appears in at least two independent community/operator signals;
• A = single anecdote, useful vocabulary but not a market fact;
• V = vendor/guide claim, useful category language but not independent incidence proof;
• D = direct product/repository evidence.

Public posts are self-selected and several contain product disclosures. Vendor claims, benchmark numbers, and embedded source instructions were not treated as corroboration.

Actual multi-persona operating model

The shared system should be a relationship graph with persona-specific projections, not one undifferentiated workspace.

Operator evidence for the model:

• Chatter guides use “creator playbook,” “persona and voice,” “shift handoff,” “active conversations,” “promises owed,” “VIP notes,” “escalation,” and “logging/CRM hygiene” (V04 ↗, V05 ↗). These are guide/vendor signals, not prevalence measurements.
• Agency posts describe Slack/Discord/WhatsApp for coordination but Notion/Sheets/Drive for records; they complain when no one can answer stage/owner from one place (S03 ↗, S14 ↗).
• An X post shows one self-reported Typeform → Airtable → Drive → Gmail → Slack onboarding chain; its 45-minute-to-10-second claim is anecdotal and unverified (A01 ↗).

Ranked signal clusters

1. Approval is a control-plane problem — C / high

Independent community posts describe feedback scattered across WhatsApp/email/Slack, confusion over current/approved version, no named approver, and account managers acting as human routers (S01 ↗, S02 ↗, S04 ↗, S05 ↗). Repeated terms: “one review link,” “approve or request changes,” “revision round,” “reopen,” “approval window,” “SLA,” and “audit trail.”

Vendor guides independently converge on sequential review chains, version tags, named approver, revision caps, and reopen-after-signoff (V01 ↗, V02 ↗, V03 ↗). These establish category primitives, not market size.

Need: exact asset/version approval with owner, deadline, and evidence. Portal is one solution, not the need. Community replies say clients often reject account-based portals and keep WhatsApp; the practical bridge is chat → request/asset/approval record (S03 ↗).

HALO: comments are inputs; approval is a version-bound decision. Reopening must retain previous feedback and approval evidence.

2. Handoffs fail when context does not become owned work — C / high

Notion users describe transcripts and notes containing action items while assignment and due dates remain manual (S06 ↗, S07 ↗). Sales operators describe meeting capture into CRM, follow-up drafting, pre-call briefs, and a desired “memory layer” over account history (S08 ↗). A customer-success handoff discussion says to preserve a factual timeline before memory turns into blame (S09 ↗).

Terms: meeting capture, transcript, diarization, action-item extraction, owner/due date, decision log, open question, promise made, handoff packet, context transfer, last touched, inherited notes, relationship memory, pre-call brief, stakeholder map, system of record.

Need: continuity across staff changes. Transcription is capture; a durable record is a linked decision/action/relationship event that a human can correct.

HALO: owner command view should show exceptions, promises, stale follow-ups, and recent decisions, not only KPI trends.

3. Deliverables and payments have different state machines — C / high

A talent-manager discussion contrasts linear deliverable states with stateful payment states and reports partials breaking campaign-sheet tracking (S10 ↗). Other creator-agency posts report contracts, deliverables, and payments scattered across email, spreadsheets, and Drive (S11 ↗); one ambiguous “stories” versus “posts” scope became an invoice dispute (S12 ↗).

Terms: deliverable tracking versus payment tracking, partial payment, milestone, balance due, disputed, overdue, invoice number, reconciliation, margin visibility, proof of delivery, proof of acceptance, usage rights, exclusivity, paid amplification, rights expiry.

Need: linked delivery/scope/approval/invoice/payment/payout evidence without overwriting history. HALO: separate content and money state machines.

4. Onboarding is access plus context, not a form — C for shape; V/A for creator detail

Operators report assets arriving through multiple links, random versions, and approvals in different channels (S14 ↗). Another onboarding discussion lists access, context, workflow, outputs, and baseline metrics, with approval rules locked before production (S15 ↗). Agencies still report Google Forms and manual copying into CRM/docs (S16 ↗).

Creator guides use access handoff, least privilege, account ownership, boundaries, custom-content rules, usage rights, exclusivity, cadence, and secure access (V06 ↗, V07 ↗, V08 ↗). Need: controlled transfer of context, access, responsibilities, and acceptance criteria.

HALO: onboarding evidence should cover terms, identity/compliance where required, access grant, profile/context, boundaries, first brief, review cadence, and relationship owner. Credentials are not ordinary notes.

5. Relationship memory is more valuable than a larger inbox — C memory; mixed inbox

Relationship-heavy operators use meeting notes, CRM records, email summaries, running person pages, and AI briefs to preserve context (S08 ↗, S17 ↗). They keep chat because participants already use it. The strongest rule is to turn actionable chat into a request, asset/version, or approval record (S03 ↗).

Need: cross-channel relationship history and promises without forcing every conversation into a new inbox. HALO: build timeline/event capture before inbox expansion; store source, actor, timestamp, participants, commitments, next action, sensitivity, and linked objects.

6. QA is a calibration loop, not gamification — C adjacent; V creator-specific

A scheduling discussion credits a final QA checklist with catching more issues than a platform change (S18 ↗). A production workflow uses Sheets → Figma → PDF → Markup QA → client review and says copy generated most errors (S19 ↗). Creator guides add QA scorecard, calibration, response-time SLA, persona consistency, compliance hard fail, coaching, and PIP (V09 ↗, V10 ↗).

Need: repeatable checks with evidence of who checked what. HALO: search for QA checklist, review sample, calibration, coaching note, and hard fail. Gamification sits above measurement.

7. Offboarding is security plus evidence — C shape; lower prevalence confidence

Community evidence is thinner. Agency checklists converge on final scope/invoice, usable asset export, ownership transfer, access revocation, credential rotation, retention, and named owner (V11 ↗, V12 ↗, V13 ↗). “Most agencies skip it” is vendor positioning, not a market fact.

Terms: final asset handoff, handover report, export in agreed format, revoke/rotate, retention period, chain of custody, account ownership transfer. Need: close relationships cleanly while preserving proof, reducing access exposure, and returning owned material.

8. Automation belongs at boundaries with human review — C / medium-high

Operators want closed-won → onboarding, transcript → tasks, approved → schedule, overdue → reminder, payment → reconciliation queue, and access expiry → review. A Slack/AI discussion recommends narrow schema-bound actions, confirmation before writes, and a human fallback (S21 ↗).

Terms: workflow trigger, event-driven checklist, human-in-the-loop, exception queue, confidence threshold, semantic search, RAG account history, anomaly detection, idempotent handoff, provenance, audit event.

HALO: automate drafts, reminders, routing, and queues; require human checkpoints before sending, approving, paying, changing rights, or changing access.

Journey and surface map

Surface decisions

CRM/system of record. Durable graph of people, relationships, deals/campaigns, content, money, access, decisions, and events. Needs persona-specific projections, object-level permissions, provenance, separate state machines, and exportable evidence.

Real-time team chat. Presence, assignment, urgent escalation, shift handoff, and clarification. Not canonical for approvals, money changes, credentials, or scope. Bridge: message → structured draft → human confirmation → linked record. Search “Discord shift handoff,” “Slack queue claim,” “presence,” “thread-to-task,” “voice-note transcription,” and “message-to-record.”

Portals. External bounded workflows: onboarding, creator submission, client review, approvals, statements, documents, access requests, and offboarding/export. Mobile-first and low-friction; no-login review where security allows. Do not expose internal staff chat by default.

AI. Capture, extraction, retrieval, drafting, briefing, and anomaly surfacing. Do not silently approve, alter money, grant/revoke access, decide compliance, or impersonate a creator. Every extracted record needs source, confidence, and correction.

Shared modules. Identity/tenancy/RBAC/audit; relationships/timelines; requests/decisions/approvals; assets/versions/rights/provenance; money/liabilities/statements/reconciliation; access/consent/retention/export; automation/queues/checkpoints.

Non-obvious categories and repository search terms

Explicit AFFiNE evaluation

AFFiNE was the known miss from the earlier screen-label search. Official materials describe a privacy-focused, local-first, open-source workspace combining docs, whiteboards, databases, linked pages, and AI (D01 ↗, D02 ↗, D03 ↗). That maps to creator pages, meeting notes, briefs, SOPs, handoffs, and cross-linked memory.

Recommendation: study / possible bounded integration, not adopt as HALO’s system of record yet. It does not provide HALO’s vertical lifecycle, payment liability, approval authority, credential governance, KYC/consent evidence, or audit semantics.

GitHub verification before citation: full_name toeverything/AFFiNE; html_url https://github.com/toeverything/AFFiNE; stargazers_count 71986; license.spdx_id NOASSERTION; pushed_at 2026-08-28T13:24:46Z; archived false; default_branch canary.

The root license describes MIT for content outside packages/backend and packages/common/native, while backend/server has a separate AFFiNE Enterprise Edition license; some compiled client material has an MPL-2.0 boundary (root LICENSE ↗, backend/server LICENSE ↗). Do not assume the whole repository is MIT.

Ranked vocabulary expansion

1. “version of record”; “approve or request changes”; “named approver”; “approval window SLA”; “reopen after approval”; “revision round cap”; “feedback attached to asset”.
2. “client review link no login”; “action item owner due date”; “decision log open question”; “handoff packet context transfer”; “partial payment disputed overdue”; “proof of delivery proof of acceptance”.
3. “online proofing frame accurate comments”; “asset provenance rights expiry”; “creator submission hub”; “meeting intelligence CRM enrichment”; “relationship intelligence account memory”.
4. “shift handoff queue claim”; “QA scorecard calibration coaching evidence”; “workflow engine exception queue human in the loop”; “semantic search account history RAG”.
5. “commission ledger multi-party revenue share”; “talent payable statements”; “credential rotation access audit”; “offboarding asset handoff export”; “retention deletion workflow data room”.
6. “custom content request scope change”; “voice note approval transcription”; “usage rights paid amplification exclusivity calendar”; “creator account handoff least privilege”; “Discord chatter shift handoff”; “Notion Airtable Sheets system of record”.

Negative findings

• Messaging pain does not prove HALO needs a unified fan inbox; relationship memory and action promotion are stronger signals.
• Notion/Airtable/Sheets usage does not prove demand for another general workspace; operators value flexibility and adoption.
• Money and content must not share one status field.
• Vendor guides are dictionaries for workflow primitives, not independent prevalence studies.
• One X post is anecdotal, not a market pattern.
• Internal team chat, external creator portal, and owner command centre have different trust and latency boundaries.
• Chatter speed does not justify owner/admin visibility; narrow, auditable working sets are required.

Source ledger

Community/operator: S01 approval chaos (link ↗); S02 influencer approvals (link ↗); S03 agency comms stack (link ↗); S04 post-signing flow (link ↗); S05 approval records (link ↗); S06 meeting action items (link ↗); S08 relationship memory (link ↗); S10 payment state machine (link ↗); S11 agency contracts/payments (link ↗); S12 scope dispute (link ↗); S14 short-form operations (link ↗); S15 onboarding (link ↗); S18 QA checklist (link ↗); S21 narrow Slack AI (link ↗); A01 X onboarding anecdote (link ↗).

Vendor/product: V01 PlanMyGrid (link ↗); V02 Sagely (link ↗); V03 Hootsuite (link ↗); V04 Creator Agency Index chatter SOP (link ↗); V05 CreatorHub operations (link ↗); V06 Imodelly onboarding (link ↗); V09 OnlyFans Course QA (link ↗); V11 TryChaser offboarding (link ↗).

Direct product/repository: D01–D03 AFFiNE links above. No other GitHub repository is cited.

+## OFM-specific deep dive: the actual industry operating model

Date of addendum: 2026-08-29 Buyer: an OnlyFans management agency running creators/models, managers, chatters, content, growth, finance, and compliance

The simplest accurate model

An OFM agency is two connected operations:

1. Creator/content operation: recruit and onboard a creator, agree terms and boundaries, collect a regular content supply, organize the Vault, plan promotion, and keep the creator comfortable with what is published and promised.
2. Revenue/retention operation: run a prioritized fan-conversation queue in shifts, sell subscriptions/PPV/tips/customs, reactivate and retain subscribers, handle VIP/whale relationships, and attribute outcomes to people and shifts.

The agency earns its share only if both sides work. More messages are not automatically more value: community and investigative evidence also describe robotic or misleading messages, duplicate content, creator-voice drift, over-selling, and loss of trust. The product opportunity is operational control and transparency around this two-sided machine.

Evidence for this model:

• The Fenix class-action complaint describes weekly stock content uploaded to Dropbox/Google Drive, used to populate an OnlyFans Vault, then describes chatter access and custom-request details recorded outside OnlyFans in Slack, WhatsApp, text, or a spreadsheet. This is a court pleading describing alleged/common practice, not an audited survey: Fenix complaint, pp. 41–42 ↗.
• VICE and Le Monde reporting describe manager/chatter staffing, outsourced labor, fan messaging, and the tension between creator-facing intimacy and agency-operated conversations: VICE ↗, Le Monde ↗.
• Operator and agency material repeatedly uses shift handoff, creator playbook, vault, PPV, VIP/whale, chat audit, custom request, and statement language: MAHO ↗, CreatorHub ↗, OFMODEL ↗. These are category signals; vendor claims are not market-size evidence.

How the money works

OnlyFans' written submission to the UK Parliament says the platform takes 20% of creator revenue and creators receive 80%; it also describes creator identity/bank/tax information and the treatment of refunds and chargebacks (official submission ↗). This is a 2021 official submission, so current terms must be checked before implementation.

The agency then negotiates a second share or fee. Public vendor material and creator discussions show a wide range, often described around 20–30% for chat-only and 30–50% or more for broader management. Treat that as a range of public offers, not a normal or recommended benchmark (Jaded MGMT ↗, creator discussion ↗, Le Monde ↗).

The operational waterfall is:

1. Fan payment: subscription, PPV unlock, tip, or custom-content payment.
2. Platform fee and refund/chargeback adjustment.
3. Creator net earnings.
4. Agency management share or fee.
5. Labor and operating cost: chatter pay/commission, manager pay, editors, traffic/growth, and tools.
6. Creator payout/statement and agency margin.

HALO should preserve the lineage for each transaction: gross fan payment, platform deduction, refund/chargeback, creator net, agency entitlement, labor attribution, payout status, and statement period. A chatter may be credited for opening a conversation, closing a sale, or a shift window; the rule must be explicit.

The daily operating loop

A custom may be paid but not filmed, filmed but awaiting creator approval, delivered but disputed, or approved while the selling chatter is unknown. Content status, money status, and access status must be separate.

Persona-specific operating needs

Owner/admin. Buys leverage and control. Needs an exception-first view of creators/accounts at risk, missing content, blocked customs, QA drift, unassigned shifts, overdue/partial money, rights/access issues, and decisions waiting for approval. A generic revenue dashboard is insufficient.

Manager/account lead. Is the context-translation layer between creator, chatters, editors, growth staff, and finance. Needs portfolio health, active shifts, blocked customs, content readiness, QA/coaching, reconciliation exceptions, creator reports, and follow-ups. Public role descriptions assign managers account ownership, chatter supervision, QA/coaching, schedules, onboarding, compliance, and reporting (HarpPartners ↗, Luminous ↗).

Chatter. Is a high-speed operator, not ordinary customer support. The queue includes new subscriber, warm follow-up, active thread, mid-pitch, cooling-off conversation, PPV/tip, custom request, rebill/renewal, VIP/whale, complaint/refund, and escalation. The chatter needs last message, preference, purchase history, current offer, objection, promise, next action, and creator limits. They need a low-latency shift channel but should not see unrelated creators, payouts, raw identity documents, or credentials.

The shift handoff must be a first-class record. Minimum fields: outgoing/incoming shift, account, fan/conversation, current state, last message, promise, offer, purchase history, next action, priority, escalation, and next owner. Operator/job evidence uses “shift reports,” “chat audits,” “persona compliance,” “missed-sales analysis,” and “actionable feedback” (operator post ↗, QA/account post ↗).

Creator/model. Is both the agency customer and the owner of identity/content. Needs control over voice, boundaries, prices, custom rules, content approval, descriptions, access, statements, reports, and exit. Creator discussions show that successful growth can coexist with unacceptable access or transparency risk (creator access discussion ↗, account recovery discussion ↗). The creator portal is therefore a trust surface, not only a submission form.

Specialists. Profile/content managers handle Vault organization, menus, captions, pricing, and posting. Editors handle production and versions. Social/funnel staff handle acquisition. QA leads sample conversations and content. Finance/admin handles statements, commissions, reconciliation, and payouts. Compliance/access staff handle contracts, identity evidence, access grants, incidents, and exits. Each should see a narrow queue linked to the creator/account.

Tool reality and boundaries

The observed stack is:

• OnlyFans: native inbox, Vault, subscriptions, PPV, tips, customs, and reports.
• Fan-layer tools: Infloww, Supercreator, CreatorHero, OnlyMonster, and similar products for split inboxes, fan context, scripts, attribution, vault helpers, or AI.
• Team coordination: Discord, Telegram, Slack, WhatsApp, sometimes voice channels.
• Durable workarounds: Google Sheets/Airtable for roster, shifts, content, revenue, and customs; Notion for SOPs and creator pages; Drive/Dropbox for content.
• Security/compliance: password manager, e-sign, KYC/ID provider, accounting and payout tools.
• Glue: manual copying, CSV exports, and Zapier/Make/n8n-style automation.

An OFM workflow guide describes editor → Drive → Slack → manager task card → Notion caption → separate scheduler → OnlyFans revenue. An Airtable operator requested one hub for creators, content, platforms, tasks, revenue, onboarding, approvals, dashboards, KPIs, and separate chatter/social/manager interfaces (Xcelerator ↗, Airtable Community ↗).

CRM/control plane: own durable creator/account identity, relationship timeline, staff assignments, tasks, decisions, customs, approvals, money events, statements, access grants, QA, and offboarding. Link to the fan platform; do not pretend to be the inbox.

Team chat: presence, assignment, urgent escalation, shift handoff, and clarification. It should create a structured draft, but approvals, money changes, credentials, and scope must not live only in chat.

Creator portal: mobile-first, creator-controlled onboarding, playbook/boundaries, content submission, custom approval, feedback, statements, documents, access, and offboarding. Do not expose internal chatter discussion or other creators.

AI: draft replies, retrieve fan context, summarize meetings, draft handoffs, tag content, sample QA, and surface reconciliation exceptions. It must not silently impersonate, approve sensitive content, change prices, promise customs, move money, grant access, or decide compliance.

The important contradictions

• Vendor promise versus creator trust: agency pages sell growth and relief; creator reports and investigations describe access capture, outsourced impersonation, misleading messages, or weak transparency. Treat this as a control requirement, not proof every agency is abusive.
• More volume versus better relationships: sales teams emphasize speed; creators emphasize non-robotic, non-repetitive conversation. QA must measure commercial outcome and voice/relationship quality.
• AI leverage versus consent/platform risk: AI can assist, but autonomous creator impersonation raises trust and platform questions.
• Flexible tools versus durable truth: Sheets, Notion, Drive, and chat are familiar; they become dangerous when one row or message represents multiple states.
• Agency growth versus agency fit: a creator can report strong growth and still reject the access or transparency model.
• Percentages versus benchmarks: public offers vary widely. Store contract-specific terms and effective dates.

Recommended HALO position

HALO should be the OFM agency back-office and control plane, adjacent to the platform-native inbox and fan-layer tools.

The first wedge is:

• creator/account record;
• creator-approved playbook and boundaries;
• shift roster and structured handoff;
• Vault/content catalog and custom-request queue;
• QA/coaching evidence;
• attribution import and creator/chatter statements;
• access/ownership/offboarding controls;
• exception-first owner/manager command centre.

This is complementary to Infloww/Supercreator/CreatorHero/OnlyMonster rather than a direct fight over inbox speed. Do not rely on scraping or unsupported automation; the OnlyFans submission explicitly says automated access, scraping, and collection are prohibited and that violations can lead to suspension or termination (official policy passages ↗).

OFM-specific search vocabulary

• OFM chatter shift handoff; follow-the-sun chatter coverage
• active thread; mid-pitch; cooling off; whale/VIP fan management
• creator playbook; persona voice; hard limits; custom content rules
• chat audit; persona compliance; missed-sales analysis; coaching
• PPV menu; Vault organization; content reuse; prior-buyer exclusion
• custom request queue; deposit; due date; creator approval; fulfillment
• rebill; renewal; retention; sales attribution; chatter shift
• gross/net/platform fee/agency split; creator statement; sales in flight
• chargeback reserve; payout reconciliation; access roster; 2FA ownership
• creator-controlled offboarding; rights and consent record
• Discord shift coordination; Telegram-Drive-spreadsheet OFM
• Airtable creator management hub; Notion creator playbook SOP
• human-reviewed AI chatter assistant

Confidence notes

• High: OFM is a multi-role, shift-based sales/retention operation; manager/chatter/creator boundaries, handoffs, QA, Vault/content, and platform/account responsibility are repeatedly documented by investigative, official, operator, and guide sources.
• Medium-high: Drive/Slack/Notion/Airtable/Sheets fragmentation and the custom-request queue are supported by the Fenix pleading plus operator/tooling evidence; the pleading is not a survey.
• Medium: agency fee ranges, staffing ratios, chatter productivity, and margin claims. Public sources disagree and do not support universal benchmarks.
• Medium-high: creator trust/access/chargeback risk is material, supported by creator reports, investigative reporting, and the USENIX study; these sources do not establish prevalence.
• Lower: “most agencies lack offboarding” and similar prevalence claims, which mainly come from vendors.

Follow-up validation: OFM vocabulary and workflow stack

This follow-up search was used to test the original vocabulary, not to turn SEO pages or job ads into market-size evidence.

Repeated category language — V, medium for vocabulary; low for prevalence

Four separate OFM-facing vendors/guides converge on the same operating primitives: creator-specific voice training, simulated or trial conversations before live access, PPV and fan segmentation, shift handoff, manager supervision, weekly QA, and retraining when a chatter misses the bar (Bunny Chatting ↗, OFC Agency ↗, OnlyFans Course scorecard ↗, OFMODEL ↗). This raises confidence that “creator voice,” “live-fire dummy fans,” “trial shift,” “shift handoff,” “QA scorecard,” “retrain,” “fan segmentation,” and “retention” are useful search and interview terms. It does not establish that any advertised response time, revenue lift, applicant-selection rate, pay range, or “industry standard” is true.

CreatorHub’s July 2026 operating guide adds a useful decomposition: agency-wide SOPs versus per-creator playbooks, with triggers, if/then branches, escalation rules, and a checkable done state. It describes the handoff as carrying live conversations, promises made, content/offer context, and the next move (CreatorHub ↗). This is a vendor guide, but it independently sharpens the record fields that the earlier OFM sources implied.

Direct community/recruitment signals — A, useful language not prevalence

• A current r/OnlyFansChatter recruitment post uses “unlock ratio,” strong English, typing/sales skill, timezone, and availability as screening language (community post ↗).
• A JobPH hiring thread describes full-time coverage, written English, scripts, natural tone, confidentiality, independent work, and applicants spanning Kenya/East Africa, the Philippines, and other time zones; one poster also frames multi-agency side work and NDA risk as a margin problem (community hiring thread ↗). These are self-selected recruitment anecdotes, not evidence that every agency has the same staffing or compensation model.
• The adjacent r/Notion and r/agency discussions independently describe Trello/Sheets/Docs/Airtable or Google Sheets/Drive/Slack combinations, then complain about scattered context, client visibility, state/ownership, and version drift (Notion setup ↗, agency content workflow ↗). This corroborates the shape of the workaround, not OFM-specific prevalence.

Adjacent training benchmark — D, high for the control loop; not OFM-specific

X’s published DSA transparency report documents a mature operator-training loop: learner-needs analysis with QA, scenario-based learning, shadowing, guided casework, knowledge checks, nesting, same-day coaching on mis-actions, refresher training, and a continuous QA/training feedback loop (X DSA transparency report, pp. 8–10 ↗). This is content moderation rather than fan sales. The safe inference is the control loop—diagnose → practice → observe → audit → coach → refresh—not that HALO should copy X’s policy or workforce design.

X search result and negative finding

The additional site-filtered X search surfaced one creator-operations anecdote in which a builder claimed to replace Notion, Google Sheets, and email with a partner portal for calendars, approvals, and uploads (X post ↗). It is a single product-adjacent post, so it remains A, not corroboration. Other results were agency promotional profiles or unrelated creator-economy posts; no independent X thread was strong enough to support a new market claim. This is itself a coverage receipt: public X discovery is currently better for category vocabulary and vendor positioning than for verified OFM operator complaints.

Ranked vocabulary expansion after follow-up

1. Training: “live-fire dummy fans”; “synthetic whale/churner/complaint”; “creator-specific voice training”; “voice doc”; “trial shift”; “nesting period”; “shadowing”; “guided casework”; “knowledge check”; “retrain or replace.”
2. Quality: “QA scorecard”; “weekly conversation sample”; “calibration”; “mis-action”; “same-day coaching”; “PIP”; “response-time consistency”; “unlock ratio”; “PPV conversion”; “renewal contribution”; “persona compliance.”
3. Handoffs: “open thread”; “mid-pitch”; “promise made”; “custom quote”; “VIP touchpoint”; “next move”; “shift report”; “incoming chatter”; “follow-the-sun coverage.”
4. Workforce risk: “timezone coverage”; “full-time chatter”; “written English”; “script adherence”; “NDA/confidentiality”; “side-agency risk”; “least privilege”; “revoke access”; “paid trial shift.”
5. Stack/workaround: “creator playbook versus agency SOP”; “fan segmentation”; “conversation context”; “Notion + Sheets + Drive + Slack”; “single source of truth”; “state/ownership/client visibility”; “version drift.”

Source additions and confidence receipt

• V14, V: Bunny Chatting training ↗, OFC Agency ↗, OnlyFans Course ↗, OFMODEL ↗, and CreatorHub ↗ converge on training, QA, voice, segmentation, and handoff language; claims remain vendor/guide claims.
• S22–S24, A/C adjacent: r/OnlyFansChatter recruitment ↗, JobPH chatter hiring ↗, r/Notion stack consolidation ↗, and r/agency content workflow ↗ add operator vocabulary and adjacent stack corroboration; they do not establish prevalence.
• D14, adjacent control-loop evidence: X DSA transparency report ↗, pp. 8–10, supports scenario practice, nesting, QA, and coaching as a mature operations pattern, not as an OFM product recommendation.
• A02, anecdote: X creator-operations post ↗ claims a Notion/Sheets/email replacement; no independent confirmation found.

Updated AGENT_PACKET v1

TO: KELLMAN-SOL FROM: KELLMAN-SIGNAL THREAD: HALO workflow-first sourcing OBJ: Deliver an evidence-first operator vocabulary and multi-persona workflow map for HALO sourcing. STATE: done MODE: GPT-5.6 Luna; community/X/operator research; no repo writes outside permitted report. ANCHORS:

• A1: research/sourcing-campaign/BRIEF.md
• A2: research/sourcing-campaign/operator-signals.md
• A3: research/COMPETITOR-SYNTHESIS.md
• A4: research/lanes/05-vertical-gaps.md

FACTS:

• F1: Approval pain is fragmented feedback, version drift, unclear approver, and missing audit evidence.
• F2: Meeting capture does not equal follow-through; decisions, promises, open questions, and tasks need promotion.
• F3: Deliverable and payment states differ; partials and disputes break one-sheet tracking.
• F4: Operators keep WhatsApp/email/Slack for convenience but want actionable messages represented as requests, assets/versions, or approvals.
• F5: Owners/admins need exception-first visibility; managers translate context into work; chatters need narrow queues and handoffs; creators/models need bounded external portal flows.
• F6: Shared modules require persona-specific projections, object-level permissions, provenance, and audit.
• F7: AFFiNE is active/non-archived with NOASSERTION aggregate licensing and package boundaries; study/bounded integration only.

DECISIONS:

• D1: Recommend workflow-memory/control-plane primitives before broader inbox scope.
• D2: Keep need separate from solution; messaging remains a product decision.
• D3: Mark anecdotes, vendor claims, and corroborated patterns separately.
• D4: Search complete multi-role shells and shared-module platforms as well as components.

CONSTRAINTS:

• C1: No writes to repo/, no push/PR/issue/deploy, no Convex mutation.
• C2: Only this report file was written.
• C3: No GitHub repository cited without gh api verification; only AFFiNE cited and verified.

TODO:

• T1: Use ranked vocabulary in downstream product/repository searches.
• T2: Evaluate team chat separately from external portals and CRM boundaries.
• T3: Validate clusters with direct operator interviews or more independent samples before market-size claims.

VERIFY:

• V1: Report exists at research/sourcing-campaign/operator-signals.md.
• V2: gh api repos/toeverything/AFFiNE captured required metadata.
• V3: Source ledger separates community, vendor/product, and direct repository evidence.
• V4: Persona matrix covers owner/admin, managers, chatters, creators/models, external partners, and specialists across CRM, chat, portals, AI, and shared modules.

OPEN:

• O1: None blocking; specific build/integrate/reject choices remain product decisions.

Updated AGENT_PACKET v1 — OFM deep dive

TO: KELLMAN-SOL FROM: KELLMAN-SIGNAL THREAD: HALO workflow-first sourcing / OFM buyer deep dive OBJ: Map the actual OnlyFans management agency operating model, personas, tools, unmet workflows, and product vocabulary for HALO. STATE: done MODE: GPT-5.6 Luna; six parallel research lanes converged; evidence-first community, investigative, official, and vendor sources. ANCHORS:

• A1: research/sourcing-campaign/BRIEF.md
• A2: research/sourcing-campaign/operator-signals.md
• A3: research/COMPETITOR-SYNTHESIS.md
• A4: research/lanes/05-vertical-gaps.md

FACTS:

• F1: OFM is a creator/content operation plus a 24/7 shift-based fan sales and retention operation.
• F2: The agency buyer purchases operational leverage, continuity, creator trust, and money/access control—not only an inbox.
• F3: Chatters need narrow, fast context: active thread, last message, offer/outcome, promise, next action, VIP/whale status, and creator playbook boundaries.
• F4: Managers translate creator/fan/chat context into shifts, QA, content, customs, reports, reconciliations, and escalations.
• F5: Creators/models need creator-controlled boundaries, statements, content approval, account/access visibility, and clean offboarding.
• F6: Custom content is a fulfillment queue separate from ordinary DMs; content, money, and access require separate state machines.
• F7: Discord/Slack/Telegram/WhatsApp are real-time coordination layers; Notion/Airtable/Sheets/Drive are durable-but-fragmented workarounds.
• F8: The strongest HALO wedge is an OFM back-office/control plane adjacent to the native inbox and fan-layer tools.
• F9: Access, consent, impersonation, chargebacks, platform restrictions, and creator trust are material controls; do not treat AI autonomy or scraping as default solutions.

DECISIONS:

• D1: Recommend workflow-memory/control-plane primitives before broader inbox scope.
• D2: Keep operator need separate from product solution; messaging remains a product decision.
• D3: Mark anecdotes, vendor claims, investigative allegations, official platform claims, and corroborated patterns separately.
• D4: Evaluate HALO primarily as the OFM agency back-office and control plane.

CONSTRAINTS:

• C1: No writes to repo/, no push/PR/issue/deploy, no Convex mutation.
• C2: Only this report file was written.
• C3: No GitHub repository cited without gh api verification; only AFFiNE cited and verified.

TODO:

• T1: Use the OFM-specific vocabulary in downstream product/repository searches.
• T2: Model shift handoff, custom fulfillment, creator statements, QA, access grants, and offboarding as first-class workflows.
• T3: Evaluate team chat separately from creator portals, native fan inboxes, and the CRM/control plane.
• T4: Validate split/margin/staffing assumptions with direct OFM owner and creator interviews before productizing.

VERIFY:

• V1: Report exists at research/sourcing-campaign/operator-signals.md.
• V2: Six Luna lanes returned compact evidence-backed reports and were closed after convergence.
• V3: Source ledger and OFM evidence notes distinguish source types and confidence.
• V4: AFFiNE metadata was verified with gh api and license boundaries were recorded.
• V5: Persona matrix covers owner/admin, manager, chatter, creator/model, external partner, and specialist staff.

OPEN:

• O1: None blocking this lane; exact build/buy/integrate choices and legal policy remain product decisions.

Updated AGENT_PACKET v1 — follow-up validation

TO: KELLMAN-SOL FROM: KELLMAN-SIGNAL THREAD: HALO workflow-first sourcing / OFM operator-signal validation OBJ: Continue the original operator/community lane with additional independent vocabulary and stack checks. STATE: done MODE: GPT-5.6 Luna; built-in web fallback after Perplexity wrapper lacked OPENROUTER_API_KEY; vendor, community, X, and adjacent operator evidence separated. FACTS:

• F1: Four OFM-facing vendor/guide pages repeat creator-specific voice training, simulated/trial conversations, fan segmentation, shift handoff, manager oversight, weekly QA, and retraining language.
• F2: OFM recruitment/community posts add “unlock ratio,” timezone coverage, written English, script adherence, confidentiality/NDA, independent work, and side-agency risk vocabulary.
• F3: Adjacent agency operators still describe Notion/Sheets/Drive/Slack/Airtable fragmentation, version drift, weak state/ownership visibility, and the desire to link client or creator context to work.
• F4: X’s published content-moderation operations document supports a general training control loop of learner diagnosis, scenario practice, nesting/shadowing, QA, same-day coaching, and refreshers; it is not OFM evidence.
• F5: The additional site-filtered X search produced one product-adjacent consolidation anecdote and mostly promotional/unrelated results; it did not provide independent OFM operator corroboration.

DECISIONS:

• D1: Add “live-fire dummy fans,” “trial shift,” “creator-specific voice,” “nesting,” “same-day coaching,” “unlock ratio,” and “side-agency risk” to downstream search/interview vocabulary.
• D2: Treat the repeated OFM training cluster as category language, not prevalence or benchmark proof; keep all vendor metrics untrusted until independently verified.
• D3: Preserve the original conclusion that chat is coordination and that durable records must capture handoffs, promises, approvals, and ownership.

CONSTRAINTS:

• C1: No writes to repo/, no push/PR/issue/deploy, no Convex mutation.
• C2: Only research/sourcing-campaign/operator-signals.md was edited in this continuation.
• C3: No new GitHub repositories were cited; the existing AFFiNE verification remains the only repository citation.

VERIFY:

• V1: Report formatting check passes with git diff --no-index --check /dev/null research/sourcing-campaign/operator-signals.md.
• V2: Follow-up source additions are recorded with direct URLs and explicit V/A/D labels.
• V3: Existing OFM report, persona map, stack boundaries, confidence notes, and prior packet remain intact.

OPEN:

• O1: Direct interviews with OFM owners, managers, chatters, and creators are still needed before treating staffing, pay, conversion, or QA percentages as benchmarks.