如何追蹤企業銷售決策單位（DMU）？

企業銷售中的決策單位（Decision-Making Unit，DMU），是負責評估、影響、核准或控制某一項採購條件的個人或群組。要有效追蹤決策單位，不能只建立聯絡人名單，而要把每個單位連到它負責的決策條件、參與成員、所需證據、目前狀態，以及前後相依的其他決定。

例如，醫院採購一套軟體，可能要分別取得使用單位、資訊安全、採購、財務、法務與管理階層的接受或核准。各單位的進度並不同步：臨床流程可能已確認，資安仍在評估，採購正在等待前置條件，預算核准人甚至尚未找出，但 CRM 裡仍只顯示一個「提案中」。

追蹤 DMU 的目的，就是把這些分散的採購進度攤開來看，並辨認現在哪個單位或條件最值得優先處理。

B2B 銷售中的決策單位是什麼？

B2B 決策單位是共同參與或控制某項明確採購決定的一群人。它可能是正式成立的資安審查小組，也可能只是由數位專業角色共同構成、實際上決定方案能否通過的功能性群組。

一個決策單位可能負責：

設定評估標準；
提供專業意見；
評估風險；
核准或拒絕必要條件；
向更高層權責者提出建議；
控制預算、人力、接觸管道或內部程序；
判斷使用者是否願意採用；
授權採購或導入。

「單位」這兩個字很重要，因為有些決定並不屬於一位萬能決策者。

以資安審查為例，系統架構師可能負責評估設計，資安主管負責核准，專案窗口則提供審查需要的資料。三者共同構成管理該項資安條件的實際決策單位。

聯絡人、關係人、部門、DMU、採購決策小組與決策節點有何不同？

這些概念彼此相關，但不能互換使用。

概念	代表什麼	例子	應追蹤內容
個別聯絡人	已記錄基本資料或互動的人	採購經理	身分、職稱、聯絡方式、互動紀錄
關係人	會受到商機影響，或能影響商機的人	影響第一線採用的護理主管	商機角色、顧慮、影響來源、目前立場
部門	客戶正式的組織功能	資訊部門	組織歸屬與正式結構
決策單位（DMU）	共同影響或控制某一項採購條件的人	資安評估單位	成員、角色、標準、狀態、證據、相依關係
採購決策小組	參與較廣泛採購決定的正式或非正式群組	資本支出審查委員會	成員、任務、會議流程、建議權或核准權
決策節點	必須解決的條件、核准或里程碑	資料流程設計獲得接受	負責單位、前置條件、完成證據、狀態

一個部門可以包含數個 DMU，一個人也可以同時參與多個決策單位。採購決策小組可能由不同 DMU 的代表組成。

決策節點描述的是「什麼必須被解決」；決策單位描述的是「誰參與解決這件事」。

若要先完成個人層級的角色與影響力分析，請從++業務關係人地圖++開始。DMU 追蹤則是在這些人物之外，補上群組與決策架構。

為什麼企業銷售不能只用聯絡人清單？

扁平的聯絡人清單會隱藏真正決定商機進度的關係。

假設一筆商機裡已有下列聯絡人：

臨床部門主任；
護理資訊主管；
資安架構師；
採購經理；
財務經理；
營運長。

這份清單仍無法回答：

每個人影響哪一項採購條件？
他是獨立決定，還是代表某個群組？
誰負責評估，誰負責建議，誰才擁有核准權？
每個單位需要哪些資料或證據？
哪個單位正在等待另一個決定？
哪項條件已真正完成？
還有哪個必要單位尚未被辨認？

聯絡人清單也容易讓業務把組織位階誤認成單一路徑的影響力排名。實際上，資安架構師可能控制必要的技術關卡，採購控制商業程序，營運長則控制專案優先度。每個人都重要，但重要的原因不同。

DMU 追蹤不再只問「決策者是誰」，而是改問：

客戶必須完成哪些決定？
哪個單位負責或影響每項決定？
每位成員在單位內扮演什麼角色？
什麼證據才代表條件完成？
哪些後續工作正在等待這項決定？

這種單位層級的視角，能補強++業務商機管理++，讓整體階段底下的組織決策浮出水面。

建立「決策單位追蹤紀錄」

每一個會影響必要採購條件的單位，都應建立一份獨立紀錄。建議包含八個核心欄位。

1. 單位名稱與目的

使用與這筆商機相關的功能性名稱，例如：

臨床流程評估；
資訊安全審查；
採購與供應商建檔；
財務核准；
高階支持；
導入準備。

