從十二組提案，
看見 AI 導入的管理課題

行大運一站式開運平台

這組抓到一個很實際的顧慮：企業主一跟銀行接觸，就擔心接下來會被推銷。改從命理、家庭或事業等話題開啟對話，的確是另一種接觸客戶的方式。不過，團隊描述的目標客群同時疊了好幾個還沒驗證的條件：四十到六十五歲的傳產企業主、有傳承需求、排斥金融推銷、對命理有興趣，而且願意接受銀行提供的命理體驗。從目前提供的內容，還看不到足夠的訪談或行為資料，能證明這些條件會同時出現在同一群人身上。

我比較擔心的是，前端的服務訴求和後端的實際體驗兜不起來。團隊想降低客戶的推銷壓力，Demo 裡卻是運勢不好的客戶按下「逆天改命」就導到保險，運勢好的客戶按下「乘勝追擊」就導到投資組合。客戶看到這一步，很可能覺得銀行只是換個包裝在推銷，原本想透過活動建立的信任，反而在這裡流失。

命理搭配投資標的快篩，還是可以當作探索方向，但兩者的分工要講清楚。命理可以幫助客戶說出自己在意的事；金融商品的篩選，則要回到確認過的需求、財務狀況與風險承受度。依照現行的金融商品適合度規範，銀行必須了解客戶的財務背景、風險偏好、投資經驗與投資目的，這些判斷不能用運勢取代。^[2]

這一案可以先辦活動來驗證，不必急著開發完整的 App。在同一個接觸管道，分別發出文化主題活動和一般財務諮詢的邀請，比較兩邊的參與者是否符合預設客群、有多少人願意談真正的需求，以及最後成功約到幾位。與命理老師合作的費用、活動安排和後續的人力承接，都要算進成本，才知道這個入口值不值得經營。

只辦一次的活動本身沒有問題，只要能接觸到適合服務、也願意繼續往來的客戶，單次活動也說得通。這組要回答的問題有兩個：客戶為什麼會選擇由銀行提供的命理服務，以及每找到一位真正有需求的客戶，要花多少成本。

本節資料：評審筆記第 3–11 行；逐字稿第 204–220 行。

AI 客戶洞察助手

「不要讓最好的服務只留給前三十名客戶」，這個企圖心很清楚，但理專為什麼只顧得了這麼多客戶，還要再往下追。查資料、跑行政流程、約時間、釐清需求和判斷商品，都可能占掉理專的時間。團隊還沒有說明「三十名」是怎麼算出來的，也沒有拆解各項工作各占多少時間。如果理專主要忙在行政與聯繫，多一套商品判斷工具，不見得能讓他多服務幾位客戶。

這組最可以保留的，是嘗試把理專的判斷方法寫清楚。對缺乏財務診斷經驗的新進理專來說，一個能逐步解釋判斷依據的助手可能很有幫助。不過，逐字稿中提到的安全線、依年齡比較資產，以及淨值和目標報酬之間的對應，都還缺少足夠的推導。客戶有能力承擔多少風險、願意承擔多少風險，以及為了達成目標需要多少報酬，這三件事要分開判斷；資產超過某個門檻，也不能直接推論他適合追求某個報酬率。

我在現場問「是要教會理專，還是取代理專」，是想釐清系統到底要改變哪一段工作。產品不必永遠二選一：可以先由系統整理資料、列出缺漏，再交給理專判斷；理專有需要時，系統再說明為什麼要問這些問題、哪些條件會改變建議。這樣才看得出哪些工作適合自動化，哪些必須保留給專業判斷。

驗證也要分成兩種。有工具輔助時，理專能不能做得更快、更正確，這是生產力的問題；沒有工具、遇到新的客戶狀況時，理專還能不能做出比較好的判斷，這是學習的問題。兩種效果都值得追求，但都不是一份滿意度問卷就能交代的。

所以第一步應該回到幾位理專的實際工作，找出最花時間、最常出錯的判斷環節，再測試這套方法有沒有真的改善。介面做得越像正式產品，越要把方法的適用範圍講清楚，免得使用者把畫面上整齊的呈現，當成已經驗證過的結論。

本節資料：評審筆記第 18–29 行；逐字稿第 232–254 行。

理專副駕

「沒有人記住張董」在簡報開場時比較像感性訴求，到了問答才具體起來：理專換人的時候，過去的往來紀錄、客戶偏好和溝通上要注意的地方，都沒有好好交接。講到這裡，提案的工作對象就清楚了，客戶關係的問題也和組織的經驗傳承、服務能不能延續連在一起。

