酷播亮新聞
文章為作者根據自己工作經驗總結出來的關於電商產品初建時需要關注的幾個流程，希望能夠給你帶來一些啟發和收穫。 由於篇幅有限文章僅闡述了7個流程當中的前兩個流程，接下來的5個流程會在後續的文章中補足。
去年我幫朋友的養老院做了一次業務諮詢和系統設計，他們原本已經有了4家連鎖性質的養老院，但開設新院、連鎖管理和市場推廣方面的需求特別急迫，特別想用互聯網化的思維 重建系統，最終形成具備提供養老行業標準化服務體驗的Saas系統。
在這個過程中我也受到多方面的啟發，本來想盡快寫出來，結果一拖就是一年多，正好當下有些閒功夫，寫出來和朋友們分享分享。
朋友請我幫他們做諮詢和設計主要的訴求是這家養老院業務擴展迅猛，短短幾年時間就已經開設了4家養老院，且後續將以每年2家的速度開設新院，而在這個過程 中他們整理、總結和驗證出了一整套養老服務的標準化流程和規範以及養老院內部管理體系，但如果是連鎖式發展，這套養老行業的SOP（Standard Operation Procedure）又怎麼能快速復制和更新到 分佈到各地的分院中呢？
如果借鑒酒店行業的連鎖經營，當然是希望通過行業內的連鎖管理IT系統實現對各分院的集約化管理，但是苦於養老行業的互聯網化在發展初期並沒有受到太多資本的關注，也沒有可以 影響整個行業，特別是Saas化的養老行業互聯網化平台，所以只能從0基礎起步自建養老業的平台。
這裡說的養老平台是需要滿足養老院自身服務運營的基本需求，而不是現在一些創業項目中只是涉及渠道化養老的互聯網養老項目，目前國內的養老行業分佈還是以養老院為主體，社區養老和居家養老 為輔，而這裡最難的是養老院的方式，因為入住養老院的老人，是社會急需幫助和關注的弱勢群體。
這裡需要說明的是按照國際劃分標準老人的定義是65歲以上的人群，而他們的構成差異也比較大，有自主行為能力的老人，他們其實和普通人沒有什麼區別，他們的養老其實主要是 以提供一些生活服務和醫療的便利性和一些社群的關照為主，這就是目前互聯網渠道化養老項目的關注點。
而更需要社會關注和幫助是那些喪失自主生活能力的低能老人，他們需要的更加細緻，深入和全面的社會服務和關注，需要製定老人全方位的生活照顧計劃，這就是為什麼需要強調養老服務過程 的標準化的重要性原因了。
這家養老院前期就已經零零碎碎的搭建起了各式各樣分散、獨立的小系統，有服務訂購系統、客戶基本管理系統、老人能力評估、計費、人事、財務系統等，可以說 “麻雀雖小，五臟俱全”。 那我該從哪裡入手呢？ 我怎麼重新整合這些已經形成體系的分散系統，從而構建一套可以支持標準化服務體驗的Saas化養老平台呢？
我們構建一個業務領域的IT系統首先要搞清楚該領域或者企業的運營核心是什麼？ 從運營核心入手分析行業的流程和規範才能事半功倍的幫助企業快速解決業務瓶頸。 一個服務型行業或者企業的運營核心無外乎是：
核心運營實體
圖中運營實體：建議書、要約、產品、服務、資源，在我看來是大部分的電商系統的核心運營實體，而客戶首先和這些運營實體發生關係和連接的流程和功能就是我們需要 重點優先考慮的。
圖片來源eTom GB921-E
在電商中客戶是怎麼和以上的運營實體發生連接的呢？ 目前普遍的產品銷售和服務提供行業的電子商務化都是建立在銷售理論中的：“客戶請求2商戶響應和滿足”的模型下，x東，x寶如此，其他垂直行業電商也是如此。
所以C2C（Customer2Customer）的流程分析就是我們創業階段電商優先關注的流程。 我們如果從MVP產品的交付角度來說，能滿足如下C2C的常見流程所需功能的系統基本也就具備開門接客的必要條件。 我們總結常見的C2C流程如下：
7個C2C核心流程
他們分別是：
- Request-to-answer（請求到響應）
- Order-to-confirmation（訂購到確認）
- Usage-to-payment（使用到付款）
- Request-to-change（請求到變更）
- Termination-to-confirmation（終止到確認）
- Problem-to-solution（問題到解決）
- Complaint-to-solution（抱怨到解決）
以上7個流程涵蓋了從客戶發起，到最終得以響應或者解決的端到端過程，該過程是對客戶體驗影響最為深刻的流程，我們無論是新建電商還是已有電商都可以按照此流程重新 檢驗自己產品在業務設計上是否完整，當然一個企業除了這7個C2C流程，還有諸多管理流程，例如：
養老行業內部管理流程
但如果選擇一個系統構建的優先級的話，一定是上面7個流程，因為它們直接關係著以客戶為中心，以企業運營核心要素（建議書，要約，產品，服務，資源）為主體的架構思路 。 下面我們將分別談談這7個流程都是什麼含義。
1. Request-to-answer（請求到響應）
請求到響應
我們知道現代的商業銷售模型基本都是建立在請求到響應的核心模型下，是在客戶發起請求到商家響應請求的過程，這裡的請求是泛意的請求，並不是特指購買產品或者服務的 請求，而是一種諮詢、一種信息了解和一種客戶需要。
在傳統行業中，企業通過門店，客服中心等傳統渠道接收這種諮詢請求，而在互聯網電商模式下，一次搜索，一次網頁瀏覽，一次產品收藏等其實都是一種請求，客戶的請求是 顯性或隱性的把自己的需要(need)告知給商家，而商家響應的是：匹配滿足客戶有意願和購買能力的產品，最終將解決方案反饋給客戶確認。
上圖是一個High Level的請求到響應的流程圖，您可以當一個宏觀流程參考，具體行業細節流程上差異比較大，所以我們只能分析宏觀流程。 而圖中的請求諮詢、判斷銷售前景、匹配產品組合、提供銷售建議、確認方案，是基本銷售過程，具備一定的跨行業性和普世性，無論是服務、產品銷售，2B、2C模式都 有參考意義。
可能你會說這個流程看似在面對服務和2B市場的時候可以採用，但在產品銷售和2C市場中也太複雜了吧？ 在某寶的購物體驗中沒有這麼麻煩啊！
對，確實作為客戶的購物體驗中確實也許沒有這麼複雜和麻煩，但作為商戶來講這些工作就一個也不能少，只是有些過程是自動化的，非人工的，是實時反饋的，所以客戶的體驗 才如此簡單和快速。 但作為一個系統架構者如果也認為業務是如此簡單，就太天真了。 客戶的體驗簡單和系統提供複雜的構造本身沒有衝突，反而是通過系統的複雜構造才能提供客戶的簡單體驗。 “麻雀雖小五臟俱全”，系統也是如此。
由於篇幅所限我舉一個快速消費品的購買流程，來說明無論是快速消費品還是複雜服務都需要該流程。 “銷售前景”這個概念一般我們常見的2B市場或者是複雜服務提供市場，例如：養老行業，一次老人家屬的諮詢，往往都需要養老院One By One的去分析和跟踪他們的簽約前景。
在快速消費品行業也同樣存在，我們要網購一把電動牙刷，通常會先搜索電動牙刷，再看品牌、看功能、看評論、再比較性價比，最後做出最後購買決定，這是站在用戶角度 的流程，如果我們換到商家的角度再看，絕不會把這些過程看成是自然行為，商家都想通過這個購買流程盡最大可能去影響客戶的判斷，比如：搜索的排序，功能有針對 性體現，提供最適合消費者購買力的品牌等。 你去看看某寶的App首頁構成，你就知道了。
商家系統銷售策略就是如何利益最大化的響應客戶請求的策略，只是消費者沒有感覺而已，那是後台數據的One By One的自動分析和跟踪，這是大數據的用武之地。 目前大數據，機器學習發展的如火如荼，可以預見不遠的將來類似養老這樣的複雜業務也逐漸會採用人機交互的自動化實時分析方式替代，但這恰恰證明請求到響應的流程在銷售行業中是 如此的重要。
2. Order-to-confirmation（訂購到確認）
訂購到確認
訂購到確認流程是我們最常見的電商流程，當消費者對商家提供的產品或者服務的解決方案感到滿意，就會向商家發起訂購，而從消費者發起訂購開始後該消費者才能真正能 稱之為“客戶”（歐盟相關法律對客戶有嚴格定義和數據保護，商家不能隨意使用和洩露客戶資料），訂購代表一種契約，買賣雙方必須嚴格遵守該契約，當客戶下了訂單後， 如賣方無法提供相應產品或服務的時候，賣方要承擔相應賠償責任也就是說賣方提供產品或服務的可行性和能力分析一定要在訂單階段以前展開。
關於我在網購中一次不愉快體驗：我有一次雙11在某寶的某品牌狗糧旗艦店上購買了幾袋狗糧，價格是按照雙11價格成交的，但在兩週後的收貨確認 的過程中，發現狗糧包裝破損，當然我拒收，退貨，但這時商家客服人員卻說他們只願意退款，而不願意換貨，擺出一堆公司規定想說服我，因為我在雙 11購買的價格比平時便宜150元，所以如果採用退款，我再下訂單的方式，我將每袋損失150元。 當然最後我把什麼是訂購的理論和我的權益給客服人員做了一次掃盲後，最終他們答應可以給我以雙11價格重新購買該狗糧的權利。
當然最後這些客服人員是忌憚於我這樣的知識型客戶投訴，還是他們真正明白了什麼是交易，訂購，客戶權益的概念，不得而知，但至少說明某寶在訂購流程的標準化上面還有很多 提升空間，他們給了商家太多忽悠客戶的空間，如果平台在訂購流程中只發揮渠道作用，而不提供產品、服務質量控制，我想所謂的新電商也是空談。
言歸正傳，在訂購到確認流程中我還要重點解釋的是訂單，支付的關係和訂單構成關係，先說說訂單和支付關係，我們常見訂單支付有三種模式，分別是預付費訂單、後付費訂單 和使用後付費訂單。
我們常見的電商是預付費訂單，電商的80%都是這樣的訂單，因為目前最普及的電商模式還是產品銷售模式，所以預支付產品費用到第三方平台，是對買賣雙方最好 的利益保障手段。
另外有一些物流破損風險的產品可以選擇收貨後支付的方式，這種方式目前來看使用人群較少，因為在現在平台託管資金如此發達的今天，收貨後再支付也沒有提高消費者的 權益保障，而且還增加了操作麻煩。 而第三種支付方式，“使用後支付”是下一步服務業消費升級的重點方式，值得我們關注，在下一個流程中我將重點介紹。
訂單構成關係，我們看到的訂單按照商家提供的產品結構的不同，會拆分為：產品訂單，服務訂單和資源訂單，也就是說這和我們平台、商家賣什麼而決定，我們常見的是 產品訂單，我們在電商平台購買的都是產品（包括服務類產品），商家所售賣的產品是在他自身經營範圍以內的滿足人們使用和消費的滿足人們某種需求的任何東西，包括有形 和無形。
所以服務類產品也是產品，而對這些產品的購買請求就是產品訂單，我們常見的購買一把電動牙刷，一台冰箱和一次美甲服務都是這類訂單，而服務類產品還多一個服務提供的 過程，這樣就會分解出服務訂單，注意這個服務是動詞服務，而非名詞服務，你可以理解為名詞服務service是產品的構成，而動詞服務serve，則是這個服務的提供過程。
所以當你購買了一次美甲服務後，看得見的電商訂單是產品訂單，而看不見的是serve訂單，這個serve訂單是管理服務人員如何按時，保證質量的方式向客戶提供服務的過程。 而資源訂單是要滿足該項服務過程，而提供的對於資源的調撥，使用和預佔過程。 例如：對於車輛，人員，道路等的佔用和使用。
小結
本來想用一章的篇幅寫完這7個流程，可是前面鋪墊有點多，所以寫到前兩個流程時發現已經4千多字了，要繼續寫下去，怕讀者沒有耐心繼續讀下去，所以 如果你們喜歡，多關注我的文章的話，我會在下一篇文章中繼續寫後5個流程Usage-to-payment（使用到付款），Request-to-change（請求到變更）， Termination-to- confirmation（終止到確認）， Problem-to-solution（問題到解決），Complaint-to-solution（抱怨到解決）。
這些流程，當然是宏觀流程，是業務分析的方法論，並不是真正意義上的系統流程，這7個流程會根據企業的大小，核心運營實體（建議書，要約，產品，服務，資源）的複雜 程度，企業管理方式等演化出更多的流程實例（系統流程）。
如果我們分析業務流程沒有方法論支撐，那我們看到需求永遠是細節和枝葉，沒有業務全貌和骨幹，同樣如果我們只知道這7個宏觀業務流程而不具體業務，具體分析理解和實例化，也 不可能解決電商實際發展過程中遇到的問題，而我寫該文章的目的也是想為那些正在做互聯網化發展的傳統服務行業提供我的經驗和見解，養老行業如此，其他有待我們關注的 服務行業也一樣。
本文由 @烏士兒 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自unsplash，基於CC0協議