試算表什麼時候開始不夠用
稿件只有幾十篇時，Google 表單加一張試算表就很夠用。稿件一多，麻煩會從幾個地方冒出來：同一篇稿件要給不同的人看，狀態分散在不同分頁；同一天被排了兩篇；該寄的通知信要有人記得寄。
存在日曆每年要徵集 365 個故事，每一天放一篇。過去這件事靠 23 個 Google Sheets 和手寄通知信，一屆累積數百小時人工。冠球彩色印刷把流程交給我們做成編輯部專用的後台之後，投稿、審稿、排程、製稿到出貨都在同一套系統完成。
你的活動出現下面這幾種情況，就可以開始評估系統：
- 同一份資料要複製到兩張以上的表
- 有人專門負責提醒別人稿件審到哪裡
- 通知信漏寄或寄錯過
- 想知道總進度，要打開好幾個檔案才算得出來
投稿頁：步驟越少，寫的人越願意寫完
投稿的人大多用手機，而且只來一次。共編曆的活動官網把投稿做成三個步驟，填故事、傳照片，再用 Email 驗證。廣告期間每天收到 14 到 24 篇投稿，累計超過 700 篇。
規劃投稿頁時，先把欄位分成兩堆。審稿一定要用到的放進表單，其他的等稿件入選再問，第一關的填寫負擔就小很多。
照片要另外想。手機拍的照片檔案很大，上傳要有進度顯示，失敗時要能重傳，系統也要壓一份小圖給後台預覽，編輯部打開列表才不用等。
審稿：先把稿件狀態定清楚
後台開工前，最該先討論的是稿件有哪些狀態。常見的有待審、要修改、通過、已排入日期、已製稿，共編曆用了九種狀態。每一種狀態要寫清楚三件事：誰可以改它、改完下一步是什麼、要不要寄信。
狀態定好，權限也就出來了。初審的人看自己負責的稿件，總編看全部並做最後決定。這件事用試算表很難做到，拿到連結的人通常都改得到別人的欄位。
往返紀錄也要留在系統裡。退回修改的原因寫在稿件上，下一位審稿的人不用重新問一次。
排程：撞期交給系統先抓出來
存在日曆的每一天只放一個故事，稿件一多就會撞期。共編曆後台有一張 365 天的排程日曆，12 個月的方格顯示每一天的狀態，編輯一眼看得出哪幾天還空著、哪幾天擠了太多稿件。
撞期的處理我們加了一個 AI 衝突仲裁官。它自動偵測撞期並推薦裁決，最後由編輯部決定。AI 負責把選項整理好，省下編輯逐篇比對的時間。
通知信：每一種狀態對應一封信
手寄通知最容易出錯，稿件一多就會漏。共編曆把七種通知信改成自動寄出，狀態一變，信就送到投稿者手上。
做這一段要注意寄信網域的設定。大量寄信之前，SPF、DKIM 要先設定好，否則信很容易進垃圾信匣。
製稿與出貨：資料要能匯出
審稿結束後，資料要交給排版和印刷。共編曆的後台可以把製稿資料匯出成 Excel，編輯不用再一篇一篇複製。規劃時先問清楚下游要什麼格式，欄位順序和圖片命名都先定好，上線後會省很多來回。
這套系統合約 23 項全數驗收，另外多做 11 項，編輯部單月有 1,400 筆後台操作。舊資料怎麼搬進來，可以看這篇從 Excel 搬資料的做法。
開工前要準備的東西
需求訪談時有這幾樣資料，討論會快很多，報價也比較準：
- 一張現在的流程圖，手畫也可以，寫出稿件從投稿到出貨經過誰
- 投稿表單現有的欄位，以及哪些欄位審稿真的會用到
- 審稿的評分或判斷標準，有幾個人審、誰有最後決定權
- 每一封通知信的文字，包含入選、未入選和要修改
- 下游要的檔案格式，例如排版用的 Excel 欄位與圖片尺寸
- 過去幾屆的資料要不要搬進來，或是從新的一屆開始
時程也要倒著排。徵稿開始的日期通常是死線，系統要提前上線測試，投稿頁至少要讓幾位編輯用手機實際投一次，通知信也要寄到不同信箱確認有收到。金流或募資頁如果要一起上線，審核時間要另外算。
你的活動需要一套系統嗎
一次性的活動、稿件在一百篇以內、只有一兩個人審，表單加試算表就夠了，預算留給活動本身。每年都要辦、稿件上百篇、有多人一起審，或者要自動寄信和排程，做一套系統比較划算，第二年起可以沿用。
想確認你的活動適合哪一種，可以在 LINE 傳一段你們現在的流程，或一張試算表的截圖給我們，個資先遮起來。30 分鐘需求訪談不收費，費用怎麼估可以先看這篇。
相關服務與案例：冠球彩色印刷共編曆後台徵稿系統案例、客製系統開發