這是一個:

SasaDaily 假設示範案例。

不是 OpenAI 公布的真實客戶案例。

我們假設有一家:

4 人企業培訓工作室。

團隊每個月接:

企業內訓。

主管工作坊。

AI 入門課。

團隊協作課。

每個客戶的課程內容都不完全一樣。

真正花時間的,

往往不是:

站上台講那幾個小時。

而是課程前後大量:

整理與交付。

一個企業培訓案,資料到底有多散?

假設客戶確認要辦一場:

兩天的內部培訓。

工作室手上很快會出現:

課程簡介。

正式日期。

兩天流程。

講師資料。

場地資訊。

課前準備。

教材。

分組活動。

FAQ。

交通方式。

窗口資料。

行前提醒。

課後問卷。

甚至:

不同版本的簡報。

以前最常見的做法是:

寄一封 Email。

附三個 PDF。

再丟一個 Drive 資料夾。

課程前兩天,

學員開始問:

「教材在哪裡?」

「幾點開始?」

「需要帶電腦嗎?」

「停車在哪?」

「最新版本是哪一份?」

於是工作室又開始:

回信。

傳連結。

找附件。

重新整理。

問題不是沒有資料

而是:

沒有一個入口。

資料其實全部都存在。

只是散在:

Email。

Drive。

PDF。

簡報。

訊息。

表單。

每次換一個客戶,

又重新整理一次。

這種工作很典型:

沒有難到值得請工程師做一套系統。

但又重複到:

每個月一直做很煩。

這正好是 ChatGPT Sites 可以切入的位置。

OpenAI 目前把 Sites 定位成可以建立、預覽、發布及分享互動網站與輕量 App 的工具,也直接把 Internal Portal、Project Tracker、Report 等列為典型使用方式。

工作室不先做「公司新官網」

這很重要。

第一個錯誤很可能是:

看到 Sites 很方便,

立刻說:

「把我們整家公司網站重做。」

這個案例不這樣做。

團隊先挑一個:

範圍很小,

而且每個月都重複發生的工作:

每一場企業培訓的專案入口。

它不是主官網。

不是大型 LMS。

不是 CRM。

只解決一件事:

讓這一場課程所有已確認、可以分享的資訊集中在同一個地方。

第一版只放六樣東西

團隊先做最小版本。

1. 課程目的

這兩天到底要學什麼?

2. 日程

幾點開始?

中間做什麼?

3. 講師與課前準備

誰來教?

學員要準備什麼?

4. 場地與參與方式

到哪裡?

怎麼參加?

5. 教材與正式資源

所有人都從同一個入口拿最新版。

6. FAQ

把每場課程最常被問的問題放進去。

先這樣。

不要第一版就加:

會員制度。

複雜資料庫。

付款。

證書系統。

考勤系統。

二十種自動化。

ChatGPT Sites 在這裡真正省的是「重新組裝」

每個客戶需要的結構其實很像。

但是內容不同。

以前新案子來了,

工作室可能先:

複製舊文件。

改公司名稱。

換日期。

換課程。

重做 PDF。

重新整理 Drive。

重寫行前通知。

接著又發現:

某個舊客戶名字沒有換乾淨。

Sites 的理想工作方式變成:

先提供:

這次客戶已確認的資料。

再要求:

依照我們固定的培訓專案結構,
建立這一次客戶的 Site。
只使用本次提供的正式資料。
找不到的資訊標示缺少,不要自行補寫。
先給內部 Preview,
不要直接 Publish。

接著:

結構可以重用。

內容重新填入。

這就是小公司的價值。

AI 不必每次重新「發明網站」

這也是 Workflow 真正成熟後的差別。

第一次:

花時間決定結構。

第二次:

沿用。

第三次:

再改善。

慢慢變成一套:

Client Portal Template。

例如每次固定都有:

Welcome。

Schedule。

Preparation。

Materials。

FAQ。

Feedback。

真正需要改的是:

客戶資料。

