第六章：电商后台 - 运营与交易管理

6.1 学习目标

在本章中，我的核心目标是，带大家掌握电商运营后台最核心的几个模块的设计。我们将学习如何设计营销位管理系统（如Banner）、支付与订单管理系统，以及评价管理系统，为我们的运营同事，打造一套强大、高效的“指挥中心”。

6.2 营销位管理

我们已经在用户端首页，为Banner、金刚区等营销模块，预留了最好的“广告位”。但这些广告位里，具体要展示什么内容？链接到哪里去？什么时候上下线？ 这些都不能由程序员写死在代码里，而必须由我们的运营同事，在后台进行灵活、实时的配置。

营销位管理后台，就是我们为运营同事，设计的这个“展位内容配置中心”。

6.2.1 首页Banner管理

首页Banner，是我们平台最宝贵、最核心的流量入口。我必须为它设计一套功能完善的后台管理系统。

我设计这个后台，会从前台的用户体验，反推后台需要具备的功能。

• 前台需要：图片能轮播、有顺序、能跳转。
• 运营需要：Banner能定期、自动地更换。
• 推导出后台功能：基于此，我设计的后台，就必须包含Banner列表、Banner新增/编辑、审核和自动上下线等核心功能。

“新增/编辑Banner”的表单，是这个模块的核心。我的设计会包含以下配置项：

对于“跳转页面”这个配置项，我设计的后台，至少要支持两种链接类型：

1. H5链接：运营可以填写一个任意的网址（URL）。
2. 原生页面链接：运营可以选择跳转到App内部的某个特定页面（如：某个商品详情页、某个分类列表页）。

所有配置好的Banner，都会在一个列表中进行统一的管理和查看。

6.2.2 推荐位管理

除了首页Banner，我们的App中，还有很多其他的推荐位，比如首页金刚区、商品详情页的“为你推荐”等。

如果我为每一个推荐位，都设计一个独立的后台，那整个系统将变得无比臃肿和混乱。因此，我的设计思路是，建立一个统一的、平台级的“活动管理中心”，用一套通用的逻辑，来管理所有不同位置的推荐内容。

我们看到的这张“电子渠道运营管理平台”的截图，就是一个很好的例子。它将首页、消息推送、banner等所有运营活动，都放在一个列表中进行管理。

我设计的“新建/编辑推荐位内容”的后台表单，会包含以下这些核心的、可复用的配置项：

6.2.3 活动会场管理

活动会场，是一个比单个“推荐位”，要复杂得多的营销模块。它通常是一个由多个不同模块（如Banner、商品列表、优惠券入口等）聚合而成的专题页面。

要实现这种高度灵活的页面，我需要为我的运营同事，设计一个“可视化”的页面搭建工具，也就是一个轻量级的CMS（内容管理系统）。

我们看到的这张“复杂业务管理”的后台截图，就是一个很好的范例。我设计一个活动会场搭建后台，会包含以下核心思路：

1. 基础信息配置：在表单的顶部，让运营可以先设置好整个会场的活动名称、开始/结束时间、分享标题，并上传最顶部的头图。
2. 模块化组件：我会预先定义好一套“标准组件库”，运营同事可以像“搭积木”一样，自由地选择和组合这些组件，来搭建自己的页面。
   • 我的拓展设计（常见组件）：这个组件库通常会包括：
     • 商品列表组件：运营可以选择一批商品，并选择不同的展示样式（如：一行两个、列表等）。
     • 优惠券组件：运营可以关联几张优惠券，让用户在页面上直接领取。
     • 图片组件：可以上传任意图片，作为楼层分隔或视觉点缀。
     • 文本组件：可以添加富文本内容。
3. 可视化编排：一个更理想的设计，是让运营可以通过“拖拽”的方式，来自由地调整页面上各个组件的上下顺序。
4. 统一的管理与审核：所有搭建好的活动会场页面，都会生成一个唯一的URL。运营同事可以将这个URL，配置到我们6.2.2节设计的“推荐位”的跳转链接中去，从而实现引流。

6.3 支付管理

我们在3.5.2节，已经从“技术实现”的视角，探讨了如何接入多种支付方式。现在，我们回到“平台运营”的视角来思考。

