賴旻柔 · AI 導入作品集

12 年職涯、9 年 B2B SaaS，曾協助 150 家以上中小企業完成 SaaS 導入。我擅長聽懂非技術團隊的工作痛點，把模糊需求轉成能運作、可驗證，也能由團隊接手的 AI 自動化流程；並透過教材與實作陪跑，讓工具真正進入日常工作。

應徵方向：AI 導入顧問 / AI Automation Consultant Email · mingroulai@gmail.com

01 · 教學與呈現

把 AI 與自動化教到真的會用

從付費實作課、線上講座到校園工作坊，我把抽象概念拆成非技術學員能跟著完成的步驟；以下場次皆有簡報與會後問卷可供核對。

5 場公開講座與校園工作坊

4.46／53 場公開活動平均滿意度

4.81／5政大 BAC 工作坊滿意度

精選 4 場工作坊｜滿意度與簡報

場次	日期	形式	滿意度	回饋份數	簡報
自動化應用工作坊	2025/06/20	付費售票	4.00	11	查看 →
AI 協作問卷應用工作坊	2025/07/31	免費線上	4.48	141	查看 →
數據驅動課程營運工作坊	2025/12/10	免費線上	4.48	123	查看 →
政大 BAC 校園工作坊	2026/05/27	校園實體	4.81	31	查看 →

滿意度為各場會後問卷平均分，回饋份數即有效樣本數。政大場 31 份中 26 份滿分；同系列另於東吳大學辦過一場（2026/06/03）。

學員原話

覺得講師由淺入深介紹讓我學習得很上手！
2026/05/27 · 政大 BAC

對於 AI 提示詞的應用有更深的認識，之前一直覺得沒辦法讓 AI 精準呈現想要的內容，透過這次課程了解如何讓它提供更精確的訊息。最重要的是認識到了 Claude 這個 AI 工具，感謝講師的用心準備
2025/07/31 · AI 協作問卷應用工作坊

感謝 Zoe 詳細清晰的教學，收穫滿滿
2025/06/20 · 自動化應用工作坊

對於更精準的數據洞察，從多方的角度有更加的了解，非常感謝這次講座的分享！
2025/12/10 · 數據驅動課程營運工作坊

這樣可以讓我們更能活用 SurveyCake，太棒了
2025/07/31 · AI 協作問卷應用工作坊

原來部署可以如此容易
2025/06/20 · 自動化應用工作坊

皆為會後問卷開放式回饋原文。首場付費實體場 11 份回饋裡，8 人課後對自己動手有信心，4 人打算一週內就用上。

學員輪廓：以 AI 協作問卷應用工作坊為例

45 人行銷企劃，職稱第一；其次營運 20、人資 19

83%每週用 AI 工具 2 到 3 次以上

62%當天才第一次知道產品有 AI 生成問卷

59%最大收穫是學會寫有效的提示詞

來上課的是教育、製造、醫療、科技、零售等產業的在職工作者：八成常用 AI，卻有六成不知道手上的工具已經有 AI 功能。導入卡的不是工具，是「怎麼開始用在自己的工作上」。

教學現場

點擊照片可放大；按 Esc 即可關閉。

2025 年 6 月 SurveyCake 自動化應用工作坊現場，講師在學員座位間指導

2025/06 · 自動化應用工作坊（付費售票）

2026/05 · 座位間逐一協助

2026/05 · 政大 BAC 校園工作坊

精選簡報頁

Prompt 四大核心技巧2025/07/31 · AI 協作問卷應用工作坊

簡報頁：還有更輕鬆的自動發信選擇，內建通知信、電子豹模組、Make 三種做法並排

三種自動發信做法並排：內建通知信、電子豹、Make2025/06/20 · 自動化應用工作坊

課程生命週期地圖：四階段數據收集節點2025/12/10 · 數據驅動課程營運工作坊

