業務 AI 培訓要練什麼？讓客戶研究、需求訪談與提案真正接得起來

專題編輯：Sylvia Yeh｜人才發展與職場編輯

編輯說明：署名為 TARAISG AI 專題編輯角色，不代表真實個人。本文經 AI 輔助資料查核與編輯複核，未宣稱已由人類專家審閱。

假設一份提案很快完成，業務卻說不清楚客戶為何需要其中 3 個功能；客戶追問交期，才發現文件引用了已過期的產品規格。主管遇到這種情況，需要的培訓內容會與「如何寫出吸睛開發信」不同。公司必須先找出銷售過程在哪一個判斷點失去品質，再決定讓 AI 協助什麼。

尤其在需要詢價、訪談、技術確認與多人決策的 B2B 業務，產出速度只是工作的一段。客戶說的問題是否被理解，方案是否真的符合限制，報價與承諾是否取得授權，成交後的執行團隊是否能接手，都會影響這份成果能不能使用。培訓應沿著這些交接點安排，讓工具操作成為完成工作的手段。

本文提供的是可供企業改寫的培訓設計，主要面向業務主管、業務營運與 HR。所有配分、議程、觀察天數及案例均為編輯建議或假設示例，不是客戶實績、產業標準或成交保證。課程範圍以受控練習與人工覆核為主，不代表已建成自動寄信、報價或下單系統。

原創教學示意，非統計圖、產品介面或真實企業實績。

如果你要練的是單次報價與寄出前的檢核，可搭配閱讀業務從需求到提案的 8 種安全工作法。本文的工作表供主管安排跨角色練習、評量作品與追蹤課後交接。

一、先找銷售工作卡點，才能判斷需不需要業務 AI 培訓

安排課程前，請主管帶來三種材料：一份被退回的提案、一段沒有確認清楚的需求紀錄，以及一筆交接後反覆補問的案件。材料可改用從零虛構的範例；若使用真實工作摘要，應先確認已獲准對外分享，並排除可識別或機密內容。它們能幫助團隊把「業務效率不好」拆成可觀察的問題。

例如，提案總是延誤，可能因為業務不會整理資料，也可能因為產品負責人尚未確認規格。前者可以設計分類、查核與摘要練習；後者需要調整資訊提供與批准流程。如果沒有釐清原因，就可能上完一堂漂亮的工具課，原本的等待依然存在。

美國 CDC 的訓練品質指引將需求評估列為起點，並提醒訓練未必是所有落差的解法；其後才連結學習目標、活動與評量。這套指引原本服務 CDC 開發或資助的訓練，本篇借鏡其設計原則，不將它當成企業銷售課程的認證。S1

把卡點分成能力、資料與管理條件

能力問題，是人員不知道如何完成一個合理而且可執行的任務。例如資料已齊全，仍無法判斷哪些資訊與客戶需求相關；訪談紀錄已提供，卻分不清明確要求與業務自己的推測。這類問題適合以示範、練習、回饋與再次作答改善。

資料問題，是材料本身缺漏、過期或互相衝突。例如同一產品有兩份規格表，沒有人能確認哪份有效。課程可以訓練人員辨識問題，卻不能替公司決定產品承諾。企業要先指定資料責任人，或把課程成果限定為找出缺口與待確認項目。

管理條件則包含價格授權、回覆時限、分工、系統存取與主管支持。業務做出正確草稿後，仍須等待一週才能得到批准，解法未必是讓他再快五分鐘。培訓需求表應把這些障礙寫出來，讓課程不承擔原本屬於制度的責任。

課程範圍宜先鎖定一條工作鏈。若團隊目前最需要改善的是初談到提案，就先把研究、訪談與提案練完整，不必同時加入影音生成、社群經營、廣告投放及複雜自動化。企業能清楚說出哪一段變好，才有基礎評估下一次訓練。

二、按銷售責任分組，讓新人、資深業務與主管各有練習

同樣使用一套 AI 工具，不同角色要練的判斷可能差很多。新人需要認識產品與客戶情境；資深業務需要把經驗轉成可說明的方法；業務助理要確認欄位、版本與交接；主管則需要看出提案依據與風險。若要求所有人以相同速度完成相同操作，新人可能還沒理解內容，資深人員卻已經缺少值得練習的挑戰。