這個工具有沒有用，關鍵在 Call Memo（拜訪紀錄）寫得好不好。所謂寫得好，重點在於分得出哪些是客戶親口說的、哪些是理專的推測，以及當時是在什麼情況下說的，寫得多反而是其次。接手的理專也要能判斷：這項偏好現在還適用嗎？上次答應客戶的事做完了沒？舉例來說，「不喜歡股票」和「今年有一筆大支出，暫時承受不了波動」，會導出完全不同的服務建議。如果兩者都被簡化成「保守型客戶」，真正有用的資訊就不見了。

提案中提到的兩週、三週與三分鐘，目前只能當作設計目標，還不能當成客戶的行為規律。商品到期日是事先知道的，可以提前安排聯繫；但還沒發生、也不知道日期的市場事件，不會因為系統設計了「提前三週提醒」就能預先掌握。這兩類提醒要分開說明。

第一階段可以先聚焦在理專交接時的一頁式客戶摘要。摘要裡每一項重要描述都要能追溯到原始紀錄；資訊互相矛盾或已經過時的，就標示出來，請接手的理專核對。先衡量準備時間、資料錯誤，以及重複詢問客戶的次數，再追蹤到期資金有沒有留下來，會比一開始就同時承諾完整的資產建議和市場預警，更容易驗證。

「被記得的錢會留下來」這個假設可以測，但資金去留也會受到價格、商品條件與資金用途影響，必須有對照比較，才分得出客戶紀錄的傳承到底多貢獻了多少。就算短期內留存率看不出差異，交接品質變好、服務沒有斷掉，本身也是很明確的階段成果。

本節資料：評審筆記第 36–40 行；逐字稿第 264–278 行。

高資產客戶財務實驗室

幫客戶算清楚自己有多少淨資產，價值很容易理解。難的是，客戶往往要先整理、授權或手動輸入其他金融機構的資料，才看得到後面的分析。這組把資料整理、財務診斷和商品建議一次放進產品裡，使用者要花的時間和心力，可能比簡報上看起來的多。

團隊提出 OCR、手動輸入與自動帶入三種方式，也訂了三分鐘建好資產表、辨識率等測試門檻。這些可以當作預定的驗證條件，但目前還不能算是已經達成的成果。正式評估時，要逐一列出支援哪些資料來源、怎麼取得、需要哪些授權，以及多久更新一次。「銀行 App 禁止截圖」或「只有第三方才能串接」，不見得每家金融機構都一樣；同樣地，也不能只用一句 OCR 或 API，就跳過實際取得資料的步驟。

另外，系統辨識成功，不代表財務資料就正確。金額、幣別、日期、負債餘額，或同一筆資產被重複計算，只要有一項出錯，後面的診斷就可能跟著出錯。介面要讓客戶清楚看到哪些資料已經確認、哪些只是系統辨識的結果，也要讓他能輕鬆修正。如果把校正的工夫全丟給使用者，完成率一樣會受影響。

我會建議第一版先減少需要的資料，只幫客戶完成一個明確的判斷，例如未來有一筆支出時，手上的流動資金夠不夠。等客戶拿到第一個有用的答案，再請他補充更多資料。這樣能比較早看出客戶的使用意願，也比較容易知道客戶願意為哪一種協助花時間。

至於同薪資或同產業的財富排名，要先說明拿誰來比。團隊展示了這項功能，但沒有說明比較樣本的代表性。如果資料只來自部分使用者，就不能讓客戶誤以為這是自己在同齡或同業中的真實位置。這一案後續要追蹤的是：客戶看完分析以後，有沒有真的做出一個對自己有用的財務決定。

本節資料：評審筆記第 49–57 行；逐字稿第 282–300 行。

法金客群跨售模擬實驗室

這組同時要滿足 PM 和 AO 的需求：PM 想知道產品該怎麼設計，AO 想知道怎麼了解客戶、怎麼處理客戶異議。放在同一個平台上有助於雙方合作，但兩種用途要分開驗證。角色扮演做得再逼真，也不能證明它對市場反應的預測是準的。

AO 訓練可以先做。依照實際常見的客戶異議和業務規則設計情境，觀察學員是不是更會問出需求、看出限制，並提出合適的下一步。訓練成效不能只看能不能說服客戶接受產品，也要看學員能不能分辨哪些案子不適合承作、哪些資訊還不夠。

PM 模式則要先決定商業目標。增加開戶數、提高授信額度的動用率、增加跨售，或爭取成長型企業，需要的資料和判斷標準都不一樣。以中小企業來說，現金流週期、交易模式、財務透明度和擔保條件，往往比把企業主描述成某種個性，更適合拿來設計產品。

