為合夥人主導團隊而設的關係跟進系統

想像一個合夥人主導的顧問業務，有 25 人，服務一組長期客戶關係。

合夥人帶來工作、主導敏感對話，並掌握不少難以整齊放入 CRM 的背景。顧問和營運同事推動項目前進。客戶期望連貫性：如果公司承諾了介紹、筆記、建議書，或董事會會議後的跟進，就需要有人記得這件事為何重要。

這個業務不需要 AI 代它管理關係。它需要保護 follow-through 的基礎設施。

這正是 Proximity 可以被調整成關係跟進系統的地方。

系統的工作，是保存共享記憶、準備背景，並把承諾浮現出來供人審閱。它不應自動化關係判斷、決定語氣、評估信任、選擇策略，或未經批准發送敏感客戶通訊。

工作流程

這個工作流程，是每週關係跟進審閱。

團隊需要知道：

• 向客戶或合作夥伴作出了哪些承諾。
• 每項承諾由誰負責。
• 哪些背景令跟進敏感或重要。
• 哪些過往對話、文件或決定相關。
• 哪些承諾即將到期或已逾期。
• 哪些跟進在行動前需要合夥人審閱。

CRM 很有用，但關係主導的工作往往依賴比銷售階段更細膩的背景。合夥人記得某位客戶不喜歡倉促建議書。顧問知道上次草稿因欠缺數據而延遲。營運同事知道承諾中的介紹取決於第三方。這些都不應只留在記憶裏。

Proximity 會把承諾和背景轉化成可審閱的營運層。

這個營運層的重點，不是把所有客戶互動變成銷售機會，也不是把人際判斷壓縮成一個分數。它要處理的是一種更日常、但對專業服務非常關鍵的問題：團隊曾經答應過甚麼、為甚麼答應、誰應該跟進，以及跟進前需要知道哪些背景。當這些資料只留在個別人的收件箱、會議筆記或腦海中，客戶感受到的就會是斷裂。

在合夥人主導顧問、法律、財富管理或企業服務團隊中，很多承諾都不是正式任務單。它可能是一句「我下星期介紹你給某位董事」、一次「我會叫同事整理一頁紙」、或會議後一句「我們先內部看一看再回覆」。這些承諾未必很大，但累積起來就是信任。

Proximity 會建立甚麼模型

在這個部署中，Proximity 會以「承諾」作為核心對象。

經批准來源可能包括：

• 會議筆記。
• 電郵討論串。
• CRM 紀錄。
• 項目追蹤表。
• 日曆。
• 建議書草稿。
• 合夥人筆記。
• 客戶歷史摘要。
• 內部交接筆記。

系統會把這些來源結構化為：

• 人、機構、關係負責人和內部團隊。
• 承諾、來源、負責人和到期日。
• 相關項目或機會。
• 敏感性或審閱邊界。
• 過往背景和相關決定。
• 跟進草稿狀態。
• 審閱負責人。
• 完成證據。

關於 transactive memory systems 的研究在這裏很有用。Ren 和 Argote 描述團隊如何在成員之間編碼、儲存、取回和溝通知識，包括知道誰知道甚麼。Lewis 的研究則量度專門化、可信度和協調。合夥人主導的業務本來已經以社交方式如此運作。Proximity 令其中一部分記憶更持久、更可審閱。

這種模型亦令交接更實際。新加入的顧問不需要只靠「你問某某吧」去理解客戶背景；他可以看到哪一項承諾來自哪次會議、哪封電郵、哪份建議書草稿，以及哪位合夥人需要先看過。營運同事也不用只憑日曆提醒追逐下一步，而可以看到提醒背後的商業和關係背景。

換句話說，系統保存的不是抽象知識庫，而是可行動、可審閱、仍然由人負責的共享記憶。它讓團隊記得更穩定，但不把關係判斷交給軟件。

系統會準備甚麼

每週審閱之前，Proximity 可以準備一個關係佇列。

每個項目可能包括：

• 承諾內容。
• 承諾在哪裏被捕捉。
• 它為何重要。
• 負責人和下一個日期。
• 相關過往背景。
• 供審閱的草擬跟進語句。
• 如需要合夥人批准，列明審閱邊界。
• 欠缺背景或不確定性。

系統亦可以準備合夥人通話簡報：

• 近期互動。
• 未完成承諾。
• 敏感背景。
• 項目狀態。
• 可能在通話中出現的文件或決定。
• 通話前建議先在內部釐清的問題。

