這是一個 SasaDaily 假設案例。
不是 Atlassian 公布的真實客戶成效。
假設有一家 6 人 B2B SaaS 公司：
- 1 名 Product Manager
- 2 名 Engineer
- 1 名 Marketing
- 1 名 Customer Support
- 1 名 Operations／Founder
公司每兩週發布一次產品更新。
真正耗時間的事情，卻不只是寫 Code。
而是每次功能準備上線後，
同一段背景要一直重新講。
一個功能，為什麼要講四次？
例如工程團隊正在開發：
新版客戶權限管理。
工程師在 Jira 裡已經討論：
為什麼要改？
哪些客戶受影響？
有哪些 Known Issues？
哪一部分延後？
哪一個限制不能在 Launch 時承諾？
工程完成後，
Product Manager 接著要重新整理一份：
Launch Brief。
Marketing 再問一次：
「這次到底改了什麼？」
客服又問：
「如果客戶說舊權限不能用了，要怎麼回答？」
Founder 週會再問：
「目前 Release Risk 到底在哪？」
六人公司不大，
但同一組 Context 仍然可能被：
工程 → Product → Marketing → Support → Management
重新整理五次。
這就是典型的：
Work about work。
第一步：產品經理先和 Rovo 把工程 Context 整理完整
假設團隊本來就使用：
Jira、
Confluence。
產品經理先在 Rovo Chat 問：
「整理目前新版權限功能的 Release Status，分成已完成、Blocker、Known Risk、還需要決定的事情。」
Rovo 可以根據這位使用者本來有權限查看的 Jira／Confluence Context 協助整理。
這一步先不做任何外部動作。
只建立一條清楚的：
Release Thread。
裡面留下：
為什麼做？
目前做到哪？
什麼還沒完成？
哪些是已決定？
哪些只是 Proposal？
這條 Chat 開始成為這次 Release 的工作 Context。
第二步：不另開新對話，直接 @專門 Agent
整理到 Marketing 階段時，
產品經理不需要：
Copy 整段內容，
再開一個新 Agent，
重新解釋一次。
新版 Rovo Chat 可以直接在目前 Thread：
@mention 專門 Agent。
假設團隊有一個：
Launch Planning Agent。
它進入目前對話時，
可以取得這個 Thread 已經累積的：
- Context
- Decisions
- Artifacts
然後接著整理：
Launch Message。
Target Audience。
FAQ Draft。
Internal Checklist。
真正節省的不是：
AI 少打幾個字。
而是：
第二個 Agent 不用重新學第一次 Agent 已經知道的事情。
第三步：Marketing 不拿摘要，直接接手完整 Chat
Marketing 接手時，
以前 Product Manager 可能要另外寫：
「工程目前狀態如下……」
但 Summary 有個問題。
它容易把過程壓掉。
例如：
工程原本考慮方案 A，
後來因 Security Risk 改成方案 B。
如果 Summary 只留下：
「最後使用方案 B。」
Marketing 很可能不知道：
方案 A 為什麼不能再提。
新版 Rovo Chat 可以直接 Share Chat。
Marketing 接手後，
可以沿著原本的 Discussion 繼續工作。
所以交接的不只是：
Final Answer。
還包括：
Why。
這對跨部門工作非常重要。
但 Marketing 不會因為 Share Chat 就取得工程機密
這個案例裡一定要保留一條界線。
假設原本 Engineering Manager 能看到：
Private Security Jira Issue。
Marketing 沒有權限。
分享 Chat，
不代表 Marketing 因此取得這張 Issue 的完整存取權。
Atlassian 明確表示：
Shared Chat 仍然 Permissions-aware。
所以：
Context 可以交接。
Access 不會跟著升級。
如果 Marketing 完成工作真的需要那份資料，
應該正式調整原資料權限。
而不是把 Share Chat 當成繞過 Access Control 的方法。
第四步：客服直接接同一條產品脈絡
Launch 前，
Customer Support 也需要知道：
客戶可能問什麼？
哪些問題已經修好？
哪些還只是 Known Limitation？
哪些回答不能承諾？
以前通常又做一份：
Support Brief。
這次可以讓客服直接接手 Shared Chat，
再拉進：
Support Knowledge Agent。
Agent 根據目前 Context 協助整理：
- FAQ Draft
- Known Issue List
- Escalation Condition
- Support Reply Draft
但正式對客戶說什麼，
尤其涉及：
退款、
SLA、
補償、
Feature Delivery Date，
不能只因為 AI 已經整理好就直接送出。
這些仍然保留：
Human Gate。
第五步：每週都做的 Sprint Summary，不要再重新 Prompt
這家公司每星期五還有一件固定工作：
Founder 要看 Weekly Update。
過去 Product Manager 每週都要重新叫 AI：
讀 Jira。
找本週完成。
整理 Blocker。
列下週 Priority。
找需要主管決定的事項。
如果每週都重新教一次，
就代表這其實已經是一個：
固定 Workflow。
新版 Rovo Chat 可以把它建立成：
Custom Skill。
例如：
Weekly Leadership Update Skill。
固定規則包含：
- 本週完成
- Blocker
- 下週 Priority
- 需要決策事項
- 沒有證據的事情不得自行補完
每次只另外指定：
哪一個 Board。
哪個日期範圍。
哪一個 Release。
這樣才是真正把：
Prompt
變成：
團隊工作方法。
哪些事情適合讓 Rovo 做？
把整個 Release Workflow 拆開，
AI 適合先處理：
讀取既有 Jira／Confluence Context
↓
整理 Release Status
↓
保留 Decisions 與 Open Questions
↓
把 Specialist Agent 拉進同一 Thread
↓
產生 Marketing Brief Draft
↓
產生 Support FAQ Draft
↓
產生 Weekly Status Draft
↓
把重複流程做成 Custom Skill
這些工作的共同點是：
整理、轉換、交接、草擬。
哪些一定留下給人？
這家公司的 Human Gate 則設定在：
正式 Release Date
Production Deploy
Pricing Change
客戶 SLA／交期承諾
退款／補償
公開 Marketing Claim
Security Incident 對外說法
刪除或大幅修改正式 Jira／Confluence Records
為什麼？
因為這些事情做錯，
不只是：
「AI Summary 不太好看。」
而是真的會：
影響客戶、
影響金錢、
影響 Production、
形成公司承諾。
Atlassian 的 Skills 對部分會修改資料的 Consequential Actions 會要求 Confirmation。
但公司仍然應該自己定義：
什麼事情即使平台沒有攔，也必須人工批准。
假設能省多少時間？
這裡只做保守的假設。
假設兩週一次 Release，
每次跨部門交接原本需要：
Product → Marketing：45 分鐘
Product → Support：45 分鐘
Engineering → Product 補背景：45 分鐘
週報重新整理：45 分鐘
不同 Agent 重複輸入 Context：30 分鐘
合計：
210 分鐘。
也就是：
3.5 小時／每次 Release Cycle。
假設使用 Rovo Chat 後，
Share Chat、@Agent 與 Custom Skill 把大量重複整理拿掉，
但仍保留人工 Review，
每次降到：
2 小時。
理論上減少：
1.5 小時／Cycle。
如果一個月兩次 Release：
約 3 小時／月。
這個數字並不驚人。
但不要忘記這是一家只有 6 人的小公司。
真正應該記錄的不是：
「AI 一個月幫我們省了幾十小時。」
而是四個更實際的 KPI：
交接前後花多少時間？
同一個背景重講幾次？
因 Context 遺失造成多少返工？
Human Review 又花多少時間？
如果沒有改善，
Custom Skill 再漂亮也沒有 ROI。
還可以再量一個指標：Handoff Rework
例如這家公司過去每月發生：
6 次跨部門重新確認。
像是：
「這不是已經決定了嗎？」
「Marketing 怎麼還在用舊版本？」
「客服不知道這功能延後了？」
如果共享 Context 後，
降到：
2 次。
這可能比單純省 3 小時更有價值。
因為 Release 最大成本，
有時候不是整理那 30 分鐘。
而是：
有人拿錯 Context 做了錯的事情。
Memory 也不要變成永久垃圾桶
新版 Rovo 可以讓使用者查看與修改 Memory。
這家公司可以讓它記住：
週報習慣用 Bullet Points。
客戶資料不能進公開 Draft。
某些固定 Project Naming Rules。
但不要把：
這星期臨時 Delay 一天，
這次客戶特殊要求，
暫時性的 Bug 狀態
全部當成長期 Memory。
否則：
今天省掉重新解釋，
下個月卻開始被舊 Context 干擾。
所以 Memory 也要定期問：
這件事下個月還成立嗎？
不成立，
就不要當長期規則。
這個案例真正省的是「交接成本」
Rovo Chat 這次更新如果只看表面，
好像只是：
Memory、
@Agent、
Share Chat、
Custom Skill
四個新功能。
但對這家 6 人 SaaS 公司來說，
它們其實都在處理同一件事情：
不要讓同一份工作，每換一個人就重新開始。
工程做過的 Context，
Product 接得到。
Product 做過的決策，
Marketing 接得到。
Marketing 準備 Launch 時的背景，
Support 接得到。
每週都重複的整理方法，
下一週也接得到。
AI 真正進入企業後，
下一個效率瓶頸很可能不是：
AI 寫得不夠快。
而是：
AI、同事與部門之間，工作接不起來。
如果你也想知道自己的工作裡，哪一步最適合先交給 AI，留言「流程」。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 商業案例｜2026/09/18：7 人軟體整合公司怎麼用 Claude Code Projects？API／Web／Mobile 平行改版，共享規格變更，Merge／Deploy 仍由人批准
AI 商業案例｜2026/09/03：5 人物業管理公司怎麼用 Workspace Studio？租客報修自動整理搬檔，維修承諾前由人批准
