從試算表到飯店物業管理系統：匯入前如何清理資料

為何匯入作業還沒開始就已注定失敗

資料匯入之所以吸引人，是因為聽起來只要一個步驟：匯出試算表、上傳至 PMS，然後就完成了。但在實務上，匯入首先面臨的是格式與資料完整性問題，其次才是技術問題。

一套 飯店物業管理系統 要求資料採用明確定義的結構：住客紀錄需要名字、姓氏，以及至少一項聯絡資料；房型需要一致的名稱、明確的客房數量及最多入住人數；訂房紀錄則需要對應的住客、日期、房型、房價及來源通路。經過三、四年逐步累積而成的試算表資料，通常無法在未經整理的情況下符合這些要求。

資料清理絕非可有可無；它決定了資料能否順利匯入，還是匯入後必須耗費數小時人工修正。

開始之前：將現有資料對應至 PMS 的需求

在修改試算表之前，請先取得 PMS 的匯入範本或欄位規格。多數系統都會提供 CSV 範例或匯入指南，列出住客、客房、房價及訂房資料的必填與選填欄位。該文件就是目標格式；清理試算表的目的，是重整現有資料，使其符合這套格式。

逐一檢查試算表中的各類資料：

• 共有多少筆不重複的住客紀錄？其中大多數紀錄填寫了哪些欄位？
• 目前使用了多少種客房名稱？這些名稱代表房型還是個別客房？
• 房價方案是否有完整記錄，還是房價欄中只有一個數字？
• 列出了多少筆未來訂房？資料是否完整？

這項檢查有助於判斷哪些部分需要投入最多清理工作，以及哪些類別採用人工重新輸入，可能比清理後匯入更有效率。

清理住客名單

住客名單通常是最雜亂的資料類別。經過數年累積，一般小型飯店的試算表中，往往會出現同一位住客因不同訂房通路而使用不同電子郵件地址建立的多筆紀錄、不同的姓名寫法（例如 J. Smith、John Smith 與 Smith, John），以及只有一次訂房且沒有可用聯絡資料的紀錄。

先移除重複資料。 在 Excel 或 Google 試算表中，依電子郵件地址或電話號碼排序，找出同一位住客重複出現的資料列。保留資料最完整的一筆紀錄，並刪除其餘紀錄。如果某位住客曾入住五次，卻分成五筆獨立資料列，請將這些紀錄合併。

統一姓名格式。 多數 PMS 會將名字與姓氏分別儲存在不同欄位。若試算表欄位中包含「Smith, John」或「John Smith (Booking.com)」等內容，就需要在匯入前拆分。請使用試算表的資料剖析或公式工具，將資料清楚地分隔至不同欄位。

標記資料不完整的紀錄。 若住客資料列中既沒有電子郵件地址，也沒有電話號碼，系統就無法向其傳送自動訊息。請決定要照原樣匯入這些紀錄（系統中會有姓名，但沒有任何聯絡管道），或直接略過。無論資料品質如何都匯入每一位歷史住客，通常不值得為後續清理投入額外成本。

篩選近期住客與回訪住客。 上次入住已超過兩年且未再回訪的住客，不太可能在新系統中創造價值。匯入這些紀錄只會增加資料量，卻沒有實際用途。實用的篩選條件是：只匯入至少曾入住兩次，或在過去 12 個月內曾入住的住客。

統一客房名稱與房型

PMS 會依房型管理房態庫存；房型是將功能、房價及容納人數相同的實體客房歸為一類。試算表通常記錄個別客房，而且命名往往不一致。例如「Room 101」、「Deluxe King 2nd Floor」、「Ocean View—king」及「OK king」，可能都是不同員工在不同時間填寫、但實際指向同一房型的名稱。

匯入前，請先定義 PMS 將使用的房型。以一家擁有 12 間客房的住宿業者為例，可能會分成三或四種房型：標準大床房、標準特大床房、豪華特大床房及無障礙大床房。每間實體客房都必須對應至其中唯一一種房型。

定義房型後，請檢查試算表中指向同一房型的各種客房名稱，並將其統一。匯入資料所使用的名稱必須與 PMS 中設定的名稱完全相符；以「Deluxe King」匯入的訂房，無法連結至名稱為「King Deluxe」的房型。

此外，也要釐清客房名稱與房號的差異。部分 PMS 使用房號進行內部分房，並以房型名稱顯示於訂房頁面。試算表可能混用了這兩項資料，因此需要在匯入前加以拆分。

準備房價方案

房價方案用於定義房型的價格架構，包括每晚房價、適用條件（日期、住宿天數及住客人數），以及適用時所連結的 OTA 通路。

