甚麼時候需要 CRM，甚麼時候試算表已足夠？

梳理一筆查詢從進線到交接的路徑

選一筆具代表性的查詢，依次走過資格判斷、跟進、確認合作及交付交接。寫下每一步由誰負責、需要哪些資料，以及資料目前放在哪裏。分清是軟件缺少能力，還是流程缺少規則。無論使用甚麼系統，「應該有人跟進」都需要變成具名負責人及日期。

先讓試算表接受一次公平測試

搬遷資料前，先統一現有登記表的做法：確定共同使用的主檔、各階段的明確定義，以及檢查逾期行動的例行安排。只保留有人會用來作決定的欄位。管理得當的簡單登記表，可能已能滿足目前需要。

• 每筆記錄有固定識別碼及具名負責人。
• 記錄目前階段、上次聯絡、下一步及到期日。
• 約定如何辨識及處理重複記錄。
• 確定誰維護欄位，以及成員離開時誰接手。

選平台前，先測試一次交接

假設例子，並非客戶項目：兩位同事共用查詢表，但跟進背景仍留在各自的收件箱。把一筆進行中的記錄交給另一位同事，請他找出最近答應的事項及下一步。如果找不到，可以試行共用活動記錄及任務分派。若加一個欄位和一套有效的例行做法就能解決，可以延後購買 CRM。

用實際角色驗證權限

寫清楚哪些人可以查看、修改、匯出及刪除資料。Google 明確提醒，保護 Sheets 的儲存格範圍不應用作安全措施；受保護的試算表仍可以被複製。不要把隱藏分頁當成保密控制。評估 CRM 時，要在擬使用的產品方案中，以具代表性的帳戶測試所需權限。「按角色存取」這個功能名稱，本身並不等於驗收方法。

以小範圍補上真正缺少的能力

如果漏跟進、交接困難或權限問題持續存在，可以先從查詢流程開始。定義必要欄位、階段、負責人、任務及待辦工作的檢視方式。先匯入清理過的樣本，並試一次匯出，再搬遷全部記錄。比較設定現成 CRM 與客製開發；只有所需流程足以支持日後維護負擔時，才選擇客製方案。

帶着流程需求開始討論

準備匿名化樣本、階段定義、權限規則、失誤例子，以及負責推動使用的人。約定如何測試交接、逾期任務及資料匯出。Chronicle 按確認的範圍以美元（USD）報價；軟件訂閱及持續支援應另行釐清。如果改善後的登記表運作可靠，就可以繼續使用，等已確認的需求改變時再評估。