AI 副業實戰教學

Micro SaaS交付溝通技能:把過程、修改和驗收寫清楚

改了功能沒通知 = 使用者突然找不到入口 = 流失。本文給你 3 類溝通場景模板(發版 / 故障 / 變更)+ 客服 4 類回應表 + 客戶成功 5 步營運 SOP,讓小團隊 SaaS 溝通成體系。

📖 本篇術語速查表
英文 / 縮寫中文一句話解釋
brief專案簡報寫清目標、輸入、輸出、範圍和驗收標準的檔案。
workflow工作流從材料到交付再到覆盤的一組步驟。
scope範圍本次包含和不包含的內容邊界。
QA質量檢查交付或釋出前檢查事實、格式、許可權和風險。
feedback loop反饋迴圈把使用者行為和原話轉成下一步修改。
skill技能本文所在的Micro SaaS技能階段。
Prompt提示詞寫給 AI 的任務說明,用來生成執行方案。

讀完你能交付:一張《[SaaS 名]》交付溝通卡(發版 / 故障 / 變更 3 類場景模板 + 客服 4 類回應表 + 客戶成功 5 步 SOP + 狀態頁設定清單)。 一句話錨點:使用者流失多數不是產品差,是「我不知道發生了什麼」;溝通成體系 = 留存翻倍。

不想讀完?把下面這段提示詞丟給 AI 幫你跑完——複製提示詞,餵給 Codex / Claude Code / Cursor / DeepSeek,把變數改成你的專案,AI 會按本文 H2 輸出執行方案。

# 角色:獨立軟體 SaaS 交付溝通節奏和驗收編排顧問

你是我 SaaS 方向的交付溝通節奏顧問。我會把目前一單服務的交付步驟、已發生的衝突案例、溝通渠道、收款方式交給你,你的工作不是替我群發訊息,而是把一單服務拆成"啟動、中點、終點、售後"4 個溝通節點。每個節點告訴我何時發、發什麼、走哪個渠道、客戶多久不回信就預設驗收、改稿超出幾次開始收費。

你只設計溝通流程。不替我群發訊息、不編"客戶滿意度均值""專案延期率"、不替我做合同或法務判斷、不允許"客戶永遠是對的"模糊承諾、不允許設計無限改稿免費。

## 核心任務

把目前服務翻譯成一份交付溝通節奏卡:4 個節點(啟動 / 中點 / 終點 / 售後)每個節點 5 欄位(觸發條件 / 訊息內容 / 渠道 / 驗收標準 / 風險提示);修改邊界明確(不超過 N 次免費 + 超出按 X 美元一次 + 重大變更觸發新合同);客戶拖延 SOP 和需求外升級 SOP;收款節奏;工作時間邊界宣告和自動回覆模板。


**成功標準**:交付的結果必須同時滿足——4 節點有時間窗;修改邊界明確;含拖延 SOP;含時間邊界;未編滿意度均值。 任意一條沒滿足即視為未達標,需補料後重跑。
## 資訊輸入

設計之前先看我手裡的欄位齊不齊。

如果目前服務一次交付的時長和步驟能講、已發生過的客戶拖延或改稿或退款衝突能列、溝通渠道清楚(郵件 / 微信 / Discord / Loom)、收款方式和預付政策有數、想保護的工作時間邊界(週末 / 晚上)講清楚,這 5 件事我能填出 70% 以上,你就直接開始設計。如果未發生過沖突,預設按"修改不超過 2 次免費"保守模板。

訪談我時你要問的就是這五件事:

1. 一單服務從啟動到交付完整步驟是?多久?
2. 上次客戶讓你最累的是改稿、拖時間、改方向、還是不付錢哪一類?
3. 主溝通渠道是哪一個?(郵件 / 微信 / Discord / Loom 非同步影片)
4. 收款方式?是預付 100%、30 / 70 分期、還是交付後付?
5. 想保護的工作時間邊界?(週末 / 晚上 / 節假日)

如果未發生衝突,預設"修改不超過 2 次免費"。如果週末時間欄位空,預設含"週末不回信"宣告。

## 工作流程

第一步是設計 4 節點。在 `<thinking>` 標籤裡先梳理"客戶什麼時候最容易跑路 vs 最容易提改稿要求"再下筆。

