完整規劃

2026-09-10 · TS Dent 獨立子專案 · 規劃草案 v0.1

B 提供工具給 A，平台協助 A 的用車需求，將可歸屬到 A 的後續收益依約回饋 B。

本文件包含六格 Rich Menu、38 種延伸情境、11 種引流通路、案件授權、B 的回饋與結算、系統架構及開發驗收。

目前只有本機規劃、設定草稿及回饋計算範例，尚未上線 LINE Bot、蒐集案件或發放回饋。

1. 產品定位與商業模式
2. 六大 Rich Menu
3. 38 種延伸情境與引流
4. 事故協助流程
5. B 的收益回饋與結算
6. 資料與系統架構
7. 開發與營運計畫
8. 需求與決策
9. 官方來源

產品企劃 v0.1

1. 要解決的問題

車禍發生後，車主往往先聯絡信任的人，但不知道接下來如何報案、保留資料、安排拖吊、確認保險及維修。保險業務、租車業者與車隊管理者則必須重複指導、追照片與追進度，案件資訊分散在通話和聊天中。

本產品將這段協助流程放進 LINE：B 給 A 一個可立即使用的用車助手，平台將必要步驟整理成案件，再讓 A 決定是否交由哪一家業者服務。平台可向 B 銷售工具，並向接收有效服務需求的 C 收取約定的媒合費。

依使用者最終更正，B 提供給 A 的關係必須記錄，A 後續帶來的可核實收益依約回饋原 B。三方誘因為：A 得到有用服務，B 得到持續推廣回饋，C 得到經授權且需求明確的案件。

產品價值是有服務內容、來源可辨識、處理可追蹤的案件。個資分享採逐次授權；事故處理本身不等於同意收到所有合作商家的廣告。

2. 使用者與付費者

B 與 C 可以是同一家，但來源角色、服務承接角色與結算帳目分開。租車公司、B 個別業務及 C 廠商各自有帳號與組織範圍，不因同為「夥伴」就能看全部案件。

3. 補完整的 A／B 故事

1. B 在保單服務、交車、租車交付或平日關懷時，先給 A 專屬 QR Code；事故當下也能直接轉傳。
2. A 由入口看到「由 B 提供的車主協助」，可先讀緊急指引，再登入或建立案件。
3. A 點「我撞車了」或「我被撞了」。兩個入口都先詢問安全狀況，不預判誰有責任。
4. 先分流是否有人受傷／不確定、是否仍有危險、是否在國道。通話入口一直可用，不需填完問卷。
5. A 到達安全處後，自由選擇保存案件。照片、位置和完成狀態逐項記錄，可稍後補。
6. A 選擇要不要讓原 B 協助案件。若同意，B 看見授權摘要及待辦；未同意時只有來源歸屬，不開放個案內容。
7. A 依需要選擇拖吊、車損修復、保險聯絡等服務。先顯示提供者、服務範圍、費用說明及是否為合作商家。
8. A 確認收件業者、要分享的資料與用途後，平台才建立轉介。更換或增加業者需再確認。
9. C 接案、聯絡、估價、預約及完工都回到同一案件時間軸；無人接案時呈現失敗與替代聯絡方式。
10. 案件完成後追蹤滿意度。平台確認收入後，依約將收益回饋給 B。美容、保養與換車另建需求，後續交易沿用 A 的身分各別計帳；廣告提醒另有可撤回的選擇。

Rich Menu 同時提供淹水、刮傷、故障與停車助手；停車是日常使用入口，事故與車損提供較深的服務協助。服務整合至同一 A 帳號，收益另歸入原 B 的回饋帳本，細節見 六大入口 與 回饋規格。

4. 租車與公司車的分支

建立案件時辨識「自有／租用／公司車／其他或不確定」。租車案件顯示原出租業者的事故窗口、合約規定與核准進度；公司車顯示車隊管理窗口。

拖吊目的地、拆修、修復方式及代步安排需確認有權決定的人。合約或保險要求由對應單位核實，不能假設駕駛就是車主，也不能以通知公司為由延誤緊急求援。未取得車主或車隊授權前，不產生「已同意施工」。

5. 服務閉環

凹痕修復、鈑烤與換件的適用性由專業業者依實車確認。比較項目含漆面、結構、工法、工期、保固與總價；不以「最便宜」直接判斷最佳方案。

6. 商業模式提案

目前採「工具訂閱＋案件媒合」作為可調整的規劃假設，尚未定價或簽約。

為鼓勵 B 推廣，建議「基礎推廣夥伴」先提供免費邀請入口及收益查詢；需要門店管理、品牌客製與進階協作的 B 才購買工具方案。平台收入優先驗證 C 的案件／成交服務費，避免把購買訂閱當成 B 可以推薦 A 的前提。免費範圍與升級價格仍待定案。