這些簡報不應聲稱知道合夥人應該作甚麼決定。它們應讓合夥人更容易準備好進入對話。

簡報亦應反映關係工作的時間性。上一次互動可能只是兩日前，也可能是三個月前；同一項承諾在客戶融資、交易、招聘或董事會節奏改變後，重要性可能已經不同。Proximity 應把「近期互動」、「仍然未完成的承諾」和「可能已過時的背景」分開，讓合夥人知道哪些內容可以直接使用，哪些需要先確認。

Anthropic 關於 effective agents 的指引區分了工作流程和更自主的 agents。關係主導工作應由窄身工作流程開始：抽取承諾、準備簡報、浮現過期承諾，並把敏感草稿路由至審閱。廣泛自主不是合適的預設，因為這類工作的價值在於人的信任。

在產品層面，這亦意味著輸出要保留不確定性。系統可以說「這似乎是一項承諾，來源是會議筆記」，但不應把它包裝成已確認指令。它可以提醒「客戶上次提到時間壓力」，但不應聲稱已理解客戶情緒。它可以草擬一段跟進文字，但應讓合夥人或負責同事決定是否發送、如何改寫、是否需要先打電話而不是發電郵。

甚麼仍然由人負責

關係判斷仍然由人負責。

Proximity 不得決定關係策略、排列客戶價值、把情緒推斷當成事實、發送敏感訊息、選擇語氣、作出承諾，或決定合夥人應該說甚麼。它可以準備背景和供審閱的草擬選項，但關係由人負責。

人仍然負責：

• 關係判斷。
• 客戶策略。
• 信任和語氣。
• 最終訊息。
• 商業決定。
• 承諾和承擔。
• 升級決定。
• 專業問責。

系統應該令這條界線可見。草稿就是草稿。建議跟進不是指令。如果使用情緒訊號，也應視為供人詮釋的弱訊號，而不是事實。

這也避免團隊把「記得更多」誤解成「判斷更好」。記憶可以支援判斷，但不能代替判斷。客戶是否適合收到某種提案、某個承諾是否仍然合適、某次延遲是否需要合夥人親自致歉，這些都要由理解關係和責任的人決定。Proximity 的價值，是把人需要判斷的材料放到面前，而不是替人把判斷藏在系統裏。

試點形態

一個實際試點，可以由一個合夥人小組和一個審閱節奏開始。

第一階段會梳理承諾目前在哪裏作出、在哪裏遺失。第二階段會從經批准的會議筆記和電郵建立承諾佇列。第三階段會準備每週合夥人簡報，並追蹤跟進是否完成。

成功訊號包括：

• 較少遺漏承諾。
• 更快準備客戶通話。
• 團隊成員變動時交接更好。
• 跟進負責人更清楚。
• 更多敏感事項被路由至合夥人審閱。
• 合夥人表示簡報捕捉到有用背景，而且沒有假裝替他們作決定。

試點亦應觀察團隊是否開始更一致地記錄承諾來源。如果大家只把系統當成另一個待辦清單，價值會有限；如果它成為每週審閱前的共同記憶層，合夥人、顧問和營運同事就能圍繞同一份背景討論下一步。這才是關係跟進系統的目的：不是更大聲地提醒人，而是讓跟進有上下文、有負責人，也有審閱邊界。

試點範圍應保持窄身，否則系統很容易被 CRM 清理、銷售流程或一般任務管理拖走。較好的起點，是選一組長期客戶、一位或兩位合夥人，以及一個固定的每週審閱。先證明承諾能被可靠捕捉、來源能被查回、敏感草稿能被路由至正確人手，再考慮擴展到更多團隊或更多資料來源。

同時，團隊應保留人工修正入口。若系統誤把一句客套說話當成承諾，或漏掉真正重要的跟進，合夥人和營運同事需要能即時更正，並讓更正成為之後審閱的一部分。關係記憶只有在可被人修正時，才值得信任。

這亦令審閱更像團隊習慣，而不是一次性清理工作。每週回到同一個承諾佇列，團隊才會慢慢建立共同語言：哪些承諾需要合夥人看、哪些可由顧問跟進、哪些只需營運確認。系統保存記憶，人仍然負責關係。

所以試點的成功不應只看完成了多少待辦，而應看客戶承諾是否更少遺漏、敏感跟進是否更早升級，以及合夥人是否覺得簡報有幫助但沒有越界替他們判斷。