零售与电商：身份归并、订单、旅程、退货与风险
零售模块把 SellioCRM 变成你店铺之上的客户层：把匿名浏览重新连回最终登录的那个人，从你的平台镜像订单与库存却从不假装拥有它们，构建分群与旅程，运行优惠券、推荐、评价、转介绍与订阅，并把退货当作一份提议而不是一道障碍。它不是电商平台：绝不运行你的结账流程，也绝不成为一笔销售的记录正本。可选功能，管理员启用前一直关闭。
零售行业模块是可选的。关闭期间，你的 CRM 不会有任何变化。管理员在“设置”的“行业”中启用。它是为电商、实体店以及两者之间的一切而建，并从一个不太舒服的事实出发：你的 CRM 不是你的店铺。它镜像平台所说的内容，始终带上来源和数据的时间，而当它需要作用于店铺时，通过一个幂等、需要审批并记入审计轨迹的委托动作来完成。
你的大部分流量是匿名的，而这正是真正的问题
有人浏览两周，然后才下单。没有身份归并，这就是两段互不相干的故事。本模块把登录之前的行为，连回登录之后出现的那位客户，并且刻意谨慎地决定“怎么连”：像店铺客户号、忠诚度号或社交登录这样的强标识可以自行重连；而邮箱、电话或设备不可以。家人共用电话。这类情况会进入人工复核，而不是悄悄把两个人合并，并且每一次合并都可以撤销。
同步是集成悄悄腐坏的地方
回调通知 会重复到达、乱序到达，或者根本不到。每一条来自平台的记录都以来源、资源、外部标识和版本为键，因此重复或迟到的消息就是什么都不发生。夜间对账会与平台核对数量，因为真正伤人的故障不是你看得见的报错，而是那条从未到达、也没人察觉的记录。
订单、库存与发货是镜像，不是归属
订单带着来源系统和读取时刻，所以你始终知道这个数字有多新。CRM 不开票，不替店铺收款，也不决定库存。它补上的是店铺自己看不到的东西：这位买家在所有渠道上是谁，下单之前做了什么，以及之后会发生什么。
海量行为，却没有任何页面读取原始事件
浏览产生的行数远多于订单。事件存放在按月分区的表中，没有任何页面直接查询它。界面读取的是由作业重新计算的聚合，每一份都带着生成时刻的印记。这是有意的取舍：宁可数字晚几分钟但始终可用，也不要实时却偶尔把页面拖垮。
分群、旅程，以及你能开口多少次的上限
分群由行为、订单和档案构成，驱动旅程与营销活动。凌驾于它们之上的是接触压力规则：每个周期的上限、免打扰时段、抑制名单，以及旅程之间的优先级，这样三个活动就不会各自决定在同一个晚上联系同一个人。这套引擎已被提升到共享内核，因为上限与免打扰时段在任何行业都是同一个问题。
优惠券、推荐、评价、转介绍与订阅
优惠券带着规则和限额，而不是活在电子表格里。推荐来自人们真正一起购买的东西。评价邀请遵守订单状态。转介绍会记在带来客户的那个人身上。订阅跟踪周期与流失信号。这些都不取代你的店铺：这是店铺从来没有过的关系层。
把退货当作提议，而不是障碍
是否符合条件，按订单日期起算的政策期限来判断。当退货符合条件时，店铺储值可以在纯退款之上带一份加成，让换货真的比拿回现金更有吸引力。这被设计成客户可以拒绝的提议，而绝不是横在他应得退款前面的阻力。
用信任而不是怀疑来表达风险
关于一笔订单或一位客户的信号，汇总成一个信任分：一百表示可信，零表示高风险。被驳回的信号不再计入，这一点很重要：一条规则如果继续为人工早已澄清的事惩罚客户，那它教会你的团队的，就是忽略这个分数。
忠诚度按你的方式来
忠诚度有两种模式，可按租户选择：只进不改的自有台账加等级，或者你已在运行的外部计划的镜像。在自有模式下，更正是一笔新分录而不是一次修改，所以余额永远解释得清。
这个模块不做的事
- 它不是电商平台：没有店面、没有结账、不替店铺收款，也永远不是一笔销售的记录正本。
- 它不决定库存；它镜像你的平台所报告的内容，并附上数据的时间。
- 本版本不导出到数据仓库；路径已有文档，但尚未实现。
- 它不会因为两个人共用邮箱、电话或设备就把他们合并。
- 它不展示实时事件流；界面读取的是带有计算时刻的聚合。