分組不宜直接以年齡或年資決定。可以在課前用一份簡短工作樣本，觀察人員能否辨識資料缺漏、說明客戶問題、組織方案與指出必要覆核。角色與作品共同決定分組，較能看出真正需要的支持。

新人先練辨識，資深人員練解釋

新人的練習可以從「這段話能否對客戶說」開始。給他核准產品資料與一份 AI 生成的說明，要求找出沒有來源的功能、遺漏的限制與過度肯定的字句。這能把產品學習與工具檢查結合，避免新人只記住漂亮話，卻不理解公司實際能提供什麼。

資深業務則可以處理資訊較模糊的情境。例如客戶只說希望降低營運負擔，業務要提出幾種可能原因，並說明需要哪些資訊才能判斷。AI 可以協助列出問題，但資深人員應解釋為何先問這一題，以及不同回答會如何改變方案。這類說明能讓個人經驗變成團隊可學習的資產。

業務助理與技術窗口要參與交接練習

若課程只有業務參加，成果可能停在說服客戶，沒有經過實際交付端檢查。可安排助理確認訂單欄位，技術窗口檢查適用條件，或由營運同仁指出承諾需要哪些前提。這些角色不必全程學習所有工具，但應參與與自己責任有關的測試。

練習時可以刻意保留一個不確定條件，觀察業務是否會標示並交由正確的人處理。例如資料寫「最快兩週」，但沒有說明備料完成日。若學員把它改成「兩週保證交貨」，就暴露了需要補強的承諾判斷；若把問題丟給所有人，也代表尚未理解責任分工。

主管要練回饋方式，而非只看分數

主管的任務，是根據作品指出具體差距。與其寫「提案不夠有說服力」，可以指出「這項效益沒有連到客戶確認的問題，請補原始依據或改成待驗證假設」。當主管用相同語言回饋，學員比較知道如何修改，也能降低課後每位主管標準不同的困擾。

對同一份練習，主管與講師可以先各自評閱，再比較分歧。如果講師重視生成速度，主管重視承諾正確，必須在正式課程前把要求對齊。課程驗收不應等到結束才決定，否則學員可能非常努力，卻練了公司不打算使用的方法。

三、客戶研究先做證據分層，讓 AI 幫忙準備更好的問題

業務做客戶研究，是為了理解哪些問題值得在會議中確認。資料量增加不一定提高準備品質，一份很長的公司介紹也不等於知道採購需求。課程可以要求學員把研究成果壓成一頁，並且區分已確認事實、合理假設與未知事項。

公開研究可從公司官網、公開年報、正式新聞稿、產品文件與公開招募資訊開始。來源的發布者、日期及用途都要保留。公司宣布擴廠是公開事件，但不代表正在購買你的產品；招募某種職位可以提供討論線索，仍不能直接判定該部門有預算。業務應把這些線索改寫成需要確認的問題。

一頁客戶研究卡的四個區塊

第一區是確認過的事實，只寫能回到來源的資訊，例如服務範圍、公開產品與公告事件。第二區是與本次會議可能相關的工作影響，明示為推論。第三區是待詢問事項，說明哪個回答會改變方案。第四區是會議目的，限制本次需要取得的共識。

例如，客戶官網新增海外服務據點，業務可形成「跨據點文件協作可能增加」的假設，接著詢問目前文件如何分工與核准。不能直接在開場說「我們知道貴公司跨國協作效率很差」。前者讓客戶校正資訊，後者把尚未證實的問題扣到對方身上。

讓學員練習刪除沒有用的資訊

可以提供 10 段公開資料，要求學員只保留與會議目的有關的 3 至 5 項，再解釋刪除理由。某位主管的興趣、未經證實的私人關係，或與工作無關的個人資訊，不應因為搜尋得到就被納入開發話術。課程要教的是商業理解與證據判斷，不是蒐集越多個資越有優勢。

