概述
Portaly 原有的贊助功能以單筆交易為主，粉絲每次支持都要重新操作，創作者也無法預期下個月的收入。本專案主導每月定額贊助從 0 到 1 的規劃與上線：付款一旦從「一次」變成「每月」，這筆交易就從事件變成關係，因此真正要定義的不是一個付款介面，而是一組橫跨前台、後台、金流與信件的訂閱狀態系統。上線首月，每月定額贊助即占當月總贊助營收約 36%。
主要成果
- 完成定期贊助 0→1 上線：涵蓋創作者設定、粉絲付款、訂閱管理、退款與例外處理、雙邊通知的完整通路。
- 定義訂閱狀態與業務規則：釐清續扣、主動取消、創作者取消、付款失敗、定期退款五種情境下的狀態轉換、金流行為與通知對象，成為團隊對齊的依據。
- 建立創作者的支持者經營工具：定期名單支援狀態、累計金額、取消原因與匯出，讓長期支持者成為可經營的對象。
- 商業成效：上線首月，每月定額贊助即占當月總贊助營收約 36%。
角色與貢獻
- 需求與規格：盤點既有流程與定期扣款影響範圍，完成 PRD、業務規則與例外情境定義。
- 功能設計：規劃創作者設定、贊助者付款與後台管理等端到端流程，並完成介面與通知設計。
- 功能測試：撰寫測試案例，進行 E2E 測試。
- 跨部門協作：協調前後端、金流與營運，確認技術可行性、交易狀態與客服情境。
- 成效驗證：追蹤上線後贊助金額與使用狀況，評估功能商業成效。
專案執行摘要
| 項目 | 內容 |
|---|---|
| 目標 | 把一次性贊助擴展為每月自動扣款，建立創作者可持續的收入來源 |
| 現況 | 原有產品僅支援單筆付款；每次支持都需重新操作，平台也缺乏管理長期支持關係的機制 |
| 核心策略 | 保留單筆贊助，另外建立完整的訂閱生命週期；先定義跨前台、後台、金流與通知的狀態與規則，再設計介面 |
| 實際成效 | 完成 0→1 上線；上線首月，每月定額贊助即占當月總贊助營收約 36% |
| 下一步 | 付款失敗重試機制、續扣留存指標、方案與權益分級 |
為什麼要做
Portaly 是創作者的個人頁面與變現工具。原有的贊助功能以單筆贊助為主：粉絲進到創作者頁面、輸入金額、留言、付款，關係就結束了。這個模式在三個層面都碰到天花板：
粉絲端
支持無法變成習慣。每一次支持都是一次獨立決策。想長期支持一位創作者，必須重複進站、重複填資料、重複付款——意願存在，但摩擦讓它無法延續。
創作者端
收入不可預期。無法知道下個月會有多少贊助；即使平台已提供單筆贊助名單工具，也較難經營「長期支持者」這個族群。
平台端
抽成結構受限。一次性斗內對平台的抽成收入較不穩定。且當時台灣的 Link-in-bio 平台，較少能支援本地金流的每月定額贊助。
補充的競品分析 競品盤點 · 三個假設 · 定位矩陣
此專案為決策者於內部開發會議提出的需求，當時並未有參考的數據依據，但我後續根據當時的市場狀況做競品分析，嘗試理解此決定的商業脈絡。
分組方式：依 Jobs-to-be-done，而非產品類別
兩組競品的威脅方式與防守方式完全不同，因此分開盤點。
A 組｜解決同一個問題：讓創作者取得可預期的定期收入
只保留三個真正影響決策的維度：
| 競品 | 開通門檻 | 關係綁定在 | 台灣金流／發票 |
|---|---|---|---|
| YouTube 頻道會員 | YPP 門檻（1,000 訂閱＋4,000 小時，或 Shorts 1,000 萬次） | YouTube 帳號 | ✕ |
| Twitch 訂閱 | Affiliate／Partner 門檻 | Twitch 帳號 | 需外掛歐付寶／綠界 |
| 方格子 vocus 訂閱制 | 無 | 站內內容庫 | ✅ |
| Patreon | 無 | Patreon 帳號 | ✕ |
| Ko-fi ／ Buy Me a Coffee | 無 | 各自平台頁 | ✕ |
| Linktree Subscriptions | 無 | 創作者自有頁 | ✕ |
| Portaly（當時） | 無 | 創作者自有頁 | ✅ |
抽成參考：YouTube 30%／Twitch 50%（頂級可談 70/30）／Linktree 9–12%／Patreon 5–12%＋金流費／Ko-fi・BMC 5%／Portaly 12%（免費）・6%（頂級）。
→ 盤點下來，A 組裡真正的直接競品只有 Linktree。其餘全屬「內容平台內建」或「純會員制平台」，入口邏輯與 link-in-bio 不同。
B 組｜能替代我們的方案
- 搶粉絲的同一筆每月預算（零和）：PressPlay（課程與內容訂閱）、Firstory（Podcast 贊助）、Substack（電子報訂閱）。粉絲每月能穩定給出去的錢有上限。
- 創作者用別的方式達成「收入可預期」：業配長約、團購與聯盟分潤、數位商品重複銷售、線上課程——包含我們自家的單筆贊助。「反正每月都有人斗內」在創作者體感上也是一種收入預期，新功能得先跟舊功能競爭注意力。
三個假設
| 共同假設 | 沒有人問的問題 |
|---|---|
| ① 定期支持必須綁定「權益」才成立 YouTube 給徽章與專屬表情、Patreon 以 tier ＋ perks 為產品哲學、vocus 綁付費內容、Ko-fi 也是 tiered content |
粉絲每月付錢，是為了拿到那些東西，還是為了讓創作者知道自己在？權益可能是產品做出來的解釋，而非行為的真實動機。一旦接受此前提，就必須建內容牆與存取控制，同時把創作者門檻拉高（得先產出專屬內容才能開通）。 |
| ② 定期支持是粉絲單方向的自動扣款，創作者是被動收款方 所有平台皆為「粉絲設定 → 系統扣款 → 創作者看報表」 |
若訂閱最脆弱的時刻是「粉絲忘了自己為什麼還在付」，產品該做的是不是讓創作者有能力維繫關係，而非把扣款做得更順？ |
| ③ 這個機制屬於「創作者的內容所在地」 在哪裡發內容，就在哪裡收訂閱 |
中小型創作者已是跨平台經營（IG、YouTube、Podcast、電子報），受眾分散但支持關係被綁在單一平台，等於每換一次主戰場就要重建一次金主名單。 |
最值得打破的假設：① 權益綁定
假設 ③ 已被 link-in-bio 的形態天生打破，但非我們獨有（Linktree 相同）——那是資格，不是差異化。假設 ② 值得做，但屬第二步：要經營支持者，得先有支持者。假設 ① 是唯一一個打破後能同時降低雙邊門檻的假設。
打破後打開的三層機會：
- 創作者開通門檻降到近乎零——不需預先設計三個方案分別給什麼權益。這正是大量 Patreon 帳號開了卻從未上線的主因。可直接命中「未達 YouTube 門檻、主力在 IG／Podcast」的中小型創作者。
- 產品重心從「內容牆」轉向「關係的可見度」——若訂閱本質是身分而非商品，該做的不是存取控制，而是讓支持被看見：支持者名單、連續支持月數、一鍵感謝、可辨識標記。工程複雜度遠低於權益系統，卻打到真實動機。
- 反向解鎖假設 ②——關係不綁內容後，創作者手上出現一份可攜的長期支持者名單，可據此做後續經營。
此機會是否成立，取決於「粉絲付費動機是身分而非權益」是否為真。應視為待驗證假設而非結論。可驗證指標：無權益版本的第二次續扣率與第 2 月留存、以及粉絲對「為什麼支持」的歸因分布。
定位矩陣
選軸標準：既能區分現有玩家，且為結構性、對手短期難以移動的維度。（「單次 vs 定期」在功能補上後即失效；「抽成高低」可被價格戰複製，皆不採用。）
- X 軸｜支持關係留在哪裡：左邊是綁在平台帳號裡，右邊則偏向由創作者自己掌握。像 YouTube、Twitch 的會員機制本來就是平台生態的一部分，不太可能往另一端移動。
- Y 軸｜使用者為什麼願意持續支持：上方偏向「為了內容、會員身分或專屬權益付費」，下方偏向「想持續支持這個創作者，並維持長期連結」。
從這張圖可以看到，目前比較少產品同時做到：開通門檻低、支持關係掌握在創作者手上、不需要額外做會員內容，同時又支援台灣金流與電子發票。
這個位置之所以還有空間，不只是因為「目前沒什麼人做」：
- YouTube、Twitch 不太會往這裡走：他們的會員功能本來就希望把創作者和支持者留在平台內，不太可能主動把這段關係交還給創作者。
- Patreon、Ko-fi 這類海外產品要進台灣有成本：除了介面語言，還需要處理台灣金流、電子發票等在地需求，未必會優先為台灣市場投入。
- Linktree 是比較接近的競品：產品方向已經很接近「創作者自己的支持入口」，若未來補齊台灣金流與在地需求，就會成為最需要持續關注的對手。
→ 這次盤點讓我確認兩件事：第一，市場上的一次性支持與定期支持通常是並存而非互相取代，因此第一版保留單筆贊助；第二，Portaly 在「創作者自己掌握支持關係＋台灣在地金流」這個位置上，當時仍有差異化空間。
參考資料
問題定義
要解決的問題
- 如何在不破壞既有單筆贊助體驗的前提下，加入每月自動扣款？
- 如何讓創作者與贊助者在任何時刻都清楚知道「我現在是什麼狀態、接下來會發生什麼、我可以怎麼改變它」？
- 訂閱關係會產生退款、取消、扣款失敗等例外，如何避免不同系統之間出現狀態矛盾？
專案目標
- 上線每月自動扣款的定額贊助，並與單筆贊助並存
- 提供創作者可設定、可預覽、可管理支持者名單的完整工具
- 定義所有訂閱狀態的轉換條件與對應的金流、後台、信件行為
- 讓贊助者能自助查詢與取消訂閱
→ 核心命題：付款從「一次」變成「每月」，這筆交易就從事件變成關係。要定義的不只付款介面，還有一組會被雙方各自操作、且必須跨系統保持一致的狀態系統。
系統架構與業務規則
需求最初只有「在贊助頁新增每月贊助選項」，但實際上會牽動付款、訂閱狀態、名單管理與通知等多個環節，因此我先盤點完整服務流程與影響範圍，再進一步定義各情境下的功能與狀態。
系統架構圖
在整理系統架構與各端流程的過程中，我也進一步確認了兩個需要一併納入規格的重點：
| 判斷 | 理由 |
|---|---|
| 訂閱狀態是跨頁面共享資料 | 同一個訂閱狀態會同時出現在贊助者管理頁、創作者名單、金流管理、信件與社群資格。任何一方的操作都必須推導出其他四處的變化。 |
| 設計功能時也必須一併設計信件 | 訂閱是一段使用者大部分時間都不在產品裡的關係，加上贊助者無須註冊 Portaly 也能完成定額贊助，因此不能只依賴站內會員中心管理。交易信除了讓使用者感知付款、續扣等訂閱狀態，也承擔後續管理入口，讓贊助者能查看定額資訊並進行取消。因此信件從一開始就被納入產品流程與規格。 |
訂閱生命週期與狀態轉換
每月定額贊助並不是一次性的流程。隨著續扣、取消、付款失敗或退款，訂閱狀態會持續改變，也會連動前台、後台、金流與通知。因此先把各種訂閱狀態與轉換規則定義清楚，方便和團隊溝通，並撰寫規則表放入 PRD。
業務規則表
| 情境 | 是否退款 | 是否終止訂閱 | 創作者端 | 贊助者端 | 通知 |
|---|---|---|---|---|---|
| 正常續扣 | — | 否 | 累計金額／次數更新 | 維持訂閱中 | 扣款成功通知 |
| 贊助者主動取消 | 否 | 是 | 狀態改為已取消 | 下期不再扣款 | 雙方取消通知 |
| 創作者取消訂閱 | 否 | 是 | 狀態改為已取消 | 下期不再扣款 | 贊助者取消通知 |
| 信用卡付款失敗 | 否 | 是 | 狀態改為已取消 | 訂閱終止 | 付款失敗＋取消通知 |
| 創作者執行定期贊助退款 | 是 | 是 | 退款並終止訂閱，3–5 分鐘內更新 | 收到退款、訂閱終止 | 退款＋取消（兩封） |
| 創作者關閉每月定額贊助功能 | 否 | 否 | 前台不再顯示入口，既有訂閱不變 | 不受影響 | 無 |
| 單筆贊助退款 | 是 | 不適用 | 維持原流程 | 收到退款 | 一般退款通知 |
範圍取捨
確認流程與規則後，我再進一步收斂第一版範圍。原有的單筆贊助先保留，定期贊助則以「完成基本訂閱流程」為優先，避免第一版加入過多金流與會員機制。
| 第一版納入 | 暫不納入第一版 |
|---|---|
| 創作者：開關定額贊助、設定金額與文案、自訂金額、前台預覽 | 更換卡號：需增加金流驗證流程，使用頻率相對較低 |
| 贊助者：選擇定額、首次付款、透過交易信查看訂閱、自助取消 | 修改發票資訊：涉及額外稅務與驗證流程 |
| 後台：定期名單、訂閱狀態、累計金額、次數、取消原因、匯出與退款 | 方案與權益分級：需額外處理權益發放與存取控制 |
| 系統：每月續扣、狀態同步與雙邊通知 | 付款失敗重試／寬限期：第一版先採付款失敗即終止，降低狀態複雜度 |
| 年繳與折扣：會增加付款與退款規則，暫不納入 |
其中，自助取消被列為第一版必要功能。定期付款除了要能開始，也必須讓贊助者知道目前的訂閱狀態，並能自行停止後續扣款；至於換卡、權益分級等進階管理功能，則留到後續版本。
最大挑戰：退款不等於取消訂閱
挑戰
單筆退款只處理「一筆已發生的交易」；定期退款同時牽涉「過去的交易 ＋ 未來的訂閱關係」。若直接沿用原本的退款流程，就會出現：這筆錢已經退掉，但下個月仍然繼續扣款。
行動
將兩件事拆開，並建立業務規則表定義兩者分別如何影響前台、後台、金流與通知：
| 取消訂閱 | 定期贊助退款 | |
|---|---|---|
| 處理範圍 | 只停止未來扣款 | 退款當期交易 ＋ 終止未來訂閱 |
| 可逆性 | 可逆，可重新訂閱 | 不可逆 |
| 入口 | 支持者名單 | 金流管理頁 |
| 確認機制 | 一般確認 | 獨立彈窗，明確揭露會連帶終止訂閱與 3–5 分鐘處理時間 |
兩個進一步的判斷
- 高風險操作不放在名單頁：名單頁是創作者最常瀏覽、每列都有按鈕的地方，誤觸成本最高，所以不可逆的退款收斂到金流管理頁——那裡的使用情境本身就是「要處理一筆款項」。
- 非同步金流要寫進文案：退款狀態約需 3–5 分鐘更新，把延遲直接寫在確認彈窗裡，避免創作者以為系統失敗而重複操作。
→「錢」與「關係」是兩個不同的 state；操作的可逆性，決定它應該出現在什麼位置。
產品交付
前述規則最終落地至贊助者付款、訂閱生命週期與創作者管理三個核心場景；以下以代表性流程呈現，而非逐頁展示所有介面。
01｜核心交易體驗
贊助者付款流程 選擇每月定額 → 填寫資料 → 信用卡 3D 驗證 → 收到確認信
- 單筆與每月定額以分頁並存，切換分頁時保留已輸入資料——切換是「比較」行為，不是放棄
- 預設金額降低決策成本，自訂金額承接高意願支持者
- 贊助者無須註冊即可完成定額贊助，因此確認信同時是交易憑證與後續的管理入口
02｜訂閱生命週期與例外處理
定期贊助真正的複雜度不在首次付款，而在付款之後：續扣、取消、退款會同時改變前台、後台、金流與信件四處的狀態。以下先呈現取消與退款的狀態轉換，再以贊助者自助取消、創作者執行退款兩條路徑作為代表性流程。
路徑一 贊助者自助取消
- 入口放在交易信而非站內會員中心——贊助者無須註冊 Portaly，管理頁必須能從信件直接進入
- 管理頁固定揭露「贊助狀態」與「下次扣款日」，讓贊助者隨時知道自己現在是什麼狀態、接下來會發生什麼
- 取消屬可逆操作，採一般確認彈窗；完成後即時更新狀態並寄出雙邊通知
路徑二 創作者執行定期退款（不可逆）
- 定期退款 ＝ 退還當期交易 ＋ 終止未來訂閱，與「取消訂閱」是兩件事，因此不共用入口
- 高風險且不可逆，入口收斂到金流管理頁，不放在每列都有按鈕的支持者名單頁
- 非同步金流：3–5 分鐘的處理延遲直接寫進確認彈窗，避免創作者以為系統失敗而重複操作
03｜長期支持者管理
名單呈現最新贊助日期、贊助者、訂閱狀態、金額、已贊助次數、累計金額、留言、Email、取消原因，並可匯出。排序上「訂閱中」永遠優先於「已取消」，再依日期排序。
- 累計金額與贊助次數讓「長期支持者」從一筆筆交易變成可辨識、可經營的對象
- 創作者也可從名單端取消訂閱（僅停止下期扣款、不退款），與金流管理頁的退款明確分流
04｜其他產品觸點
- 創作者設定：單筆與定期可獨立開關，設定結果即時反映在前台預覽，把驗證成本降到零；只有「同時開啟定額且已啟用 PayPal」時才顯示限制提示，兩種贊助都關閉時先警告前台贊助區塊會消失
- 交易信件：贊助成功、取消、電子發票開立皆有對應信件，構成產品之外的第二層狀態同步
- 上線溝通：後台彈窗公告新功能，CTA 直接導向設定頁
產品溝通
每月定額是加在既有單筆贊助上的新模式，因此功能完成後，也規劃了三個主要曝光入口，降低創作者從「知道功能」到「開始設定」的距離：
- 產品內彈窗：在後台直接曝光新功能，CTA 導向設定頁。
- 功能發布信：精簡說明功能如何使用。
- 官網教學文章：聚焦「是什麼、能帶來什麼、如何開啟」，以「讓粉絲穩定支持你的創作」溝通價值。
文案一律從創作者的收益角度出發：「讓粉絲穩定支持你的創作」，而不是「新增每月訂閱付款」。同一個功能，前者是收入，後者是工單。
初步成效
上線後，團隊優先關注新功能是否真的被使用，以及每月定額能為既有贊助業務帶來多少營收貢獻。
在原本只有單筆贊助的收入結構中，新上線的定期模式已在第一個觀察月份貢獻超過三分之一的贊助營收，顯示創作者與贊助者確實開始採用這種新的支持方式。
在撰寫 PRD 時，也同步拆解了功能指標。因為這個專案的目標不只是「多收一筆錢」，而是把一次性的贊助轉成持續支持，因此我認為只看金額還不夠：少數高額贊助者也可能讓營收上升，但無法反映定期支持關係是否真的成立。
因此我把成效分成兩個層次：
| 關注的問題 | 代表指標 | |
|---|---|---|
| 商業結果 | 功能有沒有人用、是否產生收入？ | 定期贊助金額、累積收入、創作者啟用率 |
| 產品健康度 | 支持關係有沒有持續下去？ | 第二次續扣成功率、留存、有效定期支持關係數 |
前者告訴我結果好不好；後者幫助判斷這個結果能不能持續，以及下一步該優化哪裡。
但後續因我轉往其他專案，沒有持續取得完整的續扣與留存資料，因此這次只能完成商業結果的初步觀察，尚未驗證長期留存。
完整的指標拆解 成功 · 執行 · 權衡 · 生態指標
成功指標｜這個功能算不算成功
當月成功續扣的定期支持關係數
該月至少成功扣款一次、月底仍為「訂閱中」的「創作者 × 贊助者」配對數。
不用金額當成功指標：少數高額贊助者就能把數字拉高，掩蓋關係正在流失。這個數字可以拆成乘法：
當月定期支持關係數 ＝ 新增關係數 × 續扣成功率
執行指標｜能直接施力的三件事
| 指標 | 怎麼算 | 影響乘法的哪一邊 |
|---|---|---|
| ① 創作者啟用率 | 開啟定額的活躍創作者 ÷ 有贊助區塊的活躍創作者 | 新增關係數 |
| ② 定期首購轉換率 | 完成首次定期付款 ÷ 進入贊助頁人數 | 新增關係數 |
| ★ ③ 第二次續扣成功率 | 第 2 期成功扣款 ÷ 首次付款成功 | 續扣成功率 |
③ 較重要，要確認每月定額贊助是否真的讓創作者每個月的現金流更穩定。
權衡指標｜此功能上線後可能影響到的
- 單筆贊助金額／筆數：每月定額贊助有沒有影響本來的單筆贊助。
生態指標｜當時公司實際在看的數字
- 每月固定的定期贊助金額（單月能收到多少定期贊助）
- 累積的定期贊助收入
- 啟用每月定額贊助的創作者人數比例
市場對此功能的反饋
功能上線後，公開使用案例顯示，創作者不只將「每月定額贊助」作為持續收入來源，也開始延伸出不同的經營方式，例如提供訂閱者限定回饋、設定持續贊助獎勵，或將定額贊助固定放入 Podcast、社群內容的支持入口。
這些案例顯示，使用者並非只把功能視為「每月自動扣款」，而是進一步用來建立長期支持關係與粉絲經營機制。Portaly 創辦人後續也曾公開分享，已有創作者透過此功能累積六位數的月訂閱收入。
反思與下一步
1. 當贊助多位創作者時，管理中心該怎麼設計
- 第一版其實有考量多位創作者的訂閱管理，但為了快速驗證，我選擇沿用既有的信件管理機制，而非另外開發集中管理中心。這降低了開發成本與時程，也增加了取消操作的摩擦，對續訂相對有利，但犧牲了多訂閱使用者的管理便利性。
→ 這讓我意識到，使用者體驗、商業目標與技術成本之間的取捨沒有標準答案。為了快速驗證，MVP 可以接受一定程度的摩擦，但這些摩擦應該來自有意識的產品決策，並在上線後透過取消率、續訂率與實際使用情境持續驗證。
2. 上線新功能，不只是把功能設計完
- 過去我的專案經驗較聚焦在功能本身，這次參與產品內彈窗與功能發布信的規劃後，我開始意識到：產品完成只是第一步，使用者是否知道、理解並願意開始使用，同樣是產品體驗的一部分。
→ 若重新規劃，我會將上線溝通納入產品成效追蹤，從信件開信、CTA 點擊到功能啟用，以及產品內彈窗的曝光、點擊與啟用，建立完整的轉換漏斗。
3. 指標框架要跟決策者對齊，不是自己關起門來設計
- PRD 定義了續扣、留存等功能指標，但公司實際追蹤的是固定贊助金額、累積收入與啟用比例，兩套框架沒有事前對齊，導致部分指標最後沒有被持續追蹤。
→ 下次我會在上線前先與決策者對齊成功指標，確保數據真正成為後續決策依據。