我們戲稱ktv業務部是點評公司内的小“創業公司”，加入ktv事業部一年來，我們也像一個初創團隊一樣，從0開始，基本完成了ktv預訂業務第一個階段的探索。
今天從業務角度上對ktv預訂的流程，以及我們在ktv預訂流程發展過程中的探索給大家做一下介紹。今天的介紹主要分為如下幾個大塊：
ktv預訂業務基本介紹
ktv預訂展示側的抽象
ktv訂單模型的演變
ktv預訂流程的演變
一個完整的ktv預訂流程如上圖所示：
使用者從商戶清單中找到目标ktv；
進入商戶詳情頁後，在詳情頁中選擇歡唱的時間段、包型，進入套餐選擇頁；
使用者選擇到店時間和套餐内容；
進入支付頁面進行支付；
告知使用者預訂結果。
對于使用者來說，預訂流程中需要決策的内容非常多，如：商戶、時間、包型、套餐等；我們在産品設計時，對使用者的決策流程進行了簡化，使用者在三頁之内就可以選擇完所有的内容。簡單流暢的購買流程、較少的決策環節，對提升使用者的購買體驗非常有幫助，舉個例子：曾經在剛與美團合并時，我們沒法直接修改美團的商戶詳情頁，就通過在商戶詳情頁中增加一個連結鍊到價目表頁面上；随着融合的深入我們對美團的商戶詳情頁進行改版，将價目表嵌入到商戶詳情頁後，美團側的成交量在一天内增加了50%以上。
在簡單的流程背後，是ktv業務部成立一年以來對業務的多次探索。一年左右的時間，ktv預訂業務經曆了四輪比較大的疊代：
1.在ktv預訂業務開發之初，ktv預訂是通過商家自助錄單+ivr(聲訊電話)通知商家接單的方式進行，每當有新使用者下單時，都向商家撥打一個ivr電話播報到店時間、需要的包型、使用者的手機号等資訊，然後由商家決定是否接待。這種方式商家有最大的自由度可以決定是否接單，但對于使用者來說從支付成功到預訂成功(或失敗)的時間間隔會比較長，使用者體驗并不是很好。
2. 第二個階段我們嘗試引入了庫存模式：商家事先預留一部分庫存給點評平台售賣，當使用者下單的時候，如果庫存尚未售賣完成，則直接扣減庫存并告知商家；然後将ivr通知商家的方式作為庫存模式的降級：當庫存售光的時候再采用之前的ivr接單方式讓商家決定是否接單。在這個階段，我們也對商家接單的途徑進行了擴充，除了ivr之外，增加了商戶背景通知和點評管家通知能通知方式，并讓使用者自行決定采用哪種方式通知。
3. 第三個階段對售賣方式進行了擴充：增加了按人數售賣的方式(主要針對華南部分城市ktv+自助餐捆綁銷售的場景)、增加了時間段包段模式；
4. 第四個階段，我們承接了美團app上的ktv預訂業務，在展示側，為商家提供了poi++等增值服務；在交易側，進行了三方系統直連的探索和售中客服的介入，同時、引入了房态管理的概念，擴充了原有的ktv庫存的概念。
ktv預訂平台的整體流程與團購的流程比較類似，都包含上單、稽核、展示、下單、批價、支付、消費、退款、結算等流程。差別于傳統團購模式，在展示環節和下單環節，我們需要關注使用者選擇的日期、時段、包型、套餐等資訊；從訂單次元上看，ktv預訂訂單所包含的内容比傳統的團購包含的内容會更豐富一些；另外，在支付成功之後，差別于傳統團購直接扣減庫存的方式，ktv預訂會走一個完整的預訂流程，才能決定商家是否接受該使用者的訂單。
目前，ktv預訂平台服務的對象有銷售、營運、使用者、售中客服、商戶等。ktv預訂平台訂單錄入采用銷售提報的形式發起，通過營運稽核後，訂單會被放到線上供使用者購買；營運可以在ktv預訂平台上進行預訂方案稽核、廣告釋出、活動和立減釋出等；會員參與購買流程并支付；支付後如果商家拒絕或者逾時未對訂單做出響應，售中客服就回介入聯系商家，挽回這些失敗的訂單；商戶可以在平台上進行訂單查詢、驗證、對賬，釋出自己的預訂折扣、自促活動等，進而提高自己的曝光量。
ktv預訂平台在設計和開發時，以微服務的形式進行系統組織，主要分為 各種service組成的服務層 和 web接口/界面組成的展示層。
在服務層：針對ktv預訂平台的流程，有admin-service(稽核、營運) product-service(展示) order-service(下單) checkout-service(預訂) verify-service(消費) refund-service(退款)等；這些服務在運作時又依賴于更底層的服務，如 promo-service(優惠)、stock-service(房态、預訂庫存)、gateway-service(預訂三方對接)、notify-service(預訂商家通知)、in-sale-service(預訂售中客服)等。
在展示層：我們分别向使用者、商戶、營運、售中客服等提供對應的展示界面。展示側在開發的時候，各個web端隻提供前端調用的jsonp接口，采用動靜分離的形式完成界面與邏輯的解耦以及接口的複用，舉例來說：訂單查詢、驗證的jsonp接口，可以同時為pc上的商戶背景和手機上的點評管家提供資料源。
在接下來的介紹開始前，首先簡單介紹下ktv預訂的房态模型。房态模型會影響展示側的展示方式、是否可以生成新訂單、訂單下單成功後如何走預訂流程。
既然是預訂業務，在預訂前就需要确定某個事情發生的時間、地點。對于ktv預訂，時間次元即為 幾月幾日幾點幾分到店、幾點幾分離店；地點次元即為選擇什麼樣的包型。基于此，就抽象出了ktv預訂的房态模型：
某一天、某個時間段、某個包型可能會有三種狀态：有房可售賣、需要商家接單确認、滿房狀态。房态的轉換，發生在ktv預訂平台發生預訂行為後或者商家、售中平台對庫存進行修改時。
對于庫存類的訂單，當有一個預訂成功發生後，庫存扣減1，當庫存扣光後，某個特定時間段的某個包型就切換到接單狀态（之是以這樣做是因為商戶隻會給我們留較少的保底庫存，還會有線下未售光的包房）；接單狀态有訂單發起預訂，并且商家不接單的總數超過某個值後，這個時段的包型就切換到了滿房狀态，将不會再有新的預訂訂單進入到這個時段的包型。
商家和售中客服可以調整具體某一天某個包型的房态。商家可以從有房狀态切換為滿房狀态、也可以在滿房狀态和接單中狀态直接互相切換。
不難發現，ktv預訂的房态是周期性生成的，是以在房态模型存儲時，會劃分為房态規則表和每日房态表兩張表。當各個調用方調用每日房态表查詢某個特定時段的房态時，如果此時段的房态尚未生成，則會從房态規則表中複制一份資料到每日房态表。
預訂産品的sku粒度比傳統的團購産品要複雜的多，這一點是在設計預訂系統時候的一項挑戰。
在ktv預訂場景下，一個sku需要細化到某一天、某一個包型在某一個時間段的某個套餐。我們在資料落地時設計了product、 product-item、product-item-attribute三張表用來存儲資料。其中 product表用來給所有的item分組，item與item-attr是對多的關系，attribute表用于補充item表中的屬性。這樣設計的存儲結構在系統需求擴充的時候比較靈活：如我們在ktv預訂系統研發之初，是沒有套餐模式售賣的，當後來加入套餐售賣模式後，在不改變表結構的情況下，隻需要在attr表裡面增加一種新的屬性，即可對新業務進行支援。
當ktv預訂的内容展示在使用者的界面上時，又是另外一種樣式：分為價目表頁面展示 和 套餐選擇頁展示。其中價目表頁面隻關注周x，某個時段，某種包型的最低價格；使用者選擇包型後，進入套餐選擇頁，關注點則落在了套餐類型上（詳見第三頁的流程2，3），為了簡化邏輯，我們在将存儲層的資料轉換為表現層的資料時，我們抽象出了一個 itemgroup的概念：将同一個周次、同一個時段、同一個包型的不同套餐歸為一個itemgroup，itemgroup用于價目表的展示；itemgroup裡面的内容用于套餐選擇頁展示。
在實際上單的階段，一個itemgroup下的所有套餐，共享一個庫存單元。
接下來介紹下ktv預訂訂單模型的演變。ktv預訂業務的訂單模型，大體分為四個階段。在演變過程中，資料結構越來越複雜，進行訂單狀态修改、訂單狀态查詢時候涉及到的子系統、查詢接口等也慢慢細化。下面對四個階段的演變分别作出說明。
在ktv預訂産品開發之初，ktv業務模型還不清晰，為了完成快速線上驗證，我們将訂單可能出現的所有狀态全部雜糅到一個字段上，導緻訂單狀态既包含預訂流程的狀态、也雜合了支付流程、消費流程、退款流程等多個流程的狀态。
這種狀态存在一個很大的問題就是沒法進行狀态回溯和流程梳理，打個比方，如果一個訂單經曆了這樣一個流程：支付成功(1)->預訂失敗(3)->系統自動發起退款(4)->退款成功(5)；那麼它的流程和：支付成功(1)->預訂成功(2)->使用者自己發起退款(4)->退款成功(5)這條路徑的終态一緻，單從資料庫中的訂單終态，沒法區分這兩個訂單在預訂流程上的差別。
第二個階段為業務擴充階段。在這個階段，系統需要快速地支援新的業務需求，如預訂流程不再是簡單的ivr聲訊電話通知商家接單的模式、還加入了庫存模式，在有庫存的情況下需要先扣減庫存，當沒有庫存的時候才需要用多種方式通知到商家由商家決定是否接單。為了支援這些業務，并且利于業務流程的回溯，在開發進度的壓力下，我們對訂單表進行了擴充，增加了reservestatus、verifystatus、refundstatus等字段，進而最業務流程也做了部分支援。
這次訂單模型演變快速解決了業務擴張的問題。如後來當我們引入了系統直連、售中挽回等多種預訂模型時，單憑借reservestatus已經不足以支援各個預訂模式的業務切換需求了。于是我們開始嘗試将不同的業務資料存放在它們自己的資料表中，于是便有了第三個階段。
第三個階段時候，ktv預訂的訂單量已經達到了一定的規模，預訂、退款等流程在進一步擴充，将雜糅在訂單表中的資料拆分到各個服務下面，不同的服務根據自身的實際場景進行資料組織。為了簡化訂單服務，訂單狀态隻保留了訂單聲明周期中的關鍵節點如支付成功、預訂成功、消費成功等節點；由于退款會發生在訂生命周期的各個階段，在訂單表中也備援了一份退款結果的資料，進而友善訂單服務的各種查詢場景。
這個階段的架構能夠基本支援ktv預訂業務，訂單表的查詢壓力也分擔到了各個系統。如結算過程進行結算時依賴消費記錄表和退款記錄表，無需再直接從訂單表上查詢資料。
為了進一步提高訂單服務的穩定性，我們又嘗試将訂單服務拆分為訂單建立、更新服務 和 訂單查詢服務，通過讀寫分離保證系統的可靠性，防止因為大量的查詢擁堵導緻訂單建立、更新流程受到影響；也防止查詢服務挂掉或者建立服務挂掉保證訂單的所有邏輯都不可用。
在實際應用場景中，各個調用方不止關注訂單的狀态，還會去關注訂單狀态變化過程中都産生了哪些流程上的變化，如在預訂成功時，調用方會關注是三方直連預訂成功的還是扣減庫存預訂成功的等；在消費成功後，業務方會關注是誰在什麼平台上發起的消費。要拼裝出諸如“預訂成功，已消費，消費後由客服發起退款，并退款成功” 這樣一個訂單狀态描述，除了依賴訂單表中的資料外、還需要消費資料、退款資料等資料的支援。
ktv預訂面向的調用方有使用者、商戶、營運、售中、售後等很多個，在綜合查詢訂單流程和訂單狀态時，每個調用方都需要了解訂單狀态、預訂流程、消費流程、退款流程等業務流程，這就導緻了很多功能的重複解釋和重複開發，代價太大。于是我們在原有的所有服務基礎上，增加了一個綜合查詢服務：綜合查詢服務用于應對不同調用方的查詢需求，并隔離調用方和複雜的業務邏輯。
目前ktv的訂單模型正處于第三和第四階段的中間階段，正在逐漸完善綜合查詢服務。對于近期的業務，第四個階段的訂單模型已經可以滿足ktv預訂業務的訂單查詢需求了。
下面對ktv預訂流程的演變做簡單的說明
在ktv預訂的業務模型演進過程中，預訂流程做過一次比較大的重構。
ktv1.0探索階段，當訂單支付成功後、直接使用ivr通知商家，由商家決定接單還是拒絕、或者商家逾時無應答放棄訂單。此時的預訂流程非常簡單，在一個checkout服務中就可以搞定。
ktv2.0階段為了縮短訂單預訂成功的時間、并且盡量減少對商家的打擾，我們引入了庫存模式：當有庫存時，首先消耗庫存訂單，這種訂單無需商家接單，在使用者支付成功後很短的時間内即可完成預訂。與此同時，商家接單模式下通知商家的管道除了原有的ivr電話外，增加了商戶背景和點評管家等管道，這時候我們将商家通知的流程從checkout服務中拆分出來，作為notify服務，負責使用各種管道對商家進行通知，并提供給商家通知方式配置的功能。
這兩個階段相對來說，項目的結構都比較簡單，但當三方系統直連和售中客服管道接入後，checkout服務中的簡單邏輯判斷就不符合要求了。
在近期的一次疊代過程中，增加了三方系統直連預訂模式和售中客服挽回訂單模式。
三方系統直連指的是直接與第三方ktv商戶的erp對接庫存，當有新的預訂請求發起時，直接向第三方平台發起扣減庫存請求，并将預訂人、預訂時間等相關資訊一并發送到第三方平台。這種對接方式應該是最友善的ktv預訂方式，但受ktv行業系統研發能力所限，隻有一部分ktv能采取此種方式進行預訂，是以ktv2.0階段的庫存方案和通知接單方案仍将繼續存留。
售中客服挽回訂單指的是通知商戶接單商戶拒絕或者逾時未接單的情況下，售中客服主動聯系商家咨詢其拒絕或者錯過訂單的原因，并最大程度地挽回訂單。售中客服介入的預訂管道在酒店預訂、旅遊産品預訂等場景中已經有了一些比較成熟的應用，ktv預訂業務引入售中客服這個流程，事實證明對提高商戶的接單量也具有很大的促進作用。
在加入三方直連和售中客服模式後，預訂流程就變得更加複雜了（如上圖）：訂單支付成功後，首先判斷是三方直連的訂單還是傳統庫存模式的訂單：如果是三方直連的訂單，會直接向第三方平台發起預訂，第三方平台會告知預訂成功或失敗，有一種異常情況是當第三方平台異常時，三方直連模式将會降級為商家接單模式；庫存模式在有庫存的情況下直接扣減庫存、在沒有庫存的情況下通知商家接單；當商家拒單或者逾時未接單的時候，會将訂單流入到售中客服的訂單池中，由售中客服聯系商家看是否能夠挽回訂單。這樣看起來，比ktv2.0時代的預訂流程複雜了許多。
為了簡化模型，我們對庫存模式下走庫存流程還是接單流程進行了抽象，将通知商戶接單的模式當做是庫存扣減模式的一種服務降級（如上圖所示），這樣調整後，模型得到了一定的簡化：每一種預訂模式可以有他的一種降級預訂模式、當目前預訂模式有明确的預訂結果時，預訂流程結束、當沒有确定的預訂結果時，切換到其對應的降級模式重新發起預訂。因為每一種模式都隻有一個後繼的降級模式，是以checkout的流程就比較好抽象了。
抽象後的預訂流程checkout子產品執行流程如上圖所示：當訂單支付成功向預訂平台發起預訂時，預訂平台根據參數判定目前使用的預訂管道、判斷完成後向對應管道發起異步預訂流程并在checkout表中記錄流程執行狀态；當特定的管道傳回預訂結果後，對預訂結果進行判定：如果預訂結果為預訂成功 或 預訂失敗的終态時，預訂流程結束；當預訂結果不為終态時，則去查詢目前管道的降級管道，查詢到降級管道後，向降級管道再次發起預訂。
此次抽象後，ktv預訂流程被拆分成了5個服務：checkout服務（用來協調責任鍊上的執行流程）、gateway（用來與三方系統進行直連）、stock（用來管理房态）、notify（用來采用各種管道通知商家接單）、in-sale（用來進行售中客服接單）。每個服務的權責比較清晰，耦合度也比較低：如當需要增加一種新的三方直連方案時，隻需要在gateway服務中做出擴充；當需要擴充一種新的商家通知方式隻需要在notify服務中進行相關開發即可；當有新的預訂方式增加時，在checkout的調用責任鍊中再增加一個新的環節即可。整個系統的擴充性非常良好。
以上是我對ktv業務部一年的業務發展過程中我們經曆過的一些業務上的變化和重構的了解。自己在網際網路行業的經驗還不夠豐富，對業務演進的總結和了解還有一些不全面的地方，希望大家可以批評指正。
本文來自<b>中生代技術群</b><b> freshmantechnology</b>
本文分享者簡介：
<b>由文超</b>，2014年畢業于江南大學。畢業後在聯想集團mbg做手機傳感器驅動的研發，15年轉行網際網路加入點評，現就職于新美大ktv業務部。