AI 產生的摘要仍要回到原頁核對。來源存在，不表示摘要完整；公告日期與事件日期也可能不同。學員應特別檢查數字、否定詞、適用地區與條件，例如「計畫導入」不能改寫成「已完成導入」。這些差異會直接影響業務開場與提案理由。

NIST 的生成式 AI 風險文件將錯誤生成與資料隱私列入風險，並提出核對模型輸出來源與引用等做法。它是自願性風險管理參考，不能證明特定工具不會出錯，也不等於完成台灣各項法律義務。S4

可直接改寫的研究任務指令

可以要求學員依下列方式交辦：「依提供的核准資料整理客戶研究卡。每一項事實列出來源與日期；無法證實的內容放入假設欄；提出 5 個與會議目的有關的確認問題。不得推定預算、內部困難或未公開決策，不為了填滿欄位補寫不存在的資訊。」

這份指令是練習起點，並不是所有工具都能自動完成來源查證。學員仍要交出核對紀錄與修改理由。評量時可把其中一個來源刻意改成過期版本，看他是否會發現，而不是只看輸出是否符合表格。

四、需求訪談的核心，是把推測變成客戶願意確認的內容

AI 可以協助整理提問，但不能替客戶決定真正問題。培訓應讓業務練習在對話中辨識模糊詞、確認限制，以及分清楚對方已說明的內容與自己補上的解釋。好的需求紀錄會保留不確定性，讓下一次會議知道還缺什麼。

Salesforce Trailhead 的關係銷售教材區分澄清問題與確認問題：前者協助對方補充意思，後者核對業務是否理解正確。這是銷售教學中的一種方法，本篇將它用於設計練習，不把教材中的建議當成成交率的實證保證。S2

先練澄清，再練提出方案

當客戶說「我們希望更快」，可以先問「目前哪一段等待最久，怎麼判斷時間太長」。當客戶說「系統不好用」，應追問具體任務、使用者與失敗情境。若業務立刻把所有問題翻成自家產品功能，可能還沒理解需求，就已開始說服。

課堂角色扮演可以安排一位學員擔任客戶，手上有一張不公開的情境卡。情境卡寫明工作困難、不能改變的條件，以及只有被適當問到才會揭露的資訊。業務的目標不是猜中卡片所有內容，而是在合理時間內取得足以判斷下一步的資訊。

觀察者記錄哪些問題幫助釐清，哪些問題包含未證實的前提。例如「你們是不是因為人員不夠才需要 AI」已替對方設好答案；改問「目前哪些工作最常延後，通常卡在哪一步」較能讓不同原因浮現。練習後由扮演客戶的人回饋，他在哪些地方被理解，在哪些地方感到被推著走。

把需求分成四種狀態

本文建議在紀錄中使用「已確認」「待確認」「不在範圍」「有條件成立」四種狀態。它們不是通用 CRM 標準，而是讓學員練習保留判斷邊界。客戶說有需要，仍可能沒有同意方案；主管說可以討論，也不代表已核准預算。

例如「希望月底前看到範例」可以記為已確認的展示需求；「月底正式上線」若只是業務推測，應留在待確認。客戶提出整合另一套系統，若本次沒有技術評估，可列為不在目前試辦範圍，或附上取得介面與權限後再評估的條件。

這個練習對跨部門專案特別有用。客戶的使用者、資訊人員、採購與決策主管可能各自關心不同條件。業務應記錄資訊由誰提出、誰能確認，不能把一個窗口的想法寫成整個組織共識。資料不足時，交付一份清楚的待確認清單，本身就是有效進展。

用 AI 模擬客戶時，要控制評量邊界

課程可以用 AI 角色扮演增加提問練習機會，但模型可能過度配合，也可能自己補出情境卡沒有的答案。講師應先固定角色資料，要求模型不知道時明確表示未知，再由人檢查對話是否偏離設定。不能只因為模型說「你問得很好」，就認為業務已掌握客戶訪談。

若要用模擬結果評分，可以選擇幾個可觀察行為：是否確認目的、是否追問模糊詞、是否核對限制、是否總結並讓對方修正。評量不必獎勵問得最多的人，過多重複問題也可能增加客戶負擔。學員應能說明，哪些資訊已足以支持下一步，哪些應留待合適的窗口。

