外賣,也可以“聚合”

8 評論 2660 瀏覽 28 收藏 11 分鐘

在這篇文章里,作者針對外賣聚合平臺做了分析與解讀。而在O2O外賣平臺之外,其實(shí),O2O零售平臺的核心業(yè)務(wù)流程也與其有些相似。一起來看看,或許可以幫你更加了解多渠道聚合。

一、背景

1. 訂單來源

在過去,商家普遍使用傳統(tǒng)POS收銀軟件進(jìn)行線下店面收銀,可以在一定程度上提升收銀效率。

之后隨著O2O外賣渠道的發(fā)展,越來越多的商家選擇在線上平臺運(yùn)營門店,提升商家曝光效應(yīng),進(jìn)而來擴(kuò)大門店客流量。甚至商家會(huì)在多個(gè)線上平臺運(yùn)營門店。

O2O外賣,就是消費(fèi)者在線平臺下單,購買服務(wù)、商品,在線下商家完成服務(wù)履約。比如:美團(tuán),餓了么等。這里的平臺/渠道就是指的訂單來源。

2. 新的挑戰(zhàn)

這也帶來了新的挑戰(zhàn)

商家在不同平臺一遍一遍重復(fù)建立商品的繁瑣操作。

當(dāng)多平臺線上訂單量急增時(shí),門店訂單履約效率會(huì)大幅降低,商家就特別容易出差錯(cuò),備錯(cuò)貨,從而造成線上門店評分低。

本來是借助線上平臺來提升門店的曝光率的,現(xiàn)在卻適得其反。這時(shí)候,商家就需要考慮,多雇個(gè)幫手來管理不同線上平臺的門店。雇人,對商家來說又增加了人力成本。

3. 詳細(xì)拆解商家的運(yùn)營管理模式

  • 商家需要把線下門店商品,手動(dòng)同步到線上不同渠道上的門店中;
  • 商家在兼顧線下門店收銀的情況下,還需要兼顧不同線上門店的新訂單履約;
  • 商家定期需要切換不同渠道平臺進(jìn)行對賬,商品庫存盤點(diǎn)清算;
  • 商家可能還會(huì)定期對一些會(huì)員,搞一些促銷活動(dòng)宣傳。

通過上述商家操作,我們可以看出來商家運(yùn)營門店主要通過五個(gè)模塊:商品管理、訂單履約、數(shù)據(jù)對賬、會(huì)員運(yùn)營、促銷活動(dòng)。

雖然,不同業(yè)態(tài)側(cè)重點(diǎn)不同,但商品管理、訂單履約、數(shù)據(jù)對賬是運(yùn)營的核心。

面對繁多的線上平臺,作為商家最頭疼的就是:多門店無法統(tǒng)一管理。商品需要在多個(gè)平臺同步,訂單無法統(tǒng)一管理,導(dǎo)致對賬困難。

那么作為SaaS收銀軟件服務(wù)商,如何解決商家遇到的上述痛點(diǎn)呢?

因?yàn)樯碳以诰€下收銀使用的是我們的服務(wù),那么我們只需要將其他平臺聚合到我們的服務(wù)中,讓商家只需要在我們的服務(wù)中操作一次即可,這就是多渠道聚合。

二、業(yè)務(wù)流程

我們來分析一下業(yè)務(wù)流程。

商家訂單來源,主要來自線下門店和線上多渠道門店。門店的相關(guān)數(shù)據(jù)都保存到對應(yīng)平臺中,導(dǎo)致數(shù)據(jù)不同步。

我們可以將線下和線上訂單數(shù)據(jù)進(jìn)行同步,借助商家線下POS終端和saas商戶后臺來實(shí)現(xiàn)訂單履約管理。最終,實(shí)現(xiàn)多端數(shù)據(jù)統(tǒng)一管理。

外賣聚合四件套,門店 、商品、履約、對賬。

1. 門店映射

首先要做的就是進(jìn)行門店統(tǒng)一。商戶后臺需要提供線下門店賬號和外賣平臺賬號進(jìn)行綁定映射。

  • 加載商戶門店列表;
  • 選中要進(jìn)行映射的門店進(jìn)行綁定;
  • 跳轉(zhuǎn)到外賣平臺登錄界面并進(jìn)行登錄;
  • 外賣平臺會(huì)加載出該賬號下的門店,勾選保存成功;
  • 外賣平臺會(huì)推送綁定成功消息到商戶后臺,然后商戶后臺成功保存線下和線上門店的映射關(guān)系。

2. 商品映射

線上多平臺門店要和線下門店進(jìn)行商品同步,主要包括:商品基本檔案,商品的價(jià)格、庫存、上下架。

在門店映射的基礎(chǔ)之上,商家可以將本地商品批量上傳到外賣平臺。上傳商品時(shí)只需要將核心的SKUID,分類 ,商品名稱等基本信息和線上平臺一一對應(yīng)即可。

商家還需要進(jìn)行商品映射,商品映射這一步是計(jì)算庫存的核心。

只有進(jìn)行商品映射之后,商家在SaaS商戶后臺才能夠查看到來自不同平臺消耗的庫存量。

對于商品單品的常用基本操作主要是價(jià)格、庫存、上下架,我們可以將此操作集成到商家后臺,以提升效率。

3. 訂單履約

為了提升商家多店訂單履約效率,我們將訂單業(yè)務(wù)操作分為:接單,出餐,配送,訂單完成,退款審核和發(fā)起退款功能,統(tǒng)一放到POS終端設(shè)備上。