銀行的授信風險胃納，尤其不能省略。客戶想不想要、銀行願不願意承作，以及這筆業務能不能帶來合理的報酬，是三個不同的問題。模擬如果只回答客戶喜不喜歡，還不足以作為法金產品決策的依據。

團隊提出用既有的購買紀錄來驗證，這個方向可以繼續，但也要把沒買、沒被接觸過，以及沒通過審核的客戶一起納入。如果只看成交客戶，很容易把過去業務選擇拜訪誰、審核核准了誰，誤認為是整個市場的需求。下一步可以先把 AO 訓練做成能實際測試的服務，再為 PM 模式準備足以比較的資料。

本節資料：評審筆記第 64–70 行；逐字稿第 310–328 行。

CarLab 360

PM 用 Excel 試算，財務質疑假設，PM 回去重算，再開一次會。CarLab 360 抓到的就是這段一再重複的流程：開會時沒辦法當場比較不同情境，只好來回往返，時間拖長，彼此的不信任也跟著增加。問題描述得這麼具體，才有辦法判斷新工具到底改善了哪一段。

不過，共同試算只能解決一部分的分歧。資料、公式和假設不一致，可以透過模型釐清；但風險偏好、預算責任和成長目標不同，還是要靠明確的決策權限來處理。就算雙方完全認同試算結果，對這個風險值不值得承擔，也可能有不同看法。系統可以讓這些差異更容易攤開來討論，但不能假設雙方看著同一張儀表板，就會自然有共識。

第一版要先和雙方確認損益定義、參數來源、誰可以修改，以及怎麼核定。自然語言介面可以幫忙調整情境、說明差異，但參數要調多少，應該來自已經核定的假設或過去的實際資料。如果讓生成式 AI 自己把新聞轉成精確的數字，畫面雖然能馬上更新，數字卻不一定有足夠的依據。

團隊提到的信用卡虧損與年度上限，是現場的說明，不能直接當成銀行實際的損益；「例如五億」也只是舉例。後續要拿到這項產品實際採用的損益規則，才有辦法驗證系統。

省下時間本身就有價值，但還可以進一步衡量來回討論的次數、假設考慮得夠不夠周全，以及核定後的實際結果和原先預估差多少。這一案已經有條件先從一項信用卡產品開始，讓財務和 PM 在實際開會時一起使用。能重現試算結果、說得出差異在哪裡，比急著加入更多 AI 功能重要。

本節資料：評審筆記第 77–86 行；逐字稿第 332–344 行。

PreSense

PreSense 先讓虛擬客群閱讀行銷素材，再評估他們的理解程度、興趣和信任感。這一案首先要查清楚，這些虛擬回應和真人的反應到底有多接近。行內既有的客群標籤可以用來建立情境，但知道客戶有哪些特徵，還不足以預測他看到某則文案後會怎麼做，這中間還需要驗證。

我在現場請團隊比較虛擬測試和小規模實際投放的成本，是希望團隊說明為什麼選擇這條路。真人測試也不一定比較便宜：招募受測者、轉換率低時需要的樣本數、金融行銷的法規限制，以及接觸客戶的成本，都可能讓比較結果不同。比較的標準應該是：要拿到足以改變決策的資訊，總共要花多少成本。

團隊最後把用途縮小成「淘汰最不合適的方案」，這樣雖然降低了原本的承諾，誤判的風險仍然存在。如果被淘汰的剛好是真人最喜歡的方案，系統一樣會造成損失。所以後續測試要保留一部分被 AI 淘汰的版本，也拿去給真人檢驗，才知道模型有沒有把好方案刪掉。

第一版可以先處理判斷標準比較明確的問題，例如文案有沒有歧義、條件有沒有互相矛盾、重要的限制有沒有講清楚，再請實際的目標受眾確認是否看得懂。一旦涉及偏好和實際行動，就要承認模型的判斷還需要校準，不能讓儀表板上的分數看起來像客戶已經投過票。

國外的研究也發現，建立虛擬客戶時用了哪些資料，會影響模擬的結果。有一項研究找了 1,052 位美國受試者，除了人口特徵，還用了深度訪談和問卷來建立虛擬代理人。即使如此，這樣的結果也不能直接推論到臺灣的金融客群，認定行銷素材的反應已經能準確模擬。^[3]

本節資料：評審筆記第 93–106 行；逐字稿第 354–377 行。

Project Echo