当我们的平台，已经同时接入了微信支付、支付宝、银联等多种渠道后，我就必须为我的运营和财务同事，提供一个后台，来管理这些支付渠道。比如，因为某个渠道的费率调整或系统维护，我们需要暂时关闭它，这个操作，就必须能在后台，一键完成。

6.3.1 支付渠道管理

这是支付管理后台的核心。我设计的这套功能，能让运营同事，像控制“开关”一样，灵活地管理前端向用户展示的支付方式。

1. 支付渠道列表

这个模块的首页，是一个“支付渠道列表”。它清晰地列出了我们平台已经完成技术对接的所有支付渠道。

2. 支付渠道配置

点击“配置”后，就会进入“支付渠道配置页”。这个页面的核心作用，是为我们的技术人员，提供一个安全地、结构化地，存储和管理各个支付渠道API凭证的地方。

正如我们在3.5.2节提到的，我们从微信、支付宝等官方申请下来的商户资质，会包含一系列用于API通信的“账号密码”。这个配置页，就是用来填写和保存它们的。

• AppID：我们应用在支付渠道的唯一标识。
• mchid (商户号)：我们公司的商家身份编号。
• 商户API证书/密钥：用于我们服务器与支付渠道服务器之间，进行安全加密通信的“密码”。

通过这套“列表（控制开关）+配置（填写参数）”的设计，我就将复杂的“技术对接”过程，与日常的“运营开关”过程，完美地解耦了。

6.3.2 交易流水与对账（拓展设计）

一个更完整的支付管理后台，除了上述的“渠道管理”，还应该包含以下两个核心模块：

1. 交易流水查询：我需要设计一个功能，让我的财务和客服同事，可以查询到通过我们平台的每一笔支付记录。这个流水列表，需要支持按订单号、用户ID、交易时间、支付渠道、支付状态等多个维度，进行复杂的查询和筛选。
2. 对账与结算管理：这是一个更高级的财务功能。我需要设计一个“自动对账”的系统。它能每天自动地，从微信、支付宝等渠道，拉取官方的结算账单，然后与我们自己系统的订单记录，进行逐条的、自动化的比对，并将差异项标记出来，供财务人员处理。这能极大地提升我们公司的财务管理效率。

6.4 订单管理

我们已经设计了营销和支付。当用户完成支付后，一个“订单”数据就正式诞生了。订单，是连接用户、商家、平台三方的“契约”，是整个电商交易流程中，最核心、最根本的信息载体。

订单管理模块，就是我们为不同角色，提供的查看和操作这份“契约”的后台功能。它的设计，必须同时服务于商家（履约）和用户（查询）。

6.4.1 商家端订单管理

我们先设计商家端的订单管理后台。它的核心目标，是为商家内部的运营、仓储、打包等多个协同部门，提供一套高效、准确、流程化的线上作业工具，帮助他们顺利地完成从“接收订单”到“发货”的全过程。

1. 强大的查询与筛选区

为了应对商家在日常运营中，需要从海量订单里寻找特定订单的复杂场景（如：处理客诉、核对问题订单），我必须在页面的最顶部，设计一个功能极其强大的“查询与筛选区”。

订单列表，是商家运营人员每天上班后，第一个要打开的页面。它是所有订单处理工作的“总任务看板”。

2. 按状态分类的工作队列

在筛选区的下方，我会设计一组“状态Tab页”。它的作用，是为商家预设好最高频使用的筛选器，将订单列表，直接划分为几个独立的“工作队列”。

• 待出库：这是商家最重要的工作队列，所有已付款、等待打包发货的订单，都会在这里出现。
• 未付款：商家可以在这里，看到那些已经拍下但还未付款的订单，可以进行催付等运营操作。
• 已出库、已完成、已取消：方便商家查询历史订单和问题订单。

3. 结构化的订单信息列表

列表的主体部分，我会以“一个订单包裹”为一行，进行结构化的信息展示，确保商家能在一行内，获取到这笔订单最核心的信息。

• 核心信息：如截图所示，必须包含商品信息（缩略图、标题）、单价/数量、货款金额、下单账号、订单状态等。
• 物流信息：对于已发货的订单，需要清晰地展示快递公司和快递单号。

4. 丰富的操作项

列表最右侧的“操作”列，是商家进行订单处理的核心入口。我需要根据订单的不同状态，提供对应的高频操作。

