有机云｜裂变任务上线前先过四道闸：奖励、有效、防刷、兑奖

裂变任务能不能上线，先看四件事有没有写死：奖励怎么给、什么邀请算有效、哪些行为要防刷、兑奖由谁在什么时间完成。四道闸缺一项，活动开始后再补规则，前面已经产生的邀请记录就要重新解释，参与者也容易对结果产生争议。

在有机云里，客户裂变和群裂变都能配置多阶任务。工具负责记录邀请与完成情况，活动规则仍要由团队在上线前写清。下面按奖励、有效、防刷、兑奖的顺序展开，每一步都给后台配置与验收动作。

先过奖励闸：阶数和奖品先写死

阶数越多不等于活动越有效

多阶任务适合把一次邀请拆成几个可完成的小目标，但阶数一多，参与者先要理解规则，再决定做不做。阶数与奖励在上线前定死，活动期间只按既有版本执行。

运营在【引流拓客】→【客户裂变／群裂变】新建任务时，先写清每一阶的完成条件和对应奖励。阶与阶之间要能看出递进关系，例如邀请人数增加后奖励升级，不要让两阶只差一个很小的动作。

奖励名称要具体到参与者能理解的程度。写「礼品一份」不如写清是什么、何时发、找谁领。奖励描述含糊，兑奖阶段就会反复解释，前面拉来的人也会怀疑活动规则。

每阶只留一个完成条件

一阶任务同时要求邀请人数、连续登录和填写资料，参与者很难判断自己卡在哪一步。每阶只留一个主要完成条件，其他动作放到活动说明里，任务记录才容易核对。

有机云的客户裂变与群裂变都按多阶任务组织，运营配置时先逐阶检查完成条件与奖励是否一一对应。某个阶段的条件无法在后台记录，就不要把它写进奖励规则。

四道闸在上线前要逐项签字

四道闸要落在同一张能逐项打勾的验收表里。每项都要写明负责人、验收动作和不通过时怎么处理。

闸门	上线前要写清	后台核对什么	不通过的信号
奖励	阶数、每阶条件、奖品与发放时间	每阶条件是否都有对应记录	参与者说不清做到哪一步
有效	哪些邀请计入、哪些不计入	邀请与完成统计能否分开看	邀请数上涨，完成数不动
防刷	老客户是否计入、异常邀请怎么处理	任务是否有明确计入范围	同一批人被反复计入
兑奖	谁核对、何时发、争议找谁	完成名单能否导出核对	活动结束才开始找人兑奖

这张表要在活动上线前完成，而不是等出现争议再补。任何一项写不出来，先把活动状态留在待开启。

再过有效闸：什么邀请才算数

有效邀请要同时满足三个条件

一次邀请至少要看三件事：新客户从活动入口进入、完成了任务要求的动作、没有被其他记录重复计入。只看邀请人数，会把点开链接、进群后又退出的人一起算进来。

客户裂变与群裂变的任务对象不同，有效标准也要分别写。客户裂变看好友关系是否建立，群裂变看客户是否进入正确群聊。两类活动混用一套有效标准，统计结果一定解释不清。

运营在后台查看实时统计时，要把累计邀请数与完成任务数放在一起看。邀请数持续上涨、完成数长期不动，通常说明参与者在某个动作上被卡住，或者规则没有被理解。

老客户是否计入要提前写明

老客户帮转介绍很常见，但老客户再次参与、重复邀请同一个人，是否计入任务，必须在活动说明与后台配置里保持一致。

如果活动只面向新客户，配置时就要明确老客户是否计入；如果老客户也能参与，则要单独写清他的邀请怎样算有效。不要在活动进行中按个案解释，否则同一类行为会出现两种结果。

名单口径要能回到客户记录

有效邀请最终要落到客户记录上，不能只停留在活动页面的数字。客户进入后有没有带上来源标签、能不能进入后续人群包，决定这次活动能不能被复盘。

有机云的自动打标签可以按参加活动触发，运营先为活动配置独立标签，再用测试客户走一遍邀请、进群、打标和统计。标签没有落下，说明活动记录与客户档案还没有接上。

第三闸是防刷：先把异常范围定小

防刷先防重复计入，不必一开始就复杂

活动刚上线时，最常见的问题是重复记录。同一个客户换入口再次进入、同一邀请被两个任务同时统计，都会让奖励口径失真。

团队先明确哪些行为不计入：同一个人重复进入、没有完成指定动作、从非活动入口进入。规则写清后，再决定哪些异常需要人工核查。没有基础口径，直接上复杂判断只会增加争议。

异常名单要有人复核

后台发现异常邀请时，不要直接删除记录。先保留原始邀请时间、入口与客户标识，再由活动负责人按规则判断是否计入。

复核结果要能回到任务记录，写清维持计入、取消计入或转人工处理。只把异常名单发在群里，下一次换人值班仍要重新判断。

测试账号要故意走错路径

