預約系統流程十一段全圖：屏東預約系統業主與預約系統公司從型態判讀、規則表、申請順序到上線後維運的分工

作者 Bo Wei・偉騰開發興業有限公司・發布 2026-10-11・更新 2026-10-11（由前臺東縣環境保護局局長謝清泉主持）

預約系統從決定要做到真正上線，中間有十一段可以切開檢查的流程：先判讀自己是哪一種型態、要不要客製，再把業主、預約系統公司、LINE 平台、金流機構與電子發票加值中心的分工列清楚，接著依序完成規則表、規格與分期、流程設計與原型、開發與串接的申請順序、審核端會問的問題、試跑補正、資料匯入切換，最後是上線後的維運義務。每一段都有一份可以拿在手上的文件當錨點，屏東與全台各縣市的業主都能以線上方式走完。

結論先說：預約系統的流程不是「找一家預約系統公司、等它做好」，而是業主與開發團隊交替出手的十一段。業主負責的是規則與決定，開發團隊負責的是把規則變成系統並把外部服務串起來，中間還有金流機構、LINE 平台與電子發票加值中心各自的申請與審核。哪一段該由誰出手、要先準備什麼文件，決定了專案是一到兩個月走完，還是在來回確認裡拖過旺季。

最常見的錯誤直覺是先挑工具再想規則：看到一套現成的預約工具就套上去，才發現同時段容量、緩衝時間、療程次數或候補遞補套不進去，最後還是要人工調整。另一個誤會是把金流與發票的申請當成開發的一部分，實務上這些特店與加值中心的申請一律以業主名義提出、由對方審核，開發團隊只能協助準備文件與完成測試驗證，時程要另外算進去。

本文依十一段的順序走：前提判讀、分工、規則表、規格與分期、流程設計與原型、開發與串接的申請順序、審核端會問什麼、試跑與補正、資料匯入與切換、上線後的維運義務，最後是遠距作法與爭議時紀錄的價值。

每一段都標出一份錨點文件，讓屏東以及全台各縣市的預約制店家、課程主辦單位與場地出租業者可以照著核對自己走到哪一段。

預約系統流程第一段：型態判讀，用四種型態對照表決定走現成工具還是客製

錨點文件是型態對照表。

預約與報名系統依核心規則分成四種：

• 人員時段型看人員與服務時長、緩衝與同時段容量；
• 設備場地型看設備數量、時段單位與連續時段；
• 課程活動型看場次名額、候補、分組與資格；
• 到府服務型看人員路線、區域與服務時長。

先把自己放進其中一格，再回答三個問題：規則是否標準到現成工具套得進去、要不要與 LINE 官方帳號或既有系統整合、資料是否要留在自己名下。三題都是否定的，現成工具夠用，預約系統公司也應該這樣建議；只要有一題是肯定的，才進入客製流程。這一段由業主自己完成，開發團隊的角色是幫忙確認型態與列出現成工具的限制。

預約系統流程第二段：分工表，業主、預約系統公司、平台、金流與發票各管什麼

錨點文件是分工表。

業主負責提供規則、政策、既有資料與各帳號權限，並在每一段做決定；預約系統公司負責規則表整理、規格、設計、開發、串接、測試與教育訓練；LINE 平台負責官方帳號與訊息 API 的審核與配額；金流機構負責特店審核、交易處理與撥款；電子發票加值中心負責發票開立介接與驗證；電信或訊息服務商負責簡訊通道。

分工表最重要的一欄是「以誰的名義申請」：官方帳號、金流特店、發票加值中心、網域與雲端都應該登記在業主名下，開發團隊只保留協作權限。分工沒寫清楚的專案，最常卡在金流審核文件沒人準備、或官方帳號開在廠商名下日後搬不走。

預約系統流程第三段：規則表，把服務、人員、容量、緩衝與期限逐條寫下來

錨點文件是規則表，這是整個預約系統流程裡業主投入最多、也最值得投入的一段。

規則表至少要逐條寫出：每項服務的時長與可執行的人員或設備、同時段可收的組數、每組之間的緩衝時間、最早可提前多久預約、多久前改期或取消不扣訂金、是否收訂金或全額、有沒有會員或療程次數、多據點各自的營業時段與人員。

報名型的另外列場次名額、候補遞補規則、分組與資格條件、報名與付款是否綁定。規則表確認的速度是時程的最大變數，開發團隊會依表排程並在驗收時逐條測試，所以這一段寧可多花一週把例外狀況問完，也不要在開發中途才補規則。

預約系統流程第四段：規格與分期，一頁規格加上第一期只做最痛的流程

錨點文件是需求規格書。

規格書把規則表轉成系統要做的事：

• 客人端在網站、LINE 或兩者預約；
• 後台的排班、名額、報到與取消管理；
• 提醒的時間點與通道；
• 金流與發票的流程；
• 與客戶資料或行事曆的同步。

