為顧問團隊而設的敏感客戶跟進系統

想像一個 18 人專門顧問團隊，服務的客戶正面對敏感的個人、財務或營運處境。

團隊不是臨床照護提供者，但工作仍然需要細緻照顧。客戶可能正承受壓力。細節可能具保密性。跟進可能取決於個人背景、過往承諾、家庭互動、業務壓力，或法律和財務限制。一個漏接電話或準備不足的訊息，都可能損害信任。

團隊需要更好的跟進基礎設施。它不需要 AI 代它決定甚麼對客戶最好。

這正是 Proximity 可以被調整成敏感客戶跟進系統的地方。

系統的角色，是保存背景、準備審閱，並令升級需要可見。它不應自動化照顧、專業建議、情緒判斷、診斷、風險評估或面向客戶的決定。

工作流程

這個工作流程，是每週客戶跟進審閱。

團隊需要知道：

• 哪些客戶正在等待跟進。
• 曾承諾甚麼，以及由誰承諾。
• 哪些敏感背景應影響下一次接觸。
• 哪些文件、筆記或過往決定重要。
• 哪些情況在發送任何訊息前需要資深同事審閱。
• 哪些跟進屬例行，哪些需要升級。

這種工作流程在重視關係的專業服務中很常見：顧問、財富管理、移民、家族辦公室、專門諮詢，以及其他客戶關係依賴連貫性和細心的場景。

問題不是專業人士缺乏判斷。問題是圍繞判斷的背景分散在筆記、通話、電郵、工作、文件和記憶之中。

在專業服務場景中，這類敏感跟進可能出現在家族辦公室、財務顧問、移民支援、教育顧問、企業重組或高壓營運顧問工作裏。客戶未必是在尋求臨床照護，但仍可能處於脆弱或高壓狀態。一次跟進如果忽略了家庭成員關係、保密要求、董事會時間表、資金壓力或法律限制，就可能令客戶覺得團隊沒有真正理解情況。

因此，這個工作流程不應被簡化為「誰逾期未回覆」。更重要的是下一次接觸前需要知道甚麼、哪些內容不應由初級同事直接發出、哪些情況需要資深同事或專業顧問先看過。Proximity 要做的是把這些背景和邊界呈現出來。

Proximity 會建立甚麼模型

在這個部署中，Proximity 會以「客戶跟進」作為核心工作對象。

經批准來源可能包括：

• 客戶筆記。
• 會議摘要。
• 電郵承諾。
• 工作清單。
• 文件要求。
• 過往決定紀錄。
• 內部審閱筆記。
• 升級規則。
• 相關的同意或權限紀錄。

系統會圍繞以下內容結構化背景：

• 客戶、事項、負責人和關係主理人。
• 承諾、來源、到期日和負責人。
• 敏感背景和存取邊界。
• 欠缺文件或未答問題。
• 跟進草稿狀態。
• 所需審閱人。
• 升級原因。

本文提到的私隱例子，比這個顧問場景更廣。WHO 關於健康 AI 的指引強調倫理、人權和負責任使用。美國 HIPAA 是保護健康資料的具體私隱制度。NICE 對數碼健康技術的證據標準亦顯示，影響越高的系統，需要越強的證據和治理。一般教訓可應用到醫療以外：敏感客戶工作需要背景、私隱、證據和人手問責。

這種模型要特別小心存取邊界。不是每位團隊成員都應看到所有敏感背景；有些資料只應供關係負責人、合夥人或指定專業人士審閱。系統如果把所有資料混在一起，只為了產生一段流暢摘要，就會破壞原本應有的保密安排。相反，它應顯示某項資料存在、誰有權查看、它是否影響下一步跟進，以及是否需要升級。

「升級原因」亦不應神秘。系統不應只顯示警示，而應說明是因為逾期、客戶情況變更、欠缺同意、文件未齊，還是因為草稿涉及專業建議。這樣人才能判斷警示是否合理，也能改善之後的工作流程。

系統會準備甚麼

每週審閱之前，Proximity 可以準備一個客戶跟進佇列。

每個項目可能包括：

• 曾承諾甚麼。
• 承諾來自哪裏。
• 相關客戶背景。
• 欠缺文件或未解問題。
• 建議負責人。
• 供審閱的內部筆記或訊息草稿。
• 如果系統偵測到敏感性、不確定性或逾期跟進，列明升級原因。

當關係負責人缺席，或客戶在團隊之間轉移時，系統亦可以準備交接簡報。簡報應說明有甚麼改變、曾承諾甚麼、哪些背景重要，以及仍有甚麼未解決。