五、提案訓練要練論證，讓每一個方案都找得到需求依據

提案可以把資料整理得有條理，也可能把未確認的想法包裝得更有說服力。培訓時應先建立需求與方案的對照，再生成簡報或文件。若跳過這一步，AI 很容易根據一般產業知識補出客戶沒有提出的需求，業務也難以發現。

Salesforce 的提案教材將產品或服務、客戶需求、提供的價值等列為提案重要內容。這可以支持提案需要連結客戶問題的原則，但不能由此推論使用 AI 製作文件就會提高成交率。本文的論證表與評分方法為原創教學建議。S3

一項需求至少連到一個可檢查的回應

可讓學員先完成五欄表：客戶已確認的需求、支持該需求的紀錄、建議方案、方案成立的條件，以及還需誰確認。只有能說清楚這五欄，才進入文案生成。這個順序讓講師容易看出問題來自資料、推論或方案本身，而不是被版面吸走注意力。

例如，客戶想減少每週人工彙整資料的時間，方案可以是改善資料收集與報表草稿，但需先確認來源格式與主管審核要求。若提案直接承諾減少一名員工，已跨越現有證據。業務可以提出待驗證的效益假設與量測方法，卻不應把假設寫成確定結果。

把產品優點轉成適用條件

「容易整合」對不同客戶的意思不同。對使用標準介面的公司，可能只需設定；對封閉系統或文件格式混亂的公司，可能需要額外處理。課堂可以要求學員把每一句優勢改寫成「在什麼條件下，可以完成什麼」，並列出不適用或需另評估的情況。

把條件寫清楚，是為了讓客戶檢查方案是否符合自己的環境，以及需要投入哪些配合工作。業務可以同時說明預期價值與成立條件，不必靠「全面提升」「完全自動」「立即見效」等缺乏量測依據的詞，撐起整份提案。

數字、價格與交期要有單獨的檢查步驟

AI 可以協助整理報價說明，正式價格仍應來自核准資料與授權程序。學員要檢查單位、數量、幣別、稅別、有效期間及排除項；沒有確認的欄位不能自行補值。交期也應對應起算條件，例如資料齊備、需求凍結或訂金確認，避免只留下看似明確的天數。

為了把練習做得更具體，可提供兩份相似產品資料，刻意讓其中一份有不同適用範圍。要求學員標出提案每項數字來自哪一頁，遇到衝突時寫下詢問對象。講師評量的是他如何處理不確定資訊，而非是否能產出一張填得很滿的報價表。

讓不同角色讀同一份提案

完成初稿後，可以由另一組扮演使用者、採購或資訊窗口，各自提出一個需要釐清的問題。使用者可能問操作負擔，採購關心費用與責任，資訊人員關心環境與權限。業務要回到證據回答，不能為了讓每個角色滿意而臨時擴大承諾。

這個活動也能訓練提案的資訊層次。決策摘要應清楚交代問題、選擇、限制與下一步；細節資料放在附錄或連結中。若客戶要翻很多頁才知道自己需要做什麼，表示提案雖然完整，仍可能沒有服務當次決策。

六、追蹤與交接要練「下一步」，避免只把催促寫得更客氣

業務追蹤的價值，是讓雙方知道案件停在哪裡、接下來由誰完成什麼。單純把「請問考慮得如何」改成更有禮貌的文字，未必能推進工作。課程可以要求學員根據會議內容，產出一筆有條件、有責任人、能被接手的行動紀錄。

一筆合格的紀錄至少回答：目前已確認什麼、還有哪個問題、需要誰處理、預計何時檢查，以及什麼訊號表示可以進入下一階段。若日期尚未與客戶確認，應標明建議日期，不能把業務自己設定的期限寫成雙方約定。

追蹤訊息要提供新的決策材料

可把課堂練習分成三種情境。資料待補時，整理缺少的欄位與用途；客戶比較方案時，說明真正影響選擇的差異；內部核准尚未完成時，確認對方是否需要摘要、測試證據或參與者說明。每一封草稿都應有明確功能，避免只增加訊息量。

