AI活動報名流程設計：從付款、座位到現場報到一次補齊

原內容日期：2026-09-02。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

填完表單，真的算報名成功嗎？

很多活動網站在表單送出後，立刻顯示「報名成功」。參加者以為已經有座位，主辦方卻認為要付款完成才算成立。

活動當天的爭議，往往在這個小小的狀態名稱中就已經種下。

先定義成功狀態

表單已送出、等待付款、付款待核對、已確認、候補中及已退款，代表完全不同的權利與後台工作。

每個狀態都應有進入條件、離開條件、負責角色與通知。參加者也要看得懂現在是否已取得名額。

票種必須換算成共同容量

認桌一次占用10席，單人票占用1席。如果只分別計算「桌數」與「人數」，很容易出現收入正確但座位超賣的情況。

主桌、工作人員及預留席也要先從可售容量中分開。

前台旅程與後台作業要一起畫

參加者看到付款成功時，後台可能還要做款項辨識、名額確認、發票處理、同行者補件及桌次分配。

利用泳道將網站、金流、報名管理、財務、座位及現場報到放在同一張流程中，才能看見工作交接點。

金流最怕狀態不同步

常見情況包括付款成功但網站沒收到結果、參加者重複付款、人工匯款無法識別，以及最後名額同時被多人付款。

流程應保留交易識別、報名編號、時間、金額與處理狀態，而不是只請參加者再傳一張截圖。

認桌需要第二階段補件

桌主付款完成，不代表另外9位的資料已齊全。可以先確認整桌名額，再於指定期限前補齊同行者名單、飲食及必要需求。

同時要決定桌主能否自行修改、何時鎖定，以及整桌取消或換人時由誰核准。

例外流程比正常流程更重要

候補逾時、重複付款、名單不足、退款失敗及現場查無資料，都應在開放報名前先寫出處理方式。

每項例外至少要包含先查什麼、可自行處理範圍、必須核准的動作、狀態更新及紀錄。

現場報到要有異常櫃台

正常報到人員負責快速查找與標記。查無資料、待付款、臨時改名、補差額及特殊協助則交由具備權限的異常窗口。

如果所有人都可以放行或調桌，活動結束後就很難完成金額與人數對帳。

AI可以設計流程，不能替主辦方定政策

AI可以找出缺口、建立狀態機、整理例外與產生測試案例。但退款比例、保留時間、轉讓、個資保存及法定告知，都要由正式負責角色決定。

資料不足時，最好的輸出不是一套看似完整的規則，而是一張清楚的待決策清單。

結語

好的報名流程，會讓參加者隨時知道目前狀態，也讓主辦團隊在每個例外發生時知道誰能決定、該留下什麼紀錄。

表單只是入口。付款、名額、通知、座位、報到與結案連在一起，才是一個真正可以運作的活動流程。

逐步操作

第一步：先定義「正式報名成功」

至少區分：

• 表單已送出
• 等待付款
• 已收到付款通知
• 付款核對中
• 已付款並確認名額
• 候補中
• 已取消
• 退款處理中
• 已退款
• 已報到
• 未到場

如果活動規則是「付款成功才保留名額」，畫面與通知都要明確說明。不能讓參加者以為填完表單就一定有座位。

第二步：先寫票種與容量規則

例如：

票種	價格	單位	佔用名額	主要填表人
認桌	12,000元	1桌／10人	10席	桌主
單人	1,500元	1人	1席	參加者本人

還要確認：

• 總桌數與總席次
• 預留主桌、工作人員及貴賓席
• 認桌與單人是否共用同一容量
• 單人如何併桌
• 未滿10人的認桌能否成立
• 桌主名單補齊期限
• 候補的啟動條件

未確認的規則標示待決策，不要讓AI自行選一個合理答案。

第三步：畫出參加者旅程

一般流程可先寫成：

1. 閱讀活動與票種規則
2. 選擇票種
3. 填寫必要資料
4. 同意活動及個資告知
5. 進入付款
6. 取得付款結果
7. 主辦方核對名額與款項
8. 收到正式確認及報名編號
9. 補充同行者、飲食或座位資料
10. 活動前收到提醒
11. 現場報到
12. 活動後收到收據、照片或後續通知

每一步都要問：參加者看到什麼？要做什麼？失敗時怎麼回來？

第四步：同步畫出後台泳道

至少包含：

• 參加者
• 報名網站／表單
• 金流或收款窗口
• 報名管理者
• 財務對帳
• 座位／桌次管理
• 現場報到
• 客服／異常處理

泳道的價值，是看出「前台顯示完成」之後，後台是否還有人要核對、分桌或發通知。

第五步：建立報名狀態機

每個狀態要有明確進入與離開條件：

目前狀態	觸發事件	下一狀態	限制
等待付款	金流回報成功	付款待核對／已確認	依實際流程決定是否還要人工核對
等待付款	超過保留時間	逾時取消	保留時間需由主辦方決定
候補中	有名額釋出並通知	等待付款	需設定回覆期限
已確認	參加者提出取消	取消審核中	依正式退費規則處理
已確認	現場完成身分核對	已報到	保留報到時間與工作人員紀錄

不要只用「已報名／未報名」兩種狀態，否則付款與名額很容易混淆。

第六步：只收必要資料

一般活動可能需要：

• 報名人姓名
• 可聯絡的Email或手機
• 票種與人數
• 同行者姓名或代碼
• 飲食、無障礙或其他必要需求
• 發票／收據所需資訊
• 活動告知與個資同意

不一定需要身分證字號、生日、住址或完整公司資料。每個欄位都要問：「不用這個資料，哪個必要流程會無法完成？」

第七步：設計付款與名額保留

需要確認：

• 何時建立訂單／報名編號
• 名額從何時開始保留
• 保留多久
• 付款成功如何回寫
• 付款失敗能否重新付款
• 金流成功但網站沒收到結果怎麼辦
• 人工匯款如何識別
• 少繳、溢繳、重複付款如何處理
• 每日如何核對訂單、付款與實收金額

付款成功不一定等於主辦方已完成名額與資料核對；實際狀態要依所選金流及作業規則確認。

第八步：設計認桌與同行者資料

認桌流程可分兩階段：

1. 桌主先完成報名與付款，取得桌號候選或報名編號。
2. 在指定期限前補齊同行者名單與需求。

需決定：

• 桌主是否可自行更新名單
• 名單鎖定時間
• 改名是否需要審核
• 同行者是否會收到通知
• 桌主取消時整桌如何處理
• 名單未補齊是否影響報到

第九步：設計單人併桌與座位鎖定

座位規則應先確認：

• 單人報名何時分桌
• 是否接受同行偏好
• 哪些需求優先，例如無障礙或親子
• 桌次何時鎖定
• 鎖定後誰能調整
• 現場換位是否更新正式名單

AI可以提供候選分配原則，但不能替主辦方自行決定敏感或可能造成差別待遇的條件。

第十步：建立例外處理矩陣

至少測試：

• 表單送出但未付款
• 付款成功但名額剛好已滿
• 金流成功但報名系統未更新
• 同一人重複報名
• 同一筆報名重複付款
• 匯款人姓名與報名人不同
• 認桌名單未滿10人
• 參加者要求取消或轉讓
• 候補通知後未在期限內付款
• 現場找不到報名紀錄
• 參加者忘記手機或QR Code
• 飲食及無障礙需求臨時變更

每項要有判斷依據、負責角色、處理時限與紀錄方式。

第十一步：每個狀態都設計通知

通知至少包含：

• 目前狀態
• 已完成的事情
• 還要做什麼
• 期限
• 金額及票種
• 報名編號
• 修改、取消或詢問入口
• 不處理的後果

不要在Email或簡訊中顯示完整敏感資料或付款資訊。

第十二步：設計現場報到與異常櫃台

正常報到：

1. 以報名編號、姓名或核准方式查找
2. 確認狀態為已確認
3. 標記已報到
4. 告知桌次或場次

異常處理需分開：

• 查無資料
• 狀態仍待付款
• 名字與同行者資料不符
• 重複報到
• 臨時換人
• 需補差額
• 有特殊協助需求

只有具備權限的人員才能放行、改票種、收款或調整桌次。

第十三步：上線前跑測試案例

不要只測自己成功報名一次。至少使用：

• 1桌認桌成功
• 1位單人成功
• 最後一個名額
• 付款失敗後重試
• 付款成功但回寫延遲
• 重複付款
• 候補遞補
• 取消及退款
• 桌主修改同行者
• 現場查無資料

每個案例都檢查前台顯示、後台狀態、金額、通知、座位及稽核紀錄。

第十四步：活動後完成結案

確認：

• 實收、退款與金流報表一致
• 報名、付款、座位與報到人數可對帳
• 未到場、退款及異常案件已結案
• 活動照片與後續通知符合授權範圍
• 不再需要的個資依政策處理
• 重要問題與改善事項記錄於下次活動模板

可直接複製的完整提示詞

你是一位資深活動營運顧問、服務設計師、產品經理、金流對帳與現場報到流程規劃人員。你擅長把活動需求整理成端到端使用者旅程、後台泳道、狀態機、商業規則、例外處理、通知節點及上線測試案例。

【任務】
請依我提供的活動資料，設計從活動資訊、選票、報名、付款、名額確認、桌次／座位安排、活動前通知、現場報到到活動後結案的完整流程。

你的工作是整理規則與指出缺口，不得自行創造價格、容量、退費政策、保留期限、法定告知、付款結果、座位優先權或個資保存期間。

【活動基本資料】
活動名稱：[填寫]
活動性質：[餐會／課程／研討會／內部活動／其他]
日期時間：[填寫]
地點：[填寫]
主辦單位：[填寫]
預計總容量：[人數／桌數／待確認]
報名開始與截止：[填寫]
主要聯絡窗口角色：[填寫]
敏感資訊限制：[填寫]

【票種與容量】
票種ID｜票種名稱｜價格｜單位｜每單位人數｜可售數量｜主要報名人｜需要補充的成員資料
[貼上；未確認處填待決策]

【名額與保留規則】
表單送出是否保留名額：[填寫]
付款成功是否立即確認：[填寫]
保留時間：[填寫／待決策]
總容量如何扣除：[填寫]
候補規則：[填寫／待決策]
超賣處理：[填寫／待決策]

【付款資料】
付款方式：[線上金流／轉帳／現場／其他]
付款成功來源：[填寫]
是否需要人工核對：[填寫]
對帳頻率：[填寫]
發票或收據方式：[填寫]
付款失敗重試規則：[填寫／待決策]
少繳、溢繳、重複付款處理：[填寫／待決策]

【取消、退款與轉讓】
取消方式：[填寫]
退款規則及期限：[填寫／待決策]
退款核准角色：[填寫]
退款作業時間：[填寫／待決策]
是否允許改名或轉讓：[填寫]
票種變更規則：[填寫／待決策]

【座位／桌次】
分桌時間：[填寫]
認桌名單補齊期限：[填寫]
單人併桌規則：[填寫／待決策]
特殊需求處理：[填寫]
桌次鎖定時間：[填寫／待決策]
可調整桌次角色：[填寫]

【現場報到】
報到方式：[姓名／報名編號／QR Code／其他]
可接受的替代查找方式：[填寫]
報到台角色：[填寫]
異常放行或現場收款核准角色：[填寫]
現場網路或設備備案：[填寫／待決策]

【通知管道】
Email：[有／無]
簡訊：[有／無]
通訊軟體：[填寫／無]
客服入口：[填寫]

【限制與設計規則】
1. 區分表單送出、等待付款、付款通知、付款核對及正式確認。
2. 不得將表單送出直接等同於報名成功，除非規則明確如此。
3. 不得將金流付款成功自行解讀為座位、資格或資料均已完成核對。
4. 不得自行創造價格、容量、折扣、保留時間、退款比例、手續費或截止日期。
5. 規則未提供時標示[待決策]，並提出一個可執行的決策問題。
6. 每種票券說明佔用的人數、付款單位、主要報名人及成員資料責任。
7. 認桌、團體及單人票的容量扣除與座位邏輯分開說明。
8. 不得假設未滿額認桌、改名、轉讓或現場補人一定被允許。
9. 每個狀態必須有進入條件、離開條件、可執行動作與負責角色。
10. 不得出現無法離開、重複扣名額或退款後仍占位的狀態。
11. 候補需包含進入條件、通知方式、回覆／付款期限及逾時處理；期限未提供則標待決策。
12. 付款異常需區分失敗、逾時、回寫延遲、金額不符、重複付款及無法識別。
13. 退款需保留申請、資格審核、核准、執行、完成與失敗狀態。
14. 不得自動核准退款、放行、改票種、調桌或更改付款紀錄。
15. 所有人工修改需保留時間、角色、原因、修改前後內容及證據。
16. 表單欄位遵循最小必要原則；每個敏感欄位說明必要用途。
17. 不得要求收集密碼、完整信用卡資料、安全碼、驗證碼、私鑰或不必要證件資料。
18. 對金流僅保存必要的交易識別與狀態，不重建或顯示敏感支付資料。
19. 涉及個資、金流、稅務、消保、退款、公益勸募或法規時，標示需由正式負責角色確認。
20. 座位分配不得依未經同意的敏感個人特徵進行。
21. 特殊飲食、無障礙及健康需求只收活動必要內容，限制可見範圍。
22. 每個通知包含目前狀態、下一步、期限、報名編號及客服入口。
23. 通知不得顯示完整敏感資料、付款憑證或其他同行者不必要資訊。
24. 現場異常處理需標示查核資料、可決定角色、放行條件及紀錄。
25. 上線測試需涵蓋正常、邊界、失敗、重複、取消、候補及現場異常。
26. 使用繁體中文，流程適合非技術主辦人員閱讀。

【輸出格式】

一、流程摘要
以150字內說明正式報名成功條件、主要票種、最大三項流程缺口及優先決策。

二、待決策清單
| 決策ID | 問題 | 為何現在要決定 | 可選方案 | 影響流程 | 建議決策角色 |

三、參加者旅程
| 階段 | 參加者看到什麼 | 參加者行動 | 系統／主辦回應 | 失敗時如何處理 |

四、後台泳道
使用文字泳道或表格呈現參加者、網站、金流、報名管理、財務、座位、客服與現場報到之間的交接。

五、報名狀態機
| 目前狀態 | 觸發事件 | 條件 | 下一狀態 | 負責角色 | 通知 |

六、票種與容量規則
| 票種 | 價格 | 佔用容量 | 主要報名人 | 成員資料 | 名額扣除時間 | 待確認 |

七、表單欄位設計
| 欄位 | 必填 | 使用目的 | 可見角色 | 保存需求 | 敏感度 | 可否刪減 |

八、付款與每日對帳
說明訂單建立、名額保留、付款、回寫、人工核對、差異處理及日結步驟。

九、座位與名單流程
分別說明認桌、單人、同行者補件、名單鎖定、併桌及現場調整。

十、例外處理矩陣
| 例外ID | 情況 | 先查什麼 | 可自行處理 | 必須核准 | 處理時限 | 狀態更新 | 應留紀錄 |

十一、通知矩陣
| 觸發狀態 | 對象 | 管道 | 主旨 | 必備內容 | CTA | 不可顯示資訊 |

十二、現場報到SOP
分成正常報到、查無資料、待付款、重複報到、臨時改名、特殊需求及系統離線備案。

十三、上線測試案例
| 案例ID | 情境 | 前置資料 | 操作 | 預期前台結果 | 預期後台狀態 | 金額／容量檢查 | 通知 | 通過證據 |

十四、活動後結案清單
包含收入退款對帳、報名座位報到一致性、異常結案、資料保存／刪除及改善紀錄。

十五、人工確認清單
列出啟用金流、公告退費規則、開放報名、分桌、退款、現場放行及刪除個資前必須確認的事項。

實際教學範例

活動情境

某協會舉辦年底辦桌聚會：

• 認桌：10人，12,000元
• 單人：1,500元
• 需要線上報名、付款核對、桌次安排與現場報到

還沒定義前的模糊流程

填表 → 付款 → 到現場找座位

看似簡單，卻缺少：

• 表單送出是否保留名額
• 認桌的10位名單何時補齊
• 單人席位如何併桌
• 付款逾時、重複付款與退款流程
• 現場查無資料的處理權限

建議狀態設計

狀態	說明
草稿	尚未送出
等待付款	已送出，但名額是否保留依規則決定
付款待核對	已收到付款訊號，等待必要核對
已確認	款項、名額與必要資料已確認
待補同行者	認桌已確認，但成員名單未完成
候補中	目前沒有可確認名額
取消審核中	已提出取消，尚未完成資格與款項處理
退款處理中	已核准退款，等待執行
已退款／已取消	名額依正式規則釋出
已報到	現場完成查核

認桌流程候選

1. 桌主選擇認桌並填寫本人資料。
2. 系統建立報名編號與付款資訊。
3. 依主辦方規則暫時保留一桌或等待付款。
4. 付款完成並核對後，狀態改為已確認。
5. 桌主在指定期限前補齊另外9位名單及必要需求。
6. 座位組鎖定桌次並發送活動前通知。
7. 現場可由桌主整桌報到或個別報到，方式需主辦方決定。

例外矩陣節錄

情況	不可直接做的事	建議處理
表單送出未付款	不可顯示已正式確認	顯示等待付款及明確期限
付款成功但系統未更新	不可要求參加者立刻重付	查交易識別、報名編號及金流狀態
認桌名單只有8人	不可自行拆桌或補陌生人	依正式規則請桌主補件或由座位組決定
重複付款	不可自行刪除其中一筆	保留兩筆交易並送人工核對／退款流程
現場查無紀錄	不可只看付款截圖就直接放行	由異常櫃台依交易、名額及核准權限處理

上線測試案例

案例：最後一桌同時有兩人嘗試認桌

需確認：

• 哪個時間點鎖定名額
• 另一位看到什麼訊息
• 若第一位付款失敗，名額何時釋出
• 是否進入候補
• 系統是否可能同時收兩筆款
• 發生超賣時由誰決定處理方式

AI不能做的事

• 不能自行決定退款比例與手續費。
• 不能假設付款完成就一定取得桌次。
• 不能用敏感個人特徵安排座位。
• 不能要求收集完整信用卡資料或驗證碼。
• 不能自行承諾活動一定提供改名、轉讓或現場付款。

常見錯誤、隱私與使用注意事項

表單成功頁寫「報名成功」： 若尚未付款，應顯示正確狀態。 - 名額只在付款後才扣，卻沒有超賣策略： 多人同時付款可能超出容量。 - 名額在填表時永久鎖住： 大量未付款訂單會占住活動容量。 - 票種容量沒有換算： 一桌與一人必須回到相同席次單位核對。 - 認桌只留桌主姓名： 現場報到與飲食需求會失去依據。 - 候補只靠人工私訊： 容易漏通知、逾時及重複釋位。 - 付款截圖當唯一證明： 應以正式交易或對帳資料核查。 - 退款直接修改成取消： 仍需保留退款核准與執行狀態。 - 人工調整沒有紀錄： 事後無法查明名額與金額差異。 - 現場所有人都能改桌次： 應限制角色並留下修改紀錄。 - 收集不必要的身分證、生日或地址： 違反最小必要原則。 - Email顯示完整同行者資料： 僅提供收件者必要資訊。 - 將付款或個資原文貼給AI： 先去識別化並遵守公司政策。 - AI自行寫退費條款： 必須由主辦方及適當專業角色確認。 - 只測成功報名： 最後名額、失敗回寫及現場異常才最容易出錯。 - 活動結束不清資料： 應依正式政策決定保存與刪除。