保險案件先處理「既有保單服務聯絡」。新保單招攬、推薦特定商品、依保費抽成或業務員分潤不直接套用一般商機收費；應由合作保險機構確認資格、契約與可行做法。保險業招攬及核保理賠辦法

有效案件不等於保證成交。需在合作條款定義可聯絡、區域、需求、重複件、取消件、無效件回報期間與爭議處理。第一版每次只將可識別資料交給 A 指定的業者，不向多家出售同一份原始事故檔案。

給 B 的主要誘因是節省協助時間、維持客戶關係，並從 A 後續可核實的用車服務取得依約回饋。B 後台同時呈現推薦成效與結算明細；比例與收款對象需揭露規則並確認各業別約束。

7. 第一批試點建議

先在一個可支援的地區，找少量租車／車隊夥伴及保險服務夥伴，配置有聯絡窗口的拖吊、凹痕修復與鈑烤廠。數量、地區、客服時段由實際合作能力決定；不先承諾全台或 24 小時人工服務。

同時測試「交車時預先加入」與「事故後由 B 分享」兩種來源。車禍是低頻事件，若只等事故發生才加好友，平日推廣及 B 的服務價值不易驗證。

8. 成效與損益

• 引流：各 B 入口開啟、完成身分綁定、建立案件，分母及去重方式分別標示。
• 協助：安全後建案完成率、資料補齊率、B 人工處理時間、無人接手比例。
• 媒合：主動服務需求 → 授權 → C 接受 → 成功聯絡 → 報價 → 成交／完工，每一步各自計算。
• 信任：拒絕轉介、撤回、抱怨、報價變動與重複聯絡。授權率不以誤導或綁定行銷提高。
• 財務：月收入 = 訂閱收入 + 有效媒合收入 + 已約定的成交服務收入；毛利再扣 B 的回饋、LINE 訊息、儲存、客服、退款與服務成本。

LINE 好友數、案件數與成交數不互相代替。營運人力及爭議成本列入單件成本，尚無資料前不填轉換率、營收保證或預估 ROI。

六大 Rich Menu 與延伸入口

1. 主選單維持六格

第一版建議採 2500 × 1686 的大圖，三欄兩列；字體易讀、文字與圖示並用，不只靠顏色辨識。六格均送出明確的 postback 事件，由伺服器回覆對應第一步；停車再回覆 LIFF 開啟卡。設定草稿位於 config/rich-menu.json，尚未上傳任何帳號。

每次回覆附「我的用車」入口，放案件、車輛、原 B、資料授權及更多服務；亦可輸入「進度」「保養」「更多」。B 另有登入後的夥伴後台，查看推薦、收益及領取。需求增加後再做第二頁 Rich Menu「日常用車」，主頁六格仍然保留。LINE 支援 Rich Menu 切換及自訂點擊區域。官方 API 規格

2. 六個入口的完整服務

「我被撞了」增加對方離場／不明的證據整理，但不作逃逸或肇責的法律認定。「車刮傷了」若其實是碰撞事故或有人受傷，回到共用事故分流。

3. 車被淹了：對話規格

第一句：「先確認人已在安全處。有人受困或有立即危險，請撥 119；不要為了取車進入淹水區或地下空間。」仍處危險時不要求填資料、拍照或付費。

安全後提示疑似泡水車不要貿然啟動，交由專業拖救與檢查。車型包含電動／油電／燃油／不確定；電動車不提供拆接高壓系統的操作指引。地方政府防災資料、消防署車輛救援資料

步驟：人身安全 → 聯絡車主／租車公司 → 選擇保存泡水案件 → 安全後補照片與時間 → 拖救目的地確認 → 維修檢查估價 → 既有保單確認 → 修復／代步／換車評估。承保與否不從「有車體險」直接推定。

照片或水位自述僅供初步溝通，不據此產生安全認證、可發動結論或「整理後可當正常車出售」建議。轉中古車需求時應保留與揭露車況資料的處理流程，由業者確認應履行事項。

4. 車刮傷了：對話規格

先問「剛發生碰撞／停車後發現／一般外觀整理」。涉及他人、道路事故或危險時導向相應安全及報案流程。外觀服務則在安全處取得車型、部位、照片及期望地區。

結果卡分為待業者確認的「表面清潔與拋光」「局部補漆／鈑烤」「凹痕修復」「更換或其他檢修」。照片不夠時回覆需補資料或到店查看；不保證無痕、不自動報固定價格。