Echo 要解決的是產品概念階段的等待：PM 有了想法，卻要花時間做市調、收集回饋，才能決定要不要往下做。這個需求很明確，也有機會做成好用的實驗工具。目前比較大的問題是說法前後不一致：簡報把系統講成市場驗證，問答時又把用途縮小成前期篩選，這兩種說法要先統一。

團隊在原型中把提案的通過門檻設為八十分，也提出與真人判斷的一致率超過 85%、可以節省成本等預期，但還沒有說明怎麼計算，也沒有實證資料。特別是「一致」要先定義清楚：選到相同的方案、排出相近的順序，或準確預測採用比例，代表的是不同的能力。沒有先講清楚，這些數字就不能當作驗收標準。

「人機對抗」的設計可以繼續發展。做法是讓 PM 和 AI 在看不到對方答案的情況下，各自留下判斷，並事先固定要預測什麼、用什麼指標衡量、什麼時候驗證，再拿真人測試或實際結果來比對。必要時，可以再加一組由人和 AI 一起判斷，看看結合之後是不是真的比較好。這樣才能逐步了解：AI 擅長哪些問題、資深 PM 的直覺在哪些情況比較準，以及 AI 會不會讓原本判斷正確的人改成錯誤的答案。

我會把第一個要驗收的功能訂得很小：版本固定的方案、可追溯的預測紀錄，以及事後的結果比對。角色生成和熱度圖都可以晚點再做。現階段最重要的工作，是開始累積人與模型判斷差在哪裡的實際紀錄。

團隊打算用網路留言作為市場回饋的來源。這些留言可以看出消費者的疑慮和常用說法，但不能直接當成市場比例：找得到反對意見，不代表知道有多少客戶反對；AI 生成再多回應，也不等於多了同樣數量的真人意見。Echo 如果能一直守住這條界線，才比較有機會成為 PM 長期使用的學習工具。

本節資料：評審筆記第 113–120 行；逐字稿第 385–401 行。

客戶營運數位孿生平台

客戶知道自己遇到了什麼事，卻不知道銀行把這件事歸在哪一類業務。這組從這個落差出發，讓客戶用自己的話描述問題，分類和找窗口的工作則交給銀行處理。需求定義得很具體，也說明了為什麼有些客戶一聯繫客服就想轉真人：光是看懂選單，就已經很花力氣。

不過，產品裡其實包含好幾項不同的工作：理解客戶的問題、找出對應的知識或處理流程、找到有能力也有權限處理的人員，以及決定排隊的優先順序，這些都要分開設計。我會問「要接到對的人，還是對的題庫」，是因為兩者可能都需要，但不能互相取代。問題分類正確，也不保證被分派的人員有權限把事情處理完。

根據 Jev 的官方文件，它可以用明確的選項、評分規則和機率輸出來處理結構化判斷，和客服分類的任務性質相符。但性質相符，不表示它用在行內的業務分類上就已經準確。分類規則怎麼訂、客戶講不清楚時怎麼追問，以及系統判斷不了時要轉去哪裡，都還要由業務單位一起定義。^[4]

過去的轉接紀錄也不能直接當成標準答案，因為當時可能就分錯了，或是人手不足才轉給次佳的窗口。應該由熟悉業務的人員審核一批資料，作為評估的基準；測試「用第一句話分流」時，只能給系統當下已經拿到的資訊，不能把後面的完整對話一起輸入，否則會高估系統實際上線後的能力。

排隊規則更需要另外討論。客戶情緒激動、資產較高、問題緊急，是三種不同的條件。詐騙、掛失和重大交易風險，一定要有明確的優先處理機制；但客戶表達不滿，不應該自動變成可以插隊。從團隊在問答時的回答來看，這部分還沒有一致的原則。

第一階段可以先從文字客服開始，讓系統在後台提出分流建議，但不實際改變分流。先觀察重大問題有沒有被漏掉、錯誤轉接的情況，以及客戶重複聯繫的次數，再決定要不要接上語音和排隊控制。這樣能把分類效果和其他技術問題分開來看，以免一次改太多，出了問題卻找不到原因。

本節資料：評審筆記第 127–134 行；逐字稿第 403–429 行。

智慧產業風險預警

重大事件發生時，RM 想及早知道哪些授信戶會受影響、銀行的曝險有多大，以及接下來該怎麼處理。這個需求有明確的商業價值；團隊在問答時也把效益從加快整理新聞，往前推到減少損失。

但我追問分析方法時，團隊的回答還是集中在買了哪些資料。產業資料和財報可以當作分析的素材，接下來還要說明，事件會怎麼影響客戶的訂單、成本、現金流和還款能力，最後又怎麼影響銀行的風險。兩家公司在供應鏈上有關聯，只代表影響可能傳過去，不能直接推算出損失有多大。

