為什麼客戶不回你？因為你只會「做事」，不會「傳訊號」。
工程師與客戶溝通的本質是訊號傳遞，分四個層次——最致命的是第一層搞錯。
你有沒有遇過這種狀況：合約簽好了，kick-off 也開完了，你寫信跟客戶要資料、要存取權限，結果訊息丟出去就像投進黑洞——已讀不回、半天才回一句「我問一下」、然後又是兩個禮拜的沉默。
你看著進度條動不了，心裡很急，但又不知道該怎麼推。
追太多怕對方覺得你煩，追太少對方好像就真的把你忘了。
這是每個工程師——技術顧問、接案工程師、駐點工程師（FDE）、SI 工程師——遲早都會撞到的牆。
問題出在哪？
工程師訓練裡有一個盲點：以為「做得好」就會被看見。
不會。
對方腦袋裡沒有裝你的攝影機，他看不到你熬夜兩點、看不到你週末翻十篇文件、看不到你為了一個邏輯重寫三次——他只看得到一件事：你主動傳給他的訊號。
所以推進專案這件事，本質上不是「做得好」就行，而是「把對的訊號傳給對的人」。
這篇文章要拆的，就是這四層訊號——以及不做每一層的代價。
簽完約之後，工程師的客戶溝通才真正開始
進入四層之前，先講一個前置觀念：很多工程師對「專案」有一個錯覺——以為簽約 = 案子敲定，接下來就是埋頭做。
但實際進場一兩週之後你會發現：簽約只是入場券。
入場之後的競賽才是真正的本體——對方拖延、需求變動、決策者突然換人、群組裡丟一個問題沒人回、你以為談好的事下一次會議又被推翻。
技術的部分大多數工程師都會做。
真正卡住專案的，往往是這些「非技術」的事：拿不到資料、約不到會議、找不到對的人、講不清楚現在在等誰。
而這些事，全部都是訊號傳遞的問題。
純後端工程師通常做不來這個——不是因為他們技術不行，而是他們的訓練是面對程式碼，而工程師對客戶這件事，必須包括面對人。
程式碼有確定的回應，你打 console.log 它一定會印出來。
人沒有。
你發訊息給客戶，他可能秒回、可能三天後才回、可能根本不回——而你必須在這三種狀況下都能讓專案繼續推進。
接下來四個 H2，就是這四層訊號的拆解。
第一層・訊號送對人：對接窗口不等於付錢的人
第一層是最致命的——如果你把訊號傳給錯的人，後面三層做得再好都沒用。
工程師最常犯的錯誤就是：把對接窗口當成決策者。
對接窗口可能是對方公司的工程師、PM、或是行政人員——他們很積極、很配合、回訊息很快，但他們不一定能拍板。
如果你所有的努力都只到對接窗口為止，到了驗收前一週，老闆突然跳出來說「這個方向不對」，你會發現之前白做的東西全部白做。
這就是第一層的代價：做錯一次，整個案子白做。
所以開始做事之前，要先做一件事：盤點群組裡有誰，找出真正的決策者。
群組裡要找出哪幾種人
具體要弄清楚這幾個角色：
- 誰是真正能拍板的人（決策者）
- 誰是付錢的人（不一定等於決策者，有時候是財務老大、有時候是某個股東）
- 誰只是執行層
- 誰會替你說話（Champion，就是你的「自己人」，會在你不在場時替你講好話）
找這些人不需要搞諜報。
問公司內部知道案子的同事、看 email 簽名檔和 LinkedIn 頭銜、觀察群組裡誰在下指令誰在執行，大致就清楚了。
最直接的一招是試探對接窗口：「這個如果要確認方向，是要問你還是要 loop in 其他人？」對方通常會直接告訴你答案，而且你聽起來只是在確認流程，完全不冒犯。
四種狀況分流，四種推進策略
打聽完之後，你會落在這四種狀況之一——對應四種完全不同的推進策略。
狀況 A：決策者就是對接窗口本人（老闆親自對接型）
溝通鏈最短，直接溝通，重要的事直接丟，推進力道全開。
狀況 B：決策者在群組裡，但日常對接的是執行層
日常走對接窗口，不要每件小事都 tag 老闆（這會讓對接窗口很難做人），但重要進度、關鍵節點要發到群組，讓決策者「順便」看到你的努力。
訣竅是：把工作報告寫得讓老闆滑過去也能看懂結論。
狀況 C：決策者不在群組裡，只有執行層（工程窗口對接型）
最危險的狀況——你做再多老闆都不知道，到了驗收老闆第一次看到成品，任何一個他不喜歡的點都可能變成大改。
要做兩件事：第一，找時機提議開會把決策者拉進來（「我們想跟老闆同步一下方向」——很少客戶會拒絕）。
第二，跟對接窗口的所有溝通都要紀錄完整，因為這些紀錄很可能會被轉述給老闆，等於是你的間接展示——寫得越清楚、越專業，老闆對你的印象就越好。
狀況 D：對接窗口說自己可以決定，但你不確定
最常發生——對方為了顯得自己有 power，可能會把不在自己權限內的事情也說「沒問題」。
用問題試探：「這個老闆那邊也要 sign off 嗎？」或「我們要不要先把這個版本給老闆看一下確認方向？」
如果他急著說「不用不用我可以決定」，但又不肯白紙黑字確認——那他大概沒有。
實戰例子
想像你手上同時接了兩個客戶。
客戶 A 老闆就是付錢的人，自己在群組裡對接——這是狀況 A，日子過得很爽。
客戶 B 對接的是工程背景窗口，配合度高，但你隱約感覺他不能代表老闆——這是狀況 C。
正確的做法是：在第三週左右找個切點，跟對接窗口說「這個架構決策蠻關鍵的，要不要我們約一場會，把老闆也拉進來確認方向？」會議開完，老闆第一次出現在你的雷達上，後面的推進整個會順很多。
如果什麼都不做，案子會默默走下去，直到驗收前才見到老闆——那就太晚了。
第一層做完——訊號送對人了，接下來就是讓訊號持續不中斷。
第二層・訊號不中斷：球不要停在我們這
第二層的核心觀念是：任何時候，對方都要清楚現在等的是誰。
要嘛在你這（你正在做、預計幾號回覆），要嘛在他那（他要回你資料、要做決定、要找老闆問）。
不能是「不知道」。
有一個畫面感更強的說法是——「球不要停在我們這」。
把每件事想像成一顆來回傳的球。
你做完一段，球傳給對方；對方回應完，球傳回你這。
任何時刻，球都必須在某一邊，而且雙方都要知道在哪一邊。
一旦你那邊的球停下來、你卻沒動作，對方就會默認你在擺爛。
「不知道球在哪」就是訊號斷掉。
訊號一斷，對方腦中就會自動填補劇情——「他是不是在擺爛？」「他是不是忘了？」「這個案子是不是出問題了？」
這就是第二層的代價：訊號斷掉，對方在心裡幫你寫故事——而那個故事通常對你不利。
沒答案不是不能回，最低標準是「我看到了」
工程師最常見的壞習慣：沒想清楚就不回。
要嘛在等技術 spike 跑完、要嘛在等同事 review、要嘛就是覺得「我都還沒答案，回什麼」。
但對客戶來說，你不回就是不回——他不知道你是在思考還是在擺爛。
最低標準是這樣一句話：「我看到了，正在跟某某某討論，預計幾號之前回你。」
這比已讀不回好一萬倍。
它做了三件事：
- 確認你收到了（對方不會擔心訊息掉了）
- 把球明確地丟回去/留在這邊（對方知道現在等的是你）
- 給一個時間錨點（對方不需要追你，他知道幾號該找你）
反過來，球在對方那邊也要記錄
很多人以為「球在對方那邊」就可以放著等——錯。
對方公司的人忙、會忘、會被別的事情打斷。
如果你不主動把「球在你那邊」這件事讓他意識到，三週後他反過來會說：「啊我們在等你回啊。」
所以即使球在對方那邊，你也要留下軌跡：
- 在群組裡或 email 裡明確寫出「等 OO 提供 XX，預計幾號之前」
- 過了時間點還沒收到，主動發訊息提醒（不是質問，是「想跟你確認一下進度，前面說的 XX 預計什麼時候可以拿到？」）
這不是客服思維，是風險管理
有些工程師會覺得：「我又不是客服，為什麼要做這種事？」
但這真的不是客服思維，這是風險管理。
出事的時候，第一個被怪的永遠是執行方——這是殘酷但公平的現實。
你要證明球不在你這邊的方法，就是把每一次球的轉移留下軌跡。
紀錄越完整，你越安全。
而且要先認清一個事實：對方公司的人是「自家人」，你不是。
他們之間的訊息你不會全部聽到，他們之間的爛攤子最後也會推給最外面的那個——也就是你。
你能做的就是把自己的每一步都做得清清楚楚，讓任何人翻紀錄都看得出來「這個案子的執行端是 OK 的」。
第二層做完——訊號不中斷了，但光有訊號頻率還不夠，訊號的內容也要對。
第三層・訊號夠完整：追進度不是討好，是傳遞你的動機
工程師對「追進度」這件事普遍有一個誤解——以為追進度就是低聲下氣、就是討好、就是煩客戶。
所以很多人寧願不追，自己默默做、默默等，結果就是案子卡住、自己也焦慮。
但追進度真正在做的事不是討好，是傳遞你的動機——讓對方知道「我為什麼做這個」「我希望你接下來做什麼」「這件事還可以怎麼改」。
你的動機是不透明的
工程師最大的盲點：以為「我認真做、我做得好，對方就會感受到」。
不會。
真相是：你的動機是不透明的。
沒有人知道你心裡在想什麼。
連你的努力，如果沒有透過某種方式展示出來，對方都看不見。
你昨天熬夜到三點、你週末花了八小時研究他們的資料庫、你為了確認一個邏輯翻了十篇 stack overflow——這些事情如果你沒講，對方完全不會知道。
他只會看到：「奇怪，這個工程師三天沒消息。」
所以你必須主動用行為和語言發送訊號，讓對方推斷你的動機。
這就是第三層的代價：訊號不夠完整，對方無法推斷你的動機，預設就是「他在拖延、他在擺爛、他根本沒在做」。
半成品比完整方案更有效
這裡有一個跟工程師直覺完全相反的原則：半成品比完整方案更有效。
工程師的本能是：等到做完、做好、做漂亮再丟出來。
但這會造成兩個壞處——
第一，中間的這段時間，對方完全看不到你做了什麼，他會懷疑你在不在做。
第二，等你做完才丟，如果方向錯了，你前面所有的時間都白費。
半成品讓對方看見「過程」和「思考」，而不只是結果。
它讓對方有機會早點介入、早點修正，也讓對方確信你真的有在做事。
ERD 範例：多一句說明，訊號完全不一樣
舉個具體例子。
假設你要跟客戶確認資料庫架構，你拉好了一張初步的 ERD（Entity-Relationship Diagram，實體關係圖），要丟到群組裡。
兩種貼法，效果差十萬八千里：
❌ 直接丟一張圖
你貼了 ERD，沒寫任何字。
客戶看著這張圖會想什麼？
「這是定稿嗎？還是給我看的？要我給意見嗎？還是只是通知我？他做完了嗎還是還在做？」
於是客戶就⋯⋯不回了。
因為他不知道該怎麼回。
✅ 丟圖加一句說明
你貼了 ERD，後面加一句：
「我先拉了初步架構當參考，後面還要對照你們現有的資料表再調整。如果你看到不符合現況的地方可以先跟我說，免得我後面繞遠路。」
這一句話傳遞了三個訊號：
- 「我先拉了初步架構」——我有在做事，而且已經有產出
- 「後面還要調整」——這還不是定稿，還可以改，你不用怕踩到我
- 「不符合現況的地方先跟我說」——我需要你的回饋，而且原因是合理的（避免繞遠路，不是給你出考題）
對方看到這句話，知道該怎麼回——他會開始挑問題、給意見、補資料。
球順利地丟回他那邊，而且他覺得這是他自己想做的事。
這個原則的應用範圍
ERD 只是其中一個例子。
只要你要丟東西給客戶——草稿、原型、規格書、API 文件、一段測試結果——都可以套這個公式：
內容 + 一句解釋你的動機 + 你希望對方做什麼
不要假設對方會自己推斷。
動機不會自己跑出來，它要用語言送出去。
第三層做完——訊號夠完整了，但訊號是「冷冰冰的工作彙報」還是「有溫度的關心」，差別也很大。這就是第四層。
第四層・訊號有溫度：用好奇心代替查勤
這一層是給那些「不會聊天」的工程師看的。
很多工程師對「建立客戶關係」這件事有一種抗拒，因為腦中浮現的畫面是：要客套、要應酬、要假裝自己懂業務、要陪笑、要敬酒——這些都很累，而且做不久。
會抗拒是合理的。
但其實有一個工具，不需要違背個性、不需要演戲、又最有效——那就是好奇心。
好奇心為什麼幾乎不會讓人反感？
人天生喜歡被關注、被理解。
但要分清楚——這兩件事不一樣。
「被關注」是「你存在於我的雷達上」。「被理解」是「你存在於我的內心」。
表面的關注每個人都能給，所以不稀缺。
真正稀缺的是有人願意花時間搞懂你——搞懂你做的事、你的處境、你的考量。
而客戶端的人平常最缺的就是這個。
他們每天活在「我要你做什麼」「你該給我什麼」的關係裡——老闆給壓力、同事搶資源、其他部門催交付，很少有人真的花時間搞懂他這個人。
所以當你問他這幾類問題——
- 流程類：「這個業務流程之前是怎麼處理的？」
- 痛點類：「你們的使用者最常抱怨什麼？」
- 歷史類：「當初為什麼會選這個方案？」
對方接收到的不是「這個工程師在問問題」，而是「這個人想搞懂我」。
而且這個機制不可作假。
如果你帶有別的目的——想推銷、想套話、想拐他做什麼事——訊號就會反過來，對方一秒就能聞出來。
人對這種差別敏感得不可思議。
所以好奇心是工程師最該用的工具——它不需要演技，只需要你真的有興趣。
追進度不是查勤：旁敲側擊的互動方式
工程師另一個常見的錯誤是把追進度做成查勤——每天問「資料給了沒」「文件好了沒」。
對方會煩，你也會自我厭惡。
有一個比喻很傳神：
跟一個客戶就像在追一個人。
每天問「在幹嘛」很煩。
但分享「我發現巷口開了一家新餐廳賣你愛吃的東西」就不會煩——因為這展現了你把對方放在心上。
對應到客戶關係：
- ❌「資料還沒給齁？」
- ✅「我看到你們上禮拜發的那個產品 release notes，裡面有一個欄位我蠻好奇是怎麼算的，改天聊。順便提醒一下那批資料我這邊還在等喔。」
第二種訊息傳達的是：「我有在關心你們，順便也記得我們那件事。」
對方收到的感受完全不一樣。
這就是第四層的代價：訊號沒有溫度，案子做完關係就結束——你拿到一張結案單，但沒有任何後續。
把對方丟過來的東西認真看過
還有一個很簡單但很有效的招：對方丟過來的參考資料，認真看過。
下次對話的時候，自然帶出來：「你上次給我看的那個圖，我發現裡面有一個地方跟我們現在做的方向蠻吻合的⋯」
對方會覺得「哦這個人真的有放在心上」，信任度會默默累積。
絕大多數工程師收到資料就丟到資料夾裡，需要的時候才打開——這就是差距。
互動頻率不要靠「想」，要靠「試」
很多工程師會糾結：「我應該多久追一次？三天？一週？」
不要在腦中算這個。
去試。
第一次追，看對方回得多快。
如果秒回，代表他重視這條線，你可以維持較高頻率。
如果三天才回，代表他現在沒空，你下次就拉長間隔。
如果根本不回，代表你需要換一個施力點（例如把決策者拉進來、或換到另一個窗口）。
互動節奏是試出來的，不是想出來的。
寧願讓對方覺得有點煩，也不要讓對方覺得你不在乎
最後一個提醒：在「太煩」和「不在乎」之間，選太煩。
太煩，對方頂多翻個白眼，但案子在動。
不在乎，對方默默把你列為「不可靠」，案子不會出問題，但下次就沒有下次了。
而且實際上「太煩」的標準比你想的高很多——大多數工程師根本還沒到那條線，他們是太害羞，不是太煩。
四層訊號都做完了，接下來看一個拉高的視角——這些訊號累積起來，會變成什麼。
四層訊號的長期回報：客戶關係是工程師的個人資產
前面四層都是戰術。
這段拉高一點來看戰略。
四層訊號做下來，累積出來的不只是這個專案的順利交付，更是對方對你的「印象」——而這個印象，是會跟著你走的。
多數工程師有一個線性的思維：這是公司的客戶，我只是奉命來做事的，做完就結案，關我什麼事。
這是錯的——而且是策略上虧很大的錯。
好的客戶關係會跟著你走
換公司的時候，跟著你走。
被挖角的時候，跟著你走。
自己創業的時候，跟著你走。
未來幾年某個你忘了名字的客戶可能突然丟訊息給你說「欸我朋友公司在找人，你有興趣嗎？」——這就是個人資產的價值。
為什麼有客戶端經驗的工程師比純後端工程師更容易累積職涯資本？
因為這種工作天然在累積這個——你每天都在跟客戶端的人互動，每個案子都在拓展你的人脈圈。
純後端工程師可能五年下來，認識的人就是公司內部那十幾個。
有客戶端經驗的工程師五年下來，可能認識五十家客戶端的關鍵人物——而且他們都看過你做事。
這些人就是你的個人資產。
他們會幫你介紹工作、會邀你合作、會在他們跳槽的時候第一個想到你。
投資客戶關係，本質上是投資自己
理解這一點之後，看待「跟客戶建立關係」這件事的角度會完全不一樣。
它不是公司分配給你的任務，是你自己給自己累積的籌碼。
客戶喜歡你，案子會更好做（短期收益）。
客戶記得你，你的下一個機會可能就從他們身上來（長期收益）。
而且這個資產有一個很好的特性：它有可攜性。
你的程式碼產權屬於公司，你的客戶關係屬於你。
公司付錢的時候，你提供時間和技術。
但你跟客戶建立的個人連結，沒有人能從你身上拿走。
你怎麼知道你有一天不會被某個客戶挖走？你怎麼知道你下一份工作不是某個客戶幫你介紹的？
把這個視角內化之後，你對待每個案子的方式都會不一樣——你會更投入，因為你知道這是在投資自己。
技術讓你能做，訊號傳遞讓你能繼續做。
從工程師到能獨當一面跟客戶推進專案的人，你少的不是技術，是判斷力——判斷現在球在誰手上、判斷該推哪個人、判斷該丟什麼訊號、判斷哪些關係值得長期經營。
這些東西沒有教科書，只有現場。
但希望這篇文章可以讓你少撞幾次牆。