只测顺利路径，防刷规则并没有被验证。上线前至少准备正确邀请、重复进入、错误入口三种测试样本，逐条检查后台统计。

测试完成后，把预期结果与实际结果写在同一张验收表里。结果不一致时先改规则或配置，不要带着已知问题开放活动。

第四闸是兑奖：活动前就定谁来做

兑奖路径要写到参与者也看得懂

兑奖不能等到活动结束才安排。参与者完成任务后，要知道去哪里看进度、什么时候能领、需要提供什么信息。说明写得越具体，活动后期的问答越少。

运营在活动欢迎语和玩法说明里写清兑奖步骤，再把同一版本交给负责回复的成员。活动期间不要一边改规则一边解释，参与者看到的版本必须一致。

完成名单和邀请名单要分开核对

邀请名单说明谁带来了人，完成名单说明谁达到了奖励条件。两张名单混在一起，兑奖时就会把只完成部分动作的人算进来。

活动结束后先导出完成名单，再按每一阶条件复核。异常记录回到原始邀请时间与客户标识核对，确认后再进入发放环节。

争议处理要有固定入口

参与者对结果有疑问时，需要有一个明确的人接收，并能在活动记录里查到原因。只在群里临时回复，过几天就找不到上下文。

团队可以指定一名活动负责人统一接收争议，把客户标识、任务记录和复核结论放在一起。处理规则沿用上线前版本，不为单个案例临时改口径。

上线前用测试账号走完一遍

每个阶段至少走一次

验收时不要只看后台能不能保存任务。用测试账号从活动入口进入，完成第一阶，再完成一阶升级，最后走到兑奖环节，确认每一步都有记录。

有机云的客户裂变与群裂变会显示累计邀请数、完成任务数与活动天数。测试时把这三个数字与实际操作对照，出现偏差先查入口、任务状态和计入规则。

任务状态要按上线节奏切换

任务状态包括启用中、待开启、已结束与仓库中。规则没验收完先留在待开启，测试确认后再切换；活动结束后及时结束任务，避免后续邀请继续进入旧规则。

运营要把状态切换写进活动排期，明确谁在什么时间操作。临时口头通知容易漏，状态没有切换会让活动边界变得模糊。

小范围试跑比直接全量开放稳

先在少量客户或一个群试跑，能更快发现入口、统计和兑奖说明的问题。试跑阶段只验证流程是否走通，不急着扩大邀请范围。

试跑完成后，把发现的问题逐项修掉，再用同一套测试样本复测。没有复测就直接全量开放，等于把未验证的规则交给所有参与者。

活动结束后怎么复盘

先看完成，不只看邀请

复盘先回答三件事：有多少邀请进入、有多少完成指定动作、有多少达到兑奖条件。三个数字能帮助团队判断问题出在活动入口、规则理解还是奖励吸引力。

来源报告可以核对活动入口带来的客户数量与后续留存，客户标签与人群包则帮助找到参与过活动的人。复盘不只看活动当天的热闹，还要看客户后来有没有继续被服务。

规则变更要留下版本

活动期间确需调整规则时，先写清变更内容、生效时间与影响范围，再同步活动说明和回复成员。没有版本记录，前后数据无法比较。

下一次做同类活动时，沿用上一版的验收表，只改本次的阶数、奖励和有效标准。每次都从空白开始，前面踩过的问题还会重复。

这些情况先别上线

奖励还说不清，先别开任务

每阶奖励是什么、何时发、找谁领都说不清时，先不要开放活动。参与者完成任务后得不到明确答复，前面的邀请也很难继续。

没人负责兑奖，先别放量

兑奖需要核对完成名单、处理异常与回答争议。没有固定负责人时，先缩小活动范围或延后上线，不要把兑奖留成活动结束后的临时任务。

有效标准还在讨论，先别统计

团队对什么邀请算有效还没有一致口径时，后台统计出来的数字只会放大分歧。先把规则写成一句话，再让所有人按同一版本验收。

常见问题

Q1：任务宝工具哪个好，先看什么？

A：先看它能不能把多阶任务、邀请统计、完成统计和任务状态记录清楚，再看团队有没有四道闸的验收规则。工具能记录过程，规则仍要由团队定。

Q2：老客户参与裂变，邀请算不算有效？

A：由活动规则决定，但必须在上线前写清，并在后台计入范围里保持一致。活动开始后再按个案判断，参与者很难信服。

Q3：邀请数上涨、完成数不动，先查什么？

A：先查任务条件是否说得清，再查参与者卡在哪个动作。也要核对入口与计入范围，排除重复记录造成的虚增。

Q4：防刷规则是不是越复杂越好？

A：先处理重复计入和错误入口，再按实际异常增加判断。基础口径没定好就上复杂规则，复核成本会更高。

Q5：在有机云里怎么验收一场裂变活动？

A：在客户裂变或群裂变里配置多阶任务，用测试账号走完邀请、完成、升级和兑奖，再核对累计邀请数、完成任务数与客户标签。四道闸都通过后再切换任务状态。