報價到收款流程圖（由商機到收妥款項）

甚麼是報價到收款流程圖（由商機到收妥款項）流程

大部分報價到收款的問題都不是定價問題，而是版本問題。報了甚麼價、簽了甚麼約、入了甚麼帳、開了甚麼票，是四份分別存放在四個系統裡的文件，而在相當多的公司裡，當中沒有任何兩份是對得上的。一個折扣在通話中讓了出去，卻從來沒有寫進訂購單。一項付款條件在改稿中被修改，卻從來沒有傳到開票時間表。一個里程碑交付了，沒有人告訴財務可以開票，於是一張三月本可發出的發票拖到六月才發出，付款時限就此遲了三個月才開始計算。每一道裂縫單看都很小，而每一道不是蠶食毛利，就是拖長天數。第二種失效，是一道只量度較價目表折讓多少個百分點的審批階梯。延長付款期、分段遞增的承購承諾、免費的專業服務、封頂的調價安排以及度身訂造的服務水平，全部都在讓出毛利，卻從來不會被登記為折扣；於是最應該被細看的交易一路暢通無阻，而一個例行的一成折扣，卻在等一位正在放假的總監。這兩種失效都住在職能與職能之間的接縫上，而不是住在職能內部——這正是為甚麼只有把整個循環由頭到尾畫出來，它們才會浮現。

本圖橫跨由合格商機到收妥現金的整條弧線，但它刻意在前半段畫得深、在後半段畫得淺。銷售動作本身——需求探詢、示範、技術驗證，以及交易被納入其中的預測——畫在 /yue/templates/銷售管道流程 上；而商機之前的一切，由線索取得、評分到銷售接納的交接，則放在 /yue/templates/銷售線索資格評定流程 上。合約在授權規定、簽署與存檔之間走的那條內部路線，本身就是一個獨立的流程，畫在 /yue/templates/合約審批流程 上；在本圖裡，它被壓縮成客戶簽署訂購單這一步。往下游看，「按訂單跟進履行進度」只是一個方格，代表的是整個 /yue/templates/訂單履行流程。而「已逾期」分支不會在這裡重畫一次追收階梯，它直接離開本圖，前往 /yue/templates/應收帳款流程。最近的鄰居是 /yue/templates/訂單到收款流程 ，它由已接納的訂單開始，深入處理信貸暫緩、交付憑證、少付款與追收。報價到收款開始得更早，由商機開始，而它的細節落在訂單存在之前就已經發生的定價與審批工作上。商務前半段請用本頁；履行與收款那半段請用訂單到收款流程。

這裡有三個建模決定，在成文的定價政策中通常是隱含的。第一，折扣管控是一道階梯，而不是單一關卡：「折扣是否在客戶經理權限內？」向上交給「銷售經理是否批准該折扣？」，而後者有三個出口——「批准」、「超出其權限」和「駁回」——所以把一宗交易呈報上去和駁回一宗交易是兩種不同的結果，只有駁回才會落到「在已批准區間內重新定價」。修訂亦不是繞過階梯的辦法：「修訂報價並重新定價」會回到第一道測試，因為縮短年期或在付款條件上讓一步，都可能把一宗交易推進客戶經理從來無權批准的級別。第二，價格與文本是分開判定的。「是否要求非標準條款？」由交易審核組在法務介入之前就回答，因此一宗用標準文本的交易永遠不必排在改稿後面等候，而法務被問的是條款，不是價格。第三，「履行是否已確認可開票？」同時放行收入分錄與發票，令收入跟隨的是已履行的義務，而不是稍後才到帳的現金；而它的「尚未」迴路需要有人為它計算帳齡，因為一張已交付卻未開票的訂單，不會惹來任何人投訴。

本流程圖涵蓋的內容

本範本包含

• 六條泳道——客戶、客戶經理、銷售經理、交易審核組、法務與財務／收入——鋪在五個階段上：報價編製、審批、報價與接納、訂單與入帳，以及開票與收款。
• 報價編製刻意只有一步：「設定組合並定出報價」把產品組合、合約年期與數量綁定到現行版本的價目表上，令日後的訂購單帶著財務真的開得出票的產品編號。
• 一道三層的折扣審批階梯——「折扣是否在客戶經理權限內？」，然後是「銷售經理是否批准該折扣？」並為超出其本人權限的交易另設一條分支，再到「交易審核組是否批准該折扣？」——其中任何一位審批人的駁回都會落到「在已批准區間內重新定價」，而該步驟回到「設定組合並定出報價」，再走一次整道階梯。
• 一條獨立的條款路線：「是否要求非標準條款？」把標準文本直接送去發出報價，把非標準的要求送往「審閱非標準條款」和「法務是否接受該等條款？」，而後者的修改分支會經「與買方議定備選條款措辭」折返，重新進入法務審閱。
• 「客戶是否接納報價？」處有三個真實的結果：接納的走向簽署，要求修改的經「修訂報價並重新定價」折返到第一道折扣測試，而失效的報價則終止於「報價以失單或過期結案」。
• 收款尾段：「信貸與開票檢查是否通過？」帶一條預付款迴路，「訂單入帳並放行履行」，然後由關卡「履行是否已確認可開票？」同時放行「按合約認列收入」和「就該里程碑開出發票」，最終走到「款項已收妥，收入已認列」，或在「轉由應收帳款繼續追收」處交接出去。