重點不是建立一段更自動化的客戶關係。重點是令人的關係少一點依賴脆弱的記憶。

交接簡報不應只是「客戶檔案」。它應聚焦下一步照顧和跟進：最近一次接觸發生了甚麼、客戶正在等待甚麼、哪個承諾最接近到期、哪些說法可能需要避免、哪些資料只供內部理解。這些內容能幫助接手同事更有分寸地行動，而不是用一段通用摘要冒充熟悉客戶。

跟進佇列應幫助團隊分辨不同類型的工作。某些項目只是行政提醒，例如補交文件或確認時間；某些項目則可能涉及客戶壓力、家庭分歧、財務承諾或法律限制，需要更小心措辭。把兩者放在同一條普通待辦清單中，會令重要差異消失。

甚麼仍然由人負責

照顧和專業判斷仍然由人負責。

Proximity 不得診斷、評估身心狀況、決定客戶需要、提供專業建議、決定正確情緒語氣、未經審閱發送敏感訊息，或以最終方式決定是否需要升級。它可以標示模式和準備背景，但必須由負責人審閱。

人仍然負責：

• 專業建議。
• 客戶照顧判斷。
• 關係判斷。
• 升級決定。
• 最終訊息內容。
• 私隱決定。
• 敏感披露。
• 任何對客戶作出的承諾。

產品應該清楚顯示這條界線。草稿就是草稿。升級佇列應路由至具名人士。敏感背景應尊重權限。系統應顯示來源紀錄和不確定性，而不是把所有事情磨平成自信語句。

NIST 的 AI Risk Management Framework 相關，因為它把 AI 風險視為社會技術治理問題。對敏感客戶工作而言，工作流程必須支援可問責的人，而不是把責任藏在自動化背後。

這也解釋了為何系統不應「評估客戶」。它可以指出某些跟進逾期，或某些資料仍未確認；但不應把有限訊號轉化成對客戶狀態、需要或風險的最終判斷。專業人士可能需要通電話、查閱正式文件、與同事討論，或按行業規則作出判斷。AI 輸出的角色，是令這些步驟更有準備，而不是令它們看似可以省略。

試點形態

一個好的試點，可以集中於一個客戶組別和一個跟進節奏。

例如，團隊可以選擇正處於活躍轉變期的客戶，因為他們需要頻繁跟進，而且背景重要。第一階段會梳理審閱節奏和來源紀錄。第二階段會從經批准的筆記、工作和承諾建立跟進佇列。第三階段會在每週審閱中測試交接簡報和升級標示。

成功訊號包括：

• 較少遺漏跟進。
• 客戶通話準備得更好。
• 承諾負責人更清楚。
• 負責人未能處理時交接更快。
• 敏感項目更一致地升級審閱。
• 花在搜尋過往背景的時間減少。

試點亦應檢查客戶體驗是否更連貫。好的結果不是客戶收到更多自動訊息，而是每次接觸都更準備好、更尊重背景，也更少出現「之前已經講過」的情況。對內而言，團隊應能清楚看到哪些承諾仍未完成、哪些訊息仍是草稿、哪些事項已由具名人士審閱。

試點範圍應選擇一組跟進頻密、但責任邊界清楚的客戶。若一開始就覆蓋所有敏感個案，團隊很難分辨系統是在改善流程，還是在製造更多警示。較好的做法，是先定義哪些來源可用、哪些資料受限、哪些情況必須升級，再用每週審閱測試跟進佇列和交接簡報是否真的幫到負責人。

團隊也應檢查警示是否適量。太多警示會令同事麻木，太少警示又會漏掉真正需要資深審閱的事項。好的系統應讓人看到為何某項跟進被標示，並容許負責人修正分類，令下一次審閱更貼近團隊的專業邊界。

同時，任何自動草擬訊息都應預設停留在內部審閱階段。敏感客戶跟進的目標，是讓人更有準備地聯絡客戶，而不是讓系統更快把未經審閱的說話送出去。當客戶情況複雜、語氣需要拿捏、或資料權限不清楚時，系統應促成人與人之間的審閱，而不是把速度放在責任之前。

這種設計也保護團隊自身。它讓承諾、來源、敏感背景和升級理由可見，同時保留由專業人士作最終決定的空間。這才是支援照顧，而不是假裝提供照顧。

對敏感客戶工作而言，這條界線比速度更重要。客戶需要連貫和尊重，團隊需要清楚責任和可追溯背景。

當系統能把這些背景準備好，負責人便可以更快進入真正需要人手判斷的部分，而不是在會前重新拼資料。