編輯導(dǎo)語：訂單系統(tǒng)連接了用戶和商家，用戶可以通過訂單看到商品購買詳情，商家則可以通過訂單看到購買用戶信息等。而訂單類型則是訂單系統(tǒng)中很重要的一個環(huán)節(jié)，本篇文章將對訂單類型的多樣化展開一系列的講述，快來一起看看吧。

訂單類型分為常規(guī)訂單、拼團訂單、預(yù)約（定金）訂單、尾款訂單、贈送訂單等

為什么會衍生出這么這么多訂單類型？如何定義一個新的訂單類型呢，不同的訂單類型會影響什么？

且聽我慢慢道來~

訂單類型的多樣化可不是訂單系統(tǒng)自己拍腦袋想出來的。

一定是前置有業(yè)務(wù)的各種營銷訴求，如拼團、定金活動，又或者是為了促成轉(zhuǎn)化，如直接給用戶生成訂單等，基于這些背景，訂單系統(tǒng)作為交易鏈路中核心的一環(huán)，必須配合改造給予支持，因此衍生出了多種訂單類型，下面我將逐個解釋下每種訂單類型以及應(yīng)用場景。

一、交易流程

一般交易流程主要是商品建品、下單、生成訂單、支付、履約等主要核心環(huán)節(jié)。

如下圖所示，之前介紹過這部分的邏輯，這里不多贅述，感興趣的小伙伴可詳看歷史文章《最底層的交易訂單，這些知識點你知道嗎》~

二、如何定義是否是一個新的訂單類型

那么在什么時候，我們就認(rèn)為這是一個新的訂單類型呢？

一般認(rèn)為在整個交易流程鏈路中，只要售賣流程/環(huán)節(jié)與原有的不一致時，就可以認(rèn)為是一個新的訂單類型，若售賣流程/環(huán)節(jié)與其他無差，只是調(diào)用方不同，一般情況下不作為一個單獨的訂單類型。

這里要通過代下單訂單舉例，代下單的模式簡單可以理解為下圖：

什么是代下單訂單呢？

代下單模式是指上層業(yè)務(wù)系統(tǒng)（目前比較常見的如crm系統(tǒng)、客服系統(tǒng)等），因為客服、銷售可以更快觸達(dá)用戶，通過代下單模式在后臺為代替用戶下單，用戶在C端直接進(jìn)行支付，從而提高轉(zhuǎn)化率。

在這個流程中，業(yè)務(wù)系統(tǒng)仍然調(diào)用的統(tǒng)一的下單接口，交易鏈路和履約流程都未發(fā)生變化，因此在我理解代下單訂單并不算是一種新的訂單類型。

三、常見的不同的訂單類型枚舉

四、詳細(xì)說明

1. 拼團訂單

拼團活動也是近幾年電商的一種新玩法：單個購買單價相對于較高，和好友一起組成團購買，則可以享受團購優(yōu)惠價，對用戶而言，享受到了更低價；對平臺而言，通過拼團這種方式可以增加商品曝光率，提升商品銷量

下面來看下拼團單的主要交易鏈路：

• 交易：用戶下單后，交易進(jìn)行數(shù)據(jù)一致性校驗，查詢商品
• 庫存：通過數(shù)據(jù)一致性校驗后，鎖定庫存，支付后扣除庫存
• 促銷：促銷系統(tǒng)，將命中的促銷活動團ID等信息返回上游
• 訂單：生成訂單，記錄促銷活動團ID、鎖定定金權(quán)益
• 履約：未成團訂單不履約，訂單去查促銷活動，發(fā)現(xiàn)已成團后，更新訂單狀態(tài)并創(chuàng)建履約單（或促銷系統(tǒng)通知訂單可以下發(fā)履約）
• 售后：售后場景和常規(guī)訂單一樣，根據(jù)售后策略進(jìn)行售后處理

2. 預(yù)約訂單&尾款訂單