若同一部門負責數個不同決定，就不要只用部門名稱概括所有工作。

2. 負責或影響的決策條件

清楚寫下必須決定、接受或完成的事項。

資安團隊必須接受新的身分驗證與資料流程設計，採購才能完成供應商建檔。

這比只寫「資訊部門審查」更能引導下一步。

3. 成員及其內部角色

記錄已知成員，以及他們在這個單位內的實際功能：

評估者；
建議者；
核准者；
否決權持有人；
流程協調者；
資訊提供者；
受影響的使用者；
內部支持者；
接觸管道掌握者。

主持會議的人不一定擁有最後決定權。麥克風拿得最久，跟印章握在誰手上，通常是兩回事。

4. 必要資料與評估標準

整理該單位做出決定前需要的文件、證據、討論與判斷標準，例如：

系統架構圖；
資安問卷；
試辦成功標準；
導入人力規劃；
商業效益說明；
報價與付款條件；
合約修訂內容；
供應商資格文件。

若評估標準尚未確認，應直接標成資訊缺口，不要用「應該差不多」替空白欄位穿西裝。

5. 完成證據

定義什麼情況才代表該單位目前的工作已完成。

完成證據可能包括：

書面核准；
文件正式接受；
已記錄的委員會建議；
預算配置獲得確認；
供應商建檔完成；
合約條款獲得同意；
試辦計畫核准；
高階主管正式授權。

「他們看起來很放心」不是完成證據，只是一個穿著商務休閒服的假設。

6. 目前狀態與信心水準

根據證據為每個單位設定狀態，再標記你對該判斷的信心。

可使用的狀態包括：

尚未辨認；
已辨認但無接觸管道；
正在準備資料；
等待前置條件；
評估中；
已提出疑慮；
要求修改；
有條件接受；
已核准或完成；
已拒絕；
暫停；
狀態不明。

證據信心水準可分為：

已確認： 由具有直接權責的人明確說明，或已有可觀察結果；
有依據： 有多項相關互動支持，但仍缺正式確認；
推測： 根據間接線索做出的合理判斷；
未知： 目前沒有足夠資料。

7. 相依關係

記錄該單位開始或完成工作前需要什麼，以及哪些後續工作正在等待它。

資安審查需要更新後的資料流程圖；採購建檔則等待資安核准。

這同時揭露上游輸入與下游影響。

8. 下一個查核點

定義下一項必須取得的可觀察證據。

在 9 月 18 日的審查會議確認：修改後的身分驗證設計是否已符合最後一項資安標準。

「跟進資訊部門」只是一項活動；查核點則明確指出這次互動要確認什麼。

企業銷售 DMU 的九步追蹤流程

步驟一：定義下一個客戶採購里程碑

先從下一個可觀察的客戶決定開始，而不是從業務自己的 Pipeline 階段開始。

例如：

授權試辦；
核准供應商建檔；
釋出預算；
完成技術驗證；
選定優先供應商；
完成簽約；
核准全面導入。

里程碑會替 DMU 地圖劃出邊界，否則客戶公司的每個部門都可能永遠看起來「好像有關」。

步驟二：列出達成里程碑的必要條件

詢問：在客戶能做出這個決定前，哪些事情必須成立？

若目標是取得試辦授權，條件可能包括：

使用流程獲得接受；
技術設計通過；
導入負責人已指派；
試辦成功標準已同意；
預算來源已確認；
供應商建檔完成；
高階支持者授權啟動。

這些就是決策節點。它們把模糊的銷售階段轉為可驗證的客戶採購要求。

步驟三：把每項條件指派給決策單位

找出由哪個人或群組負責評估、建議、核准或控制每項條件。

決策條件	可能的決策單位	需要驗證的問題
使用流程接受	使用單位／臨床評估單位	誰代表使用者？由誰確認正式接受？
資安核准	資訊安全審查單位	誰評估、誰核准、適用哪些標準？
導入準備	營運／專案單位	誰承諾資源並負責上線？
供應商建檔	採購單位	什麼條件會啟動流程？由誰完成？
預算核准	財務／預算權責者	誰提出建議、誰授權、需要哪些證據？
策略授權	高階支持者／審查小組	由個人、委員會或受委任者核准？

在客戶證據確認前，這些都只是待驗證的假設。

步驟四：找出單位內的人與角色

把已知關係人連到對應單位，再找出角色缺口。