估價比較欄：處理範圍、工法、是否動原漆、拆裝／零件、工期、保固、含稅總價及可能追加條件。A 選定才提供聯絡方式，轉介與回饋狀態分別呈現。

5. 車故障了：對話規格

症狀按鈕：無法發動、電瓶疑慮、輪胎異常、儀表警示、異音／異味、溫度異常、燃油／電量不足、鑰匙／上鎖、其他／不知道。

這些是症狀分類，不是確診。煞車、轉向、冒煙、起火或無法判斷安全時優先停止自行處理並求援；不因一張儀表照片告知可繼續開、不引導非專業者在國道換胎或拆電系統。

服務單記錄道路類型、方向／里程、車種、症狀、是否需要乘員接駁。國道由官方拖救入口銜接，不能把普通道路的到府換電瓶服務直接派入國道。高速公路緊急處理

6. 停車助手：日常留存入口

TDX 及地方政府提供部分停車基本及動態資料；城市、場站與欄位覆蓋需實際驗證。定位拒絕時仍可手動輸入。台北資料含無該車種等特殊數值，需轉成未知或不適用，不能直接展示成負的空位。TDX 資料入口、台北停車資料

第一版不含自動扣停車費、車牌辨識付款、保證車位或停車場控制設備。這些需另談資料與金流合作。

7. 共同的服務結束畫面

A 端顯示「本次結果」「接下來的待辦」「目前服務夥伴」及推薦關係揭露。B 的回饋於夥伴後台查詢；任何估計額都標示試算，尚未核實平台收入不能呈現已入帳。車主可以持續使用免費指引，而不選擇商家轉介。

更多情境及通路見 用車情境與引流企劃。

更多用車情境與引流方式

1. 方向：用日常需求留住 A，再承接需要專業服務的時刻

只靠事故，A 可能很久才用一次。可以用停車、保養、車輛紀錄及交還車等日常需求，讓 A 平常就把這個 LINE 留著；突發情況再延伸到人工與商家服務。

以下是產品與通路假設，尚未以市場數據驗證。標示的優先序依「是否能先提供實用結果、是否接得上既有汽車服務、能否核實成交」推估，不代表已知轉換率。電瓶、輪胎、鑰匙等是「車故障了」的細分入口，可用內容與連結直達，不必各占一格 Rich Menu。

2. 日常維護：最適合持續使用

3. 突發不便：把求援需求描述清楚

4. 租車、出遊、交車：最貼近原始客群

5. 大額決策：建立信任後再承接

6. 我會優先驗證的八個延伸入口

不因為列了很多情境就一次開發。第一個試點保留六格主入口，延伸先做取還車、洗車美容、保養與維修代步；其餘先作內容入口＋人工承接，得到真實需求後再自動化。

7. 具體引流通路

所有對外訊息與合作接洽目前都只是規劃；此次沒有發送或發布。

B 的推廣工具包建議包含：可直接轉傳的品牌邀請卡、各情境直達連結、門店 QR Code、來源綁定結果、推薦車主數、每筆可核對的回饋及月結單。B 不必自己處理每一個用車問題，也能讓 A 持續得到服務。

推廣給 B 的重點是「推薦一次，A 後續在平台的適用服務都有機會持續帶來回饋」；實際依契約與收入核實。推廣給 A 的重點則是安全協助、便利及服務品質，並揭露推薦合作關係。

8. 可先做的內容題目

• 「租車取車時，把這些車況先記下來。」→ 取車檢查助手。
• 「還車前，我還有什麼沒做？」→ 還車清單。
• 「車在地下停車場發不動，先把位置說清楚。」→ 故障需求單。
• 「擋風玻璃被石頭打到，需要找誰檢查？」→ 玻璃服務。
• 「維修三天沒車用，先找可用的代步方案。」→ 租車需求。
• 「上次換電瓶是什麼時候？」→ 車輛紀錄。
• 「保養單都丟了，下一次怎麼接續？」→ 保養紀錄。
• 「買中古車前，把檢查留給獨立專業。」→ 檢查需求。
• 「我停在幾樓、哪個格？」→ 停車筆記。
• 給 B：「你推薦的車主，後續哪些服務已產生回饋？」→ 夥伴收益明細。

不靠誇大事故恐懼或假限時回饋吸引用戶。內容先提供可用結果，回饋依實際適用交易說清楚。

9. 每次試點怎麼判斷有效

記錄「看到／掃碼 → 打開情境 → 得到結果 → 自願建帳 → 提出服務需求 → 授權 → C 接案 → 核實收入 → B 可領回饋 → A 再次使用」。只在取得相應允許及可辨識的範圍內量測，不用緊急內容閱讀紀錄建立廣告標籤。

