怎麼做票務系統，不難不難不難

近期要離開票務team去別的team了，對自己不算短的票務相關產品工作做了一下總結，希望可以幫到後續做票務相關產品工作的同學。

有關產品策略

不同的票務有不同的產品策略，下面簡單說一下幾個大的趨勢

• 服務化

票務系統是一個為為用戶提供的在線購票服務，讓用戶可以更方便地進行購票，所以為用戶提供更好的服務是最重要的方向。服務包括信息服務、個性化服務、流程服務等等

• 內容化

內容化是老生常談的話題。票務項目本身自帶內容屬性，很好地利用之形成內容社區也是個很好的方向，不僅僅大麥推出了專門生產內容的發現模塊，傳統的電商平台也在朝內容化轉型

• 生活化

看展看演唱會是一種生活方式，票務平台可以成為生活化的導航平台，通過平台宣導這種理念。

• 業務交叉化

可以交叉商品售賣、直播等業務，提升票務平台的廣度和魅力。

有關票務系統的設計

在設計票務系統前我們梳理一下業務流程

用戶系統不必贅述了，我們重點看一下項目、票和現場

• 項目

票務系統是服務於一個個項目的，在票務系統後台需要有專門的地方去管理項目，簡單拆解一下項目的結構

項目基本信息有項目名、項目時間、項目地點、項目介紹、場館和嘉賓；業務信息有場次和票種。對於基本信息在創建場館的時候進行初始化，場館和嘉賓這些可復用的信息可在單獨的地方進行管理，並可以進行更豐富內容的運營，很多票務網站已經有場館和嘉賓詳情頁。

場次和票種是項目進行售賣最必不可少的兩項。場次是項目活動的時間層售賣對象，一個項目可能會有一個或多個場次，如五月天上海演唱會，有5個場次，用戶在決定購買五月天演唱會後，也要再選擇5個場次中的一個場次進行購買。一個項目用戶購票還要進行票種的選擇，如VIP票、A級票等等。場次和票種這兩個銷售屬性共同組合成票務商品的sku。

場次需包含場次名、場次時間、場次售賣時間、場次類型（坐票/站票）、出票方式（電子票、紙質票）、出票方式（快遞、無需配送）等

票種需包含票種名、票種顏色、票種描述等

項目基本信息完成後，還需要完善項目的銷售信息，需設置sku的庫存、售價等信息。若場次是選座項目，需要通過畫座位進行庫存的生成，選座場次的創建較複雜，後續可專門進行講解。

• 票

票務系統終歸還是要出票的。出票的類型有兩種，用戶前台購買出票和票務系統後台出票。

用戶前台購買出票是使用最多的出票方式。用戶購票後產生訂單，隨訂單生成二維碼電子票或線下配送紙質票給用戶。對應的需要要整個前台票務展示、購買訂單流程。這邊需要特別注意的是搶票場景下的系統壓力處理和防黃牛處理。通過預約或驗證碼等手段都可以進行一些壓力分流，而防黃牛則是票務永恆的主題，業務上可以通過限制購票用戶等級，限制購票數量等手段，而技術上需要進行ip、黑名單等監控去預防刷票。

多數業務還需要後台直接出票的功能。為了更好地管理出票流程，可產生專門管理票的模塊，之前叫憑證管理。前台出票生成訂單並生成憑證，後台出票僅生成憑證不生成訂單，憑證中僅包含票相關信息，無用戶信息、付款等訂單信息。

• 現場

完整的票務系統需要包含現場核銷流程，用戶持票去現場後，核銷端需要掃描用戶的二維碼去驗證票的真偽和是否重複入場等。

在設計核銷端的時候，一定要考慮現場的弱網情況。一般核銷工具都會有區域網或離線方案。

區域網是在活動現場假設區域網伺服器，設備訪問區域網的伺服器進行檢票。優點是，不需要依賴網路，設備與設備之間可即時進行同步，缺點是伺服器的數據可能不是最新的，遇到現場票的情況無法較好地應對。

離線檢票也有兩種方案，第一種是把數據直接下載到本地，設備在弱網的時候，訪問本地的數據，進行檢票。另一種是根據加密的二維碼的數據解析項目場次座位信息，再直接進行核銷。離線檢票的優點的是檢票速度快，不依賴網路且無需進行伺服器部署，缺點是單機之間在弱網的情況下不好進行同步，且較易造成信息的泄漏。

整個流程搭建完成後，一個票務系統的雛形便創建了，後面就是根據產品和運營策略去慢慢完善。