每一次預警，至少要讓 RM 看得懂：系統根據哪些證據判斷有影響、哪些只是情境假設、哪些客戶要優先確認，以及後續該採取什麼行動。「可能受影響的授信曝險」和「預期損失金額」尤其要分清楚，免得把影響範圍的盤點，誤看成損失預測。

團隊提出先以一條產業鏈、約三十戶授信戶做三個月的試點，範圍已經控制得相當節制。不過，試點期間不適合拿呆帳減少當作主要的成功指標，因為這段時間內可能根本還沒有發生事件或損失。比較適合的階段成果是：事件與客戶之間的關聯可以追溯、優先名單經過審查確認，以及後續確認和處理的完成情況。

做歷史回測時，只能使用事件發生當下拿得到的資料。如果把事後才公布的財報或已知的結果放進去，系統看起來當然很準，卻證明不了它在當時能提出同樣有用的預警。這組下一步要補強的，是讓分析方法和證據來源都能被檢驗。

本節資料：評審筆記第 141–146 行；逐字稿第 431–447 行。

授信流程孿生

這組把問題講得很實際：資料還沒備齊就先送審，到了後段又為了文件或備忘錄來回補件。事先檢查、讓相關人員都看得到案件進度，以及提早找出例外狀況，都有機會減少不必要的等待。

動手做之前，要先把文件要求分類清楚：哪些是法規規定、哪些是內部風控要求、哪些只是作業慣例，再由有權責的主管確認哪些可以調整。法規沒有明文要求的文件，也可能具有必要的控管作用，不能全部刪掉；過去曾經核准過一次例外，也不代表以後都可以比照辦理。

還有一點要留意：資料還沒全部備齊就先預審，有時是刻意安排的平行作業。改善方案要做的是提早發現缺件與風險；如果把所有案件都改成資料齊全才開始審，整體時間反而會拉長。判斷流程有沒有變好，還是要看一筆案件從受理到完成的整段時間。

從六天縮短到四天半，等於少了四分之一的時間，可能已經很有價值，不必因為數字不夠驚人就看輕它。接下來要看案件量、客戶等待資金的成本，以及特別慢的案件有沒有改善。團隊提到一件拖了一年的個案，說明這類少數但特別慢的案件需要追蹤，但不能只憑一件極端個案，就推估整體的效益。

第一版可以先把正式的文件規則、版本管理、缺件提示和例外申請做清楚。等案件紀錄夠完整，再判斷流程模擬能不能比一般的追蹤與統計多帶來什麼價值。第一階段不一定要先做出數位孿生；如果統一規則、讓案件進度透明，就能解決大部分的問題，那就先把這些做好。

本節資料：評審筆記第 153–163 行；逐字稿第 451–479 行。

TwinLive 孿生直播客戶平台

看完整段問答，這組的重點才比較清楚：團隊希望在客戶開口之前，就根據交易失敗的紀錄和近期發生的事件，推測客戶可能需要什麼協助。這和第四組在客戶開口後才分類的做法不同，兩組可以互補。

不過，這個提案裡其實有幾種不同的任務：預測今天哪一類問題最多、預測哪位客戶可能來電，以及針對已經發生的交易失敗主動提供協助。最後一項也許用現有的事件紀錄和明確的規則就做得到，不必全都靠複雜的個人孿生模型。先挑一種容易辨識、也處理得了的失敗狀況來做，比較容易看出主動服務到底有沒有幫助。

直播的價值要另外證明。系統異常、規則變更或操作說明這類很多人都會遇到的問題，可能適合一次對很多人說明；但個人交易、帳戶問題和爭議處理，還是需要一對一的服務。評估時要比較直播、公告、推播和互動式說明的效果，不能只看同時有多少人上線，就換算成省下多少客服量。

主播承受的情緒壓力要納入測試，但也不必預設直播一定行不通。反倒是對負面留言禁言三分鐘的做法，不足以處理風險。一般的抱怨和惡意辱罵必須分開處理，客戶不能因為對服務不滿，就失去求助的管道。直播中的留言管理、轉接和後續處理，都是實際要付出的成本。

至於「減少三分之一人力」，團隊後來澄清，意思是把人力重新配置到其他服務。既然如此，驗證時就要看實際減少了多少重複的詢問、多出多少處理複雜案件的能力，再扣掉直播和管理需要的人力。這一案可以先保留主動服務的部分，直播另外做小規模的比較，不必急著把兩者綁成同一套系統。

本節資料：評審筆記第 170–174 行；逐字稿第 481–503 行。