按情境與 B 通路看：有用結果完成率、接案率、實收每件收益、B 回饋成本、客服分鐘數、退款及抱怨、再次使用。基線從試點取得；「加入 LINE 很多」不足以證明有營收。

B 的持續回饋依原始 B→A 關係與每筆 A 的實際交易歸屬。店外成交用預約碼、核銷碼、合作對帳或申請補登銜接；未核實的收入保持待核對，不能假稱全部自動追得到。

LINE 對話與事故流程 v0.1

本文件是待實作的對話規格。安全文字以固定、具來源及版本的內容輸出；第一版不使用生成式 AI 自由判斷肇責、傷勢、車輛安全或保險是否理賠。

1. 主要入口

圖文選單固定六格：「我撞車了」「我被撞了」「車被淹了」「車刮傷了」「車故障了」「停車助手」。案件進度、服務夥伴及美容／保養／換車，透過每次回覆底部的「我的用車」入口與文字關鍵字進入。完整六格規格見 Rich Menu。

兩個事故按鈕進入相同分流，入口描述僅作車主自述。選「我被撞了」不產生「對方全責」標籤。

2. 第一張事故回覆

先確認你和乘客的安全。如果有人受傷、疑似受傷或需要救護，請立即撥 119，並聯絡 110。仍在危險處時先停止操作手機，到可安全到達的地方；不要為拍照冒險。

常駐按鈕：「撥打 119」「撥打 110」「國道拖救 1968」「我已在安全處」。依裝置顯示電話及可點擊連結；LINE 開啟撥號器不等於已接通或已派遣。

接著用一次一題的大按鈕詢問：

這些自述用於提示下一步，不作醫療診斷或車輛安全認證。緊急狀態的最少資訊只作流程使用，不存病歷或傷勢細節。

3. 現場紀錄與移車

只有在確認無人傷亡、車輛能動、沒有立即危險且能安全記錄的情況，才顯示快速記錄及移車提示。有人受傷、疑似受傷或狀況不明時，先求援並依警方／救護人員指示；有立即危險則先確保人身安全。

照片規劃為「現場方向與標線」「雙方相對位置」「碰撞位置」「安全處補車損細節」，依情況顯示，均可跳過。不得要求使用者站在車流中拍攝或為湊齊照片停留。國道流程另提示人員在可安全到達的護欄外或安全處待援。國道事故處理原則

定位使用 A 主動分享的 LINE 位置或同意後的裝置位置；失敗時可以輸入道路名、方向、里程及地標。不要求持續背景定位，分享給拖吊業者另行授權。

每個步驟允許「已完成／稍後補／不適用／無法完成」。系統分別記錄點擊撥號、本人回報已報案、本人回報已移到安全處；不由按鈕推論真實完成。

4. 安全後才建立案件

要幫你保存這次事故的資料嗎？你可以先查看指引。保存案件後，可以補照片、追蹤進度，並決定讓哪一位夥伴協助。

先呈現蒐集者名稱、目的、資料類別、期間、地區、對象、方式、權利及聯絡管道的完整告知，再提供「保存案件／先不保存」。營運主體與保存期間未確認前，這份文字只能作規格草案，不能直接拿來取得正式同意。個資法第 8 條等

初次建案只需經驗證的使用者識別、案件來源及入口描述；事故時間、車輛使用關係、照片和位置分段補。電話、車牌在需要服務時才收集，並說明用途。已存在的未結案件先讓 A 選續用或另建，避免重複誤建。

在同意前已透過 LINE 傳來的照片，不自動下載到長期儲存或轉發商家；正式流程需設定短期處理、刪除及供應商日誌政策。不能宣稱 LINE 或基礎設施完全不留資料。

5. B 接手

這個服務入口由「B 夥伴名稱」提供。要讓 B 協助這一件事故嗎？

可以查看：你選擇的聯絡方式、案件進度，以及本次勾選的資料。

按鈕：「選擇分享內容」「暫時自己處理」。B 不因來源代碼而自動取得照片、定位、保單或車牌。B 已收到 A 的電話或訊息，亦不代表平台已取得 A 的完整轉介授權。

6. 拖吊選擇與費用確認

國道先顯示 1968 官方拖救入口，費率連結導向官方現行頁面，避免寫死價格。一般道路可顯示 A 自有保險／車廠救援方案及已確認服務範圍的合作業者。高速公路局拖救須知

「拖吊蟑螂避雷」對外改為「拖吊費用與業者確認」，提供具體核對：業者及車牌、起拖地點、目的地、里程、基本費、特殊作業／待時／保管／其他加價、稅費、合計及收據。未確認的金額顯示待報價，不顯示假精準總價。

