轉介紹追蹤不要先從推薦碼工具開始，而要先把 6 個欄位補齊：推薦人、被推薦的新名單、來源渠道、活動或 UTM、同意與獎勵規則、最後處理結果。台灣 SME 常見的問題不是沒有老客戶願意介紹，而是介紹發生在 LINE、電話、店員口頭、顧問群組或朋友訊息裡，後來查不到誰介紹誰、誰要跟進、獎勵算不算成立，也不知道這批名單到底有沒有變成營收。
為什麼口頭介紹最容易漏掉商業證據
轉介紹本來是中小企業最有信任基礎的客源之一。Salesforce 的小型企業 referral program 指南把 referral program 定義成有系統地鼓勵既有客戶把產品或服務介紹給親友、同事或網絡，並用獎勵、折扣或現金回饋換取新名單。這個定義有一個關鍵字：有系統。沒有系統時，轉介紹會看起來很多，但其實只是散落在每個人的手機裡。
台灣 SME 最常見的失誤，是把「某某介紹的」寫在聊天紀錄或業務腦中。等到新客戶三週後成交，行銷不知道來源，老闆不知道該不該發獎勵，客服不知道要不要用熟人介紹的語氣接待，下一次活動也無法判斷哪個推薦機制有效。這不是工具問題，而是欄位問題。
Google Analytics 說明 traffic-source dimensions 是理解來源與歸因的基礎，source、medium、campaign、campaign ID 會幫助你知道使用者從哪裡來、經由什麼方式到達、屬於哪個行銷活動。這個概念搬到轉介紹也一樣：你不一定一開始就需要昂貴系統，但每一筆推薦至少要能回答「誰帶來的、從哪裡來、現在到哪一步」。
轉介紹追蹤先補這 6 個欄位
最小可用的轉介紹追蹤表，不是把 CRM 做得很滿，而是讓後續對帳、跟進與獎勵有共同語言。下面 6 個欄位適合先放進 Google Sheet、Airtable、Notion、HubSpot、Zoho、LINE SCRM 或你現在已經在用的 CRM。
| 欄位 | 記什麼 | 避免的問題 |
|---|---|---|
| 推薦人 | 既有客戶、合作夥伴、店員或顧問名稱，另用內部 ID 對應個資。 | 成交後找不到該謝誰、該不該給獎勵。 |
| 被推薦名單 | 新名單的姓名或公司、聯絡方式、需求摘要與建立日期。 | 只知道有人介紹，卻沒有可跟進的 lead。 |
| 來源渠道 | LINE、電話、門市、講座、Email、社群私訊、合作夥伴表單。 | 無法判斷哪個情境最容易帶來有效推薦。 |
| 活動或 UTM | 推薦活動代號、推薦碼、utm_source、utm_medium、utm_campaign。 | 同一個推薦活動在報表裡被拆成多種寫法。 |
| 同意與獎勵規則 | 是否已告知資料用途、獎勵條件、首次購買或成交後才成立。 | 獎勵爭議、個資使用範圍不清、承諾前後不一致。 |
| 處理結果 | 未聯繫、已聯繫、無需求、報價中、成交、失敗原因與日期。 | 只能看推薦數，不能看推薦品質與成交率。 |
推薦碼、UTM、CRM 欄位要分工，不要混在一起
推薦碼適合辨識「這個人使用哪個推薦入口」，UTM 適合辨識「這次流量從哪個行銷活動來」，CRM 欄位則負責保存「業務跟進與成交結果」。三者不要互相取代。把所有資訊塞進推薦碼，之後會看不懂；把客戶電話或 email 塞進 UTM，更可能造成個資外洩風險。
Google Analytics 的 manual tagging 文件提醒，如果 URL 上有任一 UTM 參數，Analytics 會依 UTM 參數推導跨渠道來源維度；缺少 UTM 參數會讓報表出現 not set。對轉介紹活動來說，這代表你不能今天寫 utm_source=line、明天寫 utm_source=LINE OA、後天又寫 utm_source=friend。先固定命名，比事後清理報表便宜很多。
建議用這個簡單規則：utm_source 寫來源平台或合作入口，例如 line、email、partner；utm_medium 寫 referral、message、offline 或 event；utm_campaign 寫活動名稱，例如 2026q4_referral；推薦碼另外放在 URL 參數或表單欄位，例如 ref=amy01。CRM 裡再用「推薦人 ID」和「獎勵狀態」對應，不要把個資暴露在網址裡。
先分清楚名單建立與成交，不然獎勵會失真
很多推薦活動失控，是因為獎勵規則只寫「介紹成功」，卻沒有定義成功是填表、完成諮詢、第一次購買，還是完成付款且過了退貨期。Google Analytics 的 recommended events 文件把初始 lead acquisition 用 generate_lead 來記錄，後續又有 lead 成交或未成交相關事件。即使你不寫程式，也可以借用這個思路：先記「名單成立」，再記「商業結果成立」。
對台灣 SME 來說，最簡單的做法是在 CRM 加兩個日期：推薦建立日、獎勵成立日。前者代表你收到可跟進的新名單，後者代表達到獎勵條件。中間再加狀態欄位，例如已聯繫、已報價、成交、無需求、重複名單。這樣才不會每次老客戶來問「我介紹的人有沒有算」時，只能翻聊天紀錄。
AI 可以幫忙整理，但不能替你判定獎勵成立
如果你已經有大量 LINE 對話、客服紀錄或業務筆記，AI 可以幫忙做第一輪整理：萃取被推薦者需求、標記可能的推薦人、把對話摘要貼回 CRM。但 AI 不應該直接判定獎勵成立，因為它可能誤讀暱稱、搞混同名客戶，或把「朋友問一下」當成正式推薦。
比較穩的流程是：AI 先把待確認欄位列出，人員再核准推薦人、獎勵條件與個資使用範圍。尤其是金額、折扣、佣金、點數、禮券或合作分潤，應該由人確認後才更新狀態。AI 的價值是減少整理時間，不是把責任從業務或老闆身上拿走。
適用與不適用的商家
這套轉介紹追蹤方式適合客單價較高、決策週期較長、介紹信任感很重要的台灣 SME，例如室內設計、顧問服務、B2B 解決方案、醫美牙科、教育課程、婚禮服務、旅遊客製、在地門市會員經營。這些生意的共同點是：介紹不一定立刻成交，但只要跟進得好，價值通常高於一次普通廣告點擊。
它不適合只想做一次性抽獎、低價衝流量、沒有任何後續跟進能力的活動。如果你的團隊連新名單 24 小時內由誰聯繫都還沒決定，先不要把推薦獎勵設得太複雜。先補跟進責任，再談推薦成長。
7 天內建立最小可用追蹤表
第一天，盤點最近 30 天所有轉介紹來源，包含 LINE 對話、員工口頭回報、表單備註、門市紙本與合作夥伴名單。第二天，把 6 個欄位放進同一張表，先不要追求自動化。第三天，統一 UTM 與推薦碼命名，至少確定大小寫、活動代號、來源渠道不會亂寫。
第四天，把正在跑的推薦入口都導到同一張表單或同一個 CRM 建檔流程。第五天，補上獎勵規則，例如「新客完成首次付款且過鑑賞期後成立」。第六天，讓業務或客服用 10 筆舊資料測試，檢查是否能回答誰介紹、誰跟進、結果如何。第七天，做第一版報表，只看三個數字：推薦名單數、已聯繫比例、成交或有效商機比例。
等這 7 天跑順，再考慮是否接自動化、推薦碼系統、會員點數或 AI 摘要。工具升級應該建立在欄位已經正確的基礎上，不然只是把混亂同步到更多地方。
資料更新與來源
本文更新於 2026 年 9 月 10 日。主要來源包括 Salesforce 的小型企業 referral program 指南、Google Analytics 的 traffic-source dimensions 說明、Google Analytics 的 manual tagging and auto-tagging 說明、Google Analytics recommended events 對 lead generation 事件的說明，以及個資會籌備處的 個資法條文及相關解釋入口。Google developers recommended events 頁面本次搜尋摘要可見，但直接開啟時逾時，因此本文只採用搜尋摘要可觀察到的 lead-generation 事件說明，不把未讀到的內頁細節當成完整查核。
個資與獎勵規則會隨產業與活動設計而不同。若推薦活動涉及現金回饋、抽獎、會員點數、醫療或金融服務，建議另外請法務或合規窗口檢查活動辦法、告知事項與資料留存期限。
結論：先把推薦變成可查的線索
轉介紹追蹤的重點，不是把每位老客戶都變成業務，也不是先買一套推薦碼系統。真正的第一步，是讓每一筆推薦都能被查回來源、跟進責任、獎勵條件與最後結果。當這 6 個欄位跑順，你才知道哪種客戶最願意介紹、哪個渠道帶來有效名單、哪種獎勵值得保留。口碑不能完全被控制，但可以被記錄、被感謝、被跟進，也可以被改成下一次更準的行銷動作。
FAQ
轉介紹追蹤一定要買推薦碼系統嗎？
不一定。台灣 SME 可以先用試算表或現有 CRM 補齊推薦人、被推薦名單、來源、活動代號、獎勵規則與處理結果。等欄位穩定後，再評估推薦碼或自動化工具。
推薦碼和 UTM 有什麼差別？
推薦碼用來辨識推薦人或推薦入口，UTM 用來辨識流量來源、媒介與活動。推薦碼通常回到 CRM 對帳，UTM 則主要用於 GA4 或行銷報表。
轉介紹獎勵應該在填表後就發嗎？
通常不建議。比較穩的做法是先定義獎勵成立條件，例如完成首次付款、過鑑賞期、簽約或達到指定金額，避免無效名單也觸發獎勵。
可以把客戶電話放進推薦連結或 UTM 嗎？
不建議。電話、Email、身分證字號等個資不應暴露在網址參數中。可用內部 ID 或推薦碼對應，個資保存在權限受控的 CRM 或表單後台。
AI 能不能自動判斷誰介紹誰？
AI 可以協助整理聊天紀錄和摘要可能的推薦關係，但獎勵成立、個資使用和成交狀態仍應由人員確認，避免同名、暱稱或語意誤判。