开发分销小程序，先把关系绑定和订单归因设计好

「佣金能不能做到三级？」这是上个月一个做食品批发的客户咨询分销小程序开发时的**句话。我们没急着回答，先问了他另一件事，客人从点进小程序到付完款，这条链路上谁算上级，你打算用什么方式记下来。他愣了几秒，说这个还真没想过。

这个反应很常见。分销小程序开发的难点通常落在关系链上，页面和商品反而是快的，谁邀请的，关系存多久，一单算给谁，这三个问题不先定，佣金就是一笔糊涂账。这篇把关系绑定和订单归因两块拆开讲清楚。

一、关系绑定常见的三种做法

做分销小程序定制开发时，先想清楚你的客人从哪里来，再决定以哪种绑法为主，另外两种做兼容，三条通道一起上反而增加排查成本。

二、深圳做批发的客源，常见这三种来路

深圳做批发和零售的客户，客源结构差别很大。线下门店型，客人进店扫码，参数二维码最直接，海报贴在收银台，店员引导一句就能完成绑定。线上社群型，客人多从微信群和朋友圈进来，分享海报是主通道，邀请码做兜底。老客转介绍型，客人习惯直接搜小程序或者从历史聊天记录里进，这种来源很难带上邀请参数，要靠下单后的补绑机制补救。

表里有效期一栏写得含糊，是因为这个天数本来就不该一刀切，下一节单独说。

三、绑定之后，关系存多久

归因窗口常见的是设七天或者十五天，也有项目图省事直接设**。七天适合快消类，客人在这个周期内的复购和转介绍都还热乎；十五天是多数项目的默认值；**绑定听着省事，代价是客源归属越积越乱，两年前离职业务员拉来的客人，订单还在给他算佣金，这种账没人对得清。我们的建议是绑定关系本身长期存，佣金归因窗口按十五天设，到期后订单归平台，关系不断，钱停了。

还有个绕不开的细节，换设备。客人在微信里点开链接用的是 A 手机，下单时换了 B 手机，绑定关系照样成立，因为关系记录在小程序账号上，跟设备无关。但如果客人换了个微信号下单，那就是两个账号，重新绑。这类边界要在需求里写明，上线之后再改，动的是订单和佣金两张表。

四、一单算给谁：归因冲突怎么处理

一个客人三天里被两个分销员先后触达，订单算谁的。行业里通行的是末次有效触达优先，最后一位带参数进来的分销员拿这一单。也有项目按**绑定算，好处是分销员之间不抢单，坏处是后来者没动力跟进。两种规则实现成本没有差别，差别在分销团队的心态，这个选择要业务负责人拍板，技术方替你决定不了。

直播和群接龙这类场景还要再加一层判断。客人先点了 A 的直播间链接，又在群里点了 B 的接龙卡片，最后下的单，按末次触达算给 B，A 会觉得白播了。遇到这种冲突，有的项目给直播渠道单独设权重，有的干脆把直播流量排除在分销归因之外，规则没有对错，提前写清楚就行。

五、二级分销小程序开发的两个易错点

层级超过一级，计算就开始变复杂。**个易错点是逐级展开，一单佣金要按上级、上上级分别算比例，比例表配错一位，整月结算全部作废重发。第二个易错点是层级断档，中间某一级的分销员被禁用或者退出之后，他的下级业绩算给谁，跳过还是冻结，要在设计阶段就定死。做二级分销小程序开发的项目，这两个点建议各写一条测试用例，上线前跑一遍。

六、退款了，佣金怎么回冲

订单退款是分销体系里最容易漏设计的分支，结算出纠纷多半出在这里。把状态链定清楚，比上线后人工调账省得多：

• 订单确认收货前退款，对应佣金直接作废，不进入结算池；
• 确认收货后退款，已结算的佣金从下期结算里冲减；
• 仅退款和退货退款分开记，退货的还要处理库存回补。

七、每月结算前，先对三张表

小程序分销开发做多了会发现，结算出问题多数不在算错，在数据对不上。每月出提现单之前，下面三样东西要能对齐：

• 订单表里当期确认收货的订单数；
• 佣金计算明细的合计金额；
• 上期遗留的冲减项和补发项。

三个数字对不上就先停，查清楚是哪个环节漏了状态回写，再往下走。

分销小程序开发制作的工期，多数落在四周到六周，其中关系链和佣金这两块要占去一半，页面反而是快的。之前写过一篇，讲的是层数怎么定，和这篇正好互补。商品侧的全链路设计，可以看。

八、先把规则写进需求，再谈开发

把这篇里的几个问题抄下来，写成一页文档，拿去和开发方谈，报价单上的水分立刻少一半：

• 绑法以哪种为主，另外两种要不要做兼容；
• 归因窗口设几天，到期后订单归谁；
• 归因冲突按末次还是**，直播流量算不算在内；
• 退款佣金按哪条链路回冲。

这页文档比任何口头承诺都管用。如需进一步沟通，可直接致电 13928418795。