管理 Management > 業務銷售
feature picture
賀大新 / 攝影

重「情」的客戶,你講「理」就沒用!我當店長 3 年學到的寶貴經驗

2020-04-20 採訪‧撰文 周頌宜
分享
收藏

經過超商,你可能心血來潮,走進去買杯 40~50 元的拿鐵;但是動輒數百萬,甚至上千萬的房子,不太可能草率買下。銷售房子不像賣水果、上館子,顧客短時間就可以決定;買賣房子是長期抗戰,客戶可能看一、兩年還不會下手,房仲業者要如何拿下好業績?或即使自己有獨到的銷售心法,被賦予帶領團隊業績成長的任務,又要如何做到?

自 2016 年起就是信義房屋台中新光店年度業績保持人的周子凡,2017 年被指派為台中逢甲惠來店店長,當時全店 5 個人的業績比他一個人的業績還低。但他接手第一年,逢甲惠來店業績就翻倍成長,到 2019 年該店業績已是當初的 5 倍之多,更榮獲中區之冠。如今,平均 25~26 歲的年輕團隊,7 位同仁業績都破百萬(不包含兩位新進人員)。

延伸閱讀:3 萬人來用餐、零客訴!他如何讓生氣的客人,最後都笑著離開?

為客戶需求分類,找到問題背後的問題

「業務人員其實是變色龍,」周子凡表示,自 2012 年大學剛畢業進入房仲業,從一房一廳的小套房到台中市市政商圈的豪宅,隨著服務不同的客人、商圈,他最後歸納出一套「待客法則」,也把這套法則傳授給同事。

歡迎訂閱《經理人》電子報,每天進步1%,一年強大37倍!

周子凡將客戶分成 3 種類型:感性型、理性型、投資型

感性型的顧客,跟他說再多道理都沒用,必須先解決「情」的問題,才能說「理」。他舉例,有次下屬氣沖沖向他抱怨,「客戶瘋了,開天方夜譚的數字,不可能賣得掉!」周子凡不想放棄,便主動承擔這個案子。

和客戶見面時,周子凡並未先說「這個價格太離譜」,而是問「你為什麼想要賣房子?」先理解客戶的堅持是什麼,才可能解決問題。「這間房子我結婚就住進來,風水好、生活順遂。」原來,客戶非常喜歡這棟房子,只是因故須搬家,不得不出售;賣房子對他們來說彷彿嫁女兒,為的是找到一個會好好愛惜它的人。

了解客戶的心情後,周子凡動之以情,說明想要買房子的人與他們當初相似,也是一對新婚夫妻,想要找一幢好房子。這時,屋主態度軟化,周子凡便趁勝追擊,為雙方安排見面,有同樣心境的兩方一拍即合,「你們最多可以負擔多少?」屋子最後以買方的開價成交。

要當客戶的顧問,釐清盲點、提供專業解答

對於理性客戶,業務要成為他們的顧問。「坦白說我最怕這種客戶,他們很敢挑戰你,回答不出來一次、兩次,就容易失去信任。」為了贏得這類客戶的信任,周子凡必須強迫自己學習更多新知識,每天解答兩個需要深入研究的問題。例如「中美貿易戰對房市的影響?」「A 區和 B 區的房子,哪棟較保值?」一天兩個問題,一年就會累積 700 多個新知。

至於投資類的客戶,他們想利用房子賺錢,像是出租套房、店面等;為了提高租金,較易產生過多的「不滿意」。面對這種客戶,周子凡將自己視為他們的投資夥伴,將每一戶房子的投報率理清楚,再仔細分析利弊。

比如說,客戶想要街邊店面,但位置好開價就高,投報率相對低;如果是巷內店面,位置稍差,投報率卻可以拉高。為客戶釐清盲點,找到他們重視的價值,才可能成交生意。

周子凡表示,將客戶需求分類是房仲的基本技能,每個人的生活歷程不同,一個招式不可能打天下;理解客戶是哪類型的人,進一步挖掘問題背後的問題,才能對症下藥,贏得信賴。

挫折只是短暫情緒,兩年後來看,根本沒什麼!

相較其他職業,房仲必須具備強大的心臟,尤其是業績不好的時候,如何鼓勵其他人持續保持戰鬥力,也是當主管的必修課。

