這是一個：

SasaDaily 假設商業案例。

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

假設有一家：

4 人小型景觀維護公司。

每天工作地點不是辦公室，

而是：

屋頂花園。

住宅庭院。

商辦植栽。

社區公共空間。

老闆真正最熟悉的是：

植物。

灌溉。

材料。

施工。

客戶需求。

但每天最容易漏掉的事情，

反而發生在：

手正在工作、根本不方便打字的時候。

例如上午 10 點，老闆突然發現四件事

第一：

某款培養土快沒了。

第二：

客戶原本指定的植物，

現場日照可能不適合。

第三：

滴灌其中一區水壓：

看起來不對。

第四：

客戶昨天好像又問：

能不能把另一區一起改。

這些事情當下都：

記得很清楚。

問題是：

老闆手上正在：

剪枝。

拉管線。

搬盆栽。

戴手套。

很多人這時候會怎麼做？

第一種：

跟自己說：

等一下再記。

然後：

忘記。

第二種：

傳一段語音給自己。

晚上手機裡：

十幾段錄音。

還是要：

重新聽一次。

第三種：

在群組丟一句：

記得買土。

結果：

哪一種？

買多少？

哪個案場？

什麼時候要？

全部沒有。

這就是很多現場型小公司的：

資訊轉換成本。

Gemini Live 最適合先解決的不是「幫我經營景觀公司」

而是：

現場想到的工作，不要再丟失。

Google 8 月 26 日開始替 Gemini Live 加入更完整的：

語音生產力能力。

其中一條路，

就是可以把使用者一路講出的：

Brain Dump

交給 Spark，

再整理成：

Google Docs

等後續工作成果。

對景觀公司來說，

這比：

「跟 AI 聊植物」

更實際。

老闆第一輪只負責「說」

例如現場可以直接講：

松江案場。
西側滴灌看起來壓力不足，
還不知道是管線堵塞還是供水問題。
目前不要直接判斷原因。
另外培養土剩下大概兩包，
但我還沒確認倉庫庫存。
客戶昨天有提到想加一區香草，
我還沒答應。
下午提醒我先確認：
庫存、
灌溉原因、
客戶到底是不是正式要追加。

講完：

繼續工作。

不用停下來：

打完整會議紀錄。

AI 第一個價值就是把「口語」變成可以工作的結構

例如整理成：

已觀察

西側灌溉異常。

尚未確認

異常原因。

倉庫實際培養土庫存。

客戶提出但尚未承諾

增加香草區。

下一步

查庫存。

檢查水源與管線。

重新確認客戶需求。

這已經比：

一段三分鐘錄音

容易處理很多。

但今天上午教過一件很重要的事

漂亮文件不能讓不確定的東西偷偷變成確定。

例如老闆原本說：

好像還剩兩包。

AI 不能直接整理成：

培養土庫存：2 包。

這兩句：

完全不同。

第一個只是現場記憶

第二個已經像：

庫存事實。

如果接著 Spark 根據：

「還有兩包」

去算採購量，

錯誤就開始：

往後傳。

所以這家公司規定：

凡是語音裡出現：

可能。

好像。

不知道。

還沒確認。

客戶有提過。

全部不能：

自動升級成正式資料。

第二步：把「現場筆記」和「正式系統」分開

這家公司不要讓 Gemini Live 成為：

公司的唯一資料庫。

現場語音整理的定位只是：

Operational Inbox。

白話就是：

今天有哪些東西：

需要處理。

不是：

公司正式庫存。

正式報價。

正式排班。

正式合約。

例如培養土剩幾包

正式答案：

應該來自：

倉庫盤點。

或者：

公司的庫存表。

不是：

老闆上午口頭說：

「我記得還有兩包。」

客戶是不是要增加施工範圍也一樣

老闆說：

客戶昨天好像有問。

不代表：

客戶正式下單。

真正需要：

回到客戶 Email。

訊息。

正式報價

確認。

AI 的任務是：

提醒這件事情沒有確認。

不是：

替公司把它確認掉。

第三步：Spark 可以幫忙把下一步做成工作文件

