背景
Zeabur 是面向 vibe coder 與工程師的雲端部署平台。作為成長策略的一部分，團隊提供贊助碼，讓合作夥伴在活動中發放，讓參與者取得額度來使用平台。
每週有 10 多位合作夥伴，透過 LINE、Discord 等不同管道向團隊提出請求。行銷團隊每週花費 3–5 小時，人工協調請求與校對資訊。
資料散落在不同對話與平台，很難維持一致、結構化的紀錄。這套流程高度依賴人工，難以持續運作，也更難追蹤夥伴成效與轉換，作為成長規劃的依據。
任務
任務是將零散的夥伴請求轉成自助流程，先從活動贊助碼開始。不同利害關係人的情境與待完成任務並不相同：
- 對夥伴而言，需要一個集中的地方提交活動資料、取得贊助碼，並查看狀態與成效。
- 對團隊而言，需要收集與既有管理系統一致的資訊，減少重複輸入與來回確認，並將每組贊助碼連結到對應夥伴，以便追蹤兌換及付費轉換。
範圍也必須是能夠實際建置與維護的。因此先處理活動贊助碼，禮券購買、成交佣金與提款則暫緩。預期價值依當時的夥伴規模與獲客成效初估，再與建置及持續支援服務所需的人力投入衡量。
回顧整理的 ITIL 盤點，檢視持續維護所需的投入。
行動
盤點既有系統
我先整理既有的合作機制與底層資料流，涵蓋推薦碼、活動贊助碼、禮卡及銷售佣金。這讓夥伴活動、使用者歸因與獎勵追蹤之間的缺口，以及仍依賴人工協調的步驟浮現。
這份圖幫助我定義 Portal 需要串連的資料：夥伴身分、請求、代碼與成效紀錄，也協助我決定讓第一版原型聚焦在活動贊助流程。
Existing system and attribution gaps
Referral Code ──→ User attribution ──→ Automated commission tracking
Event Code ──→ Credit top-up ──→ Admin performance dashboard
└── Missing link to the originating partner
Gift Card ──→ Credit top-up
└── No attribution to the selling partner
Sales Commission ──→ Manual processing
└── No integrated tracking system
建立第一版原型
我將系統圖轉成活動贊助原型，把夥伴請求與代碼管理整合在同一個介面。為了維持技術架構的一致性，系統沿用 Zeabur 既有的登入與贊助基礎設施，沒有另外建立驗證機制或重複的代碼資料庫。首版範圍聚焦活動贊助碼，讓建置與支援工作維持在可掌握的規模。
目前版本的 Portal，使用示範資料；並非第一版原型的歷史截圖。
迭代流程原型
隨著流程原型逐步成形，我在觀察同事試用時，發現另外 2 個需要調整的情境：
- 我們需要獨立的資料庫，保存合作夥伴資訊。
- 與主要使用者資料庫隔離，只保留單向讀取權限供驗證使用。
- 不應儲存敏感的使用者資訊，只留下申請所需的資料。
- 申請者需要編輯與草稿模式，避免誤送，也需要資料庫儲存這些資料。
- 只有有效的提交內容會被解析並送入主系統。
- 需要考量多次提交的請求頻率限制。
- 例外處理應另外管理。
比較幾種資料庫選項後，我選擇 MongoDB。Mongo 的 collection 設計能讓申請與審核紀錄分開儲存，同時留在同一個地方管理。
對齊自助流程與內部控管
上線後，CEO 與營運主管對一筆他們未掌握的贊助申請提出疑慮。我提供夥伴的申請紀錄與既有 wiki 準則，重新表述問題，並釐清他們在意的是申請金額，還是流程的透明度。這次討論揭露了減少人工協調與掌握贊助額度之間的矛盾。
我調閱 6 個月的申請紀錄，對照服務藍圖與使用者旅程，提出對超過約定門檻的申請增加審核步驟，並搭配每月自動報告。這讓利害關係人有具體方案可以討論，在夥伴自主操作與內部監督之間取得平衡。
與利害關係人對齊方案後，我親自完成端到端修改，並自動將報告送到 Discord，讓團隊定期掌握夥伴活動。
成果
從純人工流程，到系統原型，最後成為一套能運作的系統。Portal 將散落在對話中的工作流程，轉成實際運作的自助平台。
夥伴可以在同一個地方提交活動資料並取得贊助碼，減少與行銷團隊反覆協調。結構化的申請紀錄與內部看板讓請求更容易追蹤，自動化 Discord 報告則讓團隊定期掌握夥伴活動。
反思
現在建系統實在太容易了。有各種 vibe coding 工具，15 分鐘就能建出一個網站。在科技新創工作、身邊都是開發者，也特別推著我去學工程知識；但從系統迭代與團隊協調中，我學到很重要的一件事：事前辨識問題根因，才是最必要的工作。
從實際工作流程出發建系統，一步步解決摩擦。提問，挖出真正的需求；用工具呈現、對齊理解。避免脫離情境去建系統！