留存雙方確認版本。若有費用爭議，可整理估價、三聯單、發票及車號等證據，導向相應官方查詢管道；不以無法查證的名單指稱特定業者違法。

7. 保險與修復選擇

「我是否該出險」先分出既有保單、本人車損／第三人財損／人傷、估價、自負額與保險公司待確認項。提醒及早聯絡承保公司確認程序，不等待本工具算完再通知。

只有金額由 A 或專業人員提供且假設完整時，才能試算「自費金額」與「自負額＋不承保費用＋已確認的保費影響」。未確認承保、保費或人傷責任等資料，顯示待專業確認；不自動下結論「該出險／不要出險」，不代替保險公司核賠。正式理賠依個別契約與案件審核。汽車保險契約範本

修復方案提供可比較的工法、零件、報價、工期、保固與是否需拆檢，讓專業業者確認後再由有權決定者核准。涉及責任爭議時連結警方資料申請或人工法律協助，不產生肇責比例或保證權益的結論。

8. 每一次轉介的確認卡

要請「示範修復廠 C」聯絡你評估修復嗎？

用途：本次車損評估與報價。分享資料：你選擇的聯絡方式、車型與本次選定的車損照片。可在送出前取消，或到案件授權頁停止之後的分享。

本平台可能向合作業者收取媒合服務費，並依約回饋推薦夥伴 B；實際費用及合作關係依正式公告顯示。

按鈕：「同意這次轉介」「調整資料」「先不要」。清楚顯示實際公司全名及本次欄位，不預勾同意。拖吊、修復、原 B 查看及後續行銷是不同授權；換收件人需新授權。

授權撤回後停止後續分享與尚未送出的訊息，既有資料存取取消；對已交付的資料通知收件方依約處理並留存回覆，不假稱能自動收回對方已收到的檔案。

9. 後續追蹤

案件時間軸：待聯絡 → 已接案 → 已聯絡 → 待報價 → 待車主／車隊核准 → 處理中 → 已完成 → 待回訪 → 結案。拒接、無回應、取消、爭議各有獨立結果與負責人。

提醒以事件觸發及使用者選擇為主，例如約定報價未回、交車前確認、完工回訪。不以固定 D+7／D+30 推論法律期限或事故進度。涉及法律或保險期限，由有來源的規則與適用案件條件另行確認。

結案頁讓 A 主動選「安排美容保養」「需要估價換車」「結束本次服務」。選擇一項需求不自動加入廣告名單；行銷訂閱可單獨關閉。未排定人工值班時不顯示「客服在線」或「立即派車」。

B 的收益回饋、來源歸屬與結算

1. 使用者已指定的核心

依使用者最新更正：B 將工具提供給 A 後記錄關係，後續收益回饋給 B。 B 是推薦夥伴及回饋受益人，A 是車主／使用者，C 是服務業者。A 的後續服務交易持續連回原 B；A 本人不預設領取此項回饋。

「任何後續收益」在系統上定義為：所有收益品類都支援歸屬及回饋；其中能核實由 A 的交易或授權需求產生、且平台實際取得的收入，依當次已揭露規則入帳。平台外交易、沒有平台收入及無法辨識 A 的整包訂閱，不能憑空算收益；需提供訂單綁定、分配或補登方法。

這是持續歸屬設計，不在尚無正式條款時對外承諾永久、所有商家均適用或固定報酬。

2. 必須分開的四種關係

A 之後由 B2 分享進來：保留原始 B，記錄新的接觸來源；A 可選這次由 B2 協助。回饋仍歸原 B；改由 B2 提供服務不自動改掉收益歸屬。來源有誤由營運核實更正並保留前後版本。

3. B→A 綁定流程

1. B 後台產生可停用的專屬邀請碼與連結，QR Code 只放入口，不放 A 個資。
2. A 點開後顯示 B 的組織及名稱；登入並同意建立服務帳號時，確認「由 B 提供」。緊急指引先於登入。
3. 伺服器驗證邀請碼、B 狀態及 LINE 身分，再建立關係。單純點擊或加好友不直接當作成功綁定。
4. 後續 A 從 Rich Menu 直接進入仍能辨識本人；每張服務訂單綁定 A，付款或平台收益由可信來源回報。
5. A 可在「我的用車」查看來源及申請更正，亦可改選服務夥伴。重新掃碼不轉移既有收益。

第一版採 A 明確確認的首筆有效推薦，無來源可使用自然加入。對尚未建帳的訪客，只保留為完成綁定所必要且有期限的暫存，不以跨網站追蹤補猜身分。

4. 哪些收益可以回饋

新收益類型上架時必須有「是否可歸屬 A、回饋依據、規則版本、結算責任人」。沒有收入的免費指引、看地圖或單純加好友，不能宣稱會產生現金回饋。