• 订单详情：这是所有状态下，都必须有的入口。
• 出库：这是“待出库”状态下，最核心的操作。点击后，会进入发货操作流程（如：填写快递单号）。
• 修改物流单 / 修改地址：这是为应对异常情况，提供的必要“补救”功能。
• 延迟发货提醒：当商家无法按时发货时，可以通过这个功能，主动向用户发送一条安抚性的提醒。

5. 订单详情与状态流转

点击订单列表中的任一订单，即可进入订单详情页。这是关于这笔交易的“唯一事实凭证”，它必须完整、清晰地展示所有相关信息。

订单的生命周期，是由“订单状态”来驱动的。在商家后台，商家执行的每一个核心操作，都会驱动订单状态向前流转。

例如，当商家在后台点击“发货”并填写完快递单号后，这笔订单的状态，就会从待发货自动变更为待收货。

6. 异常订单与售后订单管理

• 异常订单处理：我需要为商家，设计处理异常情况的功能，比如因库存不足而需要“拒单”，或在发货前应用户要求“修改订单”（特别是收货地址）。
• 售后订单管理：当用户发起“退款/退货”申请时，这些申请需要进入商家后台的一个独立“售后订单”工作队列中，供商家进行“同意退款”、“拒绝申请”等操作。

6.4.2 平台端订单管理

“对于平台而言，它也有订单管理模块…”

现在，我们来设计我们自己内部运营和客服同事使用的平台端订单管理后台。

1. 核心设计差异

我设计平台端，与设计商家端的核心思路差异在于：

• 视角不同：商家端只能看到自己的订单；而平台端，必须能看到全平台所有商家的订单。
• 职责不同：商家的核心职责是操作（如：发货）；而我们平台的核心职责，更多的是监督和客服仲裁。

2. 平台端订单列表

基于上述差异，我设计的平台端订单列表，与商家端相比，有以下不同：

• 增加“店铺”维度：在列表的筛选器和表头中，我必须增加“店铺名称”这一维度。这能让我的客服同事，在接到用户电话时，可以快速定位到是哪个店铺的订单出了问题。
• 简化操作项：在“操作”列，平台端的操作会更精简。主要以“查看订单详情”为主，而不会包含“发货”这类应由商家执行的操作。

3. 平台端订单详情

平台端的订单详情页，在信息展示上，与商家端需要保持完整和一致。

• 我的设计：我会额外在页面顶部，增加一个“店铺信息”模块，清晰地展示出这笔订单所属商家的店铺名称、联系方式等。当出现交易纠纷时，这能方便我的客服同事，快速地联系上对应的商家，进行沟通和处理。

6.5 订单统计

订单管理，解决的是“处理单笔交易”的问题。而订单统计，解决的是“洞察整体业务”的问题。

我设计的订单统计模块，其核心目标，是为我们的运营、市场和管理团队，提供一个数据驱动的决策中心。它不是简单的数据罗列，而是要能通过数据，清晰地回答三个核心的业务问题：

1. 我们的“生意”做得怎么样？（交易维度）
2. 我们什么“商品”卖得好？（商品维度）
3. 我们的“客人”从哪里来？（订单来源维度）

6.5.1 核心统计维度

在设计数据看板时，我会围绕三个核心维度，分别构建不同的数据分析模块：

1. 交易维度 - “我们生意做得怎么样？”

这是最高层级的模块，用于评估平台整体经营状况。

核心指标及解读：

核心指标	我的解读
订单销售额 (GMV)	即“GMV”，特定时间段内用户下单的总金额，是衡量平台体量的最核心指标。
订单量	特定时间段内的总订单数量。
客单价 (AOV)	总销售额 ÷ 总订单数，反映用户的平均购买力。
下单/支付用户数	两者的对比可计算出“支付转化率”，评估下单后支付流程是否顺畅。
订单金额分布	将订单金额分为如“0-50元”、“51-100元”等区间，帮助分析用户的核心消费力区间。
新老客交易构成	分析新客和老客各自贡献的销售额与订单量，是衡量平台用户健康度的重要指标。

💡 支付转化率的两种计算方式：

✅ 1. 订单转化率

定义： 衡量完成支付的独立访客占总访客的比例。

计算公式：

1