假設下午回到工作室，

老闆確認：

今天現場有六個待處理項目。

這時才讓 Spark：

進一步整理。

例如：

把今天三個案場的現場語音整理成一份 Docs。
分成：
已確認問題、
尚待查證、
客戶變更、
材料需求、
明天以前必須處理。
沒有正式資料支持的地方保留「待確認」。
不要替我建立報價或下單。

這樣：

一天散落的現場資訊

開始回到：

一個地方。

第四步：材料研究可以讓 AI 幫忙，但不要直接採購

例如某個案場需要：

新的滴灌控制器。

Spark 可以協助：

研究。

比較。

整理。

例如整理：

規格。

適用面積。

相容性。

不同供應商資訊。

甚至建立：

比較用 Sheet。

但是最後：

採購

仍然應該停下來。

因為「規格看起來對」和「公司真的應該買」是兩件事

可能還要考慮：

原本系統相容性。

維修習慣。

供應商保固。

交期。

公司既有庫存。

客戶預算。

現場尺寸。

AI 可以把比較工作：

做快。

但最終責任：

仍然在：

技師與公司。

Google 自己也沒有建議使用者把付款資料隨便交給 Spark

Google 對 Spark 的官方安全說明很清楚：

不要直接在 Spark 的 Task Thread 裡輸入：

登入資訊。

付款資料。

或者你認為：

敏感的資料。

真正需要：

密碼。

付款資訊

時，

Google 建議使用者：

自己接手瀏覽器操作。

所以景觀公司的採購流程應該是：

AI 可以：

研究。

比較。

準備。

人：

確認。

付款。

第五步：客戶報價也不要直接從 Brain Dump 生成並寄出

例如老闆現場說：

如果加香草區，
大概多幾千塊吧。

這句最危險。

如果 AI 整理成：

香草區追加費用 5,000 元。

然後又自動寄給客戶，

那就不是：

整理錯一個數字。

而是：

真的產生：

商業承諾。

所以公司的規則可以很簡單

AI 可以準備：

報價需要哪些資料。

例如：

增加多少面積？

植物品種？

盆器？

灌溉？

人工？

運送？

完成後：

建立：

報價資料缺口清單。

但正式價格：

仍由人填。

這樣 AI 才是在降低行政時間，不是在替公司亂定價

例如 Spark 可以整理：

追加香草區目前仍缺：
實際面積。
植物品種。
盆器數量。
是否需要增加灌溉管線。

專案負責人：

補完。

才進入：

正式報價。

第六步：Daily Brief 可以解決早上最容易漏掉的事情

Gemini Live 現在也加入：

Daily Brief。

Google 表示，

它可以結合：

Gmail

與：

Calendar

的重要資訊，

讓使用者直接：

用語音聽。

對小型現場公司而言，

早上出門前非常適合。

例如老闆一邊裝工具，一邊問：

今天有什麼重要事情？

可能聽到：

上午屋頂花園維護。

下午住宅施工。

某客戶 Email 有新回覆。

某個供應商今天交貨。

這比到了現場才發現：

「原來客戶昨天晚上改時間」

好很多。

但 Daily Brief 不是正式派工表

這也要分清楚。

它是：

資訊入口。

真正員工今天在哪裡工作、

幾點集合、

是否改班，

如果公司已有：

正式排班系統，

最後仍應該：

以正式排班為準。

因為 AI 摘要不是新的 Source of Truth

這和昨天 Ask Gemini：

完全相同的管理原則。

AI 可以：

幫你把散落資料找回來。

但是：

公司一定要知道：

真正正式答案在哪裡。

第七步：客戶改時間，AI 只能先準備

例如客戶 Email：

星期五能不能改到星期四？

Gemini Live 可以：

搜尋。

提醒。

甚至透過 Spark：

查看 Calendar。

整理可能影響。

例如：

星期四另一案場撞期。

某員工已有排程。

供應商還沒到貨。

AI 這時候最有價值的是：

列出：

「如果真的改，會影響什麼？」

而不是：

直接回答客戶：

可以。