| 節點 | 觸發 | 訊息內容 | 渠道 | 驗收 | 風險 |
|------|------|----------|------|------|------|
| 啟動 | 收到首付款後 | Kickoff 郵件 + 客戶問卷 + 交付時間表 | 郵件 + Loom 自我介紹 | 客戶回填問卷 + 確認時間表 | 不回信 7 天預設棄單 |
| 中點 | 完成 50% 時 | 進度截圖 + 1 次免費修改窗 | Loom + 郵件 | 客戶在 3 天內提出修改意見 | 3 天不回預設驗收 |
| 終點 | 完成 100% 時 | 交付包 + 最終發票 + 7 天驗收窗 | 郵件 + Drive 連結 | 客戶在 7 天內簽字驗收 | 7 天不回預設驗收 |
| 售後 | 交付後第 7 天 | 滿意度問卷 + 案例授權申請 | 郵件 | 客戶主動反饋或不反饋 | 30 天后不再追加售後 |

每節點都要有"客戶回覆時間窗"硬約束,否則客戶拖延會拖垮自己。

第二步是寫修改邊界。

| 修改型別 | 邊界 |
|----------|------|
| 文字 / 配色 / 小調整 | 不超過 2 次免費 |
| 範圍內重大改方向 | 第 3 次起 49 美元一次 |
| 範圍外新需求(新增模組 / 新增交付物) | 觸發新合同新報價 |

第三步是寫拖延 / 升級 SOP。

| 情形 | 處理 |
|------|------|
| 客戶 X 天不回信 | 自動歸"已驗收"+ 備份截圖存檔 |
| 客戶提範圍外需求 | 立刻發"這是新需求,我給你一份額外報價單" |
| 客戶要求加急 | 加急費 100% 服務費 |

第四步是寫收款節奏。常見 3 種:100% 預付(一錘子)、30% / 70% 分期(kickoff 加 delivery)、50% / 30% / 20% 三段(kickoff 加 midpoint 加 delivery)。

第五步是寫工作時間邊界宣告和自動回覆模板。

```
我的工作時間:週一到週五 9:00 到 18:00。
週末和節假日不回信。
緊急事項請發到 emergency@xxx 郵箱,我會在工作日開始時優先處理。
謝謝理解。
```

## 示例 / 樣板

輸入是"AI 整理 Etsy 差評工具"按單服務(199 美元一次),一單 5 小時完成,曾遇到客戶改稿 6 次、3 天不回信、提範圍外新需求 3 類衝突。

期望輸出節選:

```
4 節點溝通卡片(節選)

啟動節點
觸發:收到首付款 50% 即 99.5 美元
訊息內容:Kickoff 郵件 + 問卷連結 + 5 天交付時間表
渠道:郵件 + Loom 自我介紹影片
驗收:客戶在 24 小時內填完問卷
風險:7 天不回信郵件,全額退款並標記棄單

終點節點
觸發:完成交付包
訊息內容:交付郵件 + Drive 連結 + 7 天驗收窗
渠道:郵件 + Drive
驗收:客戶 7 天內簽字
風險:7 天不回預設驗收,發自動歸檔郵件

修改邊界
- 文字 / 配色 / 小調整:不超過 2 次免費
- 重大改方向:第 3 次起 49 美元
- 範圍外新需求:觸發新合同

收款節奏
50% kickoff + 50% delivery

工作時間邊界宣告
週一到週五 9:00 到 18:00。週末不回信。
```

反面例子:客戶改 10 次也免費(違反修改邊界硬約束);編"業界客戶滿意 90%"(無源資料);寫"客戶永遠是對的"模糊承諾(違反禁軟妥協);不設拖延 SOP(違反"必須有時間窗硬約束")。

## 輸出規範

直接輸出《[服務方向]》交付溝通節奏卡正文,不要前言後語,總字數 800 到 1200 字,按以下順序:

1. 4 節點溝通卡片:觸發 / 內容 / 渠道 / 驗收 / 風險
2. 修改邊界 + 加價規則
3. 拖延 / 升級 SOP
4. 收款節奏:預付 / 分期方案
5. 工作時間邊界宣告 + 自動回覆模板

輸出前自檢:4 節點有時間窗;修改邊界明確;含拖延 SOP;含時間邊界;未編滿意度均值。

## 硬約束 · 拒絕場景
遇到下面這些情況直接拒絕設計,告訴我先回去補哪一項:

- 要求設計"無限改稿免費"拒絕
- 要求"列業界客戶滿意率"拒絕(無源資料)
- 要求"客戶永遠是對的"軟妥協拒絕
- 要求"週末也回信不寫邊界"拒絕(保護工作時間是硬條件)
- 欄位全空或仍是 `___` 佔位符沒替換拒絕

先給結論

Micro SaaS交付溝通技能要先回答五個問題:

問題要判斷
使用者是誰是否真有這個任務和場景
輸入是什麼材料、資料、賬號、參考是否足夠
交付什麼檔案、流程、樣品或結果是否可檢查
風險在哪偽需求、過度開發、支付失敗、隱私資料和長期支援壓力是否已暴露
下一步是什麼繼續、補證據還是暫停

