明明是在电商平台付款买的课程，为什么可以直接就在站内学习完成后续的履约呢？渠道订单如何实现站内履约？本文对此进行了分析，一起来看看吧。

小明是一名大学生，大三在读的他打算毕业后继续读研深造，他考虑近期报个考研的课程跟着老师学习。在挑选机构和课程时，小明意外地发现，一些非常出名的在线考研的品牌在淘宝、天猫、拼多多这些大型电商平台都有旗舰店，而且还可以叠加双十一平台活动。

小明对比了下，在电商平台下单抵扣后的价格比直接在机构APP上购买更便宜，咨询客服后，客服反馈在电商平台买的课程也可以在官方APP内学习。还有这种好事？于是小明在某个在线考研机构的电商旗舰店支付了一单。不一会儿他就发现，客服所说果然不假，他所购买的课程已经下发到APP他的账号里了，他可以在APP里直接听课学习。

那么明明是在电商平台付款买的课程，为什么可以直接就在站内学习完成后续的履约呢？其实这是一类非常常见的交易场景，渠道订单如何实现站内履约，如果对此你感兴趣就一起来看看吧~

一、什么是渠道订单

在理解“渠道单”之前，先理解“渠道”是什么，渠道其实很好理解，就是指购买这个商品的来源。“渠道单”就是这个渠道下所产生的订单。我们以上文小明的例子来看，机构的APP、各个电商平台都属于是不同的渠道。其中机构的APP、pc官网等都属于站内渠道，而像外部电商平台、线下机构等都属于站外渠道。站外流量体量较大，所以随着站内流量逐步达到了瓶颈，很多公司都开始大力挖掘站外渠道，通过站外引流至站内。

对于站内渠道，用户在自营APP主站内购买商品后，课程会直接下发至用户账户中，页面上会直接引导用户在类似于【我的课程】模块进行学习，整个流程非常丝滑；那么为了保证用户体验，对于在站外平台下的订单，系统会自动为用户履约，让用户无缝衔接在站内完成履约

二、系统设计模型

如图：模型总体来说分为三层：渠道层、网关层和基建层。

1. 渠道层

渠道层里面主要是分为站内渠道和站外渠道两大类：

站内渠道包括自营商城，其常见表现形式为自营APP、pc官网、小程序等场景。

站外渠道这里我又将其分成两种：第一种是淘宝、天猫、京东、拼多多等在线电商平台，商家可以选择在各类电商平台开店，用户在店铺内进行消费；第二种是一些线下平台，以上文中小明要购买的考研课程为例，机构合作的线下辅导班、学校等，这些线下渠道也可以为机构售卖课程，用户从线下辅导班、学校等途径购买课程，然后到APP进行履约。

2. 网关层

这一层我把他定义为网关层，网关顾名思义，就是一个转换作用的”路由“，网关层主要负责的工作是将上述站外渠道单进行统一转换，然后由网关和基建层对接，实现后续的履约。

如用户在淘宝店铺和拼多多店铺下单，其实对于底层基建层来说，并不会理解不同渠道，而是抽象成统一的交易服务，这其中就是由网关层进行封装。

一般来说，网关主要是面向于站外渠道订单。对于站内订单，一般直接对接基建能力。当然，各家实现的方案都不一样，没有对错。不同站外场景下网关层的具体实现方案其实也大有不同。

上文我们提到过，站外渠道分为两类：第一类是淘宝、天猫、京东、拼多多等在线电商平台；第二类是一些线下平台，如机构合作的线下辅导班、学校等。对于系统来说，这两类最大的区别是有无系统对接能力。显而易见，对于第一类电商平台，就是有系统对接能力的；对于一些学校、线下机构等，认为是没有系统对接能力的。

1. 对于有系统对接能力的，网关这里主要是两种实现方案：

方案1：网关直接和各个系统对接进行数据同步，这个方案的优点是对接非常直接，交互周期短；不涉及其他三方系统，通过双方直接对接就可进行进行数据交互。

方案2：引入一个三方ERP系统，网关只对接ERP，由ERP对接其他电商平台，这个方案优点是随着业务后续的拓展，开拓新的线上售卖渠道时，网关层不需要开发，由ERP支持即可。