不要讓 AI 自行虛構曾經的對話或關係，例如「如同您上次提到」卻找不到紀錄。對方沒有同意接收的資訊，也不能因為工具能大量生成就任意發送。本文討論的是在企業核准範圍內撰寫與覆核草稿，實際聯繫方式仍須符合公司與適用規範。

商機階段應由證據支持

若系統的商機階段是「已提案」，應確認提案真的送達適當窗口；若是「待簽約」，應有對應的協商進度，而不是業務覺得對方很有興趣。課程可用同一組會議紀錄，讓不同學員判斷階段並說明依據，再討論公司定義不一致的地方。

AI 可以協助找出紀錄缺漏、整理行動項目與提醒待確認資訊，但不宜以文字情緒直接判定成交機率。笑臉、積極用語或回覆速度，都不足以取代採購條件與決策程序。若公司使用預測模型，應另有模型與資料驗證，不能用一般聊天工具的猜測代替。

交接測試比文件數量更有意義

請一位沒有參與原始訪談的同事，只依學員交付的紀錄，回答客戶要解決什麼、公司承諾了什麼、仍缺哪些確認。他若無法回答，應回到文件補足，而不是要求接手者自己猜。這個測試能同時檢查需求、提案與追蹤是否接得起來。

在不同語言的業務團隊，還要檢查翻譯後的責任與條件是否一致。日期格式、規格單位與承諾程度容易因表達方式改變。課程可安排中英文對照檢查，但涉及正式契約或專業技術時，仍需由適任人員審閱，不把流暢翻譯當成內容等值的證明。

七、把四種作品串成工作坊，先確保每一段有練習與回饋

課程議程應從學員能交出的作品倒推。若目標是學會準備需求訪談，就應保留研究、提問、角色演練與回饋時間，不宜把大部分時間放在工具介紹。每次增加一個新工具，也會增加登入、環境與操作的負擔，應確認它是否直接支持學習目標。

以下提供一個 6 小時工作坊示例，含兩段各 10 分鐘休息，合計 360 分鐘。這是規劃範本，並非任何團隊都能在同樣時間達到相同程度。若學員需要熟悉帳號、產品或基本資料處理，應另外安排準備與補課，不把技術障礙混成能力評分。

課前資料包要能模擬判斷

資料包可以包含虛構公司介紹、產品規格、客戶訪談片段與兩份不同版本附件。資料需要足夠真實感，讓學員遇到與工作相近的選擇；同時要明確標為合成，避免被帶回工作時誤當真實客戶文件。範例中的公司名稱、人物與聯絡方式應採虛構標記，不使用可誤寄的真實收件人。

資料包也應附講師答案參考，說明哪些是可確認事實、哪些沒有唯一答案，以及哪些屬必須退回的風險。不是每道題都需要標準句子，尤其需求訪談與提案，可能存在多種合理做法。評分重點應放在理由、依據及限制，避免獎勵最像講師答案的人。

講師示範要留下失敗與修正

除了示範成功輸出，也應安排一次資料缺漏、一次產品條件衝突，以及一次 AI 自行補寫。講師要展示怎麼發現問題、縮小任務與回到來源，讓學員知道卡住時能採取哪些動作。只有完美演示，容易讓學員以為自己的失敗是操作能力不夠。

建議在每個單元只保留少量關鍵指令，要求學員自己補上情境與限制。完整提示詞可以作為課後範本，課堂時間則用來判斷為何要這樣要求、結果哪裡需要檢查。如此一來，課程留下的是如何交辦、查核與修改的方法；即使工具介面改變，團隊仍可據此調整操作。

不同程度學員使用共同任務、不同支援

初學者可先拿到欄位完整的範本與核准資料，進階者則多處理資料矛盾、跨角色需求或更難的接手情境。兩者仍需通過相同的基本品質要求，不能讓初學者因為操作較慢而免除查證，也不讓進階者只因生成速度快就跳過覆核。

