不是你數位工具不夠多，是你根本沒搞懂團隊的實際操作落差。

連客服要怎麼在Google Sheets換行都不知道，就想推n8n自動化？😮‍💨

👉真實案例分享：從手寫便條紙到半自動流程，怎麼偷偷救一線人員又不被主管發現。[^1]

前言

ℹ️如果你是專業PM：
本文僅為基層使用者之自述片段，內文不會提到RICE scoring、impact-effort matrix等工具。

前兩週分享了一些GAS環境的特性，還有我個人偏好的GAS專案配置，第三週則打算開始回顧以前的實作。

在進入實作以前，想先來聊聊實作前的脈絡，讓讀者對於power user，也就是略懂一點現代數位工具、非屬產品開發部門的基層人員，無關程式設計，但在實務上必須考量的部份。

正文

※ 以下案例涉及商業需求的部分經過大幅改編與簡化。

場景簡述

商業需求：客服在交易流程上，開始頻繁需要對不同客人，執行額外之交易步驟。

支援終止：原先依賴之SaaS服務商停止支援上述服務。

現階段執行流程：[^2]

現場A、現場B、現場C產生新event
=> 客服人員listen(event)
=> 客服人員依event執行其它步驟

check(event);
pass(event);
finish(event);

主管return客人名字於LINE群組或Google Sheets
=> 客服人員貼紙本便條紙在每個螢幕旁
=> 客服人員間互相sync對應該名字之相關資訊

下次與該客人交易時，執行額外之交易步驟

流程優化評估

我身為基層客服，直覺上會想使用數位工具來改善這組新的步驟串，從而提高效率與降低失誤率，以大幅減少我加班或我聽同事抱怨的次數。

可是，在實作之前，規劃階段至少必須考量：

1. 所有執行人員之可實操性
2. 對既有執行流程之相容性

可實操性

我必須考量到當前的客服團隊與未來的新進人員，是否能力上有辦法實際操作優化後的新流程。

舉其它場景的例子來說：某社福團體在偏鄉地區有一套基於紙本的流程，運作得還不錯。有外部IT團隊想要進一步電子化，以推廣至全台灣類似的非營利單位。可是，對於該流程的執行人員而言，紙本才是最容易讓每個志工都立即上手的方式。

我的優化方案，必須讓連試算表如何於儲存格內換行都是必要教育訓練成本的團隊，都能立即上手。

相容性

有能力執行 ≠ 願意執行

在《Web制作者のためのUXデザインをはじめる本》這本書裡，作者們由下至上、逐位擴展願意實踐UX的夥伴，因為就他們的經驗，日本不同於美國，會受到組織文化的限制，難以由上而下地推行。[^3]

同樣的，如果要強制性由上而下推行，必須先取得主管的buy-in。然而，這個案例屬於operational friction，透過flexible workload accommodation即可維持運作，那就顯然不會是managerial pain point，我必須找到真正的value proposition。

又或者，更實際的做法是，我先找到有同樣不想加班、願意實踐WLB的夥伴，一起維護優化版流程的同時，確保對於既有流程的相容性。

漸進式優化

以網頁開發為例，一個已經在線上運行的、香草風味JavaScript的網站，如果有大幅擴展的需求而想進一步導入Vue腳架，可以先把部分程式碼重構進template/style/script，再漸進式將其它部分也逐個重構，接著導入Vue的其它功能。

在這個案例，另一個需要保持相容性的原因是：這是一個24小時運行中、涉及交易行為的流程。不可能有時間一次性將所有流程進行完美大改版，且商業需求很可能會變動。

所以，在持續追加業務量的情況下，必須將優化目標盡可能拆分成無數個小票，每天盡可能擠出些微時間交付、溝通、對齊商業需求、再交付，以對沖loading增加所帶來的process fragmentation與overtime burden。

後話

有些時候，我會覺得自己所處的工作場景與社群媒體上講師們所描繪的自動化願景之間，橫亙著一道深不可測的裂谷。[^4][^5][^6]

這裡試著擬一個正向的結語，給也正面對著裂谷的讀者：這些看起來不起眼的工作上的小優化，雖然看起來沒有其它工具fancy[^7]，但其實就是在每天擠出的縫隙裡，一點一滴蓋一座小橋。久了你就會發現，原本那道深不可測的裂谷，開始有幾塊木板搭起來，偶爾還有同伴一起在橋上釘釘子。

Annotations

[^1]： 此段hook由比我懂行銷文案的GenAI様依「安安，我想騙其他PM點進來看這篇文章，給我一段hook」指令所生成。持平來說，我覺得如果能用n8n完全取代操作所有試算表，就可以解決小公司用人主管在人才市場上招募不到會使用試算表的下屬的痛點吧？此外，實際上這個案例的原型，花了很多時間在跟立場不同的大小主管溝通，但果然hook就要這樣下才可以騙點閱吧？

[^2]： 該Google Sheets的示例可參見昨天（Day14）閒聊的小故事。

[^3]： 我個人覺得美國實際上如何可能不是重點，畢竟當年美國裁員潮時，UX也是相對比較快被精簡或裁撤的那方。主要是作者們在成書時的時間點的行業地位，暫時對於日商既有企業文化還沒那麼大影響力，所以當然必須選擇由下至上推行。

[^4]： 某方面來說也挺正常的，就如同在某些線下meetup或大型年會，XX專業的朋友也會吐槽台灣公司有做到XX就偷笑了。

[^5]： 不談對於API key的處理，光是涉及獎金分配的試算表，就在沒有設定公式保護的情況下，直接delegate給資深但沒有相關經驗的人員處理，並且在發給獎金前沒有任何檢查步驟，從而在誤刪公式的日常微災難中，增加了客服的工作量。

[^6]： 在某些服務大企業的自動化SaaS服務趁著大AI行銷敘事，試著把市場也拓展到一些中小企業或獨立接案者時，也仍然有非常多公司由於在人才市場上可投入的資源極其有限，必須盡可能採用相對保守的作法；又或者反過來，投入大量資源buy-in新工具、新服務，卻沒有投入相應的教育訓練成本。

[^7]： 也不可能比Deno可愛😝（硬要業配）