從便條紙到試算表，再到Web App——
這不是產品roadmap，而是我為了準時下班必須走過的流程優化之路。

前言

昨天（Day15）提到了因應新的商業需求，客服人員需要執行額外的步驟；今天就繼續流水日記地回顧我當時的思路與優化方式。

正文

ℹ️正文沒有具體的程式碼，明天才會重回實作技術面。

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

個人需求釐清

核心需求：準時下班

避免因sync資訊不同步或漏掉便條紙，而導致需要事後花更多時間執行額外之交易步驟或溝通步驟，從而需要責任性或善後性加班。

次要需求：

1. 避免自己發生疏失，因為往往會伴隨營業損失。[^1]
2. 避免同事因為雜亂的流程，每次疏失發生後，需要花額外時間與心力處理同事的情緒。

初步實作

統整事實基礎

首先要處理的問題是sync資訊時之效率。

由於現實世界的event並不像前端開發般是統一規格的、結構化的event object，每一個stakeholders都可能不小心漏掉資訊，或基於各自立場有意圖地return經策略性調整後之資訊，必須從不同訊息載體或訪談口述去試圖建構出相對一致的事件脈絡。

這並不是把LINE@、email、SaaS等訊息載體串接起來就可以有效解決，暫時只能case by case，所以儘管這才是最花時間、最沒效率的部分，但只能先擱置於backlog。

backlog
1. 需求：更有效率地驗證多方資訊並統整。

不過至少，我可以把口耳相傳與零散公告整理成一個表格，它除了可以讓大家有一個共識基礎以外，未來問責時也可以作為單一事實來源。[^2]

實際上，花費時間重新爬梳，便條紙之間確實漏掉了部分名單與事件脈絡；缺少事件細節，客服人員將無法有一致的對外溝通。

我將表格分享給可能有需要的人，同時保持相容性，讓不buy-in的其他夥伴，可以繼續使用便條紙與不可白紙黑字化之事件脈絡。理想上，我希望能以共筆形式共同維護：

backlog
1. 需求：更有效率地驗證多方資訊並統整。
	1. 方案：增加共筆夥伴與建立驗證規範。

整合交易步驟

在有了一個共同表格之後，就不用擔心便條紙被漏掉，或資訊更新不即時。然而，隨著events增加，如果每筆交易都必須對照表格，依然不夠有效率且仍可能會漏看。

我希望有一個新的方案，能同時滿足：

1. 100%不會失誤
2. 融入既有交易處理流程

上述兩點非常好達成。因為當時我已經有維護幾個Web Apps，用來輔助交易處理流程[^3]。我將表格的資訊導入Web App，新增一個feature：當客服人員點擊按鈕時，同時比對該表資訊，並render是否需要進行額外交易步驟。

由於點擊的按鈕，本來在處理交易時就必須點擊，這不會產生額外的步驟。換言之，雖然有新的商業需求，只要事先彙整好資訊，就可以在不增加額外步驟的前提下，100%無誤地處理該筆交易。

流程優化

目前優化後的流程：

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

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

主管return客人名字於LINE群組或Google Sheets
=> 客服人員貼紙本便條紙在每個螢幕旁
=> 客服人員間互相sync對應該名字之相關資訊
// 追加步驟
=> 驗證資訊並整理成一個表格 as SSOT

下次與該客人交易時，執行額外之交易步驟
- 在腦海裡留意是否為特殊客人並查閱便條紙
// 可選優化方案
- 使用Web App檢查是否需要額外交易步驟

讓我用昨天（Day15）提到的再次檢視優化後的流程：在可實操性上，客服只需要點擊按鈕，這應非太困難的操作。在相容性上，比較信賴自己記憶能力的客服人員，仍然可以不使用Web App（包含其它相應的自動化功能）。

總之，由於失誤會導致事後需至少額外花費一位客服人員一小時以上的服務量能，且往往伴隨營業損失。我這裡實作的新方案，可以降低失誤率，並減少客服人員的loading。

後話

連假這幾天的文章非常之個人日記，明天應該終於可以回到跟程式碼有關的部分，我覺得後者寫起來比較開心。

程式碼不是核心

我猶豫過是否要把無關程式碼的脈絡攤得這麼大，實際上撰文時依然大幅簡化了案例原型。

我主要想分享的是，對於power user而非產品開發部門的專業工程師而言，程式碼實作的部分在實務場景上，都是相對次要、可控的部分，大部分的時間是在進行溝通與資源分配。

每個人的需求不同

例如正文提到，我開發了陽春的Web Apps供三組客服團隊使用，以用來填補既有系統之不足。A團隊會很積極跟我反應電腦中毒或系統升級；B團隊則相對不採用，即便這常常導致在我個人主觀看來，原本可以避免的無謂的事後互相推責。

訪談B團隊的某客服，實際上該客服曾事後花額外時間與客人周旋，不僅會導致加班，還會造成額外負面情緒。就客觀事實上，該客服不僅僅於值班日加班，假日也會盡可能支援其他部門繼續加班。雖然該客服沒有明述，其實不難理解，加班才是他的核心需求。

同樣的，儘管實作上能夠把某些資訊更加攤平、透明，從而提高效率，但也必須考量到stakeholders的需求。例如前天（Day14）提到的，主管的角色通常需要保留部分information asymmetry，不論對老闆或對下屬，才能保有strategic adaptability與tactical bandwidth。

Annotations

[^1]： 昨天提到，必須找到主管真正的value proposition。直覺上，客服人員未執行應執行步驟所造成的營業損失，應當是主管的value proposition。實際上，現場運營主管與負責業績的主管不同，導致彼此在資源配置上的優先順序有所落差，而個人直屬主管更傾向將資源集中於其直接負責的業績場域。簡而言之，該現場的營業損失並非直屬主管的value proposition。

[^2]： Single Source of Truth (SSOT)，保證所有人參照同一份資料，不會有人靠紙條或八卦活在平行宇宙。

[^3]： 技術選型上，如果當時並無既有Web App，就不一定要選擇此路徑，畢竟Google Workspace或微軟辦公軟體等也可以用來填補既有內部系統之不足。