若公司只安排 3 小時，可以縮成研究卡與需求訪談兩項成果，將提案與交接留待後續。課程成果應隨時間與先備調整，不應把 6 小時的所有單元壓成一半速度。保留完整的作答、回饋與修改過程，承辦人就有具體作品可以核對；若只帶過流程名稱，則無法從聽課紀錄判斷學員能否獨立完成。

八、驗收業務 AI 培訓，應看作品證據與判斷過程

學員能產出文件，是必要但不充分的證據。評量還應檢查他如何選擇資料、確認需求、推導方案、處理不確定與交給別人。以下是供企業調整的 100 分評分表，不是經統計驗證的職能量表，也不能直接用來決定升遷或薪資。

每一個面向可以再用「需協助」「依範本可完成」「能處理常見例外」「可說明方法並協助他人」描述表現。等級必須附作品位置與修改建議，不能只留下分數。不同人可能在研究與訪談之間有不同強弱，課後支持應根據差距安排。

配分衡量作品符合哪些要求，表現等級則描述完成時需要多少支持，兩者不必直接換算。例如研究項目的 20 分，可以在課前拆成來源可追溯 8 分、事實與推測分開 6 分、資訊與會議目的相關 6 分，再為每一欄準備得分與扣分範例。這同樣只是教學示例，企業仍要依產品與工作風險調整。

是否達標，也應在課前明定。除了總分門檻，還可以要求承諾、數字與權限項目達到必要條件。主管應看得出學員是依範本完成，還是能自行發現例外；否則兩份相同分數的作品，可能需要完全不同的課後支持。

重大錯誤不能用其他分數抵銷

企業可以事前定義必須補訓與複測的條件，例如未核准使用客戶資料、捏造客戶需求、擅自承諾價格或把練習草稿送出。發生這些情況時，應先確認原因及補救方式，不以版面漂亮或其他項目高分抵銷。條件要在測驗前說清楚，避免評分者事後改變標準。

同時，也要把環境失敗與能力差距分開。帳號無法登入或功能不開放，應記為環境問題；學員在已有核准工具與材料的情況下漏掉限制，才是需要練習的判斷。公平的評量不能把公司沒有提供的條件算成員工不努力。

複測要換情境，不能只改公司名稱

課後再給一題時，可以改變資訊完整程度、客戶角色或方案限制，保留相同難度與主要學習目標。例如第一次是新客戶初談，第二次改成老客戶新增部門需求，觀察學員能否重新確認範圍，而不是沿用原有承諾。新題目的作用，是增加檢查方法能否轉移的證據；仍須比對難度與必要背景，避免只是第二題比較簡單。

複測也不應以更多字數或更長簡報代表進步。可以要求學員在相同篇幅內保留必要資訊，並說明刪除了什麼。重點是讓讀者找得到決策所需資訊。若案件需要詳細規格或正式文件，便應保留必要篇幅，不能為了追求短文而刪掉限制。

讓評分者先校準，再比較不同學員

正式評量前，可由主管與講師各看兩份範例，討論哪些錯誤影響可用性，哪些只是表達偏好。如果主管把語氣不夠積極扣很多分，講師卻重視來源正確，必須先建立共同判準。若團隊有不同產品線，也應調整情境，避免某組因為熟悉資料而取得不公平優勢。

評量結果適合用來安排後續教練與補強，不宜在樣本很少、情境單一時，直接把員工排成永久能力名次。培訓讓組織看見可改善之處，應讓人願意暴露問題，才能取得比成功截圖更有用的學習證據。

九、兩種假設案例：設備銷售與專業服務，需要不同的訓練重點

以下兩個案例皆為虛構教學情境，未引用真實客戶資料，也不代表天地人的實際服務成果。它們用來說明同樣四種作品，如何依銷售工作調整練習與驗收，並非提供產業通用標準。

案例一：設備代理商，先補需求與規格的交接

假設一家設備代理商有 8 位業務與 2 位技術支援。業務經常先收到模糊需求，再把郵件轉給技術同仁。技術端需要反覆補問場地、電力、產能與既有設備限制，業務則覺得報價等太久。若直接教業務快速生成報價，可能加快的只是資訊不足的第一版。