課程資料。

教材。

而不是每次重新想:

網站到底要有哪五頁。

這會降低一種很隱形的成本:版本混亂

假設:

課程流程原本 09:00 開始。

後來客戶改成:

09:30。

工作室可能要改:

Email。

PDF。

行前通知。

Drive 文件。

工作人員版本。

少改一個地方,

就出現兩個答案。

如果學員主要入口集中到 Site,

比較容易把:

目前有效版本

集中在同一處。

注意:

這不代表所有原始檔案都應該搬進 Sites。

真正目的反而是:

讓對外資訊有一個主要入口。

假設每月八個企業案,時間差會開始變得有意思

以下只是:

SasaDaily 假設試算。

不是 OpenAI 官方效率數字。

假設以前每個新案子,

整理:

行前頁面、

文件、

FAQ、

客戶修改、

最新版連結

總共要花:

6 小時。

每月 8 個案子:

6 × 8
=48 小時

如果固定模板建立後,

每案第一版整理降到:

3 小時,

每月就是:

3 × 8
=24 小時

假設成立,

每月少掉:

24 小時重複組裝工作。

真正省下來的不是:

「AI 寫網站很快。」

而是:

不用每一案都從零重新交付。

但這 24 小時不能寫成保證

因為真正時間會受到:

客戶資料完整度。

網站複雜度。

修改次數。

團隊熟悉程度。

檔案品質。

審核流程。

影響。

所以比較好的 KPI 不是:

「OpenAI 幫我們省 50%。」

而是自己量:

導入前平均每案幾小時?

導入後幾小時?

客戶修改幾次?

重複詢問減少多少?

哪一類案子根本不適合用?

這才是真正的:

ROI。

第二個商業價值:客戶修改可能變快

以前客戶收到:

一份 PDF。

他說:

「第二頁流程要改。」

設計師:

開檔。

修改。

輸出。

重新寄。

客戶再問:

「哪一份才是新的?」

如果 Site 仍處於私人 Preview,

團隊可以先改:

內容。

結構。

順序。

確認後,

再部署新版本。

OpenAI 官方也建議修改後先查看 Preview,再決定是否部署;每一次 Deployment URL 都是 Production URL,因此不需要為了看修改效果就每次直接更新正式版本。

這種:

Preview → 客戶確認 → Deploy

對小型服務公司非常實用。

第三個價值:客戶感受到的不是「AI」,而是交付更完整

這其實更重要。

客戶不一定在乎:

你是不是用 ChatGPT Sites。

他真正感受到的是:

資料比較好找。

最新版比較清楚。

行前問題變少。

手機打得開。

教材有固定入口。

修改比較快。

所以 AI 商業化有一個非常重要的原則:

不要把「我們用了 AI」當成客戶價值。

客戶價值應該是:

原本麻煩的事情變簡單。

但有四種東西不要一起塞進去

這是這個案例最重要的邊界。

第一:正式報價

假設客戶 A:

課程費用 8 萬。

客戶 B:

12 萬。

客戶 C:

合作方案不同。

這種:

商業條件

不需要因為建立專案入口,

就跟一般學員資訊放在一起。

第二:正式合約

合約可能包含:

付款條件。

取消條款。

個別議價。

法律條款。

簽署資訊。

這些應該留在:

原本正式合約流程。

而不是:

為了「所有東西集中」

就全部放進 Site。

第三:完整員工名單

企業客戶可能提供:

姓名。

Email。

職稱。

部門。

甚至其他內部資訊。

如果 Site 只需要:

提供課程資訊,

根本不一定需要拿到:

完整名單。

不需要,就不要收。

第四:付款與信用卡資料

這一條甚至不是只有建議。

OpenAI 目前明確規定,ChatGPT Sites 不得處理 Payment Card Data,也不得直接啟用金融交易;Protected Health Information 同樣不得透過 Sites 處理。

所以不要因為 Site 已經做好,

下一句就說:

「順便幫我加信用卡付款。」

