外卖,也可以“聚合”
在这篇文章里,作者针对外卖聚合平台做了分析与解读。而在O2O外卖平台之外,其实,O2O零售平台的核心业务流程也与其有些相似。一起来看看,或许可以帮你更加了解多渠道聚合。
一、背景
1. 订单来源
在过去,商家普遍使用传统POS收银软件进行线下店面收银,可以在一定程度上提升收银效率。
之后随着O2O外卖渠道的发展,越来越多的商家选择在线上平台运营门店,提升商家曝光效应,进而来扩大门店客流量。甚至商家会在多个线上平台运营门店。
O2O外卖,就是消费者在线平台下单,购买服务、商品,在线下商家完成服务履约。比如:美团,饿了么等。这里的平台/渠道就是指的订单来源。
2. 新的挑战
这也带来了新的挑战
商家在不同平台一遍一遍重复建立商品的繁琐操作。
当多平台线上订单量急增时,门店订单履约效率会大幅降低,商家就特别容易出差错,备错货,从而造成线上门店评分低。
本来是借助线上平台来提升门店的曝光率的,现在却适得其反。这时候,商家就需要考虑,多雇个帮手来管理不同线上平台的门店。雇人,对商家来说又增加了人力成本。
3. 详细拆解商家的运营管理模式
- 商家需要把线下门店商品,手动同步到线上不同渠道上的门店中;
- 商家在兼顾线下门店收银的情况下,还需要兼顾不同线上门店的新订单履约;
- 商家定期需要切换不同渠道平台进行对账,商品库存盘点清算;
- 商家可能还会定期对一些会员,搞一些促销活动宣传。
通过上述商家操作,我们可以看出来商家运营门店主要通过五个模块:商品管理、订单履约、数据对账、会员运营、促销活动。
虽然,不同业态侧重点不同,但商品管理、订单履约、数据对账是运营的核心。
面对繁多的线上平台,作为商家最头疼的就是:多门店无法统一管理。商品需要在多个平台同步,订单无法统一管理,导致对账困难。
那么作为SaaS收银软件服务商,如何解决商家遇到的上述痛点呢?
因为商家在线下收银使用的是我们的服务,那么我们只需要将其他平台聚合到我们的服务中,让商家只需要在我们的服务中操作一次即可,这就是多渠道聚合。
二、业务流程
我们来分析一下业务流程。
商家订单来源,主要来自线下门店和线上多渠道门店。门店的相关数据都保存到对应平台中,导致数据不同步。
我们可以将线下和线上订单数据进行同步,借助商家线下POS终端和saas商户后台来实现订单履约管理。最终,实现多端数据统一管理。
外卖聚合四件套,门店 、商品、履约、对账。
1. 门店映射
首先要做的就是进行门店统一。商户后台需要提供线下门店账号和外卖平台账号进行绑定映射。
- 加载商户门店列表;
- 选中要进行映射的门店进行绑定;
- 跳转到外卖平台登录界面并进行登录;
- 外卖平台会加载出该账号下的门店,勾选保存成功;
- 外卖平台会推送绑定成功消息到商户后台,然后商户后台成功保存线下和线上门店的映射关系。
2. 商品映射
线上多平台门店要和线下门店进行商品同步,主要包括:商品基本档案,商品的价格、库存、上下架。
在门店映射的基础之上,商家可以将本地商品批量上传到外卖平台。上传商品时只需要将核心的SKUID,分类 ,商品名称等基本信息和线上平台一一对应即可。
商家还需要进行商品映射,商品映射这一步是计算库存的核心。
只有进行商品映射之后,商家在SaaS商户后台才能够查看到来自不同平台消耗的库存量。
对于商品单品的常用基本操作主要是价格、库存、上下架,我们可以将此操作集成到商家后台,以提升效率。
3. 订单履约
为了提升商家多店订单履约效率,我们将订单业务操作分为:接单,出餐,配送,订单完成,退款审核和发起退款功能,统一放到POS终端设备上。
用户在外卖APP中选品并下单支付,最终由商家提供给用户商品。至于这笔订单的支付流程如何支付收款?商家线下提供的商品要如何进行配送?
它们都是由外卖开放平台来提供支持的,SaaS软件服务商都无需关心。SaaS软件服务商需要关心的一点就是要将订单基本信息和状态同步正确。
订单正向履约流程:用户下单支付后,外卖平台将新订单推送给商户后台,商户后台写入数据库。
POS终端通过轮询监听的方式,提醒商户有新订单。商户可以在POS终端接单或拒单。
如果拒单,订单直接取消并退款结束。
如果进行接单,订单状态会同步给外卖平台。商家备货后在POS终端点击出餐,状态同步给外卖平台。外卖平台会根据门店签约的配送服务,来决定是否支持自动发配送。
如果是,则由平台进行配送履约,平台配送完成后,由平台推送订单完结状态。反之,商家可自动发起平台其他配送服务进行配送履约服务,履约完成状态同步回商户后台。商家也可以线下自配送履约。
如果商家自配送,则需要商家自动确认订单完结,SaaS软件服务商会将此状态同步到外卖平台。
订单完结之后,SaaS软件服务商就需要写入流水并计算商品库存。
订单逆向退单流程:涉及到的就是钱和商品。当订单已经完结用户申请退单时,商家审核通过后,进行退款,并写入退款流水和库存。如果申请退单,是未完结的订单,则直接退款取消订单。
商户后台系统需要记录:订单的来源,系统订单号,订单金额,订单状态等信息;订单详情要记录订单的品名称,本地映射商品ID,价格,配送费等基本。
4. 对账报表
商户后台会基于以上多平台订单履约数据和商品映射关系,进行流水报表不同维度的展示,比如:根据交易流水,商品流水,支付流水进行确认。针对于收款对账:分为收款员对账,交班对账,收款日对账几个维度展示。
三、新零售渠道聚合之道
SaaS软件服务商针对商户运营多门店:提供外卖渠道聚合,解决线上和线下门店数据不同步问题,提供数字化解决方案,助力商家高效运营门店。将此外卖渠道解决方案打包成增值服务,提供给商户。
其实市面上不光是O2O外卖平台,还有O2O零售平台(比如:京东到家,饿百,闪购),核心业务流程和我们以上分析的这个外卖聚合平台类似。
我们可以把外卖平台中的配送看作是快递业务,只不过这个“快递”配送是短时间内的,零售类因为配送范围远,配送时长也更长。
最终都是由商家提供商品、服务,借助O2O平台提供的 配送/物流 实现订单履约。完全也可以将这一类O2O零售/外卖平台,做成聚合通道,为商家提供多平台门店运营服务,提升运营效率。
本文由 @PenguinPay 原创发布于人人都是产品经理。未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
若sass平台商品结构与外卖平台商品结构差异较大呢。
外卖的商品要解析到商品规格维度,然后与 SAAS 平台商品映射。外卖商品甭管是套餐,还是单品,我们映射的都是确定它的规格为最小单位商品
举例:
美团外卖 支持多组商品属性,但带价格的属性组会按照规格组生成多sku,如sku1:杨枝甘露 大杯·加珍珠;sku2:杨枝甘露 大杯·加芋圆
饿了么外卖,不支持多规格组,对于加料是作为额外的加价属性,不会算做sku,如sku:杨枝甘露 大杯,加小料:加珍珠,加芋圆
那么你聚合的平台商品模型是怎么弄的呢?美团的sku码不支持填写重复的商品编码。
也可能零售行业没有这个问题吧。
没太理解你说的商品规格具体是指哪些方面
感谢作者,写得很好,已收藏转发!
谢谢
业务流程好清晰
😄哈哈 谢谢