What would it take to switch from Customer.io to Workflows? #213

Activity

1. Silthus

   added

   wayfinder:research

   on Oct 3, 2026
2. Silthus

   added a parent issue on Oct 3, 2026

   • Map: grow Workflows activation, from first visit to first delivered message #210
3. Silthus

   marked this as blocking on Oct 3, 2026

   • Rank the growth bets and choose which get their own map #219
4. Silthus

   self-assigned this

   on Oct 3, 2026
5. Silthus commented on Oct 3, 2026

   

   Silthus

   on Oct 3, 2026

   OwnerAuthor

   More actions

   Claimed by a Claude Code research worker (Opus 5.5)
6. Silthus

   removed their assignment

   on Oct 3, 2026
7. Silthus commented on Oct 3, 2026

   

   Silthus

   on Oct 3, 2026

   OwnerAuthor

   More actions

   Lane orphaned: the worker's temporary worktree was removed while its sub-agents ran. Unassigned; the conductor redispatches it in a persistent worktree.
8. Silthus

   self-assigned this

   on Oct 3, 2026
9. Silthus commented on Oct 3, 2026

   

   Silthus

   on Oct 3, 2026

   OwnerAuthor

   More actions

   Claimed by a Claude Code research worker (Opus 5.5), redispatch
10. Silthus commented on Oct 3, 2026

    

    Silthus

    on Oct 3, 2026

    OwnerAuthor

    More actions

    Resolved. Findings: https://github.com/Silthus/posthog/blob/research/customerio-switching/research-customerio-switching.md

    Short answer. A Customer.io team can switch today, but almost all of it is manual. PostHog already imports and syncs opt-out state both ways (topics, per-topic preferences, global unsubscribes, inbound webhook, outbound Track sync), so a parallel run is safe for preferences. It imports nothing that sends.

    Import matrix (gist).

    • Imported today: subscription topics, topic preferences (CSV), global unsubscribes, live preference sync in both directions.
    • Exportable from Customer.io's public App API but not imported: message bodies and subjects (automations, broadcasts, newsletters, transactional), snippets, ESP suppressions (bounces, blocks, spam, invalid), segment definitions, sender identities, people exports.
    • Not exportable at all: the shape of an automation. The actions endpoint returns content actions only, "not delays or flow control blocks like t/f branches". So no tool can import workflows 1:1. They get rebuilt.
    • People: warehouse person-property sync and cohort CSV only match existing persons. Teams already on PostHog mostly have them; others send $identify.
    • Liquid: customer.* and event.* rewrite to person.properties.* and event.properties.*, the unsubscribe tag maps to unsubscribe_url, snippets must be inlined, and a handful of Customer.io tags and filters have no equivalent and need flagging.
    • Triggers: event and webhook map directly. Segment entry has no trigger (What would it take to let behavior drive Workflows? #215), date and form are workable but not 1:1.

    Smallest switching path worth a map: "Customer.io import v2", built into the existing four-step modal:

    1. Import message content as Liquid templates (HTML wraps into the editor already), with variables rewritten and snippets inlined.
    2. Bulk-import ESP suppressions to protect the new domain from day one.
    3. Turn sender identities into a domain verification checklist.
    4. An agent skill that drafts each automation as a draft workflow from its trigger and its ordered messages, through the MCP tools that already exist. A person adds the delays and branches and turns it on.

    Step 4 needs no new backend and could ship first as a skill, to learn what switchers need before building steps 1 to 3 (a guess at the order). Depends on #214 (caps), #215 (segment entry), #216 (transactional callers) and #225 (domain verification).

    Compliance note on the global-unsubscribe import: ask Michael.
11. Silthus

    closed this as completedon Oct 3, 2026