小程序上卖出去的券、卡、套餐，最终要到店里用掉。核销这个环节做不好，前面所有的努力都会在最后一米断掉，用户到了店里用不了，比没买过还糟。
核销的设计要考虑的现实情况是，店员忙、光线差、网络不一定好。
一、几种核销方式
用户出示码，店员扫。这是最常用的方式，用户打开小程序的券页面，店员用手机或者扫码枪扫这个码。优点是速度快，缺点是依赖用户手机有电有网。
店员输入核销码。用户报一串数字，店员在系统里输入。适合用户手机没电或者扫不出来的情况。码不要太长，六位以内比较好念。
店员扫用户的付款码或者身份码。这类依赖微信的支付能力，用在需要确认身份的场景。一般消费类的券用不上这么重的方式。
还有一种是用户自己点确认，店员在旁边看着。最简单但风险最高，容易被用户离店后再点。除非是小额且信任度高的场景，不建议用。
二、店员端怎么设计
店员端要足够简单。店员的注意力在客户身上，不在手机上。打开就能扫，扫完立刻出结果，成功或者失败一目了然，不要有中间步骤。
核销结果要给足信息。显示用户的券是什么、能抵多少、还剩几次。店员需要知道这些才能判断该收多少钱。
操作要有撤销口子。误扫、扫错、用户临时不用了，这些情况都会出现。要有一个短时间内的撤销按钮，撤销之后券恢复可用，同时记录撤销操作。没有撤销口子，店员只能通过客服去解决，效率很低。
多门店的环境下，店员只能核销自己门店的券。跨店核销要么禁止，要么需要额外授权。这条规则要在系统层面控制，不能靠店员自觉。
三、断网和异常怎么处理
店里的网络不一定靠得住。核销时网络断了，系统给不出结果，店员不知道该放人走还是让客户等着。
一种做法是做离线核销。在有网的时候把当天可能用到的券信息同步到店员端，断网时先记录核销动作存本地，网络恢复后自动上传。这种方案要在规则上允许一定的冲突，比如同一张券在断网期间被两个店核销，需要事后处理。
另一种做法是断网时降级为人工。店员记录下券号，让客户先消费，事后补录。这种做法要靠纸质记录，容易丢，适合极端情况下的临时方案。
不管用哪种，都要有异常上报。核销失败时店员能一键反馈，把问题提交到后台，而不是打电话找人。上报的信息要带门店、时间、券号，便于定位。
四、核销数据有什么用
核销数据最直接的用途是结算。线上卖了多少、实际核销多少、各门店核销多少，这些数字是分账和对账的依据。
第二个用途是判断效果。券卖出去不等于有效果，真正到店核销才算。核销率低说明要么券的设计有问题，要么门店执行不到位。这两个原因的区分方法是看不同门店的核销率，个别门店低是执行问题，普遍低是券本身的问题。
第三个用途是了解用户行为。用户在什么时间段来核销，买了多久之后才来，这些都是运营决策的依据。比如发现大部分用户都在周末核销，那工作日可以针对性设计一些专属的优惠。