大多數 小型飯店的試算表 並未以結構化資料記錄房價方案，而只是在房價欄中填入一個數字，沒有註明該價格適用於平日、週末、旺季，還是全部時段。匯入前，請先決定 PMS 將使用哪些房價方案，以及試算表中的各項房價應對應至哪一個方案。

只匯入目前仍有效的房價方案。已不再適用的過往季節性房價無須移轉。首要任務是確保適用於未來訂房的房價正確匯入系統。

如果住宿業者依通路採用不同房價，例如 Booking.com 使用淨價、電話訂房使用直客價，請在匯入前確認 PMS 如何處理這類設定。部分系統要求各通路分別使用獨立的房價方案；另一些系統則採用基準房價，再套用佣金規則。若將通路專屬房價匯入基準房價欄位，即使系統未顯示錯誤，也會產生不正確的金額。

移轉未來訂房

未來訂房是匯入後影響最重大的資料。若下個月將入住的住客未出現在新 PMS 中，住宿業者往往要到辦理入住時才會發現問題，而不是在移轉期間。

從目前的試算表匯出所有未來訂房，涵蓋從今天起至少未來 90 天內的全部資料。每筆訂房至少須包含以下欄位：住客姓名、入住日期、退房日期、房型、每晚房價、總金額、來源通路及付款狀態（已收訂金、尚有餘額或已全額付清）。

匯入後，逐列對照原始試算表，核對每一筆未來訂房。確認日期是否正確移轉（日期格式不符是最常見的匯入錯誤）、房型是否正確對應，以及付款狀態是否準確。任何顯示為全額付清但實際仍有餘額未付的訂房，或相反的情況，都必須在住客抵達前修正。

針對 OTA 訂房，請將匯入的紀錄與 OTA 平台上的確認資料交叉核對。PMS 紀錄與 OTA 紀錄應顯示相同的日期、房型及住客姓名。

哪些資料不必移轉

進行系統移轉時，人們往往直覺地想把所有資料全部搬過去。這會造成匯入資料過度膨脹，不僅需要更長的清理時間，也會為仍在熟悉新系統的團隊增添無謂干擾。

不必移轉：

• 已取消的訂房（屬於歷史紀錄，而非有效資料）
• 兩年多前僅入住過一次且沒有聯絡資料的住客
• 已結束季節的歷史房價方案
• 通路連線啟用後，平台會自動推送至 PMS 的 OTA 訂房

優先移轉：

• 所有未來訂房
• 回訪住客，以及過去 12 個月內曾入住的住客
• 適用於已確認訂房或近期訂房的房價方案

常見問題

從試算表移轉至飯店物業管理系統時，應匯入哪些資料？

需要匯入的四類資料是住客名單、房型與客房名稱、目前有效的房價方案，以及未來訂房。其中，未來訂房最為迫切；任何即將到來的訂房若未能正確移轉，都會在住客辦理入住時造成問題。住客歷史及過往訂房可選擇性匯入，或日後逐步重新輸入；在系統正式上線的第一天之前，無須確保這些歷史資料全部完備。

將飯店住客名單匯入 PMS 前，該如何清理資料？

依電子郵件地址或電話號碼排序，找出重複紀錄，並保留每位住客資料最完整的版本。統一姓名格式，將名字與姓氏分別置於不同欄位。標記或移除沒有聯絡資料的紀錄。篩選名單，只保留曾入住超過一次，或在過去 12 個月內曾入住的住客；匯入歷來輸入的每一筆紀錄只會增加資料量，卻無助於實際使用。

為什麼客房名稱會在飯店 PMS 匯入時造成問題？

PMS 是依房型而非個別客房名稱來管理客房。若試算表中的命名不一致，例如同一房型分別記錄為「King」、「King Room」、「Deluxe King」和「Room 101 King」，匯入時就會產生無法對應任何已設定房型的紀錄。解決方法是在匯入前先定義酒店的房型，並統一試算表中的所有客房名稱，使其與系統設定完全一致。

改用 PMS 時，應匯入未來多長期間的預訂？

匯入從今天起至未來至少 90 天內的所有預訂。匯入後，逐筆對照原始試算表核對紀錄，以找出日期格式錯誤、房型不符及付款狀態差異。OTA 預訂也應與 OTA 平台本身的確認紀錄交叉核對；在啟用渠道串接前，PMS 紀錄與 OTA 確認紀錄中的日期、房型及住客姓名必須完全一致。

從試算表遷移至酒店 PMS 時，哪些資料不應匯入？

不必匯入已取消的預訂、兩年多前僅入住過一次且沒有聯絡資料的住客、已結束營運季的歷史房價方案，以及在渠道串接啟用後會由 OTA 平台自動推送至 PMS 的 OTA 預訂。匯入沒有營運用途的紀錄，只會為原本就需要仔細核查的遷移工作增加資料清理負擔。