「Banner 那邊能不能順便加一個影片輪播？應該很簡單吧。」

做專案對這種訊息應該都不陌生(而且十次有八次會附帶「應該很簡單吧」)。收到的當下，很多人的直覺是趕快回覆、展現效率，好像慢了一步就是服務不周。但不免又會擔心急著回覆卻埋下後續爭議的種子：範圍沒對齊、成本沒算清、承諾說出口才發現做不到。

好的客戶溝通不是回得快，而是回得準。這篇想分享我自己處理需求回覆的三個步驟。

第一步：先對內，確認工程範圍、工時與報價

收到需求後，我做的第一件事不是回客戶，而是先跟工程團隊對齊

：這個需求的實際範圍到底是什麼？

「客戶說的需求」和「實際要做的工程」常常有落差。客戶眼中的「加一個影片輪播」，在工程端可能牽動版面結構調整、載入速度、行動版的呈現方式，以及後台要不要多一套上稿流程。這個落差不翻譯清楚，後面所有的討論都會建立在雙方想像不同的基礎上。我認為 PM 的價值就在於翻譯這個落差

把客戶的願景，拆解成工程團隊可以估算的具體項目。

重點是避開潛在的危機：在沒有掌握範圍與成本之前，任何承諾都是風險。哪怕只是一句「這個應該沒問題」，都可能產生溝通或期待的落差。

第二步：評估客戶接受度，能直接回就直接回

有了工時與報價，先不急著寄出去，我會先做一個判斷：以我對這個客戶的了解，這個數字他們吞得下去嗎？

評估的依據包括幾個面向：客戶的年度預算規模、這個需求對他們的急迫程度、過去合作中他們的決策標準，以及他們對不同類型需求的願付價格。同樣一筆金額，對某些客戶是零錢，對某些客戶要走三層簽核，這些判斷只能來自平常合作的累積。

如果評估下來客戶可以接受，那就直接回覆，乾淨俐落，附上列點說明的範圍、時程與報價，不需要過度包裝。溝通成本也是成本，能一次講清楚的事，不要拆成三封信。

第三步：預判會被拒絕時，先準備好 Plan B 再出手

這是我會花最多心思處理的一步。如果評估下來，客戶高機率無法接受這個報價，那就不要直接把數字丟出去等著被打槍。被打槍之後再補救，後續提供的意見都可能在客戶心中被打折扣。

我的做法是先回頭抓出客戶的核心需求—他們真正想解決的問題或主要概念是什麼—在保留這個核心的前提下，逐項檢視其他功能是否還能拆分，以及在實際使用情境上的必要性。

舉個例子：客戶想做包含多項功能串接的短期活動頁面，我們評估這項需求所需工時和金額都可能超出客戶預期。因此在方案設計上，我會保留「活動資訊完整呈現」、「活動主視覺/行銷包裝」等核心需求，提出不做額外系統功能串接的靜態頁面版本，大幅降低成本，但在實際使用情境中，用戶體驗並沒有被削減。

最後給客戶的不是一個報價，而是兩個方案：Full Plan 是完整需求的範圍、工時與報價；Plan B 是拆分後的版本，針對關鍵痛點對症下藥，把資源集中花在刀口上。

這麼做的核心是：讓客戶「做選擇」，而不是「yes or no」。當客戶手上只有一個選項，他的回應只能是接受或拒絕，而拒絕之後對話就斷了；當有兩個選項，對話會自然變成「哪一個方案比較適合我們」，為雙方都保留更彈性的討論空間。

--

回頭看，這三個步驟背後其實是同一個 mindset：PM 在做的溝通並不是單純的傳話，而是在客戶與工程團隊之間做風險管理與方案設計。對內先翻譯落差、算清成本，對外預判反應、設計選項，每一步都是在降低「說出口收不回來」的風險。