一、系统设计思路浅谈
结账服务正向流程：
一个个来分析：
1.1 产品录入——SKU录入购物车
英国超市SKU繁多，包括标品，非标品（无条码烘焙，单个蔬菜，水果等）。在对非标品的扫描管理上，基本都是人工检索录入：找到搜索入口，找到产品目录，找到产品。
这就比较有意思了，思考过以下几个问题：
（1）非标品量化与标准化问题：
当SKU数量无比巨大时，非标品的管理方向应该走向标准化，可量化，但怎样更好的兼顾用户购物体验确实是个问题。试想下，你准备买三个不同品种的烘焙产品和一个苹果，一个香蕉，在不同的产品上打条码肯定不现实。目前的解决方案还是尽可能尽可能小单位的量化产品，比如三个苹果一个包，但这样就无法解决我刚才的窘境。
（2）市场素质——容易被顺走
国内无人超市如果放眼到非标品市场，以上两个问题都是相对关键的。无人超市和自助结账系统有一个比较相似的点，由于用户主导过程，势必会在购买行为中产品各类问题，高度依赖用户行为。所以在此过程中用户的行为是难以被约束的。所以是否需要少量的人工介入以规避不良消费行为的产生，还是值得商榷。
(图片左上角的现金选项周末常常暂停使用……姑且想象下，左上空缺的地方是个现金标志）
>>促销折扣计算：
订单会产品根据不同促销策略进行折价。由于英国超市会有大量的促销行为，这一流程的顺畅很大部分得益于后台sku系统和促销系统的优化配置。
我研究过较长时间的Magento系统，这套系统的方向也折射了部分欧美电商的主流思想，也包括部分英国超市。以Tesco为例，在用户支付流程中，只有到达提交订单环节才能知道促销优惠金额，这是由于在后台设计体系中，促销系统相对独立且灵活，可以根据sku的多个属性进行匹配优惠。比如设置当日套餐，可按照产品属性“1主餐+1饮品+1小食=30元”进行总价优惠。
选择固定搭配只有在提交订单的时候才会对购物车中所有的sku进行促销规则对比计算，这样的设计思想其实非常好理解，减少了大量的购物车计算。也应该也是国内部分小型电商比较头疼的点，比如，用户即时获知优惠以增加购物车的数据提升，系统性能却难以保证稳定，特别是大促期间高并发冲击，这个问题就比较明显了。
这边英国人的处理方式就非常的果断，这毕竟是实体超市，结账流失的可能性非常小，所以会使用提交订单进行优惠计算的处理方式。针对于实体结算体系，我个人是倾向于这样的结算处理的。
>>支付方式叠加：
在进行付款的时候，用户可以按照自己需要进行不同付款方式的组合叠加，这其实也是很考验国内支付的一个细节点。
据目前的经验，在与第三方支付的对接中，每笔支付的金额和订单金额是需要相等的。
目前常见的处理策略就是后台拆单。比如较为的预售功能，其实用户的预订单和尾单在支付宝或者微信方属于不同的订单，电商系统后台对主订单进行了自动拆分，这样可以保证用户预订单和尾单支付时订单金额与支付金额一致。
而在现有的超市结算中，订单拆分需要前置。用户需要购买100元产品，先把自己的现金全部用完，发现还剩34.50没支付，于是用支付宝进行下一笔支付。这个时候后台的拆单就需要预先操作，在发起支付时候就对这笔34.50的订单进行拆分，同时系统后台记录在一张总订单上，以便用户核查。
二、市场浅谈
如果有盆友到英德或者澳大利亚旅行，应该会记得他们超市的自助结账系统。 其实自助结账系统产品设计初衷，第一，尽可能高的提升了人效，毋庸置疑。原一台机器配置一名结账员，在三个全家大小的Tesco，至少需要配置4至6台机器才能避免过多的排队。而现在的配置倾向于（对比至少50家超市的平均估算值）2+N，也就是2台人工加N台自助结算（N的部分与超市位置以及大小决定。每个熟悉系统的人自助结账的时间与服务员结账时间相似，显而易见，顾客主动承担了遗忘收银员的工作，这部分人效提升的推动是非常巨大的。 同时，面向于顾客，据NCR2014年的研究显示，在使用自主结账系统的用户中（包括英国，意大利，澳大利亚，德国），超过50%的觉得更加便捷。所以对于消费者和企业主双方而言，该系统在速率解决方面都是受益的。
