賓客名單需要審核時，報名怎麼做？

兩種活動，一個詞

公開售票。 誰付錢誰就能來。主辦方的工作是賣。付款就是門檻，這類工具又好又便宜。

受控名單。 有人決定誰可以來。報名是一份申請。業務團隊提名客戶，部門提交姓名，委員會審批，拒絕的消息還得傳達到，又不能讓任何人下不了台。

下面都是第二種。值得單獨說明，是因為辦受控名單活動的人常常去找「售票軟體」，找到的是為公開售票做的工具，然後用表格補缺口，一補就是六個月。

票種是一種身份，不是一個價格

這是這一頁上最有用的一個想法。

受控名單活動上，票種——VIP、賓客、媒體、分析師、工作人員、現場 crew、參展商——不是價格檔。它是決定下面這些事的那筆紀錄：

掛繩和胸牌顏色

志工不用問就拿起來的那一種

物料

哪份禮品、哪個袋子，或者沒有

用餐

哪家餐廳、哪一波

住宿

哪家飯店、到底有沒有留房

場次入場權限

哪些房間開、哪些拒絕

話術

遞出去的時候志工說什麼

報名時定好票種，後面每一項都會自動跟上。沒定好，報到台的人就得頂著身後的隊伍，當場做六個決定。

顏色就是介面。 志工不需要知道禮品政策。他們需要知道紅色拿 VIP 套裝、綠色拿小的那份。把權益編成顏色，臨時聘來的人才能讓報到台轉得快——而這個決定是幾個月前在報名表裡做的。

推論值得說清楚：活動前兩週冒出一個新的參加類別，那不是改個表單。那是一筆掛繩訂單、一份物料清點、一次房間分配、一條準入規則，以及志工話術裡的一行。 類別早一點凍結，後加的類別，就按它實際的代價來對待。

受邀賓客是來確認的，不是來填表的

業務團隊已經提名了這個人，你就有他的姓名、公司、職位和電子郵件。再讓他打一遍，既失禮又慢，邀請常常死在這裡。

能用的做法：

# 預先載入提名名單
   ↓
# 賓客打開個人連結，或輸入姓名 + 電子郵件或電話
   ↓
# 和名單匹配
   ↓
# 把你已有的資訊給他看，請他改正不對的地方
   ↓
確認 → 發出門票

成不成，看兩件事。

用兩個欄位匹配，不用一個。 只靠姓名會撞車。姓名加電子郵件，或姓名加電話，實際夠用，也有足夠的容錯，讓人能順利通過。

先設計匹配不上的路徑，因為它會比你以為的更常用——助理替主管報名、有人用了私人電子郵件、業務把名字打錯了。匹配不上時，應該直接轉到一張簡短的申請表，並標成受邀，這樣審批知道這個人被提名過，不是陌生人。它絕不能停在「我們找不到您」。

兩輪，不是一輪

受控名單活動幾乎總是兩波，而且需要不同的入口。

第一輪——邀請。 預先載入的名單、個人連結、確認而不是填表，通常沒有審批步驟，因為姓名提交時審批已經發生過了。

第二輪——公開申請。 一個公開連結、一張完整表單、一條真正的審批隊伍。這些人對系統是陌生人，主辦方確實得做決定。

兩波走同一個入口，就是錯的。要麼讓受邀賓客去填申請表，要麼讓陌生人走受邀路徑進來。兩個入口、兩張表、兩套話術，底下是同一份參加者名單。

把來源留在紀錄上——哪個團隊提名的、哪一輪、哪個通路。報名時不費什麼，事後要回答「觀眾從哪來」，只有它能答。

審批是穿了技術外衣的組織問題

審批難的從來不是隊伍。難的是一個人得拒絕另一個人，而兩邊都有同事在看。

三個角色，不該是同一個人：

• 提名。 業務負責人或部門提交一個姓名。他們知道這個人為什麼重要。
• 覆核。 有人按標準核對這個姓名——是否為競爭對手、容量、職級、區域配額。這是事務性工作，可以很快。
• 裁定有爭議的個案。 一個小組，按日程開會，處理覆核定不了的那些。

實際能跑起來，靠這些：

• 報名開放前公布標準，哪怕只在內部。沒有書面標準的審批人會全部通過，房間裡就會坐滿不該來的觀眾。
• 每份申請設一個決定期限，因為待定的報名在效果上就是拒絕——賓客訂不了行程，最後也不再試。
• 兩頭都通知。 先是覆核中，然後是已決定。流程裡沒有消息，每位申請人都會打一通電話來問。
• 拒絕措辭集中寫一次。 不要讓每位審批人各自編一套。

還有一條能在當天救下報到台的規則：

被拒絕的賓客轉給主辦方，除此之外什麼都不說。

「您的報名未獲通過——您在公司的聯絡人可以再說明」就是全部話術。志工不知道原因。志工去猜原因，會把一個行政決定鬧成一場風波。

有些類別完全跳過報名——委員、志工、贊助商工作人員、供應商現場人員。按名單提前做好胸牌，活動前交出去，不要放進審批隊伍。他們不是申請人。

報名和付款是兩個狀態

協會和學術會議尤其如此：有相當一部分人報了名、沒有付款。他們打算付。他們忘了，或者在等部門預算，或者在手機上報了一半、想著稍後完成。

從一開始就把它們當成不同的狀態，並準備好三種人都會走到報到台：

單獨開一條付款通道，和報到分開。 理由和異常處理台一樣：一筆付款要好幾分鐘，報到通道吃不下。

實際的樣子：一台開著參加者名單的筆電，未付款的人幾秒內按姓名找到，而不是重新報名；一種在賓客自己手機上能完成的付款方式；以及一位專職做這件事的志工。然後他們回到報到隊伍——更好的是，付款通道把胸牌也發了。

現場報名是一條可以往前挪的隊伍。 入口處放一個明顯的報名碼，旁邊站一個人，讓人在排隊時就把表填完，而不是占著報到台。

折扣碼是歸因工具

公開售票的活動上，折扣碼是折扣。受控名單活動上，它主要是統計工具。

按團隊、區域或合作方各發一個不同的碼，每個碼有使用上限。事後你確切知道哪個團隊填滿了房間的哪一塊：

一個碼給不了你的，這裡有三樣。

• 責任清楚。 「你們團隊分到三百個座位，帶來了一百九十八個」是一場具體的談話。也是讓同一支團隊明年更用力的那個數字。
• 容量控制。 上限是玩真的。本來會把全場佔滿的那個區域，現在佔不滿。
• 提早預警。 距活動還有四週時某個碼幾乎沒人用，這是你還來得及處理的問題。同樣的資訊到活動前一週才看到，就只能寫進檢討了。

注意上面數字裡已報名和已通過之間的缺口。這很正常，而且因團隊而異。盯著它，你就知道哪些團隊提名謹慎，哪些只是交名單。

報名截止，報名並沒有結束

截止之後還有三件事在發生，每一件都會變成報到台的工作。

替換。 總監派了副手。這是企業活動上最常見的臨時變更，而且牽一髮動全身——胸牌、物料、房間、場次入場權限。事先決定誰可以批准替換，每一次都經過這個人。絕不能在報到台上當場同意替換，因為報到台看不到房間分配，也看不到場次權限。

臨時提名。 活動前四天臨時加進一位重要的人。為這種情況留一條不靠改試算表的路徑：一張簡短的內部表單、一位審批人、一張自動發出的票。

現場報名。 名單控得再緊，也會有人沒在名單上就到了。問題不是允不允許，而是誰在現場批、要多久。活動前指定這個人，讓他待在異常處理台附近。

你在線上決定的，就是報到台發生的

這條聯繫是直接的，值得從另一頭走一遍。

一位賓客走到報到台。志工一掃，螢幕上寫著：綠色掛繩、小禮品、不含住宿、第 1 場和第 3 場、晚宴第二波。志工遞出四樣東西，說一句話。十八秒。

這些事實裡的每一條，都是幾個月前寫在一筆報名紀錄裡的。票種對了，報到台就快。不對——類別是臨到頭才加的，或者權益從未對應到顏色，或者替換從未進系統——報到台就變成把這一切當場解決的地方，一位賓客一位賓客地來，後面的隊伍都看著。

報到台是報名決定最終接受檢驗的地方。 從那一刻倒推來設計。

實際會出什麼問題

事後這些資料值什麼

一場受控名單活動應該能回答三個問題；不事先決定把答案記下來，就回答不了：

• 誰填滿了房間？ 按提名團隊看報名，以及各隊的通過率。這是明年的座位分配。
• 人是在哪裡掉的？ 提名了卻從未報名，報名了卻從未通過，通過了卻從未付款，付了款卻沒到場。四個流失點，四種不同的改法。
• 來的是對的人嗎？ 按類別看到場情況，對照目標組合。人數達標、職級組成卻不對的會議，它的失敗被人數掩蓋了。

參加者資料是個人資料。開始之前就決定保留多久、誰可以匯出、贊助商拿到的是匯總人數還是姓名。

軟體真正幫得上的地方

四處。值得說精確，因為買任何一套系統之前——包括我們自己的——就拿它們去試：

• 預先載入的名單，加上確認流程。 讓賓客對上一筆他不必重打的紀錄，是受控名單報名裡對完成率提升最大的一件事。
• 審批是角色，不是某個人。 提名、覆核和裁定是不同的權限，並留下誰決定了什麼的稽核紀錄。
• 票種作為載體。 一筆紀錄裝下胸牌顏色、物料、用餐、住宿和場次入場權限，定了類型，下游就都定了。
• 帶上限和歸因的碼。 按團隊發的碼，既能限制，也能測量。

這一頁其餘的都是組織設計——誰提名、誰決定、對被你拒絕的人說什麼。沒有工具能替你決定這些。