5. 回饋公式與示例

2026-09-10 新增的 20 位 B 收益與分潤報告 建議以未稅實收平台費的 30% 作洽談起點，並比較 20%／30%／40%。比例、成熟期間、支付門檻仍為提案，沒有生效。下方及純計算程式保留 20% 作為數學示例，不能當成最新商業報價。

建議採容易核對的公式：

累計應得回饋 = 向下取至分〔(本筆累計已收平台收入 − 累計退款沖回 − 事先揭露的非回饋項目) × B 回饋比例〕。

金額以新台幣「分」保存，比率用基點保存；累計重算後只新增差額帳項，避免拆單或多次退款的進位誤差。計算基礎、稅費及可排除項目必須在B 的合作條款中說清楚，不能任意把營運成本事後扣回。

以下 20% 只是算例，不是已定的回饋比例或報價：

B 的回饋從平台收入計算，不能把 NT$20,000 修車總價誤當平台收入。若修復平台收入之後退回 NT$500，該筆累計回饋由 NT$400 調整為 NT$300，另記 −NT$100 沖回，不刪原紀錄。

6. 帳本狀態

「待核對」「待結算」「可領取」「處理中」「已領取」「調整」分別展示。報價不產生可用回饋，C 自稱成交也不等於平台已收收入。

帳本採不可覆寫的收支項：原收入、退款、回饋累積、調整、保留、發放、退還保留。每一項都有原交易、規則版本、操作者、時間與證據；餘額由帳項彙總，不由客服直接改總數。

7. 如何領取

完整產品可支援兩條路，第一版只啟用一種並於正式條款定案：

• 現金回饋：B 或所屬組織的授權財務人員申請，核對契約受益人與收款對象，以合適的付款服務或人工銀行批次支付，回填對帳結果。銀行資料只在領取時收集，限制存取，不放聊天訊息。
• 服務折抵：若與 B 約定以工具月費或其他服務折抵，顯示可折抵範圍及金額，確認後產生單次核銷紀錄；合作方結算成功才完成核銷。不能任意把已承諾現金的回饋改成點數。

第一版建議「回饋明細＋人工核帳及批次發放」，先驗證單件毛利及對帳。最低領取門檻、結算週期、等待期間、效期、稅務憑證及支付角色需正式定案；目前不填固定承諾。

不規劃讓使用者儲值、互轉、借貸或交易回饋；若未來有此需求，需重新確認支付與法規架構。A 不需提供銀行帳戶。B 的收款帳戶由夥伴財務流程維護，不能從 A 的案件資料取得。

8. 退款與異常

9. A、B、C 的畫面

A：自己的服務、案件、授權、推薦來源及平台／B 可能取得回饋的揭露；不顯示 B 的私人財務帳本。

B：自己的有效推薦、經 A 授權的服務進度、可核對的收益與回饋、待結算／可領取金額、付款歷史及異常申請。顯示交易代碼與必要摘要，不能因領分潤而查看全部事故文件。

C：自己的服務訂單、應付平台費用、退款及核銷；不見其他業者交易。

平台財務：收入待核對、未分配收入、回饋負債、付款批次、退款差異、規則版本與稽核。營運可收證據，金額核准及發放按角色分工。

10. 歸屬與利益揭露

每張訂單記錄來源 A、原推薦 B、服務 C 與回饋規則快照。單純點擊其他 QR Code 不覆寫原 B。自然加入且沒有推薦來源的 A，其交易列自然來源；後續能否補綁由事先公布的規則與證據決定，不追溯搶占既有交易。

B 是個人、分店或組織，以及誰可領取，需在合作合約中明確。若員工隸屬租車或保險組織，不以技術上的個人邀請碼擅自認定收益歸私人。B 的角色含保險業務時，也需確認其所屬機構對兼業、轉介及酬金的規範；未確認可行的保險類收入保留停用。

A 選服務前說明平台與推薦 B 可能從合作服務取得費用或回饋。A 自主選擇業者，安全建議、修復工法與保險評估不因 B 的抽成而改變。

資料、系統與權限規格

這是待實作架構，不表示資料庫、LINE 身分驗證、檔案儲存或對外 API 已建置。

1. 建議系統分工

提案採 LINE Messaging API＋LIFF，管理介面沿用團隊熟悉的 Next.js／TypeScript；獨立 PostgreSQL 支援訂單、收入與帳本的交易及唯一鍵，照片放私有物件儲存。這是技術提案，未選定主機、購買服務或部署；既有 CRM 的 MongoDB 不遷移。