（1）預(yù)約單

預(yù)約訂單也被成為定金訂單，在我的印象里最早是某寶在大促時推出的一種新型玩法：對用戶而言，避免活動當(dāng)天太火爆，商品庫存不足，而自己手速太慢，錯失寶貝；對商家而言，對商品庫存有了更多主動權(quán)，避免不必要的囤積或缺貨情況。

就如我們?nèi)粘Ｉ钪蓄A(yù)定一個蛋糕，或者預(yù)定一個包間一樣，先支付一筆錢，「定了」某個東西，當(dāng)實際交付的時候，再將剩下的錢支付完，當(dāng)然，若此時你反悔不想購買了，那定金一般是不退的。

線上購物也是一樣的，用戶可以通過「預(yù)約付定金」的方式，將一筆款，分為定金+尾款，預(yù)先支付定金后，在一定時間內(nèi)支付尾款即可。

為了增加「預(yù)約付定金」活動的優(yōu)勢，一般情況下，定金都是可以「膨脹」的，那么實際支付尾款的時候，尾款=商品總金額-定金-膨脹金

舉個例子，某個sku售價200，定金交50，可膨脹50，那么尾款=200—50-50=100， 對用戶而言，實付金額=定金+尾款=150元，比售價更優(yōu)惠，膨脹力度越大，優(yōu)惠力度就越大。

下面來看下預(yù)約單的主要交易鏈路：

• 交易：用戶下單后，交易進(jìn)行數(shù)據(jù)一致性校驗，查詢商品
• 庫存：通過數(shù)據(jù)一致性校驗后，鎖定庫存，支付后扣除庫存
• 促銷：促銷系統(tǒng)，將命中的定金促銷ID等信息返回上游
• 訂單：生成訂單，記錄定金促銷ID、鎖定定金權(quán)益
• 履約：定金訂單不履約，因為對于定金訂單而言，購買的是「權(quán)益」
• 售后：不可部分退款，可退定金，也有的平臺售后策略為逾期未支付尾款不可單獨退定金

（2）尾款單

所謂尾款單，其實就是把用戶「預(yù)約的權(quán)益」進(jìn)行最終交付。

尾款單其實和常規(guī)訂單沒有太多區(qū)別，主要的區(qū)別點在于尾款單的算價服務(wù)需要基于定金訂單進(jìn)行算價，尾款單的履約項也是基于定金訂單來進(jìn)行的。

下面來看下尾款單的主要交易鏈路：

• 交易：用戶下單后，交易進(jìn)行數(shù)據(jù)一致性校驗，查詢同一筆sku下，命中的定金促銷活動以及定金權(quán)益，進(jìn)行算價、以及通過查詢活動期限進(jìn)行校驗
• 庫存：通過數(shù)據(jù)一致性校驗后，不鎖定庫存，因為定金訂單已經(jīng)鎖定庫存了，所以尾款單不再鎖定
• 促銷：促銷系統(tǒng)，將命中的定金促銷ID等信息返回上游
• 訂單：生成訂單，記錄關(guān)聯(lián)的定金訂單ID
• 履約：尾款訂單支付后即履約
• 售后：定金+尾款一起退款

3. 贈送訂單

這里的贈送訂單不同于用戶下單后命中滿贈或買贈活動而產(chǎn)生的訂單。

這里的贈送訂單是指系統(tǒng)自動為用戶生成的一筆贈品單/0元單，大多數(shù)是用來拉新、引流的贈品單，用戶是無感知的。

舉個例子同樣是0元單，一個是贈送訂單，一個是用戶主動下單若因為命中滿減最終實付金額是0元，因為兩者的交易鏈路不同，一般認(rèn)為這是兩種不同的交易類型。

雖然整體來看贈送訂單的各個系統(tǒng)交互和常規(guī)訂單是沒有區(qū)別的，但是在售后場景下，贈送訂單一般都是不支持售后的。

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

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