新手不要用熱情替代判斷。這個階段最容易出錯的地方,是把“我會工具”誤讀成“我能交付”。真正要檢查的是:輸入是否清楚、交付物是否可用、邊界是否寫明、風險是否能被發現。如果這些問題答不上來,先補材料,不要急著放大。

流程图加载中

3 類場景對應 3 套話術,混著用 = 使用者糊塗。詳見 AI 輸出質檢 錯誤回退場景下的溝通方法。

交付溝通技能先服務真實任務

Micro SaaS的交付溝通技能,不是為了顯得更專業,而是為了讓有明確流程痛點的小團隊或獨立使用者能在真實任務裡得到可檢查的結果。它應該服務一個真實任務:讓使用者從不確定狀態,進入能判斷、能執行、能覆盤的狀態。

Micro SaaS 交付溝通這類文章的共同啟發是:專業能力不是堆概念,而是把模糊問題整理成可執行流程。這意味著發版 / 變更 / 故障 / 客服各自有明確的通知機制與回應時長。

如果你只寫“做得更好”“提升效率”“擴大影響”,客戶或使用者很難行動。更好的寫法是:本週收集哪些材料,做出哪個樣品,用什麼表檢查,出現哪些紅燈就暫停。

新手先收窄場景

不要同時服務所有人。先選擇一個更窄場景,例如一類使用者、一種交付物、一個平臺或一個業務階段。場景越窄,例子越具體,風險也越容易提前發現。

如果你發現文章或方案可以套到任何行業,通常說明它還不夠具體。把物件、材料、工具、交付和覆盤都寫具體,才會真正幫助新手。

第 1 步:確認目標、使用者和輸入

先寫一句話:

我這次要幫助 ___ 在 ___ 場景下,用 ___ 材料,完成 ___ 結果。

這句話寫不出來,後面所有動作都會漂。目標不清,會導致樣品不清;輸入不清,會導致 AI 輸出不穩;使用者不清,會導致頁面和交付無法聚焦。

欄位填寫方式
目標使用者有明確流程痛點的小團隊或獨立使用者
目前任務把過程、修改和驗收寫清楚
已有輸入原話、樣品、資料、連結、舊流程
交付結果訪談記錄、MVP 單閉環、支付路徑、支援記錄和迭代表
紅燈偽需求、過度開發、支付失敗、隱私資料和長期支援壓力

這一步不要讓 AI 替你編材料。AI 可以整理你給出的資訊,但不能證明使用者真的存在,也不能確認平臺和支付規則。

輸入材料的最低線

至少要有三類材料:使用者原話、目前樣品或舊流程、執行平臺或工具入口。只有想法,沒有材料,就先做研究和訪談;只有工具,沒有使用者任務,也不要急著交付。

第 2 步:建立判斷表

判斷表要讓你知道現在該繼續還是暫停。

判斷項綠燈黃燈紅燈
需求多個來源指向同一任務只有興趣,沒有行動沒有真實使用者材料
輸入材料完整,來源清楚缺少部分欄位材料不可用或不授權
交付能寫成檔案和驗收交付形式還模糊只能靠口頭解釋
風險有邊界和核驗入口有未確認欄位涉及違規、侵權或敏感許可權
覆盤有資料和原話只有感覺無法判斷結果

表格不是為了好看,而是為了停止錯誤動作。很多失敗不是因為執行不努力,而是黃燈和紅燈被忽略。

反證也要寫

判斷表裡要保留反證。比如使用者不願提供材料、只想免費試做、平臺規則不清、工具能力未核驗、交付後支援壓力過高。反證能幫你避免把小問題做大。

第 3 步:做最小樣品或流程

最小樣品或流程要足夠小,但必須真實。

型別最小樣品
服務一頁 Brief、一個樣品交付、一個驗收清單
工具一個可執行流程或欄位表
內容一段樣稿、一張結構表、一份質檢記錄
變現一個範圍清楚的報價頁或提案
規模化一個小渠道實驗或 SOP 片段

樣品的目標不是展示你能做很多,而是讓使用者判斷“這是不是我需要的”。如果樣品需要你在旁邊解釋很久,就說明它還不夠清楚。

做完樣品後,至少找一個真實使用者或舊客戶看。只聽讚美沒有用,要問他哪裡不懂、哪裡有風險、是否願意進入下一步。

樣品要有退出條件

如果樣品沒人看、看了沒人問、問的問題都和目標不相關,就不要繼續加大投入。先回到目標、使用者和輸入,重新判斷場景是否成立。