你可能知道評估者，卻不知道核准者；知道委員會主席，卻不知道主席依賴哪位專家的建議；認識採購窗口，卻不知道誰負責必要的供應商風險審查。

逐一確認：

誰執行評估？
誰提出建議？
誰擁有最終權限？
誰能否決或延遲該條件？
誰提供必要資訊？
誰協調程序？
誰會受到結果影響？

這是人物層級關係人地圖的延伸，不是替代品。

步驟五：定義資料、標準與完成證據

每個決策單位都應記錄：

開始工作前需要什麼；
如何評估該議題；
需要業務或客戶提供哪些證據；
什麼結果才算完成；
若範圍改變，該決定是否會失效或必須重審。

企業業務經常記下客戶要求，卻沒有保留背後的核准邏輯。

「寄出資安文件」是一項待辦事項；「提供資料流程圖，讓資安架構師能向審查負責人建議接受」才是足以推進商機的決策脈絡。

步驟六：獨立追蹤每個單位

不要讓一個整體商機階段覆蓋各單位不同的現況。

一筆顯示為「提案中」的商機，底下可能同時存在：

臨床流程評估——已核准；
資訊安全審查——評估中；
採購——等待前置條件；
財務——負責人未知；
高階支持——目前只是推測，尚未確認。

這筆商機既不是全面順利，也不是全面停滯，而是進度分散在不同決策單位。

若要管理這些已知參與者的日常互動與協調，可延伸閱讀++複雜 B2B 銷售中如何管理多位關係人++。

步驟七：繪出相依路徑

記錄哪些單位能同步進行，哪些必須等待。

例如：

臨床流程接受與資安審查可同步推進。採購可以先準備文件，但必須等資安核准才能完成建檔。財務可在技術評估期間審閱商業效益。最終試辦授權則要等臨床、資安、營運、採購與預算條件全部完成。

相依關係會揭露關鍵路徑，也能避免業務不斷追問正在等待的單位，卻沒有處理它真正等待的上游條件。

步驟八：把互動證據連回相關單位

重要會議、電話或電子郵件後，更新受到該次互動影響的決策單位。

至少記錄：

發生了什麼；
哪些人參與；
哪些條件或判斷發生變化；
新增了哪些標準或疑慮；
承諾內容與日期；
單位目前狀態；
未解問題；
下一項完成證據。

若一場會議同時影響多個單位，可分別更新相關紀錄，同時保留共同的互動歷史。

步驟九：檢查缺少的單位與過期假設

檢視商機時，逐項詢問：

哪項必要條件尚未找到負責單位？
哪個單位仍沒有已知核准者？
哪個狀態只靠間接資訊判斷？
哪位成員的職務或權責已改變？
哪些評估標準仍未知？
哪項決定正在等待，卻沒有負責人或日期？
哪個所謂的「核准」其實可能只是建議？

目的不是讓地圖看起來資料全滿，而是讓不確定性在變成最後一刻的驚喜包之前先被看見。

如何追蹤相依關係，又不把流程做成怪獸？

你不需要重建客戶完整的企業治理流程，只要追蹤足以引導行動的最小關係集合。

每個決策節點至少記錄：

前置條件： 開始或完成前，必須先發生什麼？
負責單位： 哪個 DMU 對此負責？
完成證據： 什麼可證明條件已解決？
下游影響： 完成後，哪些工作可以開始？
替代路徑： 是否存在客戶接受的替代方案或平行流程？

例如：

決策節點	前置條件	負責單位	完成證據	下游影響
資安核准	修改後的資料流程圖	資訊安全審查	書面接受	採購可完成供應商建檔
供應商建檔	資安核准及公司文件	採購	供應商資料啟用	合約流程可開始
預算釋出	商業效益說明通過	財務	預算配置獲得確認	試辦採購可取得授權

當模型已足以指引行動，就應停止擴建。若開始需要專案管理辦公室、三位顧問和一面開會用的鑼，通常代表這張圖蓋過頭了。

虛構案例：醫院營養照護平台的 DMU

以下為虛構示例，不是 VINEQRA 客戶案例，也不代表特定醫院的正式採購程序。

一位業務正在推進醫院營養照護平台。CRM 顯示目前階段為「提案中」，但院方在授權試辦前，仍須完成數項彼此獨立的條件。