一句「可以」背後可能有四種成本

員工加班。

運輸。

材料提前。

其他客戶改期。

AI 如果只看到：

Calendar 有空，

不代表：

整個營運真的：

有空。

所以對外時間承諾最後一定停在人

Google 的 Spark 本身也設計了：

Confirmation

機制。

例如在：

傳送通訊。

修改資料。

購買。

提交表單

等特定動作前，

系統可能要求使用者：

檢查與確認。

但 Google 同時明確提醒：

這些保護措施：

不能保證排除所有風險。

使用者仍然需要：

主動監督。

第八步：這家公司甚至不應該把所有商業資料都放進 Spark

這一點今天一定要說清楚。

Google 目前的 Spark：

不支援使用公司或學校專用 Google 帳號。

現階段主要是：

符合資格的個人 Google 帳號使用者。

所以這個 4 人景觀公司案例，

不是：

「整家公司已經把 Workspace 帳號接給 Spark。」

而是：

老闆使用符合資格的個人帳號，

處理：

非敏感、低風險的工作整理。

哪些資料不要放？

例如：

客戶完整付款資料。

信用卡。

銀行帳號。

員工薪資。

員工身分證明。

密碼。

機密合約。

其他真正敏感資料。

都不應該因為：

「AI 很方便」

就塞進個人 AI Agent。

這反而是一個很重要的企業導入原則

工具能做

不代表：

公司現在就適合用它做。

有些功能對：

個人工作

已經很好用。

但如果要：

全公司部署。

權限管理。

稽核。

資料保存。

公司帳號。

合規

還需要另一套：

企業級考量。

所以這家公司今天真正採用的範圍很小

只做：

現場非敏感 Brain Dump。

工作缺口整理。

公開供應商研究。

自己的 Daily Brief。

內部待辦草稿。

這五類。

哪些完全不讓 Spark 自己完成？

正式報價。

採購付款。

客戶退款。

正式施工範圍變更。

員工排班變更。

對外承諾。

重要合約。

這些：

全部停在人。

這並不代表 AI Agent 沒有用

反而代表：

開始用得成熟了。

因為小公司真正需要的，

不是：

「全部自動。」

而是找到：

最浪費時間、

又最容易驗證

的一小段。

先壓縮掉。

這家公司最浪費時間的，其實是每天晚上重新整理腦袋

做一個假設試算。

以下數字全部是：

SasaDaily 假設數字。

不是 Google 官方 ROI。

假設老闆每天花 45 分鐘整理現場資訊

包括：

重聽語音。

翻 Email。

整理明天要買什麼。

把現場問題寫進文件。

確認有哪些事情：

還沒處理。

20 個工作天：

就是：

15 小時／月。

如果 Gemini Live＋Spark 把這段降到每天 20 分鐘

每天少：

25 分鐘。

20 天：

約：

8.3 小時／月。

也就是：

一年可能累積接近：

100 小時

的行政時間差距。

但再次強調：

這只是：

計算方式示範。

真正能省多少：

要自己量。

而且時間不是唯一 KPI

如果只是變快，

但 AI 每星期：

把三個客戶需求整理錯，

那可能根本：

沒有價值。

所以這家公司至少還要看：

現場事項漏掉幾次。

AI 整理後需要修正多少。

重複詢問客戶的次數。

錯用舊資訊的次數。

真正減少多少行政時間。

還要特別記一個數字：AI 補錯的比例

例如一星期有：

40 個現場口述項目。

其中：

30 個完全正確。

8 個要小改。

2 個把「還沒確定」

寫成：

「已決定」。

後面這兩個：

才是真正需要改善的地方。

因為景觀公司最怕的不是句子不漂亮

而是：

狀態變錯。

材料：

「可能不夠」

變成：

「已缺貨」。

客戶：

「有問過」

變成：

「已追加」。

日期：

「可能星期四」

變成：

「改到星期四」。

這種錯誤：

會直接進入營運。

最成熟的工作流可以只有五步

第一步：Speak

現場：

想到就講。

第二步：Structure

AI 把：

觀察。

未確認。