「業務最大的問題來自自己,」周子凡直說,每天都在面對各種失敗,有可能苦心經營的客戶選擇放棄、也可能已成交的案子突然反悔;但是他通常只允許自己難過一下子,不會讓低潮的心情影響工作、部屬。

周子凡鼓勵夥伴的原則有二,首先是引導對方把目光放遠,「你還記得兩年前遇到哪些挫折嗎?」「好像……不記得了!」既然已經走到今天,就代表你已克服阻礙;而現在碰到的問題,兩年後來看也是如此;何必將寶貴的時間,浪費在懊悔上?

對眼前的困境釋懷,是成功的第一步。接著周子凡會請對方回想以業務人員為職業的初衷,不外乎財務自由、給家人過好的生活,「你都還沒達到目標,就要放棄嗎?」周子凡認為,不時提醒自己「為什麼進入這行?」堅定自己的目標,才能面對排山倒海的壓力和挑戰。

相關文章
管理 Management > 產品與專案
feature picture
經理人

專案經理救進度的 3 項基本功:詳拆任務、精算時程、收斂待辦

2022-04-19 採訪.撰文 高士閔
分享
收藏

「專案唯一不變的,就是它一定會變更!」台灣IBM 諮詢資深專案經理林憲哲解釋,客戶需求講不清楚、上周交辦的任務,下周又要改變,對於專案經理來說,這些都是家常便飯,他半開玩笑說「哪天不用更改,會感覺專案不正常。」

需求變更與進度管理是專案過程中常見的挑戰,一旦計畫出現偏差,往往會讓團隊陷入疲於奔命的狀態,甚至影響最終成果。《經理人》推出線上課程「從觀念到實踐一次學會|專案管理 15 堂課」,結合實務技巧,幫助團隊掌握任務拆解、時程規劃等關鍵方法,化解不確定性,讓專案推進更有條理。

對於專案經理而言,一切都按計畫走是理想。因為,一旦發生意外,同仁可能為了趕上進度,草草做完,日後又要修改,陷入惡性循環;或者,需求增加太多,只能強迫團隊處理,最終導致專案失敗。

專案之所以會有各種意外,有 2 個主要原因。第一種是不清楚「必須完成什麼」;第二種是錯估時程。以打掃為例,第一種就是隨興地看到什麼收什麼,摺了衣服,倒了垃圾,才發現沒有掃廁所。第二種就是,以為一個上午可以收得完,結果花了 3 天。

延伸閱讀:時程一拖再拖,專案經理好焦慮!7 大工具改善延宕問題,高效完成好產品

善用工作分解結構,拆成待辦事項

如果單憑感覺、經驗列出待辦事項,很容易遺漏、忽略。《我懂了!專案管理》建議,可以採用工作分解結構(WBS,work breakdown structure),常見的方式有幾種:

以交付項目拆解:用「自行車開發專案」為例,想生產一台自行車,你必須擁有車體、變速系統、煞車、輪胎等零件,它們就形成第一層任務(別人要交付給你的項目)。之後,可以再往下細分,像是車體可分為車架、坐墊、踏板、車把。

以次專案拆解:如果專案規模龐大,每一項子任務彼此關聯性小,可以先分成「次專案」,再往下拆分。比如「高速鐵路」專案,可以先拆分成為車站站體、鐵軌工程、車體建置、營運系統等。下一層再根據地區細分,譬如「車站站體」可以分為台北、桃園、新竹。

以產品生命周期拆分:又稱流程分解結構(PBS,process breakdown structure),簡單來說,就是根據時間先後,依序排出任務。像是「軟體開發」專案,必須先「蒐集需求」,再進行「系統分析和設計」,之後才能「撰寫程式」「測試上線」。

工作分解沒有規定一定要拆成幾層或幾項,《學會專案管理的 12 堂課》提醒,原則上愈細緻,愈不會有誤解,但展開本身也要花時間,專案經理須從中權衡。《SCRUM 敏捷產品管理》指出,分解完項目,最好與團隊成員討論,確認工作量可行。

需求明確的專案,細分項目後再加總時間

至於時程估算,《學會專案管理的 12 堂課》建議 2 種方式,一是由上而下估算(top-down estimating):如果公司曾做過類似專案,就可以根據它來推估時程。假設業界標準是一個人工作一個月(人月)能開發 16 個功能點,今天接到一軟體開發專案,根據過去的資料大約有 1600 功能點。專案時程就是 100(1600 / 16)人月,如果公司願意投入 5 位工程師,專案就能在 20 個月(100 / 5)完成。

