詢問不會只從一個地方進來

除了客人直接寫信詢問，訂單還會從另外兩個管道跑進公司：OTA 平台的訂單通知信，還有官網表單的填寫紀錄。三個來源，三種形狀的資料，最後都要落到同一張表上——這種把分散管道收攏成一張表的功夫，正是旅行社自動化裡最不起眼、卻最基礎的一塊。

來源一：OTA 訂單信

幾家配合的 OTA 平台，訂單成立會寄一封確認信過來。每家平台的信件格式完全不一樣，所以拆成一支主程式加三個各自獨立的解析模組——哪天多合作一家新平台，加一個新模組就好，主程式不用動。

解析出來的欄位都一樣：訂單編號、團名、出發日期、人數、客人姓名跟 Email、金額。防重複靠的是訂單編號，同一個編號已經在表裡出現過，直接跳過不會重複開團。如果某個必填欄位怎麼樣都解析不出來，程式不會憑感覺猜一個值填進去，而是先不寫進表裡，貼上待處理的標記，發個通知等人來看。收到的如果是取消或改期通知，也不會自動改動表格內容，只會提醒人自己去確認調整。

有一家平台的訂單信格式特別常變動，還要另外計算保費這種浮動邏輯，衡量下來自己維護的成本划不來，那家就留在原本的舊工具上繼續處理，沒有勉強全部收進來。

來源二：官網表單

表單這邊選擇每十分鐘主動去問一次「有沒有新回覆」，而不是架設一個服務、讓表單那端主動通知我們。理由很實際：要接收主動通知，本地端得開一個對外的窗口，多一個環節就多一個可能出狀況的地方。詢問表單晚個幾分鐘才進系統，完全不影響使用，換一個更簡單的方式沒有任何損失。

用來判斷「這筆有沒有處理過」的依據，是每筆回覆自帶的編號，最近處理過的幾百筆會留底，重複執行也不會重複寫入。第一次啟用的時候，也刻意只抓最近一天內的回覆，不會把過去累積的舊資料整批灌進來。

來源三：人工輸入

有些詢問就是會由同事直接手動輸入，這是永遠都會存在的一條路。所以在設計欄位的時候，自動寫入的跟人工填的必須共用同一張表、同一組欄位定義，不能自動的走一套格式，人工的走另一套，不然後續要彙整資料會很痛苦。

兩件比較技術的事

第一，量體不大的東西可以直接換成新程式；牽涉金流開團這種核心營運的部分，新舊兩邊要並行跑上一段時間，把結果一筆一筆對過，確認沒有落差才敢把舊的關掉。錢的事，寧可慢一點確認。

第二，對方改版的時候要怎麼知道？解析失敗這件事必須被當成一個需要處理的事件主動通知，而不是安靜地略過不管——安靜略過看起來像是沒事，其實是把問題埋起來，等到發現的時候可能已經漏了好幾筆。

如果你也是旅行社

靠解析信件格式做出來的自動化，能撐多久要看對方多常改版。動手之前先問一句：這個平台有沒有正式的資料介接方式？有的話事情會單純很多；沒有的話，記得把「對方一旦改版怎麼發現」這件事想在前面，而不是等到漏單才發現。