每場都是同一個五段結構：痛點開場、應用場景、概念比喻、逐步實作、方案選擇。最後一段拿設定難度、費用、客製彈性比三種做法，讓學員自己選。

內部推廣與教材：AI Champion

把個人用法整理成團隊能接手的教學手冊

2025 年 7 月經主管推薦擔任 AI Champion，協助行銷團隊導入 Claude，並將 Project 規劃、知識庫準備、Instruction 撰寫與實作步驟整理成教學手冊；另建立 AI 簡報工作流，將個人製作週期由約一週縮短至兩天，並擔任公司內部 AI 簡報工作坊講師。

完整手冊含內部流程與案例，因此不公開原檔；作品集僅呈現去識別畫面。

Claude Project 教學手冊的去識別範例頁，示範如何設定角色、服務對象與核心任務

去識別範例頁：將角色、服務對象與核心任務拆成可直接跟做的設定步驟；點擊可放大。

02 · 建置案例

四個已上線、能被驗證的案例

以下案例分別處理數據整理、no-code 串接、CRM 生命週期與知識管理；共同原則是先定義需求，再用 AI 加速實作，最後以對帳、測試與人工驗收確保流程可靠。

能力：流程拆解 × AI 輔助開發

案例 A｜GTM／MKT 週報自動化

每週要跨資料庫、試算表整理的成長指標，從人工查詢改成一鍵執行。系統先把六份來源收齊，跟金流紀錄對帳；對得上的差異自己記一筆照常送出，對不上就停下來標記給人查，不會硬填一個數字交差。

6 支腳本＋共用模組，一鍵執行

2 道對帳關卡，對不上就停

30+指標格／週自動寫入

14 週連續運作（W13 到 W26）

30 分單次準備，原約半天（實務估算）

如何讓腳本可維護、可交接

一鍵執行入口依一般週或跨月週，執行對應流程。

共用工具集中管理連線、日期計算與報表寫入。

指標模組依 MKT、GTM 與營運需求拆分，方便單獨維護。

測試與驗證先跑測試與對帳；發現異常便停止，不寫入錯誤數字。

原始架構中的帳號、資料庫設定、內部路徑與指標名稱均未公開；作品集只保留能說明設計判斷的層級。

唯一會停下來的節點是「對帳仍對不上」；對上的差異照樣寫入並留紀錄，不需要人工介入。

能力：no-code 串接 × 教材化

案例 B｜問卷填答自動發信：從一條 Make 流程到一份能帶走的教材

學員多半沒有技術背景，卻要在 90 分鐘內做出一條真的會動的自動化流程，回去還能自己改。做法是把流程拆到四個環節各只做一件事：有人填完報名問卷，資料進試算表；Make 看到多一列，就照樣板寄一封帶對方名字與場次的確認信。哪一步壞了一眼看得出來。

0 行程式碼，全部 no-code

4 個環節：問卷、Webhook、試算表、Make 寄信

1 份可直接匯入的 Make blueprint

3 種方案比較：內建通知信／電子豹／Make

工作坊簡報頁：問卷回覆自動發信流程，參加者填寫報名表單，經 SurveyCake Webhook 記錄到試算表，再由 Make 寄發個人化信件

流程：SurveyCake 問卷 → Webhook 把每筆填答同步到 Google 試算表 → Make「Watch New Rows」偵測新列 → Gmail 模組寄出帶入姓名與場次的個人化信件。

教材化：把流程封裝成可匯入的 Make blueprint 與逐步教材，學員匯入後只要換成自己的試算表與 Gmail 帳號就能跑；課末再用難度、費用、客製彈性比較「內建自動通知信、電子豹模組、Make」三種做法，讓學員依需求選。

結果：成為首場付費工作坊（2025/06/20）的核心實作；同一套流程也用在公司自己的線上講座報名確認信。

⤓ 下載去識別版 blueprint（JSON）

能力：跨系統整合 × AI 協作 × 從規劃到上線

