Brightstream Logo
案例客製化系統

2026 台東博覽會 × 食品商會 — 東博限定便當集點抽獎平台

兩個月限定活動(2026/06/05–08/05)的完整活動科技平台:消費者 LIFF + PWA 集點/刮刮樂、商家後台、主辦方 15 模組 CMS、直播大抽獎——206 家合作便當店共同打底。

🐻
熊董|Johnny Yang
本案主導 · 川輝科技創辦人
2026 台東博覽會 × 食品商會 — 東博限定便當集點抽獎平台

為什麼這案值得寫

大型限定活動(縣市級博覽會、節慶、商會聯辦促銷)有個結構性問題:活動只跑兩個月,但要承擔的法規 / 報表 / 公平性責任跟年度系統一樣重,沒有時間做傳統 ERP 開發週期

這案的主辦方 2026 台東博覽會 × 食品商會找上我們,要的是:消費者端進得來、商家端核銷得了、主辦方端報表查得到、抽獎公平可稽核——而且 6/5 一定要上線。

活動首頁:東博限定便當山海大宴 + 最新資訊 + 集點入口(消費者 LIFF / PWA 雙模)
活動首頁:東博限定便當山海大宴 + 最新資訊 + 集點入口(消費者 LIFF / PWA 雙模)

我們交的東西:三端完整架構

1. 消費者端(LIFF + PWA)

消費者打開 LINE,加官方好友 → 進 LIFF → 自動 LINE Login → 進入個人帳戶。要不是 LINE 的人也能用 PWA 模式(瀏覽器 + manifest),iOS / Android 都可加到主畫面。

  • 首頁:活動 Hero(東博限定便當山海大宴)+ 最新資訊 + 集點進度
  • 掃碼集點:用 LINE 掃店家 QR 集點,後端寫入點數紀錄
  • 便當序號兌換:購買特定便當盒上印有序號,App 內輸入兌點
  • 刮刮樂:累積點數兌換刮獎機會,含 canvas-confetti 中獎特效
  • 直播抽獎:在大獎場次直播時段,消費者打開「直播抽獎」頁,跟著主辦方同步抽出大獎
  • 獎品中心:得獎清單、領獎流程、核銷狀態
  • 我的帳戶:點數 / 兌換紀錄 / 中獎紀錄

2. 商家端(206 家便當店)

每家便當店有自己的後台:

  • 登入後直接看到自家儀表板(今日核銷數、本月集點貢獻、序號餘量)
  • 核銷消費者來兌獎的 QR
  • 看自家序號池狀態

206 家 同時上線運作,每家的 LINE 通知獨立、序號池獨立、報表獨立。這種多商家架構不是 SaaS 套版可以扛的。

3. 主辦方端(15 模組 CMS)

這是 case 的真正重心。主辦方要在兩個月內把整個活動跑起來,需要的後台模組是:

  1. 登入後台
  2. 儀表板:活動整體數據(今日參與、累積點數、得獎人數、店家分布)
  3. 活動設定:起訖時間、規則文案、條款版本
  4. 會員管理:所有 LINE 消費者池、可手動調整點數、可標記異常帳號
  5. 店家管理:206 家店家的開通 / 停權 / 序號分配
  6. 獎項管理:獎品種類(電子券 / 實體獎 / 現場兌換)+ 名額 + 機率
  7. 序號管理:每家店家配發的便當序號池(防偽 + 防重複兌換)
  8. 抽獎管理:場次設定 / 排程 / 中獎名單匯出
  9. 直播大螢幕:抽獎時段現場直播畫面(給活動主場用)
  10. 獎品核銷:得獎人 → 領獎 → 商家核銷的閉環追蹤
  11. 最新資訊:活動公告、新聞稿
  12. 常見問題:FAQ 可後台改
  13. 地圖鎖點:206 家店家在地圖上的位置 PIN(消費者用)
  14. 通知紀錄:每筆 LINE 推播的稽核紀錄
  15. 報表中心:活動結算用的全部報表(給縣府 / 商會 / 會計用)
直播大抽獎:場次設定 + 中獎編號公開 + 得獎名單即時更新(公平性可稽核設計)
直播大抽獎:場次設定 + 中獎編號公開 + 得獎名單即時更新(公平性可稽核設計)

為什麼這案技術上不簡單