2. 对于没有系统对接能力的，一般采用人工导单的方式，将这种外部的订单导入系统，然后对接网关，完成后续交易流程。

3. 基建层

这里的基建层就是指底层的基建能力，如交易、订单、支付、履约、售后等，基建层并不感知渠道，只是和网关进行数据交互完成整个交易流。

三、系统实现思路

其实从小明在站外渠道买了课程，到小明完成履约整个模型里主要是三层【渠道】、【网关】、【基建】，那么第三部分我们从基建的维度，看下交易的主要流程中每个模块承担的怎样的职责。

1. 商品

商品关联&同步机制：

1）站外系统对接渠道

通过本地sku和渠道侧sku进行唯一关联。举个栗子：商家在电商平台店铺中的skuID需要和本地站内skuID进行唯一映射，也就是将站内skuID 在站外平台进行铺货，例如站内skui等同于电商后台的商品编码等，商品信息和库存信息保持一致，这样做既保证前置不会卖错、超卖，也是商品能够在站内履约的前提。

如果是上文提到的采用对接第三方ERP模式，那么sku关系的维护就是两两映射，外部ERP和站外渠道的sku可以关联到，本地商品库和外部ERP可以关联到。

2）站外非系统对接渠道

非系统对接的方案一般较为粗暴，就是人工导入订单，导入的商品信息就包括skuID、sku名称，注意，这里skuID就和本地skuID保持一致即可。

2. 交易订单

订单同步机制：

1）站外系统对接渠道

其实对于订单数据来说，通过网关拉取（或同步）到上游的订单数据。

然后网关调用交易的下单接口下一笔站内0元订单，只是订单存储的时候会将网关获取到的部分重要信息进行存储，如订单状态、外部支付金额、用户信息等。

2）站外非系统对接渠道

因为不涉及系统对接，所以也不存在订单拉取的流程，可以认为人工导入订单的过程其实就手动调用下单接口在内部下了一笔订单。

3. 支付

对于支付来说，订单其实调用支付下了一笔站内0元支付单。因为用户已经在外部平台支付完成了，所以不需要在内部重复支付

4. 履约

其实不管是站外渠道单还是站内单，对于履约服务来说，他只关心【给谁】以及【履约啥】。

1）站外系统对接渠道

【履约啥】也就是履约哪个sku，这个要素其实上面商品同步的时候已经可以定位到了，根据外部sku的信息找到对应的本地skuID；【给谁】这个就比较麻烦了，因为对于站外渠道而言，站外的交易是一套完整的流程；站内和站外渠道的账号体系完全是两套毫无关联的。

一般这类问题的解决办法是会在用户在站外渠道下单的时候，填入手机号信息，该手机号作为登录APP的账号以此做关联。对于实物订单，则可以通过网关拉取到的用户信息进行履约。

2）站外非系统对接渠道

其实在人工导单的时候 人和商品的信息就已经提供这些信息，并不阻塞履约。

5. 售后

售后主要是分为钱和物权，也就是用户支付的钱以及商家为用户履约的物权。

• 对于钱的售后，全都找渠道，原因很简单，钱是渠道收的；
• 对于物权的售后，全都找商家，原因也很简单，商品是商家履约的。

其实售后最重要的一点是，对于站外系统对接的订单，在外部退款时，要保证订单状态是同步的，不然就会出现用户白嫖的场景，既退了款，又白嫖了商品；对于站外非系统对接渠道时，在给用户退款时，也要记得内部系统收回物权。

四、个人思考

随着站内流量逐步遇到瓶颈，利用站外引流获客已成为不少商家尝试的业务模式。上述设计思路的场景可以覆盖各种类型的商品，因为不管是什么类型，交易本质都是一样的。

此外，在整个系统实现过程中，需要考虑商品关联和同步机制、订单同步机制、支付流程、履约服务以及售后处理等方面的问题。当然文章中提到的一些方案模型并不是一个标准，其实各厂实现的方案不尽相同，最重要的是根据业务需求和具体情况来选择适合的方案，没有标准答案，只要能为业务赋能解决问题，就是好方案。