保固登錄與到期管理

🎯 這條流程解決什麼

名錶的保固期動輒兩到三年，機械錶的原廠保固甚至拉到五年、八年，但客人手上那張紙本保固卡，往往撐不過半年就被塞進抽屜深處、夾進說明書裡，搬一次家就不見了。對鐘錶行來說，真正的痛點不在卡片本身，而在「售出那一刻的資料有沒有被好好記下來」。

實際情況是這樣的：門市同時賣新錶、收維修、處理調整，店員一忙起來，售出資料常常只寫在出貨單上，序號、購買日、保固年限散落在不同本子或不同人的記憶裡。等到客人三年後回店主張保固，店員得翻紙本單據、對序號、查當初是誰經手，一筆一筆找下去，常常要花上十五到三十分鐘，客人在櫃檯前等得不耐煩，找不到紀錄又容易演變成「你們是不是不認帳」的爭執。

更隱形的損失是「到期沒人提醒」。保固快結束前，正是邀客人回店做檢測、清洗、續保的最好時機，但沒有系統盯著到期日，這些回店與回購機會就一年年靜悄悄地流掉。一間月銷三十支錶的中型門市，光是漏掉的回店檢測與續保接觸點，累積一年下來就是可觀的售後營收缺口。

純人工管理保固的成本，不只是查單據的那幾十分鐘，而是「資料不完整導致無法主張、無法提醒、無法經營」的長期機會成本。

導入後的改變

導入前：保固靠紙本卡與出貨單，客人弄丟就無從查起；店員查驗保固平均花十五到三十分鐘，遇到老案子甚至放棄追查直接送原廠；到期日沒人管理，續保與回店檢測全憑客人自己記得；售後爭議時店家拿不出購買日證據，常被迫吞下不該保固的維修成本。

導入後：每一筆售出與維修完工都即時登錄，電子保固卡自動發到客人手機，弄丟也不怕；店員依序號查驗保固狀態從三十分鐘壓縮到三十秒，當場就能告訴客人「保到哪一天、保哪些項目」；系統在到期前自動提醒，把過去流失的回店與續保機會重新接回來。

以一間月售三十支、同時承接維修的門市估算，查驗保固的人工時間可省下約八成，售後爭議因為有完整購買日與序號紀錄而大幅減少；到期前的主動提醒，保守估計能把回店檢測與續保的接觸率提升三到五成，這些都是過去白白流失、現在重新抓回來的售後營收。更多同類售後自動化設計，可參考 /recipes 與 /automation 的應用案例。

流程怎麼運作

這條流程對應 frontmatter 裡的五個節點，從售出到到期完整串起售後生命週期：

1. 保固登錄（🆕）：新錶售出或維修完工時，店員在 Google Sheets 或表單填入錶款型號、機芯序號、購買日與保固年限。維修案件則額外記錄維修項目與維修保固期。這一步是整條流程的地基，序號與購買日務必填正確。

2. 電子保固（🪪）：系統自動把登錄資料整理成一張電子保固卡，內含錶款、序號後四碼、保固起訖日與店家聯絡方式，透過 LINE 官方帳號推送給客人保存。客人之後在 LINE 對話裡就能隨時調出，不再依賴紙卡。

3. 快速查驗（🔎）：客人回店時，店員輸入序號或客人姓名，系統立刻回傳保固狀態（保固中／已過期）、剩餘天數與保固涵蓋範圍，當場就能判斷這次維修是否在保。

4. 到期提醒（⏰）：排程節點每天比對所有案件的保固到期日，在到期前三十天、七天自動透過 LINE 提醒客人回店檢測或洽詢續保，把回店機會主動推到客人眼前。

5. 紀錄歸檔（🗃️）：所有保固與維修歷程集中歸檔到 Notion 或 Google Sheets，形成每支錶、每位客人的完整售後履歷，日後查驗、爭議判定、會員經營都有據可查。

需要的工具與串接重點

平台設定：以 n8n 或 Make 當作中樞。Google Sheets 作為主資料庫，建議欄位包含序號、錶款、客人姓名、LINE ID、購買日、保固年限、保固到期日（用公式自動算）、案件類型（售出／維修）。LINE 官方帳號負責發送電子保固卡與到期提醒，需先在 LINE Developers 開好 Messaging API 並把 Channel Token 接進平台。Notion 適合做結構化的售後履歷與爭議紀錄查詢介面。AI 分類 API 用來把維修文字描述自動歸類（如電池更換、機芯保養、外觀維修），方便後續統計與保固範圍判斷。

串接注意點：一是序號的唯一性，務必把序號設為主鍵，避免重複登錄造成查驗錯亂；二是 LINE 推播要綁定正確的客人 LINE ID，建議在售出時就請客人加官方帳號並完成綁定；三是到期日計算要考慮維修保固與整錶保固期不同，分欄管理才不會混淆。

常見錯誤與注意事項

• 保固範圍與人為損壞認定屬專業判斷，需人工確認：系統只負責查出「這支錶保到何時、登錄了哪些項目」，但實際維修是否屬保固範圍、是否為進水或撞擊等人為損壞，必須由技師檢視後判定，AI 不取代專業判斷，切勿讓自動回覆直接告訴客人「這個有保固，免費」。
• 理賠與原廠送修以原廠條款為準：高價錶款、原廠送修案件，保固判定須以原廠保固條款與書面合約為準，門市的電子保固卡僅供查詢參考，不能凌駕原廠規範。
• 個資保護：客人序號、購買紀錄、LINE ID 屬個人資料，存放與推播都要符合個資法，僅蒐集售後服務必要欄位，並避免在群組或公開頻道外洩。
• 登錄當下就要正確：最常見的錯誤是售出時序號或購買日填錯，導致日後查驗對不上，建議登錄後請客人核對電子保固卡內容。

台灣中小企業情境案例

台中一間經營二十多年的鐘錶行，主力是中高價機械錶與維修服務，月均售出約三十支、維修進出約六十件。導入前，老闆娘最頭痛的就是客人拿著舊錶回來說「這之前在你們家買的」，但翻遍出貨本找不到紀錄，認也不是、不認也不是。

導入這條流程後，每一支售出與每一件維修完工都即時登錄並發出電子保固卡。半年後回店的客人，店員輸入序號三秒就查到完整紀錄，爭議當場化解。更意外的收穫是到期提醒——系統在保固前一個月推播提醒回店保養，原本一年回店一次都不到的老客人，開始主動回來做檢測與清洗，續保與保養營收明顯回升。老闆娘說，最有感的是「再也不用為了找一筆舊紀錄翻半小時的本子」。

延伸應用

這條流程可以再往兩個方向擴充。第一是串接會員經營：把保固到期提醒延伸成完整的客戶回訪節奏，搭配生日問候、新品上市通知，讓售後成為持續經營客戶的入口。第二是串接維修進度通知，當客人送修時自動回報「已收件、維修中、可取件」，與保固查驗共用同一套案件資料。

進一步還能把售出資料接到庫存與銷售分析，看出哪些錶款保固期內回修率偏高，回饋給採購決策。想把這套自動化擴展到門市其他環節，可以參考 /workflows 的其他流程設計、/recipes 的內容自動化配方，以及 /automation 的整體串接思路。

流程圖

用到的工具

更多「零售商店」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →