痛點之尺 · 拆解《保險科技航圖》
作者 山姆（謝冠生）・喵喵書評創辦人
發布 最後更新
分類：創新
讀過近千本商業書，這篇不複述內容——只用《痛點》的 P.A.I.N. 之尺，挑這本書最該被戳的那一格，講一句你帶得走的判斷。拆一本書的四個步驟 →
填滿診斷表，不等於找到了那個會付錢的痛
《保險科技航圖：診斷工具與行動指南》，副標裡站著的四個字是「診斷工具」。書名沒有掛上任何一項熱門技術，這件事本身就是一個立場。余鳳全在書裡排的順序很乾脆：先看制度、看生態系、看流程，看顧客到底卡在哪一步，技術最後才准進場。
談 InsurTech 的中文書，我手上那幾本大多長成同一副樣子——前半巡禮物聯網、人工智慧、區塊鏈，後半各配一個國外案例。讀完你知道世界上有這些東西，但你不會知道自己公司下一個專案該不該做。把重心從「有哪些技術」搬到「你現在該不該動手」，這本在那堆書裡算是少數。
所以這篇要拿痛點之尺去戳的，是它交給你的那張診斷表。
一張填得完的表，跟一個成立的假設，是兩件事
診斷工具最好用的地方，是它把一個含糊的爭論變成可以逐格回答的問題。這個環節的摩擦在哪、誰在承擔、現在的流程為什麼長成這樣、換了技術之後那個摩擦會不會只是換個地方冒出來。會議室裡吵三個月的事，一張表逼你寫成文字。寫成文字以後，很多原本在口頭上聽起來很有道理的主張，會突然站不住腳——這正是這類工具最值錢的用途。
診斷工具最危險的地方，也在同一個位置：每一格你都填得出來。
填得出來，是因為填表的人就坐在公司裡。流程長什麼樣，他知道；誰在承擔，他猜得出來；顧客卡在哪一步，他從客服月報上讀過。整張表可以在一個下午填完，而且每一格看起來都言之成理。然後它被送出去、被簽名、被歸檔，專案照原案通過。
診斷的價值，在它能把某個專案否決掉。一次都否決不掉的診斷，只是替既定的決定蓋了一個比較好看的章。
住戶要的是別再爬三樓，管委會給的是刷卡進大門
【一個老社區的管委會開了半年的會，決定裝一套智慧門禁。刷卡、人臉、訪客 QR Code，都上了。系統驗收那天大家很滿意。三個月後，抱怨量沒少，只是抱怨的內容換了——住戶真正每天在受的罪，是包裹送到管理室之後，得自己下樓、簽名、再搬上三樓；門禁換成什麼樣，跟那件事完全沒有關係。】（這只是個例子。你們公司上一個做完就沒什麼人用的系統，當初診斷的是哪一格，不妨翻出來對一次。）
管委會的診斷沒有偷懶。他們真的走過流程、真的列出了痛點，只是那些痛點是從管理室這一側看出去的。住戶那一側的代價，沒有人去量。
一家保險公司的處境更難。它跟保戶之間隔著業務員、隔著通路、隔著一份沒人讀得懂的條款；等到訊號傳回總公司的診斷會議，早就被翻譯過兩三手。書裡強調要看生態系，這一點提得對——只是生態系愈長，離「那個人到底在痛什麼」就愈遠。
「痛多深」這一格，書裡量的是流程長度
這是我拿尺量下去，覺得這本書給得最輕的地方。
診斷框架能告訴你某個環節有幾道關卡、耗掉幾個工作天、經手幾個部門。這些都是流程的長度。可是痛的深度，得換一把尺才量得到：有人已經為它掏過多少錢、忍了多久。
一個保戶為了搞清楚自己這張保單賠不賠，願意請半天假跑一趟分公司；一個業務員為了避開系統，自己在 Excel 裡養了一份客戶名單，養了六年。這兩個動作，比任何一份流程圖都更誠實。它們是代價，而代價才是痛的單位。
企業內部的診斷表，天生量不到這種東西。它量得到公司自己的動作，量不到公司外面那個人為了繞過你，多做了什麼。
錢那一格，它把球留給你自己
行動指南走完，導入的代價是清楚的：預算、人力、系統整合、法遵。回收那一側就模糊多了——省下的處理成本、多留住的客戶、多收的保費，書裡談得不像診斷那一段那麼硬。
這在專業書裡很常見，也不算它的失職，畢竟每一家的數字都不一樣。但你要知道自己接手的是什麼：一張標好暗礁的航圖，不會替你算油錢。開船之前，那本帳得你自己攤開來。
先去找一個為這件事自掏過腰包的人
如果你手上正好有一個科技專案在排隊，在填診斷表之前，先做一件不必花錢的事。
找三個真的在承受那個麻煩的人：保戶、第一線業務員、每天處理那疊件的內勤。你的主管和專案窗口都不算，他們承受的是進度壓力。問這三個人同一個問題：為了繞過這件事，你這半年實際多做了什麼？
答案裡如果出現了時間、金錢、或者一套他自己土法煉鋼的做法，那個麻煩是真的，診斷表可以開始填。如果三個人都想了很久才勉強講出一點什麼，那你要診斷的東西，可能一開始就不存在。
把那三個答案抄在診斷表的最上面一行。填後面每一格的時候，眼睛都會被迫先掃過它。