大部分人看「集點 + 抽獎活動」會以為是「拉個 App + 一張 promo 頁就好」。實際上這套 stack 要解決的問題:

  • 公平性可稽核:每一次抽獎都要可重現、可審計(用 hash chain 保證抽中編號不能事後改)
  • 序號防偽 + 防重複:206 家便當店各自配發序號,序號設計要能防一張被兌兩次、防仿造、防員工內部洩漏
  • 流量瞬間爆衝:直播抽獎那一刻所有人同時打開頁面,後端要扛 spike(Supabase Edge Function 自動 scale,pgvector 與 RPC 提前最佳化)
  • LIFF + PWA 雙模:要支援用 LINE 的人 + 不用 LINE 的人(PWA 模式靠 manifest + service worker)
  • 第三方主辦關係:縣府 / 商會 / 食品產業協會各自有審核流程,後台要能匯出他們各自要的報表格式
操作手冊:管理員 15 章 / 商家 2 章 / 使用者 8 章——三角色分別寫,連 PDF 匯出都做好
操作手冊:管理員 15 章 / 商家 2 章 / 使用者 8 章——三角色分別寫,連 PDF 匯出都做好

我們做事的方式

兩個月的活動 = 沒有第二輪開發的機會。我們上線前先做:

  1. 三端 demo 環境 提早給主辦方審:管理員看 dashboard、商家試核銷、消費者走完一遍集點→抽獎→領獎
  2. 15 模組逐項驗收 才上 prod
  3. 完整操作手冊 三角色分別寫(管理員 15 章、商家 2 章、使用者 8 章)— 連 PDF 匯出都做好,新進主辦人員拿到手就能上手
  4. 直播大抽獎 開跑前 7 天先排演兩次(萬人同時湧入的壓測 + 主場大螢幕對接)

這套「demo 環境 → 逐項驗收 → 完整手冊 → 上線前演練」的 cycle,是我們做活動科技類客戶的標準作法。客戶會走、活動會結束,但出狀況的名字會留在新聞裡——我們不能讓客戶承擔這個風險。

為什麼這案證明川輝可以接縣市級活動

2026 年 6 月起這套系統承擔的是:縣府主辦活動、食品商會聯合、206 家便當店共同參與、預期數萬名消費者、跨越兩個月。

如果這套跑得起來,川輝就證明了——我們可以接縣市級 / 商會級 / 跨組織活動的活動科技平台。這是接案規模從「單一企業客戶」躍升到「公私協力專案」的關鍵 case。

之後其他縣市的食品節、農產博覽會、節慶限定活動,我們有直接 transfer 的 know-how。

認識熊董 →

In the Client's Words· 客戶的話

活動只跑兩個月,但會計報表、店家核銷、消費者爭議、抽獎公平性——任何一個環節炸了都會上新聞。我們要的不是漂亮的 App,是一套能在兩個月內承擔縣級活動規模的系統。川輝是少數能把主辦方/商家/消費者三端做完整、又能在兩個月內準時上線的合作對象。

2026 台東博覽會 × 食品商會
Bear's Note · 熊董的話

這個案子背後的判斷。

每個案子背後都有一個我做出來的判斷——通常是「這條路該走」跟「這條路不該走」的取捨。 這篇 case study 寫的是結果,但背後的判斷力,比結果更值錢。

如果你在想「這個案子如果換成我,我該怎麼做」——那正是一日流程診斷該做的事。 我會把這個案子的關鍵判斷,套到你的生意上、給你一張屬於你自己的路徑圖。

🐻
熊董|Johnny Yang
川輝科技創辦人 · 本案主導
System Screenshots · 案場照/系統截圖

畫面展示。

活動首頁:東博限定便當山海大宴 + 最新資訊 + 集點入口(消費者 LIFF / PWA 雙模)

活動首頁:東博限定便當山海大宴 + 最新資訊 + 集點入口(消費者 LIFF / PWA 雙模)

直播大抽獎:場次設定 + 中獎編號公開 + 得獎名單即時更新(公平性可稽核設計)

直播大抽獎:場次設定 + 中獎編號公開 + 得獎名單即時更新(公平性可稽核設計)

操作手冊:管理員 15 章 / 商家 2 章 / 使用者 8 章——三角色分別寫,連 PDF 匯出都做好

操作手冊:管理員 15 章 / 商家 2 章 / 使用者 8 章——三角色分別寫,連 PDF 匯出都做好

Your Case Could Be Next· 下一個案例

想加入這個列表?
從一日診斷開始。