客戶至上不意味著客戶永遠是對的

客戶至上不意味著客戶永遠是對的

昨天在看資料時看到以服務體驗跟服務態度聞名於世界的日本,因為一些服務業人員在服務顧客過程中,因被要求「客戶至上」,甚至被灌輸「客戶永遠是對的」這樣的觀念。而造成許多服務業一線員工,在面對客戶辱罵、騷擾等超過工作職責應該承擔的責任時,仍默默接受。

2018 年大阪 551 蓬萊肉包一位員工,因為被顧客惡意詛咒和侮辱,最終選擇自殺。(來源)

回想起剛出社會時,公司的老闆給了我一個很重要的觀念,他說:「客戶是我們的衣食父母,但客戶不見得總是對的。」

曾有一次公司與客戶之間發生了糾紛,起因是我們的系統確實出了一些狀況,修復的時間確實較久,這部份是我們在服務上應該負擔的責任,這部份本就責無旁貸。

但在與客戶洽談過程,對方的窗口跟主管們不斷的用各種言語羞辱我們同事。其中許多用詞都涉及了人身攻擊以及人格否定。剛開始他的直屬主管本著客戶服務客戶的想法,希望這位同事看開一點。但客戶的行為不但沒收斂,反而變本加厲,罵了一個人還不夠,非得把每個人都罵過一輪。

我們意識到他們的態度並不是為了解決問題,而是試圖將自己公司的其他問題轉嫁到我們身上,並用在道理與合約上站不住腳的甲方姿態,要我們全盤接收。

那一次,老闆處理的態度是:「產品出事,服務不滿意,我們可以檢討,合約上註記的東西如果有無法交付,我們也可以協議賠償。但羞辱員工,欺負員工這種事不能被接受。就算我們在商務上達成和解,針對羞辱員工這件事我們都要跟對方對簿公堂。」

這是我第一次感受到,即便在客戶至上的商業世界裡,還是有老闆願意把員工的尊嚴放在生意前面

我出社會後,合作過許多主管與老闆。確實有很多人會把客戶是上帝、客戶是神、客戶永遠是對的掛在嘴邊,有些主管跟老闆甚至在碰到客戶的不合理或過激的要求時,會希望員工忍忍,甚至逼員工去跟客戶道歉。

他可能不知道,客戶把員工的祖宗十八代都罵了一輪,
他可能不知道,客戶不是要處理問題,他只是在宣洩情緒,
他可能不知道,客戶連他的外型都攻擊,連他身體的缺陷都拿來作文章。

更悲慘的是,有些老闆知道客戶說了些什麼,他卻還是要求員工吞下去

這其實是一種有毒的思維,當賺錢凌駕於所有事情,甚至在人性、自尊、基本的道德良知之上,人在這樣的環境中其實一文不值。

這讓人不禁想到《讓子彈飛》影片中張麻子回應師爺的片段。

你是想站著,還是想賺錢?

張麻子說:「我是想站著,還把錢掙了。」

師爺回答他:「辦不到。」張麻子拿了告訴他:「我全都要。」


這不是你的錯

在台灣,許多職場工作者會很擔心把他跟客戶互動的狀況如實的告知主管。因為他擔心這似乎意味著「我沒搞定客戶」、「客戶對我的表現不滿意」、「我的工作能力可能有問題」。

我曾碰過許多個案,他們在客戶端承受了巨大的壓力,甚至一些不公平的甲乙方因權勢不對等的欺壓。但他們回到公司仍要裝出一副若無其事的樣子,深怕被主管知道自己跟客戶的關係並不好,進而影響到主管對自己的評價

他們有這樣的擔憂並不奇怪,因為許多主管的都以自己的經驗與態度做標準。他們會認為自己之前都搞得定,碰到各種奧客也都能自己調整心態,所以自然而然的會這樣去要求部屬們。

「這不是你的錯。」