何時使用本範本

• 你們正在導入或更換 CPQ（設定、定價、報價）系統，需要在任何人動手設定規則之前，先把審批階梯、條款路線和訂單交接在紙上議定下來。
• 你們平均一宗交易要花好幾天才報得出價，卻說不出時間是花在設定組合上、等折扣審批人上，還是花在法務審閱一些本來就不算非標準的條款上。
• 財務不斷發現一些幾個月前已經交付、卻從來沒有開過票的訂單，你們需要把開票觸發條件和已入帳但未開票的迴路畫出來，而不是假定它存在。
• 你們正在制訂定價與授權規定，希望把各級門檻掛到一張圖上——誰決定甚麼、按甚麼次序、駁回之後又會怎樣。
• 核數師或新上任的財務總監問起某一個價格是誰批准的，而報價紀錄上並沒有寫明是誰批准、何時批准、批准的又是哪一個版本。

運作方式

1. 把泳道改成你們自己的職能

   把客戶、客戶經理、銷售經理、交易審核組、法務和財務／收入，換成你們真正擁有的角色。不是每一間公司都有交易審核組：如果毛利與先例是由營運支援、商務總監或財務總監來判斷，那就把泳道改名，而不是假裝存在一個並不存在的團隊。如果法務是外聘律師，就保留這條泳道，並把周轉時間寫進該步驟的備註，因為外部審閱會改變這個流程能向買方承諾甚麼。只有在同一個人真的兼任兩份工作時，才把泳道合併。

2. 把折扣階梯寫成數字

   在每一層填上數字之前，這道階梯都是死的。訂明客戶經理可以自行讓出多少、銷售經理的權限到哪裡為止，以及甚麼只有交易審核組或財務總監才可以簽批；並且同時用較價目表折讓的百分比和一個絕對金額來表達，好讓一宗四百萬港元交易上的百分之五折扣，不會被當成例行公事。然後決定這道階梯實際量度的是甚麼：是整段承購年期內的實際折扣率，以及扣除交付成本之後剩下的毛利，而不是第一年的表面百分比。

3. 界定非標準究竟指甚麼

   「是否要求非標準條款？」只有在有人維護一份清單時才起作用。寫下標準訂購單的內容、買方最常施壓的那些條款——責任上限、賠償保證、任意終止權、資料處理、自動續期——各自的預先批准備選立場，以及凡是超出這些範圍就送法務這條規則。把備選立場公佈給銷售團隊，令他們可以在通話當場讓出一個已獲預先批准的立場，完全不必經過審閱。每半年按你們實際收到的改稿意見檢討這份清單一次，而不是按你們擔心會收到的那些。

4. 令報價文件自己帶著審批紀錄

   決定一份已發出的報價單必須顯示甚麼：版本編號、有效期、貨幣與稅務處理、包括甚麼以及明確地不包括甚麼、開票時間表，以及它所帶的審批紀錄連同審批人和日期。修訂要另立版本而不是覆蓋原件，令紀錄能夠顯示客戶簽的是哪一份報價、當時獲批准的又是甚麼。這一步就是日後回答核數提問的那一步；現在把它建好幾乎不花成本，事後重建則代價極大。

5. 訂定開票觸發條件，並為積壓計算帳齡

   按產品逐項決定「履行是否已確認可開票？」需要甚麼：一份簽收的送貨單、一份驗收證明、一個上線日期、一個用量讀數，又或者只是訂閱的起始日。把它在入帳時就寫進訂單，而不是等到開票時才來爭論；並且留意同一項確認亦會放行收入分錄，所以定義寫得鬆，動的是兩個數字而不是一個。然後為這個迴路指定負責人和一份報表：一份每週的清單，列出里程碑已到期而尚未開票的已入帳訂單，由財務閱讀，而不是由交付工作的那個人閱讀，並訂明一個帳齡上限，超過之後每一行剩下的紀錄都要有名有姓。