這不是適合放進這個工具的流程。

所以這間工作室把資料分成兩層

可以進專案 Site

正式日程。

講師。

已核准教材。

場地。

一般 FAQ。

課前準備。

公開或已授權的圖片。

必要的回饋表單。

留在原系統

報價。

合約。

付款。

內部客戶資料。

完整名單。

敏感人事資訊。

內部會議紀錄。

未公開企劃。

這個分類,

其實比:

網站做得多漂亮

重要很多。

如果只是給一個企業客戶使用,也不一定要公開全網

這是 Sites 很適合企業服務的一點。

Site 不一定只有:

「公開」

和:

「不公開」

兩種。

依帳號與 Workspace 設定,

可以限制在:

Owner/Workspace admins。

指定使用者或群組。

Workspace 成員。

或者在具備公開發布權限時,

開放給 Internet。

所以這間培訓工作室可以先問:

這個入口真正需要誰看?

如果只有:

客戶窗口+內部團隊,

就沒有必要為了方便,

直接公開全世界。

這會改變服務公司的另一個習慣:不要所有交付物都用 Email

很多小公司有一個問題:

每一件事情最後都靠:

Email。

新的日程:

Email。

新版教材:

Email。

停車資訊:

Email。

會議修改:

Email。

最後變成:

Email 本身就是資料庫。

Sites 能做的其中一件事,

就是把:

「現在有效的資訊」

移到專案入口。

Email 只負責通知:

「已更新。」

而不是:

每封信都帶一份新的真相。

第四個商業價值:交付可以變成產品

這件事特別值得看。

原本企業培訓公司賣的是:

課程。

但是當它慢慢建立:

固定專案入口。

課前準備。

教材。

FAQ。

課後回顧。

客戶感受到的服務就不再只是:

講師來兩天。

而變成:

一套完整培訓體驗。

這就是服務:

Productization。

產品化。

產品化不是把每個客戶做成一模一樣

真正意思是:

把每次都重複的部分:

固定。

把真正需要專業判斷的部分:

客製。

例如:

固定:

專案入口架構。

固定:

交付順序。

固定:

檢查流程。

但是:

課程內容。

企業需求。

案例。

正式建議。

仍然依客戶改。

AI 最適合壓低的是:

重複結構成本。

不是把所有客戶:

做成同一份東西。

團隊可以建立一個固定「建站前清單」

每個新案子,

先不要直接叫 ChatGPT 做。

先準備:

已確認

日期。

場地。

課程。

講師。

正式教材。

仍未確認

最終人數。

教室配置。

客戶 Logo 使用方式。

禁止放入 Site

報價。

合約。

付款資料。

客戶私人名單。

內部筆記。

然後才開始建立。

這會比單純寫:

「幫我做一個漂亮客戶網站」

穩定很多。

發布前再走昨天今天學過的兩層檢查

第一層:

內容。

連結。

手機版。

第二層:

誰看得到?

表單收什麼?

有沒有敏感資料?

登入與分享設定正確嗎?

也就是今天工具、

一分鐘教學、

快問快答,

最後在商業案例裡真正串起來。

OpenAI 也把最後責任留給 Site 經營者

這點一定要說清楚。

Sites 能協助:

建立。

Preview。

修改。

部署。

Hosting。

但 OpenAI 官方明確表示:

Site Owner 仍然要對:

發布內容。

訪客提交內容。

分享權限。

適用法律。

個人資料處理

負責。

所以這間工作室不能說:

「因為是 ChatGPT 做的,所以有問題找 OpenAI。」

真正把它當商業工具之後,

它就是:

你的數位服務。

如果網站收 Email,事情又多一層

假設工作室想做:

課後問卷。

其中要求:

姓名。

Email。

這就開始涉及:

個人資料。

OpenAI 最新資料保護說明指出,如果 Site 蒐集或處理訪客個資,Site 經營者需要自己確認適用的隱私與資料保護責任;在相關規則下,Site Owner 可能扮演 End User Data 的 Data Controller。