課前訪談先發現一個可訓練的缺口：不同業務對必要條件理解不同。因此課程的第一項作品不是完整提案，而是一份需求確認表。教材使用虛構客戶的來信與場地條件，故意讓其中兩項資訊互相矛盾，要求學員找出並提出適當的確認問題。

研究練習只使用核准產品資料，學員需分清一般規格、選配條件與需技術確認的項目。訪談角色扮演由技術同仁提供合理情境，學員要把不懂的地方問清楚，不能因為模型列出專有名詞就直接寫進方案。最後把需求表交給另一位技術同仁，測試是否能開始評估。

提案練習則要求每一個建議設備都對應已確認條件。若某項規格仍未知，先保留選項與待確認理由，不用一個看似合理的值補滿。正式價格與交期不在課堂自動決定，練習成果僅到可供主管及技術窗口覆核的提案草稿。

在這個情境中，課後可以觀察需求表必要欄位完整度、因資訊不全造成的補問，以及業務是否能解釋方案條件。若補問減少但錯誤承諾增加，不能判斷培訓成功；若技術端仍等待供應商資料，應把這段等待分開，不能全部算成業務能力問題。

可用的一項修改，是把產品比較表增加「不適用條件」欄。業務看到兩款產品都有相似功能時，需要說明哪一項限制會改變選擇。這讓 AI 協助整理資料的價值，接到人員的適配判斷，也讓新人更容易理解資深同仁原本省略不說的理由。

案例二：專業服務團隊，先補提案範圍與雙方責任

另一個假設情境是一家提供企業專業服務的小型團隊。客戶常說希望改善管理效率，業務容易把公司所有服務都放進簡報。提案很完整，客戶卻難以決定先做哪一段，執行團隊也擔心業務承諾的範圍過大。

這類課程的重點可以放在問題定義、方案取捨與範圍說明。教材提供一段客戶會議紀錄，包含一個明確問題、兩個相關想法與一項尚未確認的期待。學員要先判斷哪些是本次要處理的核心，再提出兩個範圍不同、各有成立條件的方案。

角色演練加入一位想增加內容的客戶窗口。業務需要練習說明新增要求會影響哪些交付與配合條件，並提出後續確認方法。練習並不鼓勵一律拒絕客戶，而是讓學員知道如何把變更帶回可討論的範圍，不在現場隨口答應所有要求。

提案作品應清楚列出由服務方提供的成果、由客戶提供的資料、雙方需要參與的會議，以及哪些內容要另行確認。AI 可以協助檢查前後用詞是否一致，最後仍需由負責人確認工作範圍。文字看起來專業，不代表已經符合契約或實際交付能力。

課後追蹤可看內部提案退件原因、範圍不清導致的補件，以及執行團隊接手後能否理解承諾。若成交變快，但後續變更多到超出可承擔範圍，就需要檢查提案與批准方式。業務培訓的品質應與可交付的客戶關係連在一起，不能只看簽約當下。

兩個案例的差異，在於第一個著重規格與技術條件，第二個著重問題範圍與服務責任。它們都不需要一開始就建立自動化銷售系統。先讓人能辨識資料、解釋方案與完成交接，再判斷哪些重複步驟值得串接，能讓後續建置有清楚的依據。

十、課後看什麼，才能知道業務 AI 培訓有沒有回到工作？

企業可以把課後追蹤拆成作品品質、工作採用與營運結果。作品品質最接近學習目標，適合較早觀察；採用需要確認真實任務與環境；營運結果則還受到客群、產品、價格、季節與銷售週期影響。三者有關聯，卻不能互相代替。

如果員工在課後交出更清楚的需求表，這是能力證據；如果團隊在符合條件的案件中持續使用，這是工作採用；如果後續成交或客戶滿意度改變，還需要更完整資料判斷原因。不能因為課程剛結束就遇到一筆大訂單，便將全部成果歸因於培訓。

先追蹤主管能核對的三個問題

第一，成果是否減少了明確可辨認的錯誤，例如把推測寫成事實、漏掉規格限制或缺少下一步。第二，學員是否能在新情境使用方法，而非只會複製課堂範例。第三，主管與接手者是否願意採用這些作品，並能說明它改善了哪一段工作。

