运费模板复盘

1 项目背景

独立站在运营的过程中需要对商品收取运费，虽然前期所有商品都是包邮，但随着业务的发展对商品收取运费是必然趋势，也有助于精细化运营

2 问题分析

问题分析前先回顾下运费模板的迭代历程，总结起来分为3阶段：

第一阶段：730版本，即独立站初始版本开发

第二阶段：1130版本，对现有运费模板进行优化，新增【一口价】收费类型

第三阶段：22年Q1版本，主要为了响应业务的快速发展，支持运费模板多类型配置

每个阶段都有各自历史使命、目标，下面将详细阐述每个阶段设计思路、开发过程中跟进的一些心路历程。

 

首先，

第一阶段：730版本，即独立站初始版本开发

那时公司属于开天辟地阶段，一切从0开始，一切也都在筹备规划、井然有序进展阶段，物流系统也不例外。从业务那得知，目前公司运费几乎都是包邮，前期可以简单单，直接做成包邮，后期在进行迭代

于是乎，得到第一阶段目标：运费按照站点+国家维度包邮，支持独立站快速使用

根据目标拆解实现步骤，分2步分析：

方案一：后端的运费如何设计，是否可直接调用？

后端运费实现较为复杂：各种附加费、费率、折扣计算，需要有专业的物流业务进行维护，鉴于独立站前期计算规则简单及没有此方面的专业人员，于是此方案不采纳，但可做为了解吗，及后续有实际需要往此方向发展

方案二：根据现有运营需求及用户操作路径进行设计

业务分析：

• 需配置的的维度有哪些

• 运营如何配置这些维护，即配置习惯怎样

其次，

第二阶段：1130版本，对现有运费模板进行优化，新增【一口价】收费类型

由于只是运费方案新增收费类型【一口价】，在第一阶段也预留了入口，因此直接进行添加就行，没有过多设计

第三阶段：22年Q1版本，主要为了响应业务的快速发展，支持运费模板多类型配置

随着业务发展包邮和一口价已经满足不了业务诉求，业务希望运费模板支持设置的收费区域更多样化同时因内部会在GMC上设置运费，因此需要兼容GMC运费设置规则，其次通过运费设置提升部分利润率

那么此次目标：

• 运费模板规则粒度继续细化同时兼容GMC及提升利润率

有了目标以后进行拆解及推演目标：

针对目标一：前2阶段完成运费框架设计，支持最基础的【运费名称、配送区域、运费方案、是否启用】设置，粒度肯定过于粗泛，那到底模块需整合那些需拓展？经过调研及业务推演，得出如下问题

• 【运费名称】是必须需要，肯定是不可变动

• 【配送区域】是否过于单一？单一的话该如何拓展，需要拓展哪些类型，各种类型的可满足哪些业务场景或市场？根据哪些元素确定配送区域？该如何组合，组合的方式有哪些？

• 【收费类型】包邮和一口价提升利润率有限，且满足不了业务场景，收费一般都是按照商品重量去收取，是否按商品重量收取就能够满足？如果遇到抛货怎么办或有些物流商针对大体积商品就按商品体积重去收取怎么办？还是按照商品重量去收取那么就跟提升利润率背道而驰

• 为了提升利润率，增加收费类型是一方面，那收费标准是怎样的呢？还是按照前2阶段按整单收费嘛？那肯定不行的，如果是单件商品整单还可以理解，那多件商品也算整单收费，那利润率不还是没办法提升嘛？再说物流商收取运费一般都是按件算费，因此这个需增加收费类型【按件】

• 除了正常运费的收取，跨境电商中物流商有各种其它费用，比如燃油费、签名费、超长超重等费用，是否这个需要单独进行设置呢

• 运费显示不应只在订单结算时才告知用户，如果有能力应该在用户浏览时就可以告知用户，减少这种落差感，造成的订单损失，那如何规划呢？

问题拆解完后，系统功能模块如何组合，如何展现才能让用户便于理解，快速操作，此时进行【用户场景地图】推演

3 解决方案

第一阶段：730版本，即独立站初始版本开发，设计方案

3.1 需求评审阶段复盘

开发测试：反馈方案一致过于简单，运费方案目前只有包邮嘛？以后新增收费方案如何设计

回复：目前业务诉求运费就是按照站点+国家包邮，前期设计的只是运费模板骨架结构，后面会根据实际业务述求进行拓展，比如收费标准，承运条件，直接在此添加对应模块就可以至于运费方案需须知包邮只是目前阶段，后期肯定会有多种收费方式，直接在【运费方案】模块增加对应类型就可

