一張報價單，為什麼業務說在等主管，主管說在等成本，最後又變成老闆自己追？有時候，卡住的原因是大家對「誰交資料、誰做決定」的理解不同。
RACI 責任矩陣把工作與角色放進同一張表，說清楚誰執行、誰核准、要問誰、要通知誰。以下用小公司的報價流程示範：先列交付物、確認授權，再拿一筆真實訂單試跑，看看分工能不能用在每天的工作上。
RACI四種角色與適用情境
RACI 是四種角色的英文縮寫，可以先記成「做、決定、給意見、收通知」。
| 角色 | 意義 | 報價情境 |
|---|---|---|
| R：Responsible | 執行工作、完成交付物 | 業務整理客戶需求 |
| A：Accountable | 對結果負最終責任，具有核准權 | 有授權的人決定報價通過或退回 |
| C：Consulted | 決定前提供必要意見 | 財務提出付款條件建議 |
| I：Informed | 接收相關進度與結果 | 知道報價已核准或寄出 |
角色定義可參考 Asana 官方 RACI 說明。
R 要把東西做出來，A 要判斷能不能交付。業務做完報價草稿，還得取得核准才能寄出；主管被加入群組，也未必知道自己負責核准。
報價接單、新品上市、客訴處理等需要多人交接的流程，都適合先檢查分工，尤其是經常重做、補件或等不到決定的環節。單人能完成、成果與權限都清楚的小事，用待辦清單即可，不必每次寄信都畫表。
I 收到通知，不等於同意，也不因此負責執行。 要請對方提供成本、確認交期或核准價格，就得指定相應角色，不能期待一則通知自動變成工作指派。
從交付物開始畫責任矩陣
先問：「這一步完成後，下一位會拿到什麼？」先別急著把業務部、財務部、老闆填進表格。部門名稱說明人在哪裡，交付物才說明事情做到哪裡。
- 界定起訖。 例如從收到客戶需求，到成交後交給營運承接，先處理這一段。
- 列出成果。 把「處理報價」拆成需求確認紀錄、成本估算表、核准報價單、寄送紀錄與訂單交接資料。
- 寫完成條件。 需求紀錄至少要有品項、數量、規格及預定交期。「已聯絡客戶」還不足以讓下一位估成本。
- 填入人員並確認。 每列指定一位主要 R、一位 A，再依需要加入 C、I，請當事人確認能力、時間與授權。
本篇採每項工作一位主要 R、一位 A，R 與 A 可以由同一人兼任，與 Asana 官方角色及責任指南的建議一致。這是實作原則，不是法律規定，也不必當成所有 RACI 版本的唯一寫法。
完成條件要請接手者一起訂。成本表若只有總金額，沒列數量、成本項目與估算依據，財務仍無法確認。先講清楚需要哪些資料，退回時才分得出是資料不齊，還是對價格的判斷不同。
多人一起做時，指定一位主要 R 負責彙整；協作者若有獨立成果，例如交期確認表，就另外拆列。A 必須拿得到判斷資料，也確實有決定權，不能只因職稱較高就填上去。
小公司報價流程的分工範例
以下是虛構教學情境，不是品牌客戶案例。假設業務、營運、財務與老闆由四位不同人員擔任；營運有權確認需求與一般報價，財務有權確認成本估算。一般報價授權上限暫設未稅 NT$100,000，且價格、付款與交期都符合公司既定條件。
| 交付物／工作 | 業務 | 營運 | 財務 | 老闆 | 主要 R／唯一 A |
|---|---|---|---|---|---|
| 客戶需求確認紀錄 | R | A | — | I | 業務／營運 |
| 成本估算表 | C | R | A | I | 營運／財務 |
| 一般報價核准 | R | A | C | I | 業務／營運 |
| 例外報價核准 | R | C | C | A | 業務／老闆 |
| 已核准版本的寄送與留存 | R/A | I | — | — | 業務／業務 |
| 成交後的訂單交接資料 | R | A | C | I | 業務／營運 |
「—」表示本列未指定該人的 RACI 角色。逐列看，需求由業務整理、營運確認能否接續作業；成本由營運彙整、財務確認估算基礎。這兩列各有一位 R 與一位 A，不能因為大家都看過，就省略確認的人。
一般報價與例外報價是互斥路徑。 符合授權條件，由營運核准；超額或需要變更任一既定條件，改由老闆核准。同一版本只走其中一條，不會同時有兩位 A；金額或條件改變，就重新判定路徑並送核。
寄送列由業務兼任 R/A，負責「寄出並留存已核准版本」，沒有自行改價的權限。成交交接列由業務準備資料、營運確認能否承接；客戶回簽內容若與核准版本不同，要先處理差異。六列都各有一位主要 R、一位 A，兼任列也一樣。
一人兼多職，怎麼避免紙上分工？
實際使用時，把職稱對應到姓名。同一人兼營運與財務，就合併欄位、保留角色標記，再逐列檢查。同一人掛兩個職稱，仍然只有一個人檢查。
R/A 同人適合權限清楚的工作；若價格或付款條件需要另一人把關，就要另設檢查與核准安排。再縱向看每個人的工作量：如果大部分 A 都是老闆，就得確認哪些決定可以授權，哪些確實需要保留。
核准權限、期限與例外處理
知道要找誰之後，還要約定「什麼條件能決定、多久要回覆」。下表的金額與時限都是教學假設與內部約定，不是法定要求，也不是 RACI 固定標準。
| 規則 | 示範約定 |
|---|---|
| 一般核准範圍 | 未稅金額 ≤ NT$100,000，且價格、付款與交期符合既定條件 |
| 例外條件 | 超過額度，或任何既定交易條件需要變更 |
| 送核附件 | 需求紀錄、成本表、報價版本與例外事項說明 |
| 回覆期限 | 資料齊備後，C 於兩個工作小時內回覆，A 於四個工作小時內決定 |
| 報價完成期限 | 需求資料齊備後，次一工作日下班前寄出已核准版本；做不到就及早通知 |
| 升級處理 | 事先寫明聯絡對象、代理資格、移交方式與紀錄位置 |
假設一筆未稅 NT$80,000 的報價符合既定條件，就走一般路徑；金額相同，但客戶要求變更付款條件，就要走例外路徑。核准權限除了金額，也包含其他交易條件。
時限要寫清楚工作時間，以及由誰確認附件齊備。需要補件時，留下缺件項目、通知時間與補齊後的起算方式。整份報價也要有完成期限，避免每個人都在時限內回覆，客戶卻仍等不到報價。
意見不同或核准逾期，下一步是什麼？
C 意見不同時，由 R 整理分歧、影響與可選方案，交給 A 決定並記錄理由。C 提供意見不等於擁有否決權；若涉及公司既有的必要審查，就須在流程中另行寫明，A 也不能跳過。
C 到期未回覆，R 要記錄缺少的資訊及其影響，依事前規則升級。必要資訊不齊就退回補件；如果事先訂有可繼續的條件，則由 A 確認並留下依據。「沒有意見」與「沒有回覆」要分清楚。
A 逾期時，由 R 依約定聯絡並啟動代理程序，記錄移交生效時間與接手人。同一事項在同一時間只有一位 A；沒有合格代理人就維持待核，通知相關人員並調整對客戶的回覆安排。未回覆不能當成已核准。
導入後怎樣檢查與更新
挑一筆真實、範圍可控的訂單，按矩陣走完，不必等所有流程都畫好。每次交接留下交付物版本、交出時間、接手時間與核准結果，依發生順序記錄，別等結案才憑印象補齊。
試跑後一起檢查：
- 每列是否找得到實際執行的 R？
- A 是否取得足夠資料，而且真的能作決定？
- C 是否及時收到問題與必要資訊？
- I 是否收到需要的進度及正確版本？
- 哪一步仍要老闆口頭催促，原因是什麼？
先記原況，再比較條件相近的後續訂單；急單、客製程度不同時，分開看。沒有資料就不寫改善百分比，單筆順利結案也不足以證明整套制度有效。
指標要用同一種方式記錄，前後才有得比：
| 指標 | 記錄方式 |
|---|---|
| 報價總耗時 | 從需求達到約定齊備條件，到核准報價寄出 |
| 等待核准時間 | 從送核附件齊備，到 A 留下決定 |
| 補件次數 | 送核後因資料缺漏而退回的次數 |
| 老闆介入件數 | 記錄有介入的訂單，區分原定核准與臨時催辦 |
客戶中途改需求，要另記原因與時間，不把新增工作全部算成團隊延誤。找出等待集中在哪一列：成本資料不完整，就改完成條件或表單；A 拿到資料卻無權決定，就調整授權。先處理原因，別急著換人背責任。
人員異動、授權額度調整、新增產品，或同一步反覆卡住時，都要重看矩陣。指定維護人，留下版本與生效日期，通知受影響者並標示舊版停用，讓新人和資深同事查到同一套規則。
讓分工接上日常經營
組織架構交代角色與管理關係，RACI 指定某項交付物由誰執行、誰核准，業務 SOP 則記錄怎麼做、用哪張表及做到什麼程度。把矩陣連到現有表單與作業步驟，同事在工作當下才查得到。
新人培訓可以沿用同一筆訂單演練，請他說出：「我要交什麼、誰核准、缺資料找誰、逾期怎麼處理？」接著實際完成一次交接，確認他能找到人、拿對版本並完成工作。
老闆也能從試跑紀錄看出，自己介入是因為必要決策，還是團隊缺少資料與授權。想進一步思考經營與團隊制度，大腦營行的商戰思維培訓可作為學習入口。
需要把方法套用到自己的企業時，可完成官方商戰思維測驗或了解工作坊。