I直接答案
满立惠能不能生效,先看订单是从哪个入口提交的。订货宝的规则是:代客下单不参与优惠活动,只有模拟开单是例外;PC 订货端提交的订单同样不进满立惠。也就是说,客户自己在手机订货端下的单才有机会触发,后台帮客户代下的单,不论金额和件数多合适,系统都不会把它算进活动里。
如果入口没问题,接着看商品本身。同一个商品同时挂在多个营销活动下时,客户在订货端商品列表下单,系统会按优惠活动的排序去决定用哪一个,排在前面的先被命中,其他活动就不会同时叠加。所以一个商品既进了满立惠、又进了别的活动,最后看到的结果可能不是你以为的那个。另外,品牌定制客户还要确认客户手上那个 APP 是否已经更新到较新的版本,版本太旧也可能不参与。
II操作问答
先确认下单入口对不对
满立惠的第一道门槛是入口。后台的代客下单不参与优惠活动,这是硬规则,只有模拟开单这一种情形不受限制。很多用户觉得「我明明在后台看到订单金额达到了门槛」,问题就出在这里——门槛是给客户自己下的单设的,不是给代客单设的。
PC 订货端是第二道门槛。客户用电脑登录订货端下单,同样不进满立惠,哪怕商品、数量、金额全都符合。想让活动生效,得让客户在手机订货端上自己完成下单动作。
所以排查的第一步很机械:把订单号拉出来,看它的下单端口字段。是代客下单还是 PC 订货端,直接决定了后面还要不要继续查。如果这两者之一命中,就不用再怀疑活动配置了。
III操作问答
在系统里一步步排查
第一步,进入订单管理,找到那笔没参与活动的订单,查看它的下单来源。如果是后台代客下单(模拟开单除外)或者 PC 订货端,结论已经明确,不需要再往下走。
第二步,入口没问题的话,去营销活动里查这个商品挂了几个活动。重点看它是否同时出现在满立惠和其他活动里。若同时参与,回到订货端商品列表,用客户当时的路径下一单测试,看命中的是哪一个活动,再决定要不要把这个商品从多余的活动里摘出来。
第三步,确认客户身份。如果是品牌定制客户,问一下客户手机上 APP 的版本,看是否已经更新到较新版本。旧版本可能在活动判定上与当前规则不一致,更新后再复测一次。
这三步走完,绝大多数「条件都满足却没参与」的情况都能定位到具体环节,而不是笼统地归为系统问题。
IV操作问答
最容易配错的两种情形
第一种,业务员图省事,直接在后台帮客户把单子代下了。业务员看到订单金额、件数全部达到门槛,就认为活动一定会生效,结果客户那边什么优惠都没看到。现象是:订单详情里金额正常,但优惠栏是空的,活动记录里也查不到这笔单。解决办法不是改活动,而是让客户自己在手机订货端重新下单。
第二种,一个商品同时挂进多个活动。运营为了「多覆盖」,把同一商品既放进满立惠,又放进别的活动。现象是:客户下单时命中的不是你预期的那个活动,或者满立惠时有时无,看起来很不稳定。实际上系统是按活动排序取一个,排序变了结果就变。稳妥的做法是同一商品尽量只留一个主推活动,确实要并存,也要先把排序确认清楚。
V操作问答
和哪些功能会互相影响
满立惠的结果会直接体现在订单价格上,参与与不参与之间的差额就是客户实付金额的差别,这也是用户最先感知到的地方。
它还会影响报表口径。按活动维度统计的报表,代客下单和 PC 订货端的订单不会计入满立惠,如果你拿总订单去对活动数据,会发现两边对不上,这不是数据错,而是口径不同。
权限上也有讲究。谁能用代客下单、谁能在后台改活动配置,取决于账号权限设置,权限放得太宽,业务员随手代下就会持续制造这类问题。此外,如果商品还涉及库存或账期相关的设置,活动命中与否不会改变库存扣减和账期的计算方式,别把两件事混在一起排查。
VII常见问题
被问得最多的几个问题
模拟开单在系统里被单独对待,它本身就是用来验证活动效果的下单方式,所以允许参与。而普通的代客下单属于后台代替客户操作,系统不把它算作客户自主下单,因此不进满立惠。排查时不要看到是后台下的单就直接下结论,先确认是不是模拟开单。
APP 版本只是品牌定制客户需要额外确认的一环,不是唯一原因。更新之后仍不生效,要回到入口和商品这两条线上查:订单是不是代客下单或 PC 订货端提交的,商品是不是同时挂了多个活动被别的活动先命中。把这两点排掉,再看活动本身的时间段和适用范围是否覆盖了这笔订单。
不会叠加。客户在订货端商品列表下单时,系统按优惠活动的排序决定用哪一个,排在前面的先被命中,其余活动不再同时生效。所以同一商品同时挂多个活动,结果取决于排序,而不是累加。想让结果可控,建议一个商品只保留一个主推活动;确实要并存,也要先把排序和预期效果确认好。
VII继续查
企业微信 · 专属顾问