新批准的联盟客迟迟不激活、不发点击时…

为刚通过审核的联盟客（B2B SaaS 或 B2C 电商）设计一套从批准到首次可追踪转化的 onboarding 序列，解决「批准后从不发点击/不出单」的问题。

适用场景

解决思路

1. 先做访谈（Interview），每条消息只问一个问题，用户已答的跳过：1) B2B SaaS 还是 B2C 电商（两者都要则计划需分两条分支）；2) 什么事件算「激活」（首次点击/首次线索或试用/首次付费成交/首次成交关单），窗口是多少天；3) 项目机制：佣金模式（循环百分比、一次性百分比、固定 CPA）、cookie 窗口、提现门槛、提现冻结期；4) 实际招募到的联盟客类型：内容/测评站、优惠券折扣站、忠诚度返现、社交创作者、邮件列表主、子网络；B2B 则为代理机构、顾问、技术伙伴；5) 现有素材 vs 需新建：追踪链接、横幅、推广文案、产品单页；B2B 另加沙盒/演示权限、对比与买家问题材料；6) 追踪设置：批准时是否自动下发链接或优惠码？服务端（postback）转化追踪是否已上线？7) 税务与提现收集：需要哪些步骤（税表、提现方式、条款确认），是否作为提现资格门槛；8) 由谁发送触达：自动化项目地址还是具名联盟经理？是否有电话和 1:1 的产能；9) 每月新增批准量；10) 首次激活数据必须在什么日期前出来（若日期落在下一批窗口内，则删除所有需要开发构建的选项，优先近零成本修复；无日期则保留默认排序）；11) 本批是一次性成果还是可复利资产（复利→自动化 drip 和持久素材中心；一次性→对已批准联盟客做人工外联）；12) 投入上限：经理每周工时、是否有具名 AM、改佣金是否需要财务或法务签字（零 AM 工时直接删除高触达和混合层级，而不是降级）。问题 10-12 决定本技能所有菜单的排序。
2. 在动手设计前先固定「激活」定义及其衡量窗口——触达次数、催促截止日、所有 KPI 都依赖它；没有它计划无法评判。
3. 验证 day-0 就绪状态：批准时即下发链接/优惠码、追踪能记录激活事件、税务/提现收集已作为提现门槛接通（清单见 references/asset-kit-and-provisioning.md）。先停下修好缺口，再规划任何一次触达。
4. 对招募对象做两次分层：按类型（问题 4）和按触达层级。类型是查表不是排序：只路由实际存在的类型。层级是排序，决定经理工时投向哪里：效率（每经理工时买到的激活）self-serve > hybrid > high-touch；价值（每联盟客激活率）high-touch > hybrid > self-serve；经常性投入（每联盟客经理工时）high-touch > hybrid > self-serve；首次发送前的一次性构建 self-serve == hybrid > high-touch。self-serve 领先是因为建成后边际成本近零，而非转化最好（它转化最差）。把它作为所有人的地板，再为能回本的细分买更高激活。构建成本打平是真的：hybrid 就是 self-serve drip 加一个日历槽位，搭建耗时相同；high-touch 几乎不需构建，但会变成常设工作。高触达会被这个排序饿死：它同时居价值线和经常性投入线之首，比率每轮都埋没它，只算效率的项目最终会给最大伙伴和长尾发同样的自动化 drip。当单个伙伴的预期收入超过电话所耗工时，或名单小到 drip 的构建永远回不了本时，要显式提升高触达——绝不等它自己胜出。默认：全体 self-serve，对预期量能回本一次回访的类型叠加 hybrid。当没有具名 AM 或每月批准量超过约一百时，从菜单中删除高触达而非降级——没人能执行的层级是不存在，不是慢，停在底部会悄悄变成计划无法执行的范围。此排序是默认而非铁律，会随执行者变化：已有里程碑自动化的联盟平台把 self-serve 构建压到近零并扩大其领先；无产能的经理（问题 12）同时删除 hybrid 和 high-touch；十几个各值大单的伙伴名单会直接反转顺序，因为近零量使每联盟客工时很便宜而 self-serve 构建永不回本。层级细节见 references/touch-plan-patterns.md。
5. 按细分映射触达计划：日偏移骨架加行为触发层，模式见 references/touch-plan-patterns.md。每次触达只要求一个动作。
6. 把条款/披露确认放在批准触达中，税务/提现收集放在首次提现可能之前——绝不在首笔佣金赚到之后。此处只决定位置；条款起草属于条款技能。
7. 在第一个窗口内、意图最高峰时加入限时激活催促。此处决定其槽位、截止日和框架；其费率经济属于佣金技能。
8. 设计「从未激活」分支：窗口结束时的诊断检查点、再激活触达、最终通知邮件，然后归档。绝不用终止威胁作为杠杆——动机研究记录威胁适得其反。
9. 为每次触达起草文案——一个动作、一个 CTA、触达 1 的前几行放链接或优惠码——并设定退出、抑制和重新进入规则，使用 references/copy-and-sequence-logic.md。
10. 每封起草邮件都过一遍你偏好的 humanizer 技能；拒绝把模型初稿当最终文案。该遍只改语气——单动作结构和金钱机制保持原样。
11. 逐节与用户验证计划——激活定义、路由、触达计划、催促、从未激活分支、文案——在推进下一节前根据反馈修订。
12. 输出下方的 Sequence Plan 工件并设定 KPI 复盘节奏。若你的运行环境有持久记忆，记住激活定义和路由决策，以便后续诊断从它们开始。
13. 交付物必须是 Sequence Plan 工件（交付契约，非示例）：SEQUENCE PLAN - <program>, <date>；Activation：事件+窗口（如批准后 30 天内首次付费成交）；Routing：类型→层级（high-touch | self-serve | hybrid），量级说明；Touches：每次触达一个块，含 T<n> Trigger（日偏移或行为事件，行为覆盖日历）、Channel（email | call | in-portal | chat）、Sender（自动化项目地址 | 具名 AM）、Action（所要求的唯一动作）、Content（一行摘要）、Asset（附带或链接的素材）；Activation nudge：激励+截止日+由哪次触达承载；Never-activated：进入条件、触达、最终通知规则、归档规则；Exits：激活时 | 进入分支时 | 抑制+重新进入规则；KPIs：窗口激活率 | 首次转化时间 | 截止时从未激活占比 | 每次触达参与度。每条触达行都要带可审阅的理由——「T3 在 day-7 无点击时触发，因为日历无法区分卡住还是流失」可审阅；光秃秃的日号不行。两个完整示例（B2C 和 B2B 各一）见 references/sequence-plan-examples.md。
14. B2B SaaS 与 B2C 电商分歧处必须分支：首次转化（B2C 追踪销售 vs B2B 线索/试用/演示/关单，需固定是哪个）；时间跨度（B2C 数天到数周，30 天窗口合适 vs B2B 30-180 天，90 天窗口合适）；触达模式（B2C 几乎全自动 self-serve vs B2B 混合/高触达，战略伙伴有启动电话）；素材包（B2C 链接、优惠码、横幅、推广文案、产品 feed vs B2B 另加沙盒/演示、对比页、买家问题材料）；day-0 下发（B2C 链接+优惠码 vs B2B 另加交易登记和沙盒/NFR 权限）；提现风险（B2C 追回随退货窗口结束 vs B2B 追回伴随每张循环发票，冻结期更长）；序列跨度（B2C 10-14 天骨架后转触发 vs B2B 同骨架但触发层横跨 90 天窗口）。两者相同（明确写出以免隐含）：激活定义优先规则、下发前置条件、每次触达一个动作、onboarding 时税务/提现门槛、从未激活分支结构、humanizer 过稿、Sequence Plan 格式本身。
15. 多个失败模式同时存在时按此顺序修复（按每工时买到的激活）：link placement > welcome dump > approval-as-finish-line > threat framing > activation nudge > archetype routing == never-activated branch。平局有理由：路由和分支各约一周构建，但路由在当前窗口内回本，分支只对下一批回本——比率相同，时钟不同。失败模式与修复：追踪链接被埋或发送时尚未下发→触达 1 前几行放链接/优惠码，序列上线前验证下发（近零成本）；欢迎信大杂烩——全塞进第一封邮件、无单一动作→每次触达一个动作，其余移到后续触达或持久素材中心（一小时）；把批准当终点线→在触达 1 中设定具体激活计划和预期（一小时）；用终止威胁逼激活→换成机会框架的激励，动机研究发现威胁适得其反（近零，仅当存在威胁时）；无激活催促、无首窗口限时激励→首窗口内截止日绑定的奖金，由具名触达承载（一周——费率上线前需签字）；对所有类型和层级一刀切→起草前先按类型和层级路由（一周——每个现有类型一个主打素材）；从未激活无分支→窗口末诊断、再激活、最终通知、归档，提前设计（一周设计，之后常设工作）；税务/提现在首笔佣金后才收集→onboarding 时设提现资格门槛，未领取设置的佣金有文档记录的过期先例（一周加财务协调）。税务/提现那行故意不在上述排序内：它买到的是避免提现纠纷和降低法律风险，不是激活，不能按同一比率排序——按合规时钟修，在首笔佣金赚到前，无论激活工作如何。
16. 诊断已有序列时（用户带着运行中的项目来，如「我们的联盟客从不发点击」），按此顺序检查而非从头重设计。顺序按每单位投入买到的信息——不是最便宜优先，那会把转化追踪放最后，让你重设计一个本来有效的序列：每工时信息量 conversion trace > approval-email check > per-touch engagement > cohort split > nudge and branch audit > rewriting touch 1；投入 rewriting touch 1 > conversion trace == cohort split > approval-email check == per-touch engagement == nudge and branch audit。两个平局都是真的：追踪和队列拆分各约一小时查询与点击工作，后三项近零因为只读已有数据。检查表：1) 端到端追踪一次转化：点击→记录的转化→待处理佣金→撤销状态（一小时，一次）——判定报告的激活数是否真实，暗跳会让下面每行都在测量虚构；症状：平台内可见活动但激活报告低、点击被追踪但转化从不出现。2) 以新批准联盟客身份打开批准邮件：里面有没有可用链接或优惠码，批准时是否已下发（近零）——判定故障是前置条件还是序列本身；症状：已批准联盟客从不点击。3) 读平台已记录的每次触达打开和点击率（近零）——定位序列在哪里流失人，只定位不命名；症状：触达 1 后打开崩塌。4) 按类型和层级拆分激活（一小时）——判定是否把同一序列发给了需要不同首动作的类型；症状：一个类型激活，其余从不。5) 审计计划中窗口内是否有截止日绑定的催促、是否设计了从未激活分支（近零）——解释队列为何在截止日停滞，只解释窗口末停滞，不解释更早的；症状：队列在窗口关闭前停滞、长尾堆积未动。6) 重写触达 1 或素材包（一周）——在 1-5 跑完前什么都判定不了，它是改动不是检查，且会毁掉本可告诉你它有效的基线；症状：无——永远不是第一步。按眼前项目重排：已运行服务端追踪的项目已提前买到第 1 行的信息，从第 2 行开始；招募只有单一类型的项目直接删除第 4 行，而非排到最后。文案层与结构层的区分见 references/copy-and-sequence-logic.md。
17. KPI 与通过门槛：窗口激活率（序列主分数）、首次推荐/首次转化时间（按队列中位数追踪）、每月队列截止时从未激活占比、每次触达参与度（打开/点击）以定位流失点。按每月批准队列衡量：每月批准形成一个队列，仅在其窗口关闭时评判。混合的全时段比率会掩盖序列是否在改善。通过门槛分两部分，因为序列在任何激活数据存在前就已上线。设计时（输出工件前检查，逐条成立才迭代）：激活定义及窗口已固定（步骤 2）；day-0 下发已验证而非假设（步骤 3）；每次触达只要求一个动作；追踪链接或优惠码出现在触达 1 前几行；限时催促位于激活窗口内；从未激活分支以归档结束，无终止威胁；每封起草邮件都过了 humanizer。上线后（作为首次复盘门槛排期）：不要报告你算不出的结论。30 天激活率 B2C 达到约 18%（TrackRev 中位数，非其约 31% 的上四分位）；B2B 90 天达到约 20%。Track360 的「低于 30% 表示 onboarding 有问题」是调查的诊断触发，不是上线门槛；当作门槛会要求第一天就达到上四分位，高于本技能开头引用的整个 5-20% 区间。这些是供应商和从业者数字，非审计研究：是迭代阈值，绝不可当作事实引用。低于门槛时诊断序列（下发、首次触达、催促），而非招募。若项目尚无数据，在交付物中说明并设定测量日期；用户也可记录其经济性为何支持不同门槛。每个数字的可靠性框架见 references/benchmarks-and-frameworks.md——向用户引用任何基准前先读它。

适用边界 · 注意事项

• 尚未加入的联盟客（还在招募/推销阶段）不适用——那属于 affiliate-recruitment-outreach 技能，本技能从批准开始。
• 没有具名 AM 或每月批准量超过约一百时，不要设计高触达层级——没人能执行的层级是不存在，不是慢。
• 在跑完诊断检查 1-5 之前不要重写触达 1 或素材包——那是改动不是检查，会毁掉本可证明其有效的基线。