之後,再根據 WBS 拆分的任務,估算每項任務的時間。比如「軟體開發專案(時間占比)」分為收集需求(15%)、系統設計(30%)、開發測試(50%)、安裝上線(5%),每項任務所需時間就很清楚,像是開發測試需要 10 個月。

由上而下估算,既快速又省成本,卻很粗略,由下而上估算(bottom-up estimating)優劣勢正好相反,估算精確,也比較花時間。簡單來說,就是利用 WBS 細分工作之後,算每項工作要花多少時間,再加總。以「收集需求」為例,可以分成問卷設計、蒐集問卷、文書處理、分析結果、撰寫報告等步驟,耗時都是 0.5 人時,加總是 2.5 個月。

林憲哲提醒,以上方式,只適合需求固定,變化不大的專案,像是建立人資系統;如果需求不明,比如數位轉型,由於市場還沒有先例,就得用「用戶故事點數」估算時程,比如以 T 恤尺寸(XS、S、M、L、XL)為任務難度分級。

《敏捷專案管理基礎知識與應用實務》指出,由於需求不清楚,估算誤差很大,所以估算時程最好用相對大小,像是用「費氏數列(即1、1、2、3、5、8、13、21…)」估算點數,由於每一個數字都是前 2 個數字的加總,代表距離愈遠的案子愈困難。例如,要爬到 4 棟樓的頂樓,要花多少時間?由於不確定建築的高度、老舊程度,以及自己的體力,因此把第 1 棟的分數假設為 1,第 2 棟是 3(1+2),第 3 棟是 5(2+3),第 4 棟是 8(3+5),時間愈靠後,分數愈高,難度愈高。

4 面向評估待辦清單,避免任務無限累加

如果出現意料之外的任務該怎麼辦?台灣敏捷協會理事林裕丞建議,採用「待辦清單」來管理專案需求,清單愈上方的任務愈重要,要先做;新增需求如果離主要目標太遠,就會安排在清單下方,最後可能會發現不做也沒差。

《SCRUM 敏捷產品管理》指出,可以從 4 個面向:價值、不確定性與風險、可發布性,以及相依關係,來建立待辦清單。

價值:該任務是不是產品上市的必要項目?不包含該項目,是否仍能達成預期效益?例如,蘋果(Apple)第一代手機訴求:流暢介面、行動上網和行動音樂,一上市就廣受歡迎。但你知道,一代蘋果是不能複製貼上的嗎?你不知道,因為這個功能沒那麼重要,所以可以列在產品清單最底部,甚至完全捨棄。

不確定性與風險、可發布性:專案的風險愈高,失敗機率愈大。風險代表不確定性,不確定性源自知識不足。因此,不確定性愈高的專案,優先度愈高,因為愈早做,就能愈早獲得新知識。Google 的第一版新聞應用,開發團隊不確定該按照日期或地點篩選新聞,最後乾脆都不做,先測試再說,結果有 300 人要求日期篩選,只有 3 人要求增添地點,答案自己浮現。

相依關係:簡而言之,就是任務與任務之間互有關聯。《學會專案管理的 12 堂課》建議,排定優先順序時,要注意 3 種關係,分別是前後關係(FS,finish to start),像是「粉刷壁面」完才能「貼壁紙」;同時進行(SS,start to start),比如「吃早餐」和「看新聞」;同時完成(FF,finish to finish),例如「每周運動 3 天」和「進行網球訓練」。

延伸閱讀:專案管理工具推薦!善用「視覺化」溝通,跟客戶、團隊不再雞同鴨講

《SCRUM 敏捷產品管理》提醒,如果 2 個任務屬於先後或同時,可以考慮用不同方式分割。比如說,「身為使用者,我想寫文字訊息」和「身為使用者,我得寫 email。由於兩者都涉及文字處理,先處理哪一項,都能提升後一項的工作效率。不過,更好的方式是結合成「身為使用者,我想要輸入文字。」

總結來說,需求明確、固定,就套用 WBS,並由下往上計算時程;需求模糊、變動,就列出待辦清單,以用戶故事點數估算工作量。傳統專案管理和敏捷專案,並不是互斥的關係,清楚自己要什麼,它們就是互補的工具。

限制「正在進行的工作數量」,避免時程延宕
經理人
相關文章
追蹤我們