可以先安排課後 2 週與 4 週的回顧，這只是便於執行的建議節點，不代表所有企業都能在一個月看到銷售成果。銷售週期較長的團隊，可能需要更久才看到商機階段變化。期間仍可檢查作品、訪談與交接，避免因為訂單尚未發生就完全停止觀察。

用小樣本找問題，避免把比例當成定論

假設 10 位參與者中，8 位完成課後作品，6 位達到事先約定的品質要求。完成率為 8／10，也就是 80％；已交件作品的達標率為 6／8，也就是 75％；若以全部參與者作分母，達標比例則為 6／10，也就是 60％。三項數字分別反映交件情況、已交件作品品質與全體達標情況，不能只挑最好看的比例。

這是一組教學假設，樣本也很小，不適合外推整個企業的能力。更有用的下一步是讀未達標作品，確認問題集中在來源、需求還是承諾，再安排針對性練習。未交件的人也可能缺少適用案件或主管支持，需要了解原因，不能直接推定不願學習。

業務 AI 培訓一定要搭配 CRM 嗎？

不一定。先用公司核准的文件與表格，也能練習研究、需求、提案及交接。若公司已有 CRM，課程可以對齊必要欄位與商機定義；正式寫入、自動更新或串接則應另外確認權限、資料及測試。不要因為還沒有系統，就延後所有能力訓練，也不要把有系統當成已具備共同做法。

AI 能不能直接替業務發開發信？

工具是否具有寄送功能，與公司是否適合授權自動寄送，是不同問題。培訓可先練習產生草稿、檢查事實與確認對象，由人決定是否使用。若後續要自動化，需另評估收件來源、同意或其他適用依據、頻率、退訂、錯寄處理與公司規則，不能把課堂練習直接接到真實名單。

資深業務不想公開自己的方法，怎麼安排？

先讓他們參與定義哪些判斷值得保留，並清楚說明知識分享的用途與認可方式。可以從一個已去除敏感內容、經核准的情境開始，整理提問順序與例外條件，不要求公開所有客戶關係。主管也要安排分享與維護時間，避免把額外工作全部放在最有經驗的人身上。

課程要教多少種 AI 工具才夠？

沒有通用數量。只要目前工具能支援選定任務，就應先確保學員學會查證、修改與交接。工具數量增加，未必代表能力範圍增加。採購課程時可要求講師說明每個工具對應哪一件作品，以及不用該工具是否仍能完成核心練習，再決定必要配置。

怎麼向講師提出一份清楚的需求？

需求摘要可填入目標業務角色、主要產品與銷售型態、目前最常被退回的工作、可用資料與環境、預期作品、批准限制、課後支持及驗收方法。不需一開始交出客戶名單或商業機密；先用流程描述與合成材料，就能討論課程是否適配。

在下一次培訓規劃會議，請主管選出一筆最近需要反覆修正的案件，問四個問題：研究是否可靠、需求是否確認、提案是否有依據、下一步是否能接手。把答案變成練習與評分標準，就能讓業務 AI 培訓從工具展示走向可檢查的工作能力。

若希望依企業產品、業務角色與資料限制設計實作，可透過天地人企業培訓服務討論課前準備與工作成果。合作範圍應先對齊能力缺口、作品及支持方式，再選擇適合的課程長度與後續安排。

參考來源

[S1] CDC，Quality Training Standards，頁面更新日期 2026 年 10 月 1 日。

[S2] Salesforce Trailhead，Collaborate with the Customer，頁面未明示發布日期。

[S3] Salesforce Trailhead，Write a Sales Proposal，頁面未明示發布日期。

[S4] NIST，Artificial Intelligence Risk Management Framework：Generative Artificial Intelligence Profile，NIST AI 600-1，2024 年 7 月。

來源查核日期：2026 年 11 月 14 日。文中教學設計、配分、案例與指令均為編輯建議；來源文件支持的原則與適用限制已分別標示。本文未實際操作寄信或銷售系統，也未取得企業銷售成效數據。