南京商城分销小程序，客户扫了两个推广码算谁的？

客户先后扫了两个人的推广码，订单算给谁，要按商城事先确定的推荐关系规则判断：采用首次有效绑定，通常保留先绑定的人；采用最近一次有效推荐，则按有效期内最后满足条件的推荐记录判断。还要检查原有绑定、关系保护期和订单归属确认节点。后扫一个码，不应在规则未允许的情况下直接覆盖已有关系，更不应自动改写已经确认的订单归属。

先把一次扫码与一笔订单分开看

用一个假设过程更容易说明问题：一位新客户周一扫了推广员甲的码，浏览商品后离开；周三又扫了推广员乙的码，仍然没有购买；周五从小程序使用记录中重新进入，提交了一笔订单。甲认为自己最先介绍了商城，乙认为自己促成了客户再次了解商品。如果企业只在需求里写“支持分销”，却没有确定如何判断有效推荐，开发人员就只能根据自己的理解处理。页面上虽然显示出了一个推荐人，企业仍然无法解释为什么应当算给这个人。

这里至少存在三种需要分别保存的信息：客户这次从哪里进入、客户当前与谁建立了有效推荐关系，以及这一笔订单按什么依据确认推荐人。周三的来源记录可以是乙，当前有效关系却可能仍然是甲；周五即使没有新的推广来源，也可以按已经生效的关系判断订单。来源发生变化、绑定关系发生变化和订单归属发生变化，应当分别设定条件。如果后台只保留一个不断被覆盖的推荐人字段，后续出现争议时，就难以还原当时的判断过程。

企业选择规则时，需要先说明准备奖励哪一种实际贡献。如果主要希望鼓励首次带来新客户，可以优先讨论首次有效绑定；如果活动更关注当次订单由谁促成，可以讨论订单确认前最近一次有效推荐；如果希望推广人员在一定时间内持续跟进客户，则需要进一步设置关系保护期。几种设计各自对应不同的运营目标，不能简单认定某一种对所有商城都更合适。尤其要避免运营人员口头承诺“客户一直算你的”，系统却在客户下一次扫码时自动更换推荐人。

仍以上面的甲、乙两次推荐为例，假设客户此前没有绑定关系，两人的推广资格和推荐记录均有效，可以比较以下几种设计方向。表中的结果只用于说明规则差异，具体项目还需要把“有效”的条件和适用范围补充完整。

“首次有效”还要进一步解释。首次打开页面、首次建立会员身份、首次提交订单，都可以成为讨论中的业务节点，但它们对应的结果并不一样。客户周一扫码却没有完成企业规定的绑定动作，周三通过另一个入口完成了该动作，谁先“有效”就不能只按扫码时间判断。需求文件应写清触发动作、适用客户和完成条件，推广人员看到的规则说明也应与系统一致。只写“先到先得”或“最后一次为准”，仍然会留下大量需要人工解释的空间。

同样扫了两个码，哪些条件会改变归属结果？

首先要检查客户是否已有有效关系。一个已经由甲持续服务的老客户，扫了乙分享的商品码，可能只是想查看商品详情。企业可以规定保护期内保留原关系，同时记录本次访问来源；也可以在符合明确条件时允许客户更换推荐人。两种安排都需要事先说明。还应区分负责日常服务的人员和参与订单奖励的推广人员：客服、门店员工、销售与推广员未必承担相同职责，调整服务负责人是否影响推广关系，应当单独确认，不能默认所有人员字段一起变化。

其次是有效时间怎样计算。假设企业决定设置一段推荐有效期，就需要说清从哪一次动作开始计时，客户反复扫码是否重新计时，以及到期后通过普通入口下单怎样处理。保护期与推荐有效期也可能承担不同作用：前者限制关系被替换，后者限制某次推荐还能否参与订单判断。如果同时采用这两类规则，应写明判断顺序。例如先检查已有关系是否受保护，再判断新推荐是否满足变更条件。否则，即使后台都有对应开关，运营人员仍可能无法预测最终结果。

再往下是同一客户如何识别。客户浏览时尚未建立可确认的会员身份，系统获得的访问信息与后续登录后的会员记录，需要按项目确定的账号机制关联。对已有会员，应先检查历史有效关系，再处理新的来源信息，避免登录之后被误当作一个没有记录的新客户。企业讨论这个问题时，重点是账号与会员记录如何对应，而不必要求用户额外填写大量资料。头像相同、昵称相似，都不应成为直接合并客户记录或转移推荐关系的依据。