所以比較好的問題不是:

「表單能不能加?」

而是:

「我們真的需要收姓名嗎?」

如果只想了解:

課程滿意度,

匿名問卷可能就夠。

這就是:

Data Minimization。

這個案例真正值得量的不是「做出幾個 Site」

假設公司三個月做:

30 個 Sites。

看起來很多。

但商業價值不能用:

數量

決定。

比較值得追蹤:

每案交付時間

以前多久?

現在多久?

客戶修改次數

有沒有因為資訊集中而下降?

重複詢問

「教材在哪?」

「幾點開始?」

這類問題有沒有減少?

錯版本事件

有沒有降低?

客戶回訪

專案期間是不是持續使用入口?

這些才是:

真正 KPI。

如果沒有改善,就不要因為是 AI 硬用

這也很重要。

假設最後發現:

做 Site 3 小時。

客戶根本不看。

大家仍然只看 Email。

那這個流程可能就是:

多做了一份東西。

不是 AI 自動化成功。

所以導入後一定要問:

使用者真的使用嗎?

如果沒有,

要改善。

甚至:

停止。

AI 工具不是:

用了就算轉型。

還有一個隱形價值:新進員工比較容易接手

假設工作室原本所有流程都在:

老闆腦袋。

每次客戶問什麼,

都找老闆。

有了固定專案結構後,

新人至少可以知道:

一個案子正式交付前,

應該準備:

哪些資料。

哪些不能公開。

誰最後確認。

這讓 AI 不只是:

幫忙做網站。

也開始逼公司:

把自己的交付方法說清楚。

但不要把 ChatGPT Sites 當成萬能客戶平台

這間 4 人工作室如果未來變成:

400 人。

一年幾千個企業客戶。

需要:

複雜 CRM。

大量會員權限。

SCORM。

正式 LMS。

帳務。

電子簽章。

付款。

完整稽核。

那專業企業系統很可能仍然更適合。

Sites 在這個案例的位置是:

填補「一個客戶案需要好入口,但又不值得重新開發系統」的中間地帶。

這才合理。

最後把整個工作流程縮成七步

1. 客戶確認專案

先取得正式資料。

2. 分資料

可分享。

未確認。

禁止公開。

3. ChatGPT Sites 做第一版

沿用固定 Client Portal 結構。

4. Internal Preview

先由工作室檢查。

5. Client Review

讓客戶確認內容。

6. 人工決定 Access 與 Publish

不是 AI 自動發布。

7. 課程期間只維護「目前有效版本」

Email 負責提醒。

Site 負責當入口。

這就是完整 Workflow。

如果要算這筆 AI 投資值不值得

不要算:

「網站做得漂不漂亮。」

算:

每月減少的重複整理時間

減少的錯版本與重複溝通成本

客戶交付體驗提升

再減掉:

建立、審核、維護 Site 的時間

如果最後是正的,

才值得繼續。

今天這個案例真正的商業啟示

ChatGPT Sites 讓小型服務公司第一次有機會:

把原本只能靠人工重複交付的服務流程,低成本地包成一個數位入口。

但真正產生價值的,

不是:

AI 會做網站。

而是公司知道:

什麼可以標準化。

什麼必須客製。

什麼可以分享。

以及:

什麼永遠應該留在人工與原系統。

當這四件事情分清楚,

AI 才不是替公司多做一個網頁。

而是在幫公司把:

服務變得更像產品。

今天,和 AI 一起進步一點。

每天學會一個 AI 技巧。

每天節省一點時間。

每天提升一點能力。

SasaDaily,陪你一起成長。

推薦閱讀

AI 商業案例|2026/07/29:室內設計工作室怎麼用 ChatGPT Work?從需求整理、現場紀錄到提案與修改,減少跨檔案重做

今日 AI 工具|2026/07/29:ChatGPT Work,連接文件與工作工具,把研究、整理、製作到更新變成一段完整流程