這是每次碰到這類個案時我會告訴他們「這不是你的錯。」。因為我們其實很難左右一個人的情緒反應,甚至無法決定我們在工作中會碰到什麼樣的客戶。

我甚至也會跟主管說「這不是你的錯。」。因為過去你在遭遇這些困難時,你的主管並沒有介入協助。讓你一個人獨立完成,你雖然撐過去了,但你可能也建立了「這很正常」的心態,無法更好的去同理你的部屬們。

當員工遭遇到不合理的狀況時,鼓勵他們說出來,並讓他們知道「這不是你的錯。」

老闆與主管的支持,對員工是最大的倚仗。

賦予員工拒絕的權限

就我過去服務客戶的經驗中,大概只有極少數人是屬於那種毫不客氣,一點都不知道如何尊重人的類型,若以比例來說,應該小於 1%。而這類人其實很容易分辨,因為他們的行為很明顯地與其他人不同。

最簡單的處理方式,其實是不做這單生意或把錢退還給對方,但這樣的決策權限公司卻很少授予一線的服務人員

所以一線服務人員只能在他能決定的範圍內回應,因為他們無法承擔失去一個客戶的代價,也不清楚公司對他這個行為會是支持還是責備

如果我們能將拒絕客戶的權限授予員工,讓他們在遭遇到極端的客戶案例時,優先保護自己

把拒絕客戶的權限留給員工,並告訴他:「這不是你的錯,我們會支持你。」

嫌貨才是買貨人?其實只是買錯了產品

有個商業世界長久以來的觀念:「嫌貨才是買貨人。」

這句話是為了告訴我們,一個挑剔、給建議、批評的客人,很可能才是真正有需求的客戶

還記得在 8 年前,公司針對某個很特殊的客戶案例做過討論。這個客戶經常使用我們的平台上課,但他每上完一堂課都會打電話給客服,或抱怨或回饋他的建議。他上了上百堂,也回饋了上百次,而且很多都是重複在提出,並希望我們盡快改進。

而我們之所以不改,並不是因為建議不好,而是他提出的建議太特殊,幾乎只有他自己會需要,並不是我們主要客群的核心需求。剛開始我們總覺得客戶回饋是我們進步的動力,所以每次都還是很用心地聆聽他的需求,並討論他所提出的建議。

但因為這個單一客戶,我們每個禮拜總得花上不少時間服務跟討論他的需求。

後來在一個會議上,我問:「我們能不能全額退錢給他?」

當時我們也針對這問題做了一些討論,現場也有人提到嫌貨才是買貨人這個概念,也有人說汲取客戶回饋才能改進產品的概念。

但我說:「如果他一開始就買錯了呢?他對學英文有需求,但其實他的需求並不是我們能滿足的。那我們要不要跟對方溝通,請他去買真正適合他的產品呢?」

最後我們決定全額退費給這個客戶,但感謝他當初選擇我們,也感謝他一直以來給我們的回饋與建議。

讓買錯產品的客人好好離開,大家都可以少受折磨。

原本只是因為看到一個網路新聞有感而發,但想想還是覺得這件事很重要,值得寫下來跟大家分享。

建立更好的職場與生活環境,從你我做起。

如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

[徵才]方圓國際誠徵兩個新職務

[徵才]方圓國際誠徵兩個新職務

今年四月份,我加入了方圓國際擔任策略長,方圓是一家茶飲連鎖公司,旗下有兩個主要品牌「吃茶三千」與「喫茶小舖」。吃茶三千在海外 30 多的城市有約 130 家門市,喫茶小舖在台灣則約有 60 家門市。 我從去年底開始擔任方圓的顧問,主要協助梳理公司的管理制度、流程與阻礙成長的問題。四月份我轉任策略長,過去這一個多月,我除了 AI 的引入與建置外,我也花了大量的時間重新構思公司的整體策略。 我們進行了「未來十年不變的事」的策略探討,最終設定了十年戰略方向,三年目標,以及 2026 年的關鍵任務。 透過這樣深度的策略思考,我們也藉這個機會盤點了公司目前的人才缺口。 以下有兩個很關鍵的角色是我迫切在找尋的。如果你覺得自己或身邊的人很適合加入方圓,請自薦或推薦給我,謝謝。 歡迎將履歷投遞到:gipi@teashop168.com.tw 門市體驗經理(Store Experience Manager) 門市是接觸終端消費者的最後一哩路,也是品牌傳遞價值的關鍵接觸點。我們在全球因應不同的市場有不同的店型設計,