決策單位	決策條件	已知成員與角色	必要證據	目前狀態	相依關係	下一個查核點
臨床流程評估	試辦流程獲得接受	臨床主任：支持者；護理資訊主管：使用評估者	修訂後流程與試辦成功標準	有條件接受	等待最後一次流程修改	修改後確認正式接受
資訊安全審查	身分驗證與資料流程通過	資安架構師：評估者；審查核准人尚未確認	架構圖、資料流程文件、驗證機制說明	評估中	需要修訂圖面；採購等待核准	確認核准者與最後標準
導入準備	試辦資源與責任歸屬確認	專案經理已知；營運負責人未知	人力安排、教育訓練範圍、導入時程	單位不完整	取決於最終試辦範圍	找出營運負責人
採購與供應商建檔	供應商具備採購資格	採購經理：流程協調者	供應商文件與資安核准	等待前置條件	必須先取得資安核准	確認可同步準備的文件
財務核准	試辦預算取得授權	財務經理：評估者；預算最終核准人未知	商業效益與使用量假設	準備資料中	需要已確認的範圍與價值假設	確認預算負責人與所需證據
高階授權	試辦取得策略核准	臨床支持者已參與；高階權責者未驗證	整合後的效益、風險、準備度與預算說明	尚未辨認	取決於各主要單位的建議	確認核准路徑與支持者

從 DMU 視圖可以看出什麼？

臨床條件接近完成，但尚未正式通過。
資安審查正在進行，並控制採購的下游關卡。
導入準備缺少必要負責人。
採購是在等待，不一定是阻礙來源。
財務正在評估資料，但最終預算權仍未知。
高階授權的路徑尚未畫出。

此時的管理優先順序

在把試辦視為已具備商業準備度之前，業務應先補齊資安證據、找出導入負責人，並確認預算與高階授權權責。

Pipeline 階段仍可用於預測；DMU 視圖則負責解釋階段底下尚未完成的組織工作。

明確決策節點與 AI 推測進度如何搭配？

決策單位可以用兩種互補方式追蹤。

業務明確定義的架構

業務可自行定義重要的：

專案階段；
決策節點；
里程碑；
決策單位；
關係人；
商業查核點。

當客戶流程已經相對清楚，或正式核准具有固定規律時，就能依這些已知條件檢視商機。

依互動脈絡推測的架構

業務持續記錄客戶互動與關係脈絡後，AI 可以協助提出可能的：

決策單位進度；
負責人缺口；
尚未解決的核准條件；
相依關係；
關係人缺口；
下一步行動。

AI 輸出應維持為建議或假設，仍須由業務依客戶最新證據確認。

兩種方法可以並用：明確節點提供已知的管理架構，AI 推測則協助浮現互動中尚未納入的變化或缺口。

追蹤企業決策單位的常見錯誤

把整個部門當成同一種意見

資訊、財務、採購與臨床部門內，可能各有不同權責與立場。應分別記錄誰評估、誰建議、誰核准、誰協調，以及誰提供資料。

把開會誤認為已做出決定

出席不等於擁有權限，討論也不等於核准。請先定義完成證據。

只追蹤人物，沒有連到條件

一串姓名無法說明他們為什麼重要。必須把人物與決策單位連到具體的決策節點。

只記條件，沒有找出負責單位

「需要法務核准」仍不完整；至少要確認負責人、單位、程序或可建立接觸的路徑。

整筆商機只用一種狀態

總體 Pipeline 階段可以與多種單位狀態並存，兩個層級都應保留。

把沉默直接判定為拒絕

沉默只代表缺乏新活動。應確認該單位是在等待資料、優先度下降、工作超載、缺少負責人，還是真的反對。

把模型蓋得太大

只追蹤必要決定及具影響力的單位，不必複製客戶的完整治理架構。

忘記更新相依關係

範圍變更可能使已完成的審查重新開啟、增加新單位或改變核准順序。商機一旦改變，DMU 地圖也要更新。

VINEQRA 如何讓每個決策單位保持可見？

VINEQRA 的設計對象，是負責複雜、長週期商機的個人 B2B 業務。它協助把客戶互動歷史，與參與人物、關係人角色、部門或決策單位、已知顧慮、里程碑或決策節點、未解問題及歷史商機脈絡連結起來。

VINEQRA 支援兩種商機推理模式：

隱含式推理： 根據已記錄的互動與關係脈絡，協助浮現可能進度、關係人缺口、未解條件、阻礙與下一步行動。
明確架構＋AI 推理： 由業務定義階段、決策節點、里程碑與關係人，提供分析相關商機脈絡的架構。

實際工作流程維持四個步驟：