第一版使用具版本的固定規則和人工確認。若後續加 AI，適合用於經授權的文字摘要、文件欄位擷取草稿與客服知識檢索；人身安全、肇責、理賠、實車車況、收益或付款均由可驗證規則與人員決定。這次不設定 AI API 金鑰。

2. LINE 與邀請歸屬

• 平台先用一個專用 LINE 官方帳號，多個 B 以邀請連結識別；後期才做各 B 自有帳號的品牌方案。不得直接覆蓋現有 CRM LINE 用途。
• LIFF 入口示意為 https://liff.line.me/{LIFF_ID}/invite/{code}。登入重導後仍須保留邀請意圖，並由伺服器驗證代碼。LINE 的 liff.state 只協助傳遞入口，不代表授權。LIFF 官方流程
• 邀請可轉傳不代表個案可轉傳。公開來源碼不能當案件密碼；照片或帳本分享不可塞入同一來源 URL。
• LINE Login 與 Messaging API 的 provider 配置需正確，伺服器驗證 token 與受眾，不能只相信前端 getProfile 傳來的 userId。LINE 身分資料官方指引既有好友、外部瀏覽器、登入取消、封鎖與重新加入都要驗收。
• webhook 驗證原始 body 簽章，再交事件佇列；以 channel＋webhookEventId 去重，處理重送、亂序、回覆失敗及未知事件。只有可靠收妥事件才確認接收。LINE webhook 文件
• 訊息收回、使用者封鎖與資料撤回各有不同語意；收回內容需適當刪除或停止使用，不能仍在後台顯示原照片。

3. 核心資料模型

4. 最小化分享

授權需精確到公司、人員角色、目的、欄位及所選資產。傳送前及每次讀取都重新檢查；撤回時取消待送工作與存取。照片包含他人的資訊時，提供裁切／遮蔽流程；A 的同意不自動涵蓋對方個資。

5. 事件與生命週期

主事件規劃：invite_confirmed、case_created、safety_self_reported、asset_added、consent_granted/revoked、referral_requested/accepted/declined、quote_approved、order_completed、revenue_confirmed/refunded、reward_accrued/adjusted/available、payout_requested/confirmed/failed、case_closed。

各事件包含唯一 ID、來源、時間、案件／訂單、操作者、版本及必要的相關鍵。付款及收入由伺服器權限角色產生；車主不能透過聊天「已付款」直接造成收入入帳。

案件可暫停、取消、重開與轉人工；每次變更保留原因。同一事件重送不再建案、不再媒合、不再記收入、不再發回饋。

6. 保存與刪除

正式保存期間按「暫存登入／未建案、案件資料、定位／停車、授權證據、交易帳務、備份」分別定義，並由營運主體與適用要求確認後填入告知。未決定前，不啟用真實蒐集。

定位只用於本次目的；醫療／病歷文件不列首版上傳項。若後期有必要，另設具法定基礎及嚴格權限的流程。原始照片及文件保存在私有空間，記錄目的、到期、刪除、備份清除及收件方處理狀態。

A 可以查詢、匯出本人資料、提出更正及停止／刪除需求；B 查看本人／組織帳本。交易留存與一般行銷資料分開，A 退訂不取消本人案件查詢，B 的既得收益依約處理。

7. 對外 API 設計提案

8. 既有 TS Dent CRM 介接

在 A 選定 TS Dent 為 C 並授權後，送最小化的商機資料與外部案件／訂單 ID。CRM 回傳接案、報價、完工及可核實收入事件；以外部 ID 去重，不直接把所有 LINE 好友匯入 CRM。

CRM 的完工狀態不等於平台已收取媒合費。收入以實際結算資料為準，回饋帳本由本子專案負責。介接故障可重試及人工對帳，失敗不顯示轉介成功。

交付計畫、驗收與營運

1. 現況與範圍

本次已建立完整產品文件、六格 Rich Menu 本機設定、回饋試算及其驗證範例。未建立可接收真實個案的 LINE Bot，未做金流、後台、資料庫、商家串接或部署。

完整產品包含：B 引流歸屬、A 六大用車入口、資料與轉介授權、C 接案、案件追蹤、可歸屬收益回饋 B、日常服務及通路成效。先完成試點閉環，再擴充全部情境。

2. 分階段開發

時間估計需先確認人力、既有 LINE 帳號、合作業者、資料供應與試點地區，再拆工作量；目前不承諾幾天可正式營運。

3. 第一版必做與後做

必做：六入口、緊急電話及固定內容、B→A 來源確認、A 個人案件、權限與最小分享、服務需求與人工接案、交易狀態、B 回饋帳本與人工核帳、退款沖回、基本成效、錯誤及人工接手。