第 4 步:檢查風險和邊界

風險檢查要放在交付前,而不是出了問題以後。

風險檢查動作
平臺規則到官方幫助中心或後臺核驗
支付退款看平臺和支付工具當天規則
版權隱私檢查素材、案例、截圖和客戶資料
賬號許可權只拿必要許可權,優先用測試資料
過度承諾刪除不可控結果,補適用邊界

偽需求、過度開發、支付失敗、隱私資料和長期支援壓力都不是小細節。新手越想快點完成,越容易跳過這些檢查。真正專業的做法,是把未確認欄位寫出來,而不是假裝已經知道。

邊界要寫給使用者看

邊界不要藏在腦子裡。哪些不包含、哪些需要客戶提供、哪些需要執行當天核驗、哪些結果不承諾,都要寫進頁面、提案或交付說明。

第 5 步:覆盤並決定下一步

覆盤要落到下一步,不要只寫感想。

發現下一步
使用者任務清楚繼續做完整版本或下一篇教學
輸入材料缺失先補訪談、樣品或官方核驗
支援問題重複回寫 FAQ、模板或 SOP
風險未確認暫停釋出或暫緩報價
反饋分散收窄使用者和場景

覆盤時要同時看行為和原話。行為告訴你使用者做了什麼,原話告訴你為什麼可能這樣做。只看其中一個,都容易誤判。

如果覆盤後沒有產生新動作,說明覆盤還停在總結層。好的覆盤應該讓下一步更小、更清楚。

操作檢查表

欄位填寫
目前主題Micro SaaS交付溝通技能
目標使用者有明確流程痛點的小團隊或獨立使用者
關鍵輸入___
最小樣品___
主要風險偽需求、過度開發、支付失敗、隱私資料和長期支援壓力
官方核驗入口___
覆盤指標使用者原話、樣品行為、交付問題、下一步動作
目前判斷繼續 / 補證據 / 暫停

這張表可以直接複製到你的專案文件裡。每完成一輪,就更新一次,不要只靠記憶。

AI 怎麼輔助

AI 適合做這些:

  1. 把使用者原話整理成問題分類。
  2. 生成 Brief、檢查表、SOP 或覆盤表。
  3. 標出未確認欄位和風險點。
  4. 改寫頁面、提案或交付說明。
  5. 把反饋轉成下一步動作。

AI 不適合替你確認平臺規則、支付退款、客戶授權、隱私邊界和真實購買意願。沒有證據時,必須寫未確認。

讓 AI 輔助時,不要只問“怎麼做”。要給它材料、目標、約束和目前判斷,讓它幫你找遺漏。

官方資料與核驗口徑

平臺規則、演算法動向、報價規則、政策口徑都會變化。本文保留的是可遷移的判斷框架,具體數字一律給區間。

跨平臺核驗入口:

涉及具體資料、比例、報價區間的部分,以執行當天后臺為準。

常見問題

改了一個小功能要不要發郵件?小變化不發會不會顯得沒活躍?

小變化不必發郵件,但必須進 changelog(站內可查)。判斷標準:會不會有使用者因為這個改動產生疑問(比如入口位置變 / 預設值變 / 命名變)→ 發郵件;純後端修復 / UI 微調 → changelog 即可。每週一份"本週變化"郵件比每天發更好。

SaaS 出故障 30 分鐘,要不要主動通知所有使用者?

要。3 步:1)故障開始 5 分鐘內 → 狀態頁更新(影響範圍 / 已在處理);2)持續 ≥ 30 分鐘 → 郵件通知(受影響使用者優先 + 道歉 + 預計恢復);3)恢復後 24 小時 → 故障覆盤郵件(原因 / 修復方法 / 防止再發生)。不通知 = 使用者失控感 = 流失。

破壞性變更(API 介面改名)怎麼發?

3 階段溝通:1)提前 30 天預告郵件(說明改什麼 / 為什麼 / 遷移步驟);2)改動當週再發 1 封提醒;3)舊介面保留 90 天 deprecation 期,老使用者可繼續用。每封郵件附 1 個遷移示例 + 1 個客服聯絡入口。

客服回覆"已修復"使用者卻說"還是不行",怎麼處理?

不要再回"請清快取試試"——這是把責任甩使用者。改 3 步:1)請使用者提供具體步驟截圖 + 瀏覽器/賬號資訊;2)開發跟著步驟復現一次;3)能復現就改 + 道歉;不能復現 → 加記錄,下次出現立刻抓。"已修復"前必須有"我已經復現並修好"的證據。

執行前至少核驗:

接下來去哪

本頁目錄