订单转化率 = (完成支付的订单数 ÷ 访问网站/App的总用户数) × 100%

解释：

• 完成支付的订单数：指成功付款的订单数量。
• 访问总用户数：独立访客或会话数（依据数据分析工具）。

适用场景： 衡量从访问到购买的整体效率，反映电商平台的直接销售能力。

✅ 2. 支付成功率

定义： 衡量成功支付交易占尝试支付交易的比例。

计算公式：

1

支付成功率 = (成功完成支付的交易数 ÷ 发起支付的交易总数) × 100%

解释：

• 成功支付交易数：用户付款成功的交易。
• 发起支付交易数：用户点击支付后实际发起的请求（无论成功与否）。

适用场景： 用于评估支付接口或渠道的稳定性和用户体验。

二者对比如下：

• 订单转化率 → 衡量用户意愿与行为。
• 支付成功率 → 衡量支付能力实现与顺畅程度。

两个指标都很关键，分别代表“转化意愿”和“支付执行”的两个环节。

2. 商品维度 - “我们什么东西卖得好？”

这个模块帮助我与品类运营同事洞察商品表现，优化选品与库存。

核心指标及解读：

我会基于这些数据设计如：

• 热销商品排行榜
• 高转化率商品榜
• 品类销售额占比等数据榜单

3. 订单来源维度 - “我们的客人从哪里来？”

这个模块帮助我与市场运营同事评估流量渠道与营销活动效果，以优化预算投入。

6.6 评价管理

我们都知道，在电商购物中，用户评价是影响购买决策的最重要的因素之一。它是一种强大的“社会认同（Social Proof）”机制。因此，为平台设计一套公平、透明、高效的评价管理体系，是我工作的重中之重。

我设计评价管理后台，需要同时服务于商家和平台这两个角色，他们的核心需求是不同的：

• 商家：更关注用户反馈，希望管理店铺声誉。
• 平台：更关注内容监管，希望维护社区环境的健康。

因此，我通常会为他们，设计两套功能各有侧重的后台。

6.6.1 评价列表与审核

首先，我需要明确评价的入口时机。在我的流程设计中，只有当订单状态流转为“待评价”（通常在用户“确认收货”后），用户端才会出现“评价”按钮。用户提交评价后，订单状态则变为“已完成”，形成闭环。

1. 平台端：内容审核与监管
用户提交的所有评价，都会首先进入我们平台端的评价管理后台。

• 核心职责：平台运营的核心职责，是内容审核。他们需要快速地筛选和处理所有评价，特别是检查其中是否包含敏感词汇、违规图片等不良信息。
• 核心功能：因此，平台端的评价列表，功能相对纯粹。列表需要展示订单编号、用户昵称、评价内容等全局信息。而最核心的操作，就是“删除”。对于违规的评价，平台拥有最高权限，可以将其直接删除。

2. 商家端：查看与互动
当一条评价通过了平台的审核，它才会出现在商家端的评价管理后台。

• 核心职责：商家的核心职责，是与用户互动，维护自己的店铺声誉。
• 核心功能：因此，商家端的后台，操作更丰富：
  • 回复：商家可以回复用户的评价，这是最重要的客户关系维护功能。
  • 置顶：商家可以将优质的、图文并茂的好评，在自己商品详情页的评价区进行置顶，作为“买家秀”的典范。
  • 申诉：当商家认为自己遭遇了恶意差评时，可以向平台发起申诉。

6.6.2 评价申诉处理

“评价申诉”，是我为保障商家权益，设计的平台仲裁流程。

• 商家发起申诉：商家在后台，点击某条差评旁的“申诉”按钮。
• 提交申诉理由：我会设计一个弹窗，让商家可以填写申诉的理由，并上传相关的证据（如：与用户的聊天记录截图）。
• 平台介入仲裁：这条申诉，会进入我们平台端后台的一个“申诉处理”队列中。
• 平台做出判决：由我们的平台运营，作为中立的第三方，来对申诉进行判决。最终的判决结果，可能是“维持原评价”，也可能是“隐藏/删除评价”。

这个申诉流程，是维护平台公平公正、调解用户与商家矛盾的关键机制。

6.7 本章总结

在本章，我们完整地设计了电商后台中，负责“让生意转起来”的几个核心运营与交易模块。