案例 C｜HubSpot 生命週期自動化：從 Onboarding 到 4-Gap 規劃

從零建立公司第一套客戶生命週期框架，約兩個月內完成內容、視覺、CRM 與數據流程整合，並上線可依使用者行為自動觸發的溝通旅程。需求、口徑與驗收由我負責；AI 用於加速文案、素材與腳本初稿。

Phase 1 · 建立可運作、可驗收的 Onboarding 基礎

需求、口徑與驗收由我負責，AI 加速初稿與腳本；每一項產出仍須經產品查證、名單核對、測試帳號實走與第二來源交叉驗證後才上線。

Phase 2 · 從 Onboarding 擴展到四階段生命週期自動化

基礎旅程上線後，我把單一 Onboarding 專案整理成四階段自動化地圖。每個階段先定義使用者目標、觸發訊號與適合的溝通渠道，再決定採用 EDM、站內訊息或人工介入。

GAP 1

註冊與啟動

協助新用戶完成第一個關鍵行為，降低不知道從哪開始的摩擦。

訊號：註冊時間、首次使用行為
渠道：EDM、站內引導

GAP 2

試用與首次付費

依用量與功能需求推進試用，讓使用者在評估期內看見付費價值。

訊號：用量累積、功能需求
渠道：EDM、Popup

GAP 3

升級與擴張

辨識多人協作與進階功能需求，規劃方案升級與月繳轉年繳的分眾溝通。

訊號：協作需求、進階功能使用
渠道：EDM、Popup

GAP 4

留存與挽回

依活躍度、續約與付款狀態安排提醒、健康提升與挽回流程。

訊號：活躍度、到期與付款狀態
渠道：EDM、站內訊息、人工介入

公開版說明

此處僅保留框架與判斷邏輯；實際名單條件、內部序列名稱、客戶資料與單週成效均已移除。

能力：知識系統設計 × 可重複使用

案例 D｜產品知識 Skill：把查詢邏輯寫進架構

行銷團隊寫文案，每次介紹一個功能或情境，都得回頭翻 Spec 與教學文件，重新確認這個方案做得到哪裡、差在哪，很煩。所以我把寫文案會用到的功能、情境，連同查詢機制一起寫成 Skill：一套可重複用的知識架構，加一套撰寫邏輯。

3 種方案分層

30 項核心功能

7 類應用場景

主檔只放判斷邏輯與摘要，細節收進四份參考檔、需要時才讀取。

舉例：要寫一封升級信提到「SPSS 匯出」。Skill 先判斷這是 TEAM 功能表裡的項目，回傳方案歸屬、一句話痛點賣點與官方連結，不用再翻 Spec 或猜方案差異。

效果：我和同事寫 onboarding 信、官網內容、功能比較文案時，不用每次重查方案差異。

知道怎麼驗證

怎麼確認自動化沒有安靜地跑錯

自動化最怕的是安靜地跑錯而沒人發現。所以驗證、防呆與示警我當成交付的一部分，量錯的地方也寫出來。

對帳不通過就停：週報跑完先做兩道對帳，對不上就中止報警，不硬寫數字進表
寫入前先驗版面：寫進試算表前先檢查欄位標籤，避免對方改版後把數字寫錯格
跑前 preflight：自動比對今天日期與週次、遞延參數，擋掉「忘記改週次」這類最常見的人為疏失
發布有版本驗證：EDM 上架流程加入備份、草稿、MD5 檔案校驗、發布後查核

一次量測設計的失誤，和後來的改法

Onboarding 序列上線兩個月後，我想驗證這些信對付費轉換有沒有幫助。收件人 30 天內首購率 2.95%，看起來高於同期自然首購率 2.25%；但做了前後對照與同期同 cohort 對照，兩種算法都看不出提升。結論不是信件沒用，是上線時沒留對照組，事後任何算法都證明不了增益。這是這個專案上我最大的方法論失誤，之後所有序列與 popup 上線前一律先設 holdout。