分期的原則是第一期只做最痛的那段：排錯最嚴重的店先做排程與確認提醒，爽約最嚴重的先做提醒與訂金，名額算不清的先做報名付款綁定與候補。每一期要寫清楚功能清單、驗收條件與不包含的項目，規格由業主簽認後開發團隊才估時程，之後的變更走變更單。規格簽認是業主的決定點，不是開發團隊的交付點，簽認前請找實際操作的同仁一起讀過。

預約系統流程第五段：流程設計與原型，客人端與後台畫面先走一輪

錨點文件是可點擊的原型。

客人端的預約步驟從選服務、選人員或設備、選時段、填資料、確認條款到付款與收到確認，每一步的順序與用語都照客人的習慣排；後台則呈現每位人員、每個設備、每個時段的狀態，支援手動加預約、調整、標記報到與未到、備註需求。

原型做好先讓店內實際排預約的同仁點過一輪，把順序不順、用語不懂的地方改掉，再進開發。這一段常被業主要求跳過，理由是「做出來再看」，但改原型的成本遠低於改寫好的程式與資料庫。原型試用是業主的工作，開發團隊負責記錄每一條回饋並更新規格，避免口頭說過的修改在開發期不見。

預約系統流程第六段：開發與串接的申請順序，官方帳號、金流特店與電子發票誰先誰後

錨點文件是申請順序表。

開發團隊進入排程引擎、提醒任務、後台與客人端的開發時，業主要同步啟動三件以自己名義申請的事：LINE 官方帳號與訊息 API 的開通、金流特店的申請與審核、電子發票加值中心的申請與介接驗證。

順序上官方帳號最先，因為客人端流程與提醒通道要靠它測試；金流特店其次，審核期間開發團隊先用測試環境完成付款流程，通過驗證後才核發正式金鑰；電子發票最後，等金流流程走通再接開立與作廢。

排時程時要把每一項的審核與驗證時間算進去，這些不是開發團隊能加速的環節。卡號一律不得存在自家資料庫，付款頁由金流機構提供或以其規範的方式介接，這一點在規格裡就要寫明。

預約系統流程第七段：審核端會問什麼，金流、平台與個資告知的問題清單

錨點文件是審核問題清單。

金流機構審核特店時會看營業登記或稅籍資料、販售的服務內容、網站或 LINE 流程上是否在付款前揭露取消、改期與退款條件，因為線上收取訂金或課程費用屬通訊交易，消費者保護規範要求這些條件在消費者確認前就看得到。

LINE 平台審核訊息用途時看的是訊息類型與發送對象是否為已同意的客人。個人資料的部分，預約蒐集的姓名、聯絡方式與需求備註屬《個人資料保護法》的蒐集行為，告知事項、保存期限、存取權限與提醒訊息的使用目的要在流程中呈現並在系統中落實。把這三組問題在送件前先自問一輪，補正次數會少很多；答不出來的題目，通常代表規則表或規格裡少了一條。

預約系統流程第八段：試跑與補正，模擬一週預約量後列出測試紀錄

錨點文件是測試紀錄。

上線前用真實情境模擬一週的預約量：兩位同仁同時搶同一時段、容量額滿後的候補、前一組延後時緩衝是否生效、提前與取消期限的邊界、提醒是否在前一天與當天各發一次且已取消的不再收到、訂金付款與退款、發票開立與作廢、後台報到與報表。

每一條規則對應一個測試案例，結果記錄為通過或待補正，待補正的項目由開發團隊修正後重測，業主在紀錄上簽認。補正是流程的一部分而不是失誤，重點是每一項補正都回頭對到規則表或規格的哪一條，若是規則本身沒寫到，就同步更新規則表，不讓系統與文件脫節。

預約系統流程第九段：資料匯入與切換，既有紀錄的匯入核對表

錨點文件是匯入核對表。既有的試算表、行事曆、現成工具的匯出檔或紙本紀錄，先整理成統一欄位：客人基本資料、歷史預約、療程或會員剩餘次數、未來已排定的預約。開發團隊在測試環境試匯入，業主核對筆數與關鍵欄位，特別是未來已排定的預約一筆都不能漏，否則切換當週就會出現客人到了系統卻沒有紀錄的狀況。

紙本紀錄可以只匯入客人基本資料與最近一段期間的預約。核對通過後約定切換日，切換前一天停止在舊工具新增預約，切換當天正式匯入並開放客人端，舊資料保留備份以備查對。這一段的分工很清楚：整理與核對是業主，匯入與比對筆數是開發團隊。

預約系統流程第十段：上線後的義務，維運清單裡的個資、提醒紀錄、退款規則與備份

錨點文件是維運清單。

上線不是流程的終點，而是幾項義務的起點：

• 預約人的個人資料要依告知的保存期限處理，離職同仁的後台帳號要即時停用，存取紀錄要留得住；
• 提醒訊息的送達、失敗與重試紀錄要保存，客人說沒收到時後台查得到那一則是什麼時候、走哪個通道送出；
• 取消、改期與退款條件若有調整，付款前的揭露內容要同步更新；
• 資料庫要定期備份並演練還原。

