一個地區四十六份報價，四十份已經過期

有一次系統跑出來的追約清單裡，標紅了一個地區：四十六份報價，四十份已經過期。那陣子正好有同事在接洽那一帶的行程，如果不是前一天清單剛好把這個地區標成最高優先、提醒業務趕快去跟供應商要新報價，等到真的有客人要報價那一刻才發現能用的報價所剩無幾，場面會很難看——業務手上明明有一整個地區的資料夾，點開來卻幾乎每一份都寫著「已過期」。

這就是接下來要講的東西存在的理由：資料光是進了系統還不夠，沒有人會天天回頭去翻一遍，所以系統自己要知道什麼時候該喊一聲。

前兩天講報價單怎麼被讀成資料、怎麼存。今天講最後一段：同事實際上怎麼用，以及系統怎麼主動告訴你該打電話了。

一個網址、一組通行碼，記一年

現在的樣子是這樣：打開一個網址，輸入一次通行碼，這台裝置記一年，之後直接開就能查。手機、電腦都能用，不需要任何帳號。目前收錄九個地區、一百二十四間飯店、一百四十一份報價單，拆成五千五百四十三筆單一價格。

這一百四十一份是歸檔總數 2,270 份裡篩下來真正有效、而且還在生效期限內的版本。數字之所以差這麼多，不是系統只處理了一小部分，是昨天講的那兩道關卡在起作用：同一份報價被重寄、換信箱寄、存進不同資料夾，靠內容雜湊認出來是同一份，不會重複入庫；過期的舊報價、格式壞掉讀不出來的、根本不是報價單的檔案，也都被篩掉記進排除清單。篩完剩下的，才是業務真正會用到、也值得你花力氣去維護的那一百四十一份。

查詢頁最有用的功能是「按日期查」

一開始我只做了關鍵字搜尋跟地區篩選，用了一陣子才發現同事真正需要的是另一件事：選一個入住日期，只顯示那天效期內的價格。

因為報價單是有期間的，同一家飯店手上可能有三份不同期間的報價。業務要報的是某一個具體日期，他不需要看到全部，只需要看到那天適用的那一份。加了日期查價之後，這個系統才真的被用起來。

平假日的定義，是這套系統最誠實的地方

每家飯店對「平日」「假日」的定義都不一樣。有的把週五算假日，有的不算；連假、寒暑假、特殊節日常常被視同假日，而且各家的規則寫法五花八門。

系統會依照星期推定一個結果，但推定出來的價格會用黃底標示，並且要求展開那家飯店的平假日定義確認。我沒有讓它假裝自己算得準——因為這件事本來就算不準，而報錯一天的房價，代價是實實在在的。

黃底這個設計其實就是前面講過的「AI 產出一律標待核對」的延伸：系統可以幫你縮小範圍，但不該假裝它是最終答案。

讓「該打電話了」自己跑出來

資料入庫只是第一步。報價單會過期，過期了沒人知道，直到業務報價報到一半才發現價格早就失效——開頭那個地區就是這種事發生過的例子。

所以系統每天掃一次效期，產出三張清單：四十五天內就要到期的（依剩餘天數排序，並標明資料庫裡有沒有新版可以接續）、已經過期而且沒有新版的（最該立刻處理）、還有效期根本沒標示的（原始報價單就沒寫迄日，只能等下次收到新版時順便問清楚）。

追約的優先順序分四級：第一優先是整個地區完全沒有任何有效報價，業務手上沒東西可報，接到單就開天窗；第二優先是某個地區大面積過期，就是開頭那種四十六份裡四十份全過期的情況；第三優先是四十五天內即將到期的一般案件；第四優先是掃描影像辨識不出來、要跟對方重新索取數位版的，這類也累積了二十三份。

輸出的東西不是一份資料檔，是一份寫清楚「打電話的順序」跟「該講什麼」的表，每一筆都附上原始報價單的連結——同事拿到手上不用再花時間查背景。

同一套邏輯可以套到別的地方

這套「效期到期、分級排序、產出清單」的做法，後來直接套用到車行合約、導遊合約、保險、還有公司證照的到期管理上。架構完全一樣，換一個資料來源就能用。

如果你也是旅行社

三天講完這套東西，我覺得最大的價值其實不是 AI 辨識，是它逼著整間公司把報價單的檔名跟格式標準化了。而追約這一半是整個系列裡最容易照抄、投資報酬率也最高的一個——不需要用到 AI，只要一張「供應商加效期」的表，加上一支每天固定跑一次的腳本就夠了。