订单在哪一步确认推荐人，同样会改变结果。客户先通过甲的入口提交订单，在付款前又扫了乙的码，如果项目规定提交订单时确定归属，这笔订单就应保留当时的判断；如果规定付款时确定，则必须进一步说明付款前是否接受新的推荐，以及新推荐影响哪些待付款订单。这两种方案都需要在实际业务中评估。这里确定的是这笔订单按谁的推荐关系处理，至于何时具备结算条件，还应按另外确认的订单与售后规则执行。

已经确认归属的订单，应保存当时采用的规则和判断结果。客户以后更换推荐人，或者企业为下一轮活动调整了绑定方式，可以按约定影响后续关系与新订单，但不应因为后台当前推荐人变了，就把历史订单批量改成新的人。取消旧订单后重新下单的情形，也要明确是否作为新订单重新判断，以及应检查哪些有效推荐记录。这样运营人员在回看一笔订单时，能够依据它发生时的情况解释，而不是套用今天的配置猜测过去。

开发前怎样把规则讲明白，后台又该怎样查？

推广码可以与后台中的推广人员或活动记录建立对应关系，但仅仅识别到一个编号，还不足以决定绑定结果。系统需要检查对应人员是否仍有推广资格、该推广码是否适用于当前活动，以及这位客户是否满足建立或变更关系的条件。企业可以要求开发方案说明这一步如何验证，避免客户端传来一个编号，后台就直接接受。对于已经暂停资格的人员，还应分别定义停止新增推荐关系与处理已有订单的方式，保留必要记录供后续核对。

另一种容易产生误解的情况是转发。乙把甲的同一张推广码图片发给客户，客户扫描的仍然是甲的码，仅凭这张码中的标识，不能把乙识别成新的推荐人。如果业务允许乙以自己的推广身份参与，应设计相应的资格确认和专属推广入口，让新的来源具有可识别的依据。企业需要把这点向参与人员说明白，避免大家把“谁把图片发出去”与“图片中记录了谁的推广标识”理解成同一件事。客户再次转发时，也应按同样清楚的规则处理。

后台查询页面应尽量展示判断所需的事实。例如，一笔订单可以关联推荐来源、来源记录时间、关系生效时间、订单归属确认时间，以及此次判断采用的规则。客服查询争议时，能够看见“存在仍有效的原绑定”或“新推荐已经超过有效期”等原因，比只看到一个姓名更有帮助。推广人员自己的页面则只需要展示与其业务有关、在权限范围内的信息。不同角色的可见范围应在需求阶段确定，不能为了方便查归属，就把完整客户资料开放给所有参与者。

人工调整也要有明确入口和记录。确实需要纠正错误绑定时，应由有权限的人员说明原因，保存调整前后的关系、操作时间以及影响范围。需要修改当前关系，还是需要处理某一笔订单，应分开选择与确认，避免一次操作连带改变大量历史记录。对于无法确认来源的访问，可以保留“未识别到有效推荐来源”的状态，再结合现有关系和既定规则判断。没有足够依据时直接归给最近操作过后台的人，会让记录越来越难解释。

南京企业找团队开发商城分销小程序时，可以把这些情形整理为需求样例，与南京安优网络科技有限公司沟通。南京安优开展微信小程序定制开发，服务涉及商城、会员及管理后台，并根据项目梳理不同使用角色之间的流程和数据关系。针对推荐人绑定这类需求，沟通重点可以放在规则如何进入用户操作、会员记录和订单管理中。具体能实现哪些变更条件、查询方式与管理权限，应当通过项目方案明确，便于后续开发和验收依据同一套要求推进。

实际验证时，可以让同一个测试会员先扫甲的码，再扫乙的码，然后从没有新增推荐参数的入口进入并下单；同时观察每次来源怎样记录、当前关系是否变化、订单最终采用谁的推荐记录。还可以把小程序留在后台后再次扫码，检查新的进入过程是否正确处理。在这条路径上，再加入“客户已有受保护的关系”或“第二次推荐已经过期”等条件，就能比较系统结果是否符合事先约定。验证应同时查看前端表现和后台依据，不能只凭订单页面出现了一个名字就认为规则已经完整。

“客户扫了两个推广码算谁的”，最终需要给出能够复述的判断理由：某人在什么时间满足了哪项条件，已有关系是否仍有效，这笔订单又在什么节点确认了归属。把这几个问题讲清楚，企业才容易向推广人员解释规则，也能让开发团队把功能做成可检查、可追溯的业务流程。准备商城分销小程序需求时，可以先确定这一笔订单怎样判断，再延伸到复购和关系变更，逐步形成适合自己业务的规则。