日常的新增服務、調整時段與人員由業主的同仁在後台操作，系統更新、監控、規則變更與提醒通道異常處理則依書面範圍委託或自行維運。維運清單寫清楚回應時間與資料匯出方式，日後換團隊或自行接手才有依據。

預約系統流程第十一段：屏東與全台業主的遠距作法、爭議紀錄，以及下一步三件事

錨點文件是爭議紀錄。

屏東的店家與主辦單位不需要等預約系統公司到場：規則表用線上會議逐條確認，原型與測試用自己的手機與電腦操作，教育訓練以視訊搭配錄影，需要觀察多設備多房間的現場動線時才到場，全台各縣市做法一致。

上線後若客人對訂金、取消或退款有爭議，系統保留的確認時間、同意的條款版本、提醒送達紀錄與付款紀錄就是說明事實的依據；以臺中市為例，消費爭議的申訴與調解由市政府法制局消費者保護官室承辦，業主能提出的紀錄愈完整，說明愈容易。

讀完十一段，下一步先做三件事：

• 用型態對照表定位自己並寫下現成工具套不進去的理由；
• 把規則表草稿寫出來，寫不出來的格子就是要先在店內決定的事；
• 盤點官方帳號、網域、金流與發票是否已以自己名義申請。

規則表草稿寫完、同仁排預約已經撞期過、或旺季名額與付款對不起來時，就是該找人談的時候。偉騰開發興業承接全台各縣市的預約與報名系統，加 LINE「偉騰開發」傳服務型態與規則表草稿，我們先回覆書面初判：建議的規則架構、需要的串接與各段分工。

自我檢查清單

• 已用四種型態對照表定位自己，並寫出現成工具套不進去的具體理由
• 分工表標明官方帳號、金流特店、發票加值中心、網域與雲端皆以業主名義申請
• 規則表逐條寫出服務、人員設備、容量、緩衝、提前與取消期限、訂金與多據點差異
• 規格書寫明每一期的功能清單、驗收條件與不包含的項目，由業主簽認
• 付款前的取消、改期與退款條件已放進客人端流程，個資告知與保存期限已設定
• 測試紀錄涵蓋撞期、容量、緩衝、期限邊界、提醒、付款退款與發票
• 匯入核對表確認未來已排定的預約一筆不漏，維運清單寫明回應時間與資料匯出方式

常見錯誤

• 先挑工具再想規則，同時段容量與療程次數套不進去，最後還是人工調整
• 把金流特店與電子發票的申請當成開發的一部分，審核時間沒算進時程，上線日跟著延後
• 官方帳號、網域或金流特店開在廠商名下，日後想換團隊連資料都搬不走
• 跳過原型試用直接開發，上線後同仁發現順序不順、用語不懂又回去用紙本
• 切換前沒核對未來已排定的預約，上線當週客人到店系統卻沒有紀錄
• 上線後沒有維運清單，提醒通道異常無人處理，退款條件改了揭露沒更新

官方參考資料

• 全國法規資料庫：消費者保護法
• 全國法規資料庫：個人資料保護法
• LINE 開發者入口網站
• 財政部電子發票整合服務平台
• 臺中市政府消保園地

常見問題

預約系統流程裡，哪幾段一定要業主自己做、不能交給預約系統公司？

型態判讀、規則表、規格簽認、原型試用、以自己名義申請官方帳號與金流特店、資料核對與驗收，這幾段的決定權與名義都在業主。開發團隊能幫忙整理與提醒，但規則怎麼訂、例外怎麼處理、哪些功能放第一期，只有業主答得出來。

屏東的店家做預約系統，預約系統公司需要來現場嗎？

多數情況不需要。規則表用線上會議確認，開發與測試在遠端完成，業主用自己的手機與電腦試預約，教育訓練以視訊進行並錄影。需要觀察多設備、多房間的現場動線，或一次訓練多位同仁時才安排到場，屏東與其他縣市的做法一致。

金流特店與電子發票的審核要多久？會不會拖到上線？

審核由金流機構與加值中心各自進行，時間不由開發團隊控制，所以要在開發一開始就以業主名義送出申請。開發團隊會先用測試環境把付款與發票流程做通，正式金鑰核發後再切換；把這段時間排進申請順序表，上線日就不會被它拖住。

傳規則表草稿，先拿書面初判

不管您在屏東還是其他縣市，預約系統的十一段流程都能以線上方式走完。加 LINE「偉騰開發」傳服務型態、規則表草稿、現在怎麼排預約以及最困擾的問題，偉騰開發興業會回覆書面初判，寫明建議的規則架構、需要的串接、各段分工與時程量級。

全台各縣市受理｜專業團隊承接辦理｜親臨現場指導｜統籌包辦到好

聯絡偉騰開發興業

服務總覽｜案例解析｜法規知識庫