打卡和薪資有關聯，但兩者不一定要在同一天切換。對行政兼辦人資的小公司來說，先找出每月最常重做、最容易缺資料的那一段，會比一次要求所有人改變習慣更容易安排。
導入順序可以分階段，資料怎麼交接卻要一開始就確認。 否則打卡換了工具，月底仍可能由行政把資料逐筆抄回原來的薪資表。
情境一：月底一直追補卡與請假，先整理出勤
如果目前的薪資規則已經清楚，主要時間都花在找員工補資料，第一階段就先解決紀錄收集與主管確認。
挑一個部門或一小批員工，測試日常打卡、一次補卡與一次請假流程。除了員工會不會操作，也要確認主管知道去哪裡處理，行政找得到結果。
這階段的驗收條件可以寫成：
- 參與測試的員工能在實際工作情境完成打卡。
- 補卡與請假有明確的申請內容及處理結果。
- 行政能整理同一期間的紀錄，辨認尚未確認的項目。
- 出勤資料能交給目前的薪資流程，欄位與格式已實際核對。
先用月底出勤核對清單定義交付內容，再看工具是否支援，會比較容易知道試用該測什麼。
情境二：出勤資料齊全，卻每月重算薪資，先驗證計薪流程
如果打卡來源穩定，主要困難在於津貼、調整項目與不同計薪方式散在多份表格，評估重點就放在薪資設定與明細核對。
先整理一個已結束月份，挑選能代表公司情況的員工，例如月薪、時薪或有一次性調整的人，逐項確認新工具如何處理。
這裡的「先驗證薪資」，是把試用重點放在計薪流程，不代表任何產品都能單獨購買薪資模組，或直接讀取所有舊打卡格式。必須先確認出勤來源、匯入方式與產品依賴，才能估算完整費用和準備時間。
以 CacaLabs 為例，薪資計算屬於 HRLab Pro，出勤與基本帳號的開通需求也需一起評估；請看薪資流程與使用界線及完整價格頁。
情境三：兩邊都混亂，先統一人員資料與責任
如果同一位員工在打卡檔、薪資表與主管名單中的名稱或編號都不同，一次導入兩個模組也不會自動知道誰是誰。
先指定一份員工名冊作為來源，核對員工編號、計薪方式與生效日期；再決定誰維護出勤、誰處理申請、誰覆核薪資。從一小批資料跑通後，再擴大到全公司。
若資料整理的窗口尚未決定，第一階段的成果應該是「名冊與作業分工可以交付」，而不是急著宣布全員上線。
哪些情況適合一起導入？
當員工名冊與薪資設定已整理、代表性資料能順利驗證、員工與主管有時間熟悉操作，而且承辦人能安排並行核對，就可以把出勤到薪資視為同一次導入範圍。
即使一起導入，也要按順序確認：日常紀錄能收齊、申請能處理、薪資結果能核對。總金額對得上，但有人漏算、某項津貼被其他差異抵消，仍不算通過。
不論怎麼分階段，都先問清楚這張表
| 評估問題 | 希望拿到的具體答案 |
|---|---|
| 員工資料要維護幾次？ | 哪份是來源、異動如何帶到其他流程 |
| 出勤如何交給薪資？ | 支援格式、必要欄位、例外處理方式 |
| 有待確認的資料時怎麼辦？ | 誰會看到、誰處理、計算結果如何核對 |
| 哪些功能需要額外購買？ | 完整產品組合與適用限制 |
| 什麼時候可以切換？ | 試用範圍、驗收人與未解事項清單 |
| 舊資料怎麼保留？ | 歸檔位置、可讀格式與負責人 |
最後把第一階段的目標寫成一句可驗證的話，例如「行政能拿到同一期間、已標明未解事項的出勤資料」，或「承辦人能解釋代表性員工每個薪資項目的來源」。完成後，再決定下一階段。
若想先了解 CacaLabs 的操作，可以看唯讀 Demo：出勤重點看紀錄與管理流程；薪資重點看歷史批次與明細。Demo 不能送出操作或重新計薪，使用自己的資料驗證須建立公司試用，並依導入清單核對結果。