有個客戶要做一個活動的客製功能，內部盤下來是四十小時的開發。
照規矩，客製開發就是客戶全額負擔。但我們最後只跟他收了一半。
不是因為交情，是因為那些項目裡有一部分，以後別的客戶也會用得到。
一條很現實的線
決定成本分攤的問題只有一個：這次做的東西，以後還會不會再賣一次？
如果會，那它就不是客製，是提前開發的產品功能，只是這個客戶剛好第一個要。 既然公司未來會從它身上賺第二次、第三次，那就沒道理讓第一個客戶付全額。
如果不會，那它就是純客製，只服務這一家的特殊流程， 之後不會出現在任何一份產品規格裡。這種就該全額收，而且不用不好意思。
為什麼要跟客戶講清楚這條線
因為報價單上的數字如果只是「四十小時，收一半」， 客戶會把它讀成議價空間，下次自然會要求同樣的折扣。
但如果你寫的是「其中哪幾項具備產品化潛力、由我方吸收一半成本」， 那你給的就不是折扣，是一個有理由的分攤方式。
差別在於：折扣會被記住，理由會被複製。 下一次談另一個案子，你可以用同一套邏輯重新分類， 而不是從上次的折扣往下再砍一輪。
這條線也在幫你決定要不要接
有些需求聽起來很大、報價金額很漂亮，但盤完之後你會發現， 它百分之百是客製，完全長不出產品。
這種案子不是不能接，但要用不同的心態接： 它是純勞務，賺的是工時的錢，不會累積成資產。 所以人力吃緊的時候，它應該是最先被排到後面的那一種。
反過來，有些案子金額不大，但做完之後你的產品多了一個模組， 下一個客戶就能直接開通。
同樣是四十小時，一個變成資產，一個變成消耗。 報價單上看不出這個差別，但排產能的時候看得出來。
誰來做這個判斷
這條線不能由業務單獨判斷，也不能只由產品單獨判斷。
業務會傾向把東西歸類成產品化項目，因為那樣報價比較好談。 產品會傾向歸類成純客製，因為他們不想維護一個只有一個客戶在用的功能。
兩邊的偏誤方向剛好相反，所以這個判斷要坐下來一起做， 而且要在報價出去之前做完，不是事後補認列。
我的做法是問產品一個很具體的問題： 如果這個功能做出來，你願不願意把它寫進產品的規格文件裡。
願意寫，就是產品；不願意寫，那它就是客製，不管它聽起來多有潛力。
判斷會出錯，所以要回頭看
最難的地方在於，「以後賣不賣得掉」是一個預測。
我做過幾次判斷是錯的：以為會產品化的東西，後來一次都沒再賣出去。
所以這件事值得每隔一段時間回頭盤一次： 當初吸收成本的那些項目，後來真的變成產品了嗎？ 如果連續幾個都沒有，那不是客戶的問題，是我們對自己產品方向的判斷需要修正。
吸收成本本身不可怕，可怕的是吸收了之後沒有人記得要回來看結果。