3.2 上线运营阶段复盘

• 需求上线已帮业务配置好运费模板数据后告知业务已上线。导致业务对此功能感知性不强

复盘：工作边界需清晰，不是说不可以帮业务提前配置好数据，而是初始功能，尽量让业务自己动手操作，在使用的过程中即加强了对功能的感知有利于发现是否合理，又能够发现使用使用习惯问题，方便后续进行提效优化设计

• 使用场景地图规划的不太合理

正确的场景地图：首先设置这个运费模板叫什么名字，然后支持配送哪些区域（站点+国家），收费方案是怎样的，以及是否要启用

之前规划场景地图：说先这个运费模板生效在哪个站点，叫啥名字，支持配置哪些区域（国家），以及是否要启用

差异点：配送区域设计分离，会增加一定的维护理解成本

复盘：demo设计好后，可以跟运营多核对几次，看是否符合其操作习惯

第二阶段：1130版本，对现有运费模板进行优化，新增【一口价】收费类型

• 设计方案：收费类型新增【一口价】

 

第三阶段：22年Q1版本，主要为了响应业务的快速发展，支持运费模板多类型配置

3.3 需求评审阶段复盘

当初为配合商城端进度，在20220120临时拉各端进行评审，因为临近春节有些伙伴有请假计划且有些伙伴还有工作外加需求的复杂性，导致需求前年肯定是没办法进行开发，需年后开发，就存在年后来时很多需求细节都已经忘记的差不多，需要重新帮开发会议，造成多重时间的浪费

复盘：需求评审时，评审时间节点需结合需求复杂性和假期进行合理安排

3.4 开发阶段复盘

• 研发：详细配送区域的数据需要单独抽离出一个单独做成一个模板，供运营维护，否则会造成如下问题：新增运费模板id还未生成，如果同时维护配送区域数据，那么配送区域数据没办法与运费模板id绑定，造成很多脏数据

经过对问题分析，抱着对运营操作体验最好，最易理解的角度出发，此方案与开发多次探讨，配送区域数据单独做成模板暂时不可取，可以在新增运费模板时先不提供选择具体配送区域数据，等新增好后在此模板上进行编辑配送区域数据

这样就可以避免同一功能，跨页面维护，造成的认知负担和操作负担

• 复盘：方案设计都有一定的背景，不同视角审视有不同的看法，需要理性看待及当初的出发点是否合理，这个合理性体现在对业务方是否合理、对技术实现是否合理。业务方的合理性是大前提，虽有时可被教育，但如果可实现，需尽量靠拢，这个很考验产品独立思考能力的过程，是否能保持业务与技术兼具合理性时，依然【不忘初心】

4 期望目标

第一阶段：730版本，即独立站初始版本开发

• 完成运费基础功能建设

第二阶段：1130版本，对现有运费模板进行优化，新增【一口价】收费类型

• 完成运费基础功能建设

第三阶段：22年Q1版本，主要为了响应业务的快速发展，支持运费模板多类型配置

• 在Q1完成6套运费模板的建设

5 上线前后效果对比

第一阶段：730版本，即独立站初始版本开发

• /

第二阶段：1130版本，对现有运费模板进行优化，新增【一口价】收费类型

• /

第三阶段：22年Q1版本，主要为了响应业务的快速发展，支持运费模板多类型配置

以美国市场举例：

1、第二阶段上线后【按国家+州省】配置比第一极端【按国家+邮编范围】每次配置提效约0.5h

2、利润率逐渐提升：需要收费的订单下单的数变少，GMV提高，利润额逐渐提高，从而利润率也逐渐提升

3、每月客服效率提升：10230分钟（1人/22工作日）

需处理收费订单：310

从开始处理至客户邮件耗时：约2分钟

客户回邮至处理发货：约31分钟

6 项目总结暨目标达成情况

第一阶段：730版本，即独立站初始版本开发

• 达成

第二阶段：1130版本，对现有运费模板进行优化，新增【一口价】收费类型

• 达成

第三阶段：22年Q1版本，主要为了响应业务的快速发展，支持运费模板多类型配置

• 达成

7 后续规划

前3阶段运费由粗泛到精细化的过程，目的都是为了实现精准算费，但是还是不够细致

长期：根据仓储、物流方式设置运费规则

短期：在现有运费模板上在细化，如进行承运条件的限制，货品发货规则的限制、