開案前 30 秒，先知道這位客人是誰

業務接到一個新案子，第一件事通常是打開搜尋引擎，看看能不能多了解一點這位客人——是第一次來台灣，還是常客；喜歡什麼樣的行程風格。這件事很多業務都會做，只是每次都要自己動手查，零零散散花掉不少時間。

我把這個動作接到進單流程裡，變成客人的詢問一進系統，就自動幫忙先查一輪。回頭看，這正是旅行社數位化這幾年在我們公司實際發生的樣子：一次一個小動作，從業務手上搬到系統裡。

怎麼接起來的

新的詢問寫進客戶資料表的當下，會觸發一個通知送到後端的小程式，由它去呼叫具備網路搜尋能力的 AI，查詢這位客人公開可見的社群資料跟興趣，把整理出來的摘要寫回資料表裡對應的欄位，業務打開這筆詢問的時候就看得到。

有一條規則放在最前面：只處理一般散客的詢問，同業的來信會直接跳過，不會浪費力氣去查一家早就認識的旅行社。

踩過的雷，這幾個最值得記下來

第一個雷是權限設定。把這個小程式部署成一個能接收外部通知的服務時，存取權限要選最寬鬆的那一種、任何人都能呼叫，而不是「任何有帳號的人」這種聽起來比較安全、實際上會擋掉外部驗證的選項。選錯了，外部服務送驗證請求進來會先被導去要求登入，整個串接會直接失敗，而且錯誤訊息完全看不出問題出在權限設定，我卡了好一陣子才發現。

第二個雷是通知事件的格式。有些系統要求訂閱事件時只能填一種固定的字串格式，換成看起來更合理的結構化寫法反而會被直接拒絕。文件上不一定寫得清楚，只能照著範例原封不動地填。

第三個雷是，驗證一旦失敗，狀態基本上救不回來，只能整個刪掉重建。這代表前面兩個雷只要踩到任何一個，最快的解法不是去找哪裡設定錯，是乾脆重新設定一次。

第四個是搜尋引擎本身的限制：同名同姓的人到處都是，要讓 AI 找對人，必須在請求裡塞進足夠的辨識資訊，像是國籍、信箱網域，不然很容易查到完全不相干的另一個人，摘要出來的內容看起來煞有介事，其實文不對題。

這件事花多少錢

以每個月一百多筆一般散客的量估算，這部分的查詢費用大概是新台幣兩百多塊；量增加到兩百筆左右，也還在幾百塊的範圍內。負責接收通知跟寫回資料的那段程式本身不用另外付費。

界線要畫清楚

查到的都是公開資訊，摘要只會寫進內部才看得到的欄位，不會外流，也不會拿去對客人說了什麼。這份摘要的定位是「幫業務多一點背景」，不是拿來做任何決定的唯一依據——查到的東西終究只是輔助，真正怎麼接待客人，還是業務自己判斷。

如果你也是旅行社

如果你的業務每次接案都會習慣性搜尋一下客人的背景，這個動作很值得自動化，因為它幾乎不牽涉判斷，純粹是把「查資料」這個機械性的步驟提前做好。以這裡的量體來看，一個月幾百塊台幣，換來業務每次開案前現成的一點背景資訊，投資報酬率算是相當高的一項。