缺資料。

下一步

分開。

第三步：Verify

人確認：

正式來源。

第四步：Prepare

Spark 再：

研究。

整理 Sheet。

建立文件。

準備下一步。

第五步：Approve

碰到：

價格。

採購。

付款。

正式時間。

對外承諾

停下來。

為什麼這種公司特別適合 Voice AI？

因為：

AI 對辦公室員工最大的優勢，

可能是：

少打一點字。

對現場工作者的優勢卻可能是：

原本根本沒有辦法打字。

這個差距：

很大。

一個工程師坐在電腦前

多打一段 Prompt：

可能只是：

多 30 秒。

一個園藝師正在屋頂施工

要停下來：

脫手套。

擦手。

拿手機。

打開 App。

輸入資料。

可能就直接選擇：

算了。

這就是為什麼：

Voice

對 Physical Work

有特殊價值。

這也是今天案例和之前 GPT-Live 汽車維修案例的延伸

汽車維修廠的問題是：

車主講了一大堆：

異音。

警示燈。

故障經過。

AI 先把：

接車資訊

整理好。

今天景觀公司的問題則是：

工作人員自己在現場產生資訊。

看到材料不足。

發現施工異常。

想到後續問題。

直接用 Voice：

把 Context 留下。

兩者都利用：

「手正在忙」

這個真實工作條件。

再往下一步，才是 Agent

Voice 解決：

輸入。

Spark 解決：

整理與後續多步驟工作。

兩個接起來，

才真正產生：

新的工作方式。

不是：

語音比較酷。

而是：

現場發現問題後，到問題進入數位工作流，中間少了一次人工轉抄。

小公司真正應該算的就是這個

不要問：

Gemini Live 有幾個 AI 功能？

問：

我們每天到底有多少資訊，
是先出現在人的腦袋裡，
最後還要人工抄進系統？

如果這個量：

很多，

Voice AI：

很值得測。

但最後公司一定還是要建立正式系統

如果生意繼續長大，

10 個人。

30 個人。

100 個案場。

不能永遠靠：

老闆的 Gemini Live

當作中樞。

最後還是需要：

正式 CRM。

庫存。

排班。

報價。

專案系統。

AI 應該是：

進入這些工作流的：

入口。

不是：

替代所有企業系統。

所以這個案例真正成熟的終點不是「所有人都用 Gemini Live」

而是：

現場語音：

更快進入：

正確流程。

例如：

發現灌溉異常。

↓

語音記錄。

↓

AI 結構化。

↓

進入正式維修紀錄。

↓

負責人確認。

↓

再產生：

真正工作。

這才是：

AI 工作流。

今天真正的結論

一家 4 人景觀維護公司，

不需要先建立：

複雜 AI Agent 部門。

它可以只先解決一件：

每天都發生的小麻煩。

現場想到的事情，不要等晚上再重新想一次。

Gemini Live：

負責讓人：

用說的留下 Context。

Spark：

負責把 Context：

變成可以工作的結構。

但是：

價格。

採購。

付款。

排班。

正式客戶承諾

還是：

人決定。

如果最後真的每月少掉：

幾個小時甚至十幾個小時

的重複整理，

而且錯誤沒有增加，

那這才是一個：

值得留下的 AI 工作流。

不是因為：

它最炫。

而是因為：

它把原本會從現場掉到地上的資訊，接回了公司的工作流程。

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

每天學會一個 AI 技巧。

每天節省一點時間。

每天提升一點能力。

SasaDaily，陪你一起成長。

推薦閱讀

AI 商業案例｜2026/08/02：汽車維修廠怎麼用 GPT-Live？從接車描述、技師交接到報價確認，減少聽錯與重複詢問

AI 商業案例｜2026/08/26：5 人活動企劃公司怎麼用 Ask Gemini？客戶改期、廠商進場與會前資料一次找齊，正式承諾仍由人確認

AI 商業案例｜2026/08/12：7 人食品原料批發商怎麼用 Workspace Studio？詢價附件自動歸檔、需求整理到業務通知，正式報價與付款前停下來