用戶在外賣APP中選品并下單支付,最終由商家提供給用戶商品。至于這筆訂單的支付流程如何支付收款?商家線下提供的商品要如何進(jìn)行配送?

它們都是由外賣開放平臺來提供支持的,SaaS軟件服務(wù)商都無需關(guān)心。SaaS軟件服務(wù)商需要關(guān)心的一點(diǎn)就是要將訂單基本信息和狀態(tài)同步正確。

訂單正向履約流程:用戶下單支付后,外賣平臺將新訂單推送給商戶后臺,商戶后臺寫入數(shù)據(jù)庫。

POS終端通過輪詢監(jiān)聽的方式,提醒商戶有新訂單。商戶可以在POS終端接單或拒單。

如果拒單,訂單直接取消并退款結(jié)束。

如果進(jìn)行接單,訂單狀態(tài)會(huì)同步給外賣平臺。商家備貨后在POS終端點(diǎn)擊出餐,狀態(tài)同步給外賣平臺。外賣平臺會(huì)根據(jù)門店簽約的配送服務(wù),來決定是否支持自動(dòng)發(fā)配送。

如果是,則由平臺進(jìn)行配送履約,平臺配送完成后,由平臺推送訂單完結(jié)狀態(tài)。反之,商家可自動(dòng)發(fā)起平臺其他配送服務(wù)進(jìn)行配送履約服務(wù),履約完成狀態(tài)同步回商戶后臺。商家也可以線下自配送履約。

如果商家自配送,則需要商家自動(dòng)確認(rèn)訂單完結(jié),SaaS軟件服務(wù)商會(huì)將此狀態(tài)同步到外賣平臺。

訂單完結(jié)之后,SaaS軟件服務(wù)商就需要寫入流水并計(jì)算商品庫存。

訂單逆向退單流程:涉及到的就是錢和商品。當(dāng)訂單已經(jīng)完結(jié)用戶申請退單時(shí),商家審核通過后,進(jìn)行退款,并寫入退款流水和庫存。如果申請退單,是未完結(jié)的訂單,則直接退款取消訂單。

商戶后臺系統(tǒng)需要記錄:訂單的來源,系統(tǒng)訂單號,訂單金額,訂單狀態(tài)等信息;訂單詳情要記錄訂單的品名稱,本地映射商品ID,價(jià)格,配送費(fèi)等基本。

4. 對賬報(bào)表

商戶后臺會(huì)基于以上多平臺訂單履約數(shù)據(jù)和商品映射關(guān)系,進(jìn)行流水報(bào)表不同維度的展示,比如:根據(jù)交易流水,商品流水,支付流水進(jìn)行確認(rèn)。針對于收款對賬:分為收款員對賬,交班對賬,收款日對賬幾個(gè)維度展示。

三、新零售渠道聚合之道

SaaS軟件服務(wù)商針對商戶運(yùn)營多門店:提供外賣渠道聚合,解決線上和線下門店數(shù)據(jù)不同步問題,提供數(shù)字化解決方案,助力商家高效運(yùn)營門店。將此外賣渠道解決方案打包成增值服務(wù),提供給商戶。

其實(shí)市面上不光是O2O外賣平臺,還有O2O零售平臺(比如:京東到家,餓百,閃購),核心業(yè)務(wù)流程和我們以上分析的這個(gè)外賣聚合平臺類似。

我們可以把外賣平臺中的配送看作是快遞業(yè)務(wù),只不過這個(gè)“快遞”配送是短時(shí)間內(nèi)的,零售類因?yàn)榕渌头秶h(yuǎn),配送時(shí)長也更長。

最終都是由商家提供商品、服務(wù),借助O2O平臺提供的 配送/物流 實(shí)現(xiàn)訂單履約。完全也可以將這一類O2O零售/外賣平臺,做成聚合通道,為商家提供多平臺門店運(yùn)營服務(wù),提升運(yùn)營效率。

本文由 @PenguinPay 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議。

該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 若sass平臺商品結(jié)構(gòu)與外賣平臺商品結(jié)構(gòu)差異較大呢。

    來自安徽 回復(fù)
    1. 外賣的商品要解析到商品規(guī)格維度,然后與 SAAS 平臺商品映射。外賣商品甭管是套餐,還是單品,我們映射的都是確定它的規(guī)格為最小單位商品

      來自山東 回復(fù)
    2. 舉例:
      美團(tuán)外賣 支持多組商品屬性,但帶價(jià)格的屬性組會(huì)按照規(guī)格組生成多sku,如sku1:楊枝甘露 大杯·加珍珠;sku2:楊枝甘露 大杯·加芋圓
      餓了么外賣,不支持多規(guī)格組,對于加料是作為額外的加價(jià)屬性,不會(huì)算做sku,如sku:楊枝甘露 大杯,加小料:加珍珠,加芋圓
      那么你聚合的平臺商品模型是怎么弄的呢?美團(tuán)的sku碼不支持填寫重復(fù)的商品編碼。

      也可能零售行業(yè)沒有這個(gè)問題吧。

      來自安徽 回復(fù)
    3. 沒太理解你說的商品規(guī)格具體是指哪些方面

      來自山東 回復(fù)
  2. 感謝作者,寫得很好,已收藏轉(zhuǎn)發(fā)!

    來自上海 回復(fù)
    1. 謝謝

      來自山東 回復(fù)
  3. 業(yè)務(wù)流程好清晰

    來自江西 回復(fù)
    1. ??哈哈 謝謝

      來自山東 回復(fù)