By gipi
克服 AI 焦慮的方法,唯有實作

克服 AI 焦慮的方法,唯有實作

2018-2019 年左右,線上學習在台灣整個大爆發,線上課程一大堆,每個禮拜都有很多線下學習活動。每天都可以看到大量的學習心得與活動心得,每個人講的內容都很有道理。全台灣好像瞬間變成一個知識島,所有人都學識淵博,而自己似乎懂得有點少。 知識焦慮年代 在那個時候,很多人染上了「知識焦慮」的病症。 害怕別人知道自己不知道的,擔心自己沒跟上世界的節拍,所以哪邊有新知往哪兒去,哪邊學習氛圍濃厚就往哪兒鑽。看起來是因為熱愛學習,但內心的煩惱其實是「害怕失去」。 害怕失去話語權,害怕失去社交談資,害怕失去機會,害怕失去競爭力,害怕自己不再是別人眼中領先的族群。 而克服焦慮最有效的方法,不是知道更多,而是實踐,從時間中獲得成果,獲得進步。 那些仍在學而沒有做的人,焦慮是無法停止的,因為他並沒有真的改變現況。 這也是當年為何我們想舉辦 case study、學習營、打卡、案例練習,並且鼓勵大家多多輸出的原因了。因為輸出,其實就是最輕量的實踐,而動手做,則是讓自己學有所用的基本配備。 在那個知識焦慮的年代裡,因為我本來就熱愛學習,也經常輸出,

By gipi
我如何與 AI 協作開發,我的開發步驟分享

我如何與 AI 協作開發,我的開發步驟分享

昨天到工程師場子分享,想說跟大家對照一下,現在是否多數人都跟我一樣,寫程式完全不手打任何一行 code,全部都是 AI 做的。 結果發現,現場只要有在用 AI 開發的人,多數時候真的都是讓 AI 來完成程式撰寫工作。 目前我的開發組合是 Claude Code / Claude Design / Fly.io / Github / Cloudflare,其他還有根據程式功能需要而使用的第三方元件。 做一個新系統的習慣是: 1. 跟 Claude 討論我想解決的問題,以及我的核心需求,中間我可能會用 Claude Cowork 做本地資料的分析,然後請他廣泛收集一下資訊,做幾輪 prototype 的模擬。確認方向是否是我所期待的。 2. 對完需求後,請他產出系統定位、限制、邊界與 PRD。 3. 把 PRD 跟幾個

By gipi
加快了速度,少了回饋

加快了速度,少了回饋

2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。 在這堂課程中我繪製了一張軟體開發過程管理的架構,這張圖我從公司策略->產品策略->需求管理,一路到開發過程管理、交付、市場回饋,最後再回到產品需求管理。 當年我曾說過,軟體開發最重要的其實不是程式開發本身,而是 align 公司策略與產品策略,同時兼顧好短期需求,將需求管理做好。 但我們也可以看到產品需求管理是上述架構中最主要的節點,上承策略,下接短期需求,右邊則是成為所以開發計畫的起頭,同時還要承接來自市場回饋,並能持續優化管理過程與技術債務管理。 簡單的說,決定做什麼,決定了產品定位,決定先做什麼,則決定了策略重心。但要做出決定,除了對目標有清晰的認知外,更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。 這陣子透入 AI 開發後我對這張架構圖有一些新的想法: 首先,是生產力過剩。 因為 AI 不用休息,生產力幾乎沒上限,

By gipi