南部某助農合作社 — 互助會智慧管理平台
把傳統紙本互助會 + 推廣組織 + 水產回饋打包成數位平台:會員/會首雙角色、競標/抽籤、線上繳費、收益試算器、5 級分潤組織、合約電簽 + 身分證 OCR 驗證——52 個功能模組一套搞定。
- 客戶
- 互助會智慧管理平台
- 產業
- 其他
- 服務
- 客製化網頁與 App

交付了什麼。
- 功能模組
- 52 項(盤點 2026-05-21)
- 雙角色
- 會員 / 會首 右上一鍵切換
- 繳費通道
- 現金 / 轉帳 / LINE Pay / 信用卡
- 推廣組織
- 5 級分潤 + 收益試算器
- 功能盤點
- 52 模組(32 已實作/11 部分/9 待補,盤點 2026-05-21)
01這案的本質
台灣中南部還有不少「互助會 + 共同採購 + 推廣組織」混合型的合作社——會員多半是農戶、漁民、傳統產業中小企業老闆,靠紙本表格、會首口頭通知、紙條對帳跑了幾十年。
這客戶找我們是想做一件事:把整套運作數位化,但不能讓不會用 App 的會員退會。

02為什麼這比想像難
如果只是「把紙本搬上網」,外包誰都能做。難的是:
- 會員角色與會首角色完全不同視角——同一個人某些會期是「跟著會」的會員、某些是自己「起會」的會首,UI 要能一鍵切換而不混淆
- 互助會本身就有兩種制度——「競標制」(每期出標金最高者得)與「抽籤制」(隨機抽),同一個平台要同時支援
- 推廣組織分潤要可解釋——5 級制(最底層→最高層),A/B 兩條線、累積會數決定升等,會員隨時要查得到「我下線多少、離下一級差幾會、這個月我可拿多少分潤」
- 農產品回饋要對到 SKU——傳統互助會繳費後拿現金,這套要能繳費後改拿等值的水產 / 農產品 SKU,平台要管庫存對帳
- 法規線——身分證 OCR、合約電簽、誠信切結都是規避「假人頭會員」與「斷會跑路」的合規動作
52 個功能模組裡有 32 個已實作、11 個部分實作、9 個待補(盤點 2026-05-21)。每一個都按 P0/P1/P2 排優先。

03我們交的東西
1. 會員 / 會首 雙視角
右上角一鍵切換。同一個 auth session,兩套路由:
- 會員路徑:
/dashboard(收支時間軸 + 會期損益)/sessions/:id(逐期明細 + 繳費 + 競標)/rewards(推廣等級)/seafood(農產品兌換)/contracts(合約簽署)/reports - 會首路徑:
/manager/*(dashboard / members / activation / bidding / seafood / contracts / settings / lottery)
會員只看到自己的會、會首看到全會務。但因為平台支援「同一人既是會員也是會首」,切換不能登出再登入——是同一個 session 內的視角切換。
2. 競標制 + 抽籤制 + 收益試算器
競標:每期會員出標、最高者得標。系統自動算「得標可領金額」、自動限制標金合理範圍(避免亂出價)。
抽籤:每期隨機抽。
收益試算器:會員入會前先試算——「1 人 24 會」「2 人合湊」「3 人合湊」各種參與方式下的入會成本、每期回饋、預估總收益。完全對應客戶手上的紙本試算表,但即時可調。
3. 5 級分潤 + 推廣組織
每個會員都看得到:
- 自己等級(從底層級到頂層級的 5 階分級制)
- 下線累積會數(例:57 會)
- 離下一級差多少會(例:差 43 會)
- 自己的 A 線、B 線下線清單
- 即時分潤試算(每位下線的當期會錢按比例算進你的回饋)
會首後台可以看到全體會員的推廣樹狀圖、強制升降級、調整分潤比例。
4. 線上繳費 4 通道 + 自動對帳
- 現金(會首手動標記)
- 銀行轉帳(會員填末五碼,會首手動對帳)
- LINE Pay(自動回填)
- 信用卡(PAYUNi 串接,自動回填)
每筆繳費寫入會員繳費紀錄、自動觸發 LINE 通知(透過 line-notify edge function)。會首後台「未繳清單」一頁看完誰沒繳。
5. 農產品回饋(水產 SKU 對 SKU)
會員可以選擇:繳費後拿現金 / 改拿等值農產品 SKU。後台「seafood」模組對到客戶實際的水產供應鏈,每月固定循環。
6. 合規動作:身分證 OCR + 合約電簽 + 誠信切結
- 身分證 OCR:edge function
ocr-id-card處理(避開隱私風險,OCR 結果不存原圖) - 合約電簽:
SignatureCanvas元件 + 後台合約模板 - 誠信切結:所有會員領取「最高級分潤資格」前必簽
這些都是規避「假人頭」「跑路」「分潤糾紛」的法務線。

04我們做事的方式
上線後 DEMO 客戶實際跑過一輪,回饋 52 項需求清單。我們做的是:
- 把 52 項按 P0(金流 / 法規 / 核心)/ P1(正式上線必補)/ P2(可延後)三級排序
- 每兩天一個批次(A / B / C / D / E)按 commit 推進,每個批次都有對應 commit hash 與 migration 號
- 過程中遇到設計衝突(例如「誠信切結是否要後台開通制」會切斷現有 MLM 分潤資格)會主動暫緩、寫成 TASK_BREAKDOWN 文件再與客戶釐清
這套 review → batch → 暫緩有衝突 → 釐清再上的 cycle,是我們做這種高合規 + 多分支業務需求的標準流程。

05為什麼這案不公開客戶名
互助會 + 推廣組織這個 vertical 在台灣有合規敏感度(涉及金管會「銀行法」對民間互助會的監理灰色地帶),客戶 + 川輝雙方都同意:對外只揭露『南部某助農合作社』,不揭露具體商號。
揭露的是 know-how,不是客戶身份。

06結論
互助會看似是傳產老梗,但「會員不擅長 App + 法規線 + 多角色 + 多分潤層 + 多繳費通道 + 農產供應鏈 + 合約電簽」這套全打包的系統,市面沒有。我們蓋出來了。
我們的會員多半是農戶——年紀偏大、不太會用 App,但對自己的會錢一毛都不能糊塗。川輝沒給我們一套漂亮但難用的系統,是真的把每一頁都做到「我阿公也看得懂」。