記錄： 保存互動、成員、標準、承諾及單位層級的變化。
理解： 釐清各單位負責哪些條件，以及彼此的決定如何連動。
判斷： 根據可用脈絡，協助浮現可能進度、缺口、相依關係或下一步。
行動： 由業務檢視建議，並以最新客戶現況完成驗證後再採取行動。

VINEQRA 提供建議，決定仍由業務做出。

進一步了解 ++VINEQRA 如何讓商機中的每個決策單位保持可見++。

可直接套用的 DMU 追蹤範本

商機名稱：
下一個採購里程碑：

決策單位：
單位目的：

決策條件：
- 必須決定、接受或完成什麼？

已知成員與角色：
- 姓名 → 評估者／建議者／核准者／協調者／資料提供者／使用者

必要資料：
- 開始評估需要的文件、證據、接觸或客戶內部工作

評估標準：
- 已確認標準
- 尚未確認標準

完成證據：
- 什麼可證明此條件已完成？

目前狀態：
- 尚未辨認／無接觸管道／準備中／等待中／評估中／要求修改／有條件接受／已核准／已拒絕／暫停／未知

證據信心水準：
- 已確認／有依據／推測／未知

相依關係：
- 此單位開始前需要什麼
- 哪些工作正在等待此單位

最近一次重要互動：
- 發生了什麼，以及哪些判斷或條件改變

下一個查核點：
- 對象、目的、預期證據與時間

決策單位檢視清單

下一個客戶採購里程碑已定義。
必要決策條件已明確列出。
每項條件都有負責或影響它的單位。
沒有自動把一個部門視為單一 DMU 或單一意見。
已知成員的內部角色有互動證據支持。
評估者、建議者、核准者與否決權持有人已區分。
必要資料與評估標準清楚可見。
每個進行中條件都有完成證據。
每個單位都有獨立狀態。
證據信心已將事實與推測分開。
上游與下游相依關係已有紀錄。
缺少的單位、核准者與負責人已明確標示。
互動已同步更新相關單位與共同商機歷史。
下一個查核點連結具體證據，而不只取決於經過多久。
模型只保留與這筆商機相關的必要架構。

如果地圖裡有很多人，卻無法說明哪個單位負責下一項必要條件，它仍只是一張換了高級外套的聯絡人清單。

常見問題

什麼是企業銷售中的決策單位？

決策單位是負責評估、影響、核准或控制某項採購條件的個人或群組。一筆企業商機可能同時存在使用接受、技術核准、採購、財務、法務、導入與高階授權等多個 DMU。

DMU 與採購決策小組相同嗎？

不一定。採購決策小組通常是參與較廣泛採購決定的正式或非正式群組；DMU 則可以是任何負責特定條件的功能性組合，即使這些人從未以同一個委員會名義開會。

同一個人可以屬於多個決策單位嗎？

可以。專案負責人可能同時參與流程、導入、採購與高階審查。應依每一個決策情境，分別記錄他在其中的角色。

如何在企業客戶中找出 DMU？

先從必要採購條件開始，再找出誰設定標準、提供資料、執行評估、提出建議、完成核准、協調程序，或有能力阻止條件完成。最後以客戶互動與可觀察決定驗證這些角色。

決策單位進度應該追蹤哪些資料？

每個單位至少應追蹤決策條件、成員與角色、必要資料、評估標準、完成證據、目前狀態、證據信心、相依關係、最新互動與下一個查核點。

AI 可以從業務紀錄中找出決策單位嗎？

AI 可以協助分析已提供的互動歷史，並提出可能的決策單位、角色、相依關係、進度或缺口。但這些輸出應維持為假設，直到業務根據最新客戶證據完成確認。

看見 Pipeline 階段背後的採購決策架構

企業銷售的進度不會只發生在一個地方，而是在彼此連結的人物、群組、核准與決策條件之間移動。

追蹤每個決策單位時，應連結它負責的條件、內部成員與角色、所需證據、目前狀態，以及上下游相依關係。明確的客戶證據要與推測分開；只要重要互動改變了商機，就應同步更新 DMU 模型。

最後得到的不是一張完美複製客戶組織的圖，而是一個可操作的管理視圖：誰必須決定什麼、哪些條件尚未解決，以及現在最值得處理哪一項工作。

VINEQRA 協助個人 B2B 業務，把決策單位脈絡與互動、關係人、里程碑、阻礙及可能的下一步行動連結起來。

++前往 App Store 下載 VINEQRA++，持續掌握每筆企業商機背後的採購決策架構。