6. 跟真正做這件事的人走一次，然後發佈一個版本

   把完成的圖拿給一位客戶經理、一位交易審核組的審閱人、看改稿意見的那位律師，以及開發票的那個人，用兩宗真實交易走一次——一宗一路暢通，一宗在審批迴路裡繞了兩圈。按他們實際的做法改正這張圖，而不是按政策寫的做法。然後把該版本經審批發佈，並保留此前的版本，令日後打開它的人知道自己讀的是哪一版的定價政策。

常見問題

報價到收款流程包含哪些步驟？

在本圖中：一個合格商機被確認為可以報價，方案按現行價目表設定組合並定出報價，折扣先對照客戶經理的權限，超出則沿階梯呈報到銷售經理、再到交易審核組；任何非標準條款交由法務審閱；報價單發出；客戶接納或要求修改；訂購單獲簽署；信貸與開票檢查通過；訂單入帳並放行履行；里程碑獲確認；按合約認列收入並開出發票；款項到帳時銷帳。有兩條路線是離開流程而不是走完流程：失效的報價以失單或過期結案，逾期的發票交由應收帳款接手。令這個流程真正運作的不是這份步驟清單，而是掛在它上面的四樣東西：折扣階梯每一級背後的數字、一份寫明甚麼算非標準條款的定義、甚麼證據才算得上履行完成，以及報價紀錄上關於誰在何時批准了甚麼的記載。

報價到收款與訂單到收款有甚麼分別？

兩者刻意重疊，但切點不同。訂單到收款由你已經接納的訂單開始，涵蓋履行它和收回款項所需的一切：訂單與主資料驗證、信貸暫緩與解除、發貨、交付憑證、開票、收款銷帳、少付款、追收與撇帳。報價到收款開始得更早，由合格商機開始，而它的細節放在創造出這張訂單的商務工作上——設定組合、定價、折扣審批階梯、非標準條款的法務審閱、發出的報價單，以及已簽訂單的入帳。本圖把主幹一直畫到收款，令整條收入鏈在一頁之內看得見，但它把履行與追收壓縮成寥寥幾步。如果你們的問題在價格、文本與審批，請用本頁；如果問題在信貸、交付憑證和收得到錢，請用 /yue/templates/訂單到收款流程。

報價到收款與銷售管道流程有甚麼不同？

銷售管道圖描繪的是銷售動作：需求探詢、需求分析、示範、技術驗證、談判、預測承諾，以及贏單或失單的結果。它由銷售部擁有，止於簽署。報價到收款描繪的則是與之並行、並且延伸到它之後的商務交易：設定了甚麼組合、成本是多少、折扣由誰批准、條款是否標準、入帳了甚麼、何時可以開票，以及現金與收入何時到位。兩者在報價和簽署處共用一條邊界，但它們回答的是不同的問題，而且通常由不同的人擁有——銷售營運與交易審核組擁有報價到收款，銷售管理層擁有管道。如果你們要界定階段、出場準則與預測紀律，請用 /yue/templates/銷售管道流程。如果你們要界定定價權限、報價與開票，請用這一份。

交易審核組（deal desk）是做甚麼的，我們需要嗎？

交易審核組擁有的是一宗交易的商務形狀，而不是客戶關係。它掌管價目表和已批准的折扣區間，對落在區間之外的交易判斷毛利與先例，在律師打開文件之前先就文本作出裁定，並核對已批准的內容是不是真的就是入帳的內容。在本圖中，它承接「交易審核組是否批准該折扣？」處呈報上來的定價，並回答「是否要求非標準條款？」——正因如此，標準文本才可以直接送去發出報價。一旦例外多到銷售經理正在批准一些他們根本無從計價的讓步，或者同一項讓步在三個地區以三種不同的基礎被批出，你們就需要這個職能。低於這個規模，這些工作仍然存在，只是出於預設而不是出於設計地被人做著——那就把正在做的人具名列出，並給他一條泳道。不應該做的，是把它留給談成這宗交易的那位客戶經理。

報價到收款流程在哪裡漏收入？

在四個可以預見的地方。從來不會被登記為折扣的讓步——長付款期、分段遞增的承購承諾、免費的專業服務、封頂的調價安排——會毫髮無損地穿過整道階梯，因為它只量度較價目表折讓多少個百分點。報價發出之後才以口頭或電郵議定的價格，會在從未經過審批的情況下走到訂購單上。已簽署的內容與已入帳的內容逐漸分歧，於是發票、收入攤分表和續期全都繼承了這個差異。而已經交付的工作從來沒有開票，因為交付的人沒有理由想到開票，開票的人又不知道里程碑已經達成。最後一項最大，也最安靜：不會有公司以外的任何人，來追討一張你沒有發出的發票。本圖在它前面放了一道關卡，在它後面放了一個迴路，而這個迴路要有價值，就需要一位負責人和一份帳齡報表。