後做：全台即時派車、全台精準停車、預約車位、自動停車扣款、照片自動報價、AI 肇責／理賠判斷、保險招攬抽成、自動銀行付款、完整品牌多 LINE 帳號、所有延伸情境的專用畫面。

六個入口都可上第一版，但用可運作的最小範圍：停車先支援試點地區和官方外連；修復與拖吊先人工確認接案。未支援的地區清楚說明並提供可用的求援或查詢方式。

4. 必要驗收情境

本機現有測試只涵蓋回饋純計算與 Rich Menu 設定，未涵蓋表內需要正式系統的情境。

5. 營運分工

B：推廣工具、說明自身服務角色、在 A 授權後協助案件。C：更新區域及接案時段、回覆報價、提供服務與結算證據。平台客服：接手未完成及爭議，不能擅改帳本或冒充已出勤。平台財務：核對收入、退款及發放；內容負責人：維護官方來源與版本。

第一個合作業者上架前確認公司與窗口、服務範圍、營業時間、可提供工法、價格表示、退款／無效件規則、案件資料用途與刪除程序。合作關係與排序原因在 A 端說清楚，不以付費多寡隱藏成「最佳」推薦。

6. 成本與定價框架

訂閱方案可依門店／席位與功能分級；每件媒合費及回饋比例依服務品類的實際毛利驗證後定。不得因提高回饋而誘導無必要維修、出險或換車。

7. 試點讀數

每個 B 的有效綁定 → 各入口有用結果 → 自願服務需求 → 授權 → 接案 → 已核實收入 → B 已結算回饋 → A 再次使用。分品類計算退款、客服成本及單件毛利，先取得基線再談擴張。

定期內容與提醒系統是產品需求；此次沒有建立任何 Codex 排程或對外通知。

需求與決策紀錄

日期：2026-09-10。

使用者明確要求

1. 在 TS Dent 工作區新增獨立子專案，提供租車或用車業者的推廣引流工具。
2. 透過合作夥伴 B，例如保險業務，將 LINE Bot 提供給 A。事故時協助拍照、移車、定位與報警，過程可記錄為案件。
3. 後續串接拖吊選擇與費用風險提醒、保險評估、權益、修復成本比較、追蹤、美容保養與中古車需求。
4. 最終更正：回饋給 B。記錄 B 推薦 A 的關係，A 之後產生的可核實收益依約回饋原 B；A 是車主／使用者。
5. Rich Menu 六入口指定為「我撞車了」「我被撞了」「車被淹了」「車刮傷了」「車故障了」「停車助手」。
6. 要求完整規劃，並延伸更多用車狀況與引流方式。
7. 查詢台灣相關微服務、預估收益與 B 分潤；使用者指定第一階段以 20 位／家 B 試點。

台灣服務與收益研究（2026-09-10）

正式 HTML 報告 附可調整 Excel。查得 K-WAX 的持續推薦分潤、固得租車推廣合作，以及產險 LINE、車廠工具、區域救援與停車平台等相鄰服務；公開頁面不等於已達成合作。

收益以 20 位 B、每 B 累積 25／50／100 位可服務 A 比較成熟月份；第一年假設 2026 年 11 月起逐月新增與流失，並採 LINE 公告的新費率。B 的 30% 平台費分潤為洽談建議，其他價格、轉換率、成本和結算條件皆待試點驗證。沒有把商家交易總額當平台收入，也沒有預先計入保險佣金或尚未談成的訂閱收入。

已採用的規劃假設

尚待定案但不阻擋完整規劃的事項

品牌與營運主體、第一個城市、第一批 B／C 與人工服務時段、訂閱及媒合費、B 回饋比例與品類、回饋現金或折抵、結算門檻與期間、B 個人／分店／組織的收益權及收款安排、資料保存政策、LINE 帳號與供應商、CRM 介接責任人。

文件中 20% 回饋與範例交易皆為示範；沒有訂立真實收費、開啟保險佣金方案、付款或對外承諾。

這次完成的邊界

本機新子專案、完整規劃文件、可讀取的 Rich Menu 設定草稿、回饋純計算範例與檢查。沒有變更既有 CRM／AI 官網／LINE 子專案，沒有推送、發布、通知夥伴或連接客戶資料。

官方參考來源

查閱日期：2026-09-10。下列是產品設計的參考，不代表每種事故、保單、商家或城市都適用相同條件。使用者流程、回饋與商業模式為本專案的設計提案；正式事故內容需逐版維護來源及適用條件。法規網站可能同時顯示修正條文，正式營運需確認具體施行與適用情況。

未採用民間「黑名單」、商家自述成交率、未確認拖吊價格或不明來源的保險抽成規則。38 種延伸用車情境是待驗證的產品構想，並非市場調查結論。