avatarAnne Hsiao

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

5233

Abstract

="d616">有時也不單單是增加資源就能夠解決問題,產品團隊分工與組織架構很難分乾淨,難免有些模糊的三不管地帶,說老實話若對公司的價值也不大,很容易造成某些問題與需求總是沒有產品經理主動去接、主動回應,客服團隊三番兩次提出了,卻總像是提心酸的。</p><p id="cd3a">理解彼此的難處後,產品團隊與客服團隊可以時常/事先針對不同目標、突發狀況的優先級與緊急程度,討論短中長期的產品目標與產品路線圖,盡量讓整個團隊都瞭解優先順序與緊急程度的原因(雖然很難),當事情發生時,可以有一致的討論與決策方向。</p><blockquote id="7e9a"><p>延伸閱讀《<a href="https://readmedium.com/prioritization-strategy-for-product-managers-7d4ff6cd8ac5">產品經理日常掙扎:如何制定產品優先級策略 Prioritization</a></p></blockquote><div id="048f" class="link-block"> <a href="https://readmedium.com/say-no-to-the-stakeholders-and-customers-840cd559a56a"> <div> <div> <h2>不知道怎麼面對各種產品需求嗎?現學現賣的工作方法與溝通術!</h2> <div><h3>擋需求的5個小撇步&拒絕客戶需求的溝通模板</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*IdOh6C2cxWtNdE13Npcpyg.png)"></div> </div> </div> </a> </div><h1 id="c1a6">▍產品經理與客服團隊合作,建立回饋流程!</h1><p id="ff83">早期團隊人數及客戶數量不多時,我們直接使用 Excel 表單來記錄第一手的回饋,而隨著團隊與客戶變多,我們改為使用溝通工具 <a href="https://www.intercom.com/">Intercom</a> 串接產品規劃工具 <a href="https://www.productboard.com/">productboard</a> 來讓我們清楚看見質化回饋內容的同時,也可以透過分類與權重來量化問題的規模。</p><h2 id="0bee">蒐集回饋的工作流程</h2><ol><li>客戶透過 Intercom 給予產品回饋</li><li>客服團隊詢問清楚問題後,將該客戶的產品回饋下註解並分類</li><li>被標註的 Intercom Convo 內容會自動按照分類進入 productboard 中</li><li>產品經理認領自己負責的產品區塊,進行更深入的整理和主題下標</li></ol><figure id="a5c3"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*_dNB7gjHJse3zs2JbrpJHA.png"><figcaption></figcaption></figure><h2 id="98c7">整理回饋的工作流程(延續上面步驟)</h2><ol><li>產品經理認領自己負責的產品區塊,進行更深入的整理和主題下標</li><li>整理完後,除了可以看到不同問題被客戶提到的數量,也能自行下不同的權重與標記。舉例來說,商業價值、資源限制、由重要客戶提出的需求</li><li>透過排序與挑選,可直接使用 productboard 產出產品路線圖來跟客服團隊討論與溝通</li></ol><figure id="05f7"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*X1_RpcHj_51TODHbpkz8vw.png"><figcaption></figcaption></figure><blockquote id="f937"><p>真的沒有業配!更多詳細功能請見 <a href="http://com">productboard</a> 官網介紹,找到一個好的工作方式與工具真的能幫團隊節省非常多時間跟資源呢~~~</p></blockquote><h2 id="84aa">分類的藝術</h2><p id="4b5e">我們在使用這個流程的時候,產品的功能與模組已經非常多元,也已經超過五位產品經理,因此客服在收到回饋後要如何分類,不但牽扯到客服的工作內容、也牽扯到產品經理接下來如何認領,若設計不良就會造成前面提到部分「三不管地帶」的回饋會沒人處理的狀況。待討論的問題如下:</p><ul><li>按照什麼依據來分?</li><li>分類要分多多細?</li><li>避免無限多分類的狀況,什麼情況可以開新的分類?</li></ul><div id="c769"><pre>管他的先開始分分看吧!但是...</pre></div><div id="8ba3"><pre>・按照「功能」來分的話,針對單個功能的優化是沒有問題,但如果是一整個流程的優化呢? ・按照「功能」來分的話,如果客戶提出的是模糊問題,客服又要怎麼分類跟下註解? ・按照「流程」來分的話,若該流程牽涉到多個產品經理的職責,要怎麼分工認領? ・按照「問題」來分的話,有些問題提的不清不楚,深入探討又是不同的新問題,怎辦? ・按照「目標」來分的話,有些客戶需求搭不上公司或產品目標,又要怎麼分?</pre></div><blockquote id="471e"><p>欸不對,產品團隊你們自己原本怎麼分工的啦吼! 能不能參考一下? 團隊問題詳見《<a href="https://readmedium.com/evolution-of-product-managers-in-fast-growing-startups-team-collaboration-4ad735c1b3ac">團隊變形記 — 中大型軟體產品團隊、產品經理的組織分工</a></p></blockquote><p id="0839">認真討論客服團隊分類的難題後,我們發現<b>這個難題中最重要的目標,是讓相對應的產品經理去認領</b>,再讓各產品經理自己做客戶研究的需求來整理回饋。因此不需要分得太細、先做再說,無論用哪種方法來分類,只要發現有跟其他產品經理職責重疊、或三不管的東西,就提出來討論。</p><p id="f984">而下個難題就是產品經理認領後,如何更深入的進行客戶研究並對依照不同的「主題」下標。這個主題可大可小,依照問題的清晰程度、產品經理的信心程度等會有不同的呈現方式,可以是問題、需求、功能,對我來說目標就是可以對要處理的問題有足夠明確的界定,足夠讓我們繼續做研究或設計。</p><blockquote id="bdea"><p>延伸閱讀《<a href="https://www.tenlong.com.tw/products/9789864768356">產品路線圖:第五章 從主題發覺客戶需求</a></p></blockquote><h2 id="2f57">辨認與產出好的回饋內容</h2><p id="4ccf">在使用這個流程的過程中,我們發現其中一個很大的問題是,客戶的需求講的不清不楚,產品團隊看得不明不白,不但難分類,就算分類完成後,也還是要花很多時間重新釐清個別客戶的使用情境與需求,最後也可能發現分在同一個類別中的回饋們,根本是徹底不一樣的問題樣貌!</p><p id="7505" type="7">如果我當年去問顧客他們想要什麼,他們肯定會告訴我:「一匹更快的馬」——亨利・福特</p><figure id="b623"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*QAgTgXiBmI_9gcW3-wiCjA.png"><figcaption></figcaption></figure><p id="36d4">以「更快的馬」為例,背後的原因可能是完全不同的:</p><ul><li>移動速度太慢,來不及見病危家人最後一面(人)</li><li>移動速度太慢,食物貨物送達時已經過期(物)</li><li>通訊速度太慢,無法即時傳達重要訊息</li><li>……</li></ul><p id="dcba">也因此往下研究後,更快的馬也許是其中一種解法,但不是唯一解法,若完全按照客戶的想法去執行,就喪失探索更多更好解法的可能性與機會了!甚至更慘的是,最後沒能真正解決問題!</p><p id="e430">在跟客服團隊溝通之後,客服團隊也理解產品團隊的難處,因此會在客戶提出新的回饋時,問清楚使用情境、描述他的痛點與期待,試圖找出客戶提出需求背後的原因,用更完整的方式來處理客戶回饋。</p><p id="be29">客服團隊可以在 Intercom 裡面加入只有內部團隊看得見的註解,整理這個客戶的需求與脈絡,再傳遞給產品團隊,同時產品團隊也可以在 Intercom 後台看到關於這個客戶的基本資料或數據。</p><p id="3233">透過兩個團隊的合作與工具的幫忙,我們建立起一套「客戶回饋清單」架構,包含客戶原始資料、客戶回饋內容、客服整理與分類的洞見,讓產品團隊可以接續使用這些資訊建立主題、挑選深入研究的客戶、建立假設。</p><div id="d39c" class="link-block"> <a href="https://readmedium.com/why-how-ladder-design-sprint-e307d476a27b"> <div> <div> <h2>Why-How-ladder:產品需求探索的思考練習 & 工具</h2> <div><h3>「用戶想要的不是電鑽,而是牆上的一個洞!」這句耳熟能詳的話,道盡產品經理探索需求的日常,釐清每個需求背後「想解決的問題」是 PM 們必備的技能。這邊和大家分享 Why-How-ladder 這個工具,可以幫助 PM…</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*gh0f4U4FrC8aXVJSbDwzAQ.jpeg)"></div> </div> </div> </a> </div><h1 id="08fe">▍產品經理與客服團隊合作,處理緊急事件!</h1><p id="bbca">每天由客戶提出的各種問題,不一定只有回饋與需求,因此辨認哪些是需要立即處理的緊急事件,俗稱 hotfix,也是產品經理與客服團隊合作的課題。</p><p id="c5c0">被客戶發現既有的 BUG、上線新版本後產品出問題、第三方合作服務商掛掉,都是常見的緊急事件。有時候是單個客戶用很天兵的姿勢使用產品功能(超出原本產品設計的預期),這種極端狀況也可能造成緊急事件。</p><p id="71ce">並非每一個緊急事件的回報來源都是客戶,這邊先針對客戶回報來分享~</p><h2 id="cd02">客戶回報緊急事件的處理流程</h2><ol>

Options

<li>客戶透過 Intercom 回報問題給客服</li><li>客服透過內部 Slack #issue channel 回報問題給內部團隊</li><li>立即辨認是否為緊急事件,緊急程度為何?</li><li>產品團隊處理產品面、技術面問題;客服團隊負責與客戶溝通、跟其他團隊討論補救措施,例如計算造成客戶的損失、品牌信任與公關處理</li><li>問題解決,我們好棒!</li></ol><p id="6bc9"><i>——事情這麼順利就好了!在每次過程中我們發現兩個<b>主要問題</b>:</i></p><ul><li>每天都有一堆客戶回報問題,如何辨認緊急事件的程度,決定是否要立刻解決,以及討論解法?</li><li>客服回報給內部團隊後,內部團隊是誰負責?產品經理?有能力找出根本問題的工程師?最會重現問題的QA?那個人會不會忙死?</li></ul><p id="d29f">我們因此換過好幾個不同的工作方式:</p><div id="7494"><pre>【階段一】世紀大亂鬥 所有客服都可以回報,所有產品經理(當時只有三位)、工程師看到回報都一起去看問題,確認如何重現後<span class="hljs-keyword">tag</span>熟悉那個部分的工程師出來檢查和解決問題。</pre></div><p id="3c9e">接著就發現好幾位產品經理同時看同一個問題太耗時耗神,同時也會打斷工程師的工作節奏。</p><p id="b25c">不過優點是因為所有產品經理同時在看,會充分討論這到底算不算是緊急事件、需不需要立即處理,也因此慢慢在客服跟產品團隊中建立出第一套簡單的緊急事件程度標準。</p><div id="10e3"><pre>【階段二】產品團隊輪班制 所有客服都可以回報,但會參考過往處理的情境先稍微判斷是否為緊急事件。 產品經理(超過五人)與工程師團隊中,部分團隊成員每週<span class="hljs-regexp">/每兩週輪班擔任「值週生」,負責處理當週的問題。若是非常緊急的情況,該產品經理與工程師直接處理hotfix上線流程,若判斷沒那麼緊急,可以先放至backlog並指定給相對應的產品經理/</span>工程師接續追蹤處理。</pre></div><p id="273a">隨著團隊愈來愈大、產品團隊的分工愈來愈細、處理緊急事件的經驗也愈來愈多後,產品跟客服團隊認為培養「兼具客戶與產品敏感度的負責人」對團隊會有很大的幫助,除了可以一條龍的處理問題、也能夠讓客服團隊更了解產品,因此訓練了幾位資深的客服成員來負責緊急事件,並直接面對工程師溝通。產品經理因熟悉上線流程,仍舊輪班負責 hotfix 上線。</p><div id="75b1"><pre>【階段三】客戶緊急事件負責人的誕生 所有客服都可以回報,並由客服團隊中的負責人判斷緊急程度、找到相對應的產品經理詢問細節、追蹤整個緊急事件。 工程師團隊中,維持每週/每兩週輪班擔任「值週生」,負責處理當週的問題。</pre></div><p id="1c8b">有些大團隊最終會獨立出一個完整的 Help Desk 團隊、技術客服團隊來專門負責日常問題的處理與產品營運。無論哪種解法,重要的是,在團隊的不同階段,釐清遇到的問題、想達成的目標、所擁有的資源,找到當下大家都能接受的工作流程,並在下一次面對問題時持續優化。</p><div id="c65b" class="link-block"> <a href="https://readmedium.com/crisis-handling-strategies-in-product-management-41be137b5020"> <div> <div> <h2>從台灣的武漢肺炎防疫小組,看產品與專案管理中的危機處理!</h2> <div><h3>武漢肺炎大概是全台灣人目前最關心的議題了!‘台灣政府這次的防疫小組(中央流行疫情指揮中心)有許多值得學習的地方,這篇文章將拆解「危機處理」中的幾個重要元素與核心價值,以及可以如何運用在產品管理與專案管理中。</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/0*s_rG65WUm-5x7P7N.jpeg)"></div> </div> </div> </a> </div><div id="ad79" class="link-block"> <a href="https://readmedium.com/story-chain-retrospective-4789d2d5a2b0"> <div> <div> <h2>跨團隊深度 Retro 心法:一起跑一場有建設性的回顧會議!</h2> <div><h3>「故事接龍法」協助團隊專注在描述事實、了解問題,不容易被解決方案給分心,而當事情的脈絡清晰時,之後的討論會更容易對症下藥;另一方面,大家在說故事的途中也會漸漸明白別人為什麼當時做了這些事情,能夠更加同理別人,進而達成「Retro as a…</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/0*IfXNIwKI1XS5D1_H.png)"></div> </div> </div> </a> </div><h1 id="2e0c">▍強大的客服團隊是好產品的一部分</h1><p id="bc45">產品經理與客服團隊對彼此又愛又恨,來自於目標相同但面對的壓力來源與工作情境不同。我很幸運在做產品的初期有第一線面對客戶的經驗,瞭解到客戶服務並不只是要回答產品的操作問題,而是要同時理解客戶想法、理解產品限制、理解公司資源,然後找出一條可以幫助客戶解決問題的路。</p><p id="4948">對我來說,強大的客服團隊也是好產品的一部分,客戶服務是促成良好客戶體驗的重要一環,客戶的成功就靠你我來守護!</p><div id="71e5" class="link-block"> <a href="https://readmedium.com/3pm-series-how-to-work-with-your-teammates-4d071c38634e"> <div> <div> <h2>【PM 夥伴攻略系列索引】團隊合作的溝通心法大全</h2> <div><h3>PM 的職務內容仰賴和許多不同角色的溝通,而每個角色都有著自己不同的思維模式、不同的工作流程、不同的目標和不同的需求在運作著。我們希望分享我們跟夥伴們工作後的心得與學習,來協助 PM…</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*WfY5KHixwn7QOpP0Vi0bww.png)"></div> </div> </div> </a> </div> <figure id="523a"> <div> <div> <img class="ratio" src="http://placehold.it/16x9"> <iframe class="" src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fbutton.like.co%2Fin%2Fembed%2Fnanachiang0910%2Fbutton&amp;display_name=LikeCoin&amp;url=https%3A%2F%2Fbutton.like.co%2Fnanachiang0910&amp;image=https%3A%2F%2Fstorage.googleapis.com%2Flikecoin-foundation.appspot.com%2Flikecoin_store_user_nanachiang0910_main%3FGoogleAccessId%3Dfirebase-adminsdk-eyzut%2540likecoin-foundation.iam.gserviceaccount.com%26Expires%3D2430432000%26Signature%3DcLY4bMphekj8PnsBM7F%252BrwKS7v0mLyTVsqN8pLpZPZ%252F7kjsJXg4tEV7xZsX0bRYHOEBlxwV4jvYVqnDcH4rONFqn5aiuRgutXvineNdTgVJdJsbi2mjbNaWYA%252Bzq5I63pgm3U1e%252FcE1CXqQ19lN%252BtAA9F2iYtIeAow85IH4olxC%252BJxvBWWXf71h1wlETGwIDBK5ghAVUkMMzoxRmGqbJCy3q%252BUIwlHodouDbN2AbOtZl6eltycSsHD4W18M%252BX%252F0bTgug8zMhN0VD3czhrt3kwxRki6apG8w6TOYyoFY46LVK7BaYNu7XniG8Th2dJxNJP%252Fm0hFYr9Fkq%252BU2Sh3mbrw%253D%253D&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=like" allowfullscreen="" frameborder="0" height="212" width="485"> </div> </div> </figure></iframe></div></div></figure><div id="63de"><pre>謝謝你的閱讀!如果有任何疑問或有興趣的主題,歡迎留言給我們 📒</pre></div><div id="6528"><pre>如果單純想給我一點鼓勵,請給我 1–10 個拍手; 如果覺得文章對你有點幫助,請給我 11<span class="hljs-string">-20</span> 個拍手; 如果想看更多團隊合作的文章,請盡情長按拍手(50個拍好拍滿也沒問題)讓我們知道 👏🏻</pre></div><div id="05c3"><pre>想要持續追蹤我們的最新文章,請記得追蹤「產品三眼怪實驗室」<span class="hljs-comment">(◉◉◉)</span>! 我們每週末都會更新乾貨文章唷!千萬別錯過了~</pre></div></article></body>

【PM夥伴攻略】如何與客服團隊合作?了解使用者與提升產品信任的好幫手!

[產品三眼怪 3PM LAB 實體分享調查]
我們即將舉辦第一次的實體分享會!想請有在定期追蹤 3PM LAB 的朋友們回饋給我們,如果有實體分享會,想聽/想參與的形式與主題會是什麼?
點選連結填寫表單,獲得優先通知的機會!

我過去曾在提供電商相關的軟體服務(SaaS, Software as a Service)的產品團隊工作,採取年費或月費訂閱制的商業模式,服務的客戶對象從個人戶、中小企業到大品牌都有,因為產品複雜程度高、客戶型態豐富,負責解決客戶問題的客服團隊格外重要。

【文章目錄】
▍產品與客服的共同目標:解決客戶問題!
▍產品經理跟客服團隊合作的小撇步
 1. 預期管理:給客服驚喜,不要給客服驚嚇
 2. 優化的藝術:優化產品外,也優化工作流程
 3. 運用同理心:不只站在客戶角度思考,也站在隊友角度思考

▍產品經理與客服團隊合作,建立回饋流程!
 1. 蒐集回饋的工作流程
 2. 整理回饋的工作流程
 3. 分類的藝術
 4. 辨認與產出好的回饋內容

▍產品經理與客服團隊合作,處理緊急事件!
 1. 客戶回報緊急事件的處理流程
 2. 流程優化的三個階段

▍結語:強大的客服團隊是好產品的一部分
Ref: productboard

雖然在大部份公司內統稱為「客服」,但我們更喜歡稱這個團隊為客戶規劃顧問、客戶關係營運或客戶成長專家。其工作內容包含了:回答與排解操作問題、瞭解與蒐集需求/回饋、協助新客戶瞭解產品、引導有潛力的客戶使用更進階的功能或升級、偵測有機會流失的客戶並盡力修補關係、提供客戶學習資源或公司資源來成長…等等。

對我來說,強大的客服團隊也是好產品的一部分!

在我剛加入團隊的時候,前兩週的 onboarding 有一半的時間是跟著客服團隊使用線上溝通管理工具 Intercom 直接回答客戶問題,幫助我快速熟悉產品(這時候客戶比我還熟產品啊),同時瞭解客戶會遇到的問題——數據可以告訴我問題出在哪個環節,但客戶本人才能告訴我問題背後的原因與需求。

▍產品與客服的共同目標:解決客戶問題!

產品的出現本身就是為了解決使用者、市場的問題,提供新的價值,而在產品上線並擁有一定數量的客戶後,持續解決客戶問題就是產品經理與客服團隊的共同目標。

【實際合作的項目包含】
・處理客戶回報的緊急事件、特殊事件
・蒐集客戶問題、需求、回饋
・新功能上線、大型改版時的客戶溝通
・優化產品流程的易用性
・提升產品品牌的信任感

有共同的目標聽起來很美好,但在這個大目標切分成小的任務後,實際執行上仍然有許多摩擦,最大的原因是,隨著溝通的對象不同,產品經理跟客服團隊心目中對各個問題的優先級與緊急程度觀點不盡相同。

【舉例來說】
・緊急事件有沒有緊急到需要打斷工程師工作而立刻上 hotfix?
・新發現的問題跟現有功能的優化哪個要先處理?
・許多客戶都在抱怨某個問題,產品經理為何不優先處理?
・客戶一直詢問新功能何時會上線,產品經理為何不給個答案?
・能不能開發一些內部功能給客服團隊,方便自動/手動處理客戶問題?

▍產品經理跟客服團隊合作的小撇步

1. 預期管理:給客服驚喜,不要給客服驚嚇

信任是很容易破滅的,這一塊不是產品本身做好就好。客服需要在第一線回應客戶,因此讓客服理解更多產品決策的脈絡與操作細節很重要。

做好預期管理,不代表一定要列出硬性的上線時程,而是讓客服團隊清楚產品團隊的工作流程與版本狀態,在突發狀況發生或是客戶提出要求時做好心理準備,並可以事先準備好一套與客戶溝通的方法。

針對日常版本更新,剛開始我們會請大家自己來看 Trello “Ready For Launch“ 欄位;隨著團隊規模變大,我們直接在 Slack 開了一個 #release channel,由產品團隊主動發布消息,隨時更新狀態(上線前、中、後)以及版本內容。

Ref: Trello — The Dev Board

針對大功能上線或改版,客服團隊可以協助挑選合適的 beta 客戶來作為第一批受試者,並交由產品經理去做訪談和實驗,以利接下來的迭代與優化。若大改版經過討論後影響範圍太大,也會事先跟客戶溝通,並分批次開放改版給所有客戶。

2. 優化的藝術:優化產品外,也優化工作流程

產品研究前期的蒐集問題與需求、上線前的版本溝通、上線後的回饋整理與優化建議、遇到緊急事件的處理流程,每一個環節都分散在產品設計的不同階段,同時跨了不只一個團隊。

在優化產品的過程中,找到合適的跨團隊的工作方式,並隨著團隊規模擴大、分工改變後不斷持續修改,才能持續保有一個健康有效率的產品團隊!

除此之外,客戶遇到的問題,並不是每一個都一定只能靠新功能、優化 UX 來解決,適當的使用第三方的服務、增加 Help Center & Blog 的內容、開發給內部團隊用的工具,幫助客服快速排解客戶問題(而不需要每次都請工程師查資料、撈資料),也算是優化客戶使用整個產品體驗的一環!

3. 運用同理心:不只站在客戶角度思考,也站在隊友角度思考

好的產品經理與客服團隊通常都擁有強大的同理心,能夠站在客戶的角度思考,既然朝著同個目標前進,為何又會有諸多摩擦呢?將同理心運用在隊友身上,也會是解決問題很好的方式。

Ref: 公視《我們與惡的距離》

從客服團隊的角度來說,客戶不斷抱怨某個問題、客戶重複詢問某個功能什麼時候要開發,回報給內部團隊後,卻遲遲收不到產品經理的正面回應,是很令人挫折的事情,也成為客戶和公司之間的夾心餅乾。

從產品團隊的角度來說,資源有限慾望無窮,需求與問題從四面八方來——老闆、業務、客服(客戶)、產品團隊內部發起、工程與技術層面的優化等等,是另一種型態的夾心餅乾。在進行每一個計畫前,要同時考慮公司目標、問題規模、商業價值、資源限制來進行優先級排序。

有時也不單單是增加資源就能夠解決問題,產品團隊分工與組織架構很難分乾淨,難免有些模糊的三不管地帶,說老實話若對公司的價值也不大,很容易造成某些問題與需求總是沒有產品經理主動去接、主動回應,客服團隊三番兩次提出了,卻總像是提心酸的。

理解彼此的難處後,產品團隊與客服團隊可以時常/事先針對不同目標、突發狀況的優先級與緊急程度,討論短中長期的產品目標與產品路線圖,盡量讓整個團隊都瞭解優先順序與緊急程度的原因(雖然很難),當事情發生時,可以有一致的討論與決策方向。

延伸閱讀《產品經理日常掙扎:如何制定產品優先級策略 Prioritization

▍產品經理與客服團隊合作,建立回饋流程!

早期團隊人數及客戶數量不多時,我們直接使用 Excel 表單來記錄第一手的回饋,而隨著團隊與客戶變多,我們改為使用溝通工具 Intercom 串接產品規劃工具 productboard 來讓我們清楚看見質化回饋內容的同時,也可以透過分類與權重來量化問題的規模。

蒐集回饋的工作流程

  1. 客戶透過 Intercom 給予產品回饋
  2. 客服團隊詢問清楚問題後,將該客戶的產品回饋下註解並分類
  3. 被標註的 Intercom Convo 內容會自動按照分類進入 productboard 中
  4. 產品經理認領自己負責的產品區塊,進行更深入的整理和主題下標

整理回饋的工作流程(延續上面步驟)

  1. 產品經理認領自己負責的產品區塊,進行更深入的整理和主題下標
  2. 整理完後,除了可以看到不同問題被客戶提到的數量,也能自行下不同的權重與標記。舉例來說,商業價值、資源限制、由重要客戶提出的需求
  3. 透過排序與挑選,可直接使用 productboard 產出產品路線圖來跟客服團隊討論與溝通

真的沒有業配!更多詳細功能請見 productboard 官網介紹,找到一個好的工作方式與工具真的能幫團隊節省非常多時間跟資源呢~~~

分類的藝術

我們在使用這個流程的時候,產品的功能與模組已經非常多元,也已經超過五位產品經理,因此客服在收到回饋後要如何分類,不但牽扯到客服的工作內容、也牽扯到產品經理接下來如何認領,若設計不良就會造成前面提到部分「三不管地帶」的回饋會沒人處理的狀況。待討論的問題如下:

  • 按照什麼依據來分?
  • 分類要分多多細?
  • 避免無限多分類的狀況,什麼情況可以開新的分類?
管他的先開始分分看吧!但是...
・按照「功能」來分的話,針對單個功能的優化是沒有問題,但如果是一整個流程的優化呢?
・按照「功能」來分的話,如果客戶提出的是模糊問題,客服又要怎麼分類跟下註解?
・按照「流程」來分的話,若該流程牽涉到多個產品經理的職責,要怎麼分工認領?
・按照「問題」來分的話,有些問題提的不清不楚,深入探討又是不同的新問題,怎辦?
・按照「目標」來分的話,有些客戶需求搭不上公司或產品目標,又要怎麼分?

欸不對,產品團隊你們自己原本怎麼分工的啦吼! 能不能參考一下? 團隊問題詳見《團隊變形記 — 中大型軟體產品團隊、產品經理的組織分工

認真討論客服團隊分類的難題後,我們發現這個難題中最重要的目標,是讓相對應的產品經理去認領,再讓各產品經理自己做客戶研究的需求來整理回饋。因此不需要分得太細、先做再說,無論用哪種方法來分類,只要發現有跟其他產品經理職責重疊、或三不管的東西,就提出來討論。

而下個難題就是產品經理認領後,如何更深入的進行客戶研究並對依照不同的「主題」下標。這個主題可大可小,依照問題的清晰程度、產品經理的信心程度等會有不同的呈現方式,可以是問題、需求、功能,對我來說目標就是可以對要處理的問題有足夠明確的界定,足夠讓我們繼續做研究或設計。

延伸閱讀《產品路線圖:第五章 從主題發覺客戶需求

辨認與產出好的回饋內容

在使用這個流程的過程中,我們發現其中一個很大的問題是,客戶的需求講的不清不楚,產品團隊看得不明不白,不但難分類,就算分類完成後,也還是要花很多時間重新釐清個別客戶的使用情境與需求,最後也可能發現分在同一個類別中的回饋們,根本是徹底不一樣的問題樣貌!

如果我當年去問顧客他們想要什麼,他們肯定會告訴我:「一匹更快的馬」——亨利・福特

以「更快的馬」為例,背後的原因可能是完全不同的:

  • 移動速度太慢,來不及見病危家人最後一面(人)
  • 移動速度太慢,食物貨物送達時已經過期(物)
  • 通訊速度太慢,無法即時傳達重要訊息
  • ……

也因此往下研究後,更快的馬也許是其中一種解法,但不是唯一解法,若完全按照客戶的想法去執行,就喪失探索更多更好解法的可能性與機會了!甚至更慘的是,最後沒能真正解決問題!

在跟客服團隊溝通之後,客服團隊也理解產品團隊的難處,因此會在客戶提出新的回饋時,問清楚使用情境、描述他的痛點與期待,試圖找出客戶提出需求背後的原因,用更完整的方式來處理客戶回饋。

客服團隊可以在 Intercom 裡面加入只有內部團隊看得見的註解,整理這個客戶的需求與脈絡,再傳遞給產品團隊,同時產品團隊也可以在 Intercom 後台看到關於這個客戶的基本資料或數據。

透過兩個團隊的合作與工具的幫忙,我們建立起一套「客戶回饋清單」架構,包含客戶原始資料、客戶回饋內容、客服整理與分類的洞見,讓產品團隊可以接續使用這些資訊建立主題、挑選深入研究的客戶、建立假設。

▍產品經理與客服團隊合作,處理緊急事件!

每天由客戶提出的各種問題,不一定只有回饋與需求,因此辨認哪些是需要立即處理的緊急事件,俗稱 hotfix,也是產品經理與客服團隊合作的課題。

被客戶發現既有的 BUG、上線新版本後產品出問題、第三方合作服務商掛掉,都是常見的緊急事件。有時候是單個客戶用很天兵的姿勢使用產品功能(超出原本產品設計的預期),這種極端狀況也可能造成緊急事件。

並非每一個緊急事件的回報來源都是客戶,這邊先針對客戶回報來分享~

客戶回報緊急事件的處理流程

  1. 客戶透過 Intercom 回報問題給客服
  2. 客服透過內部 Slack #issue channel 回報問題給內部團隊
  3. 立即辨認是否為緊急事件,緊急程度為何?
  4. 產品團隊處理產品面、技術面問題;客服團隊負責與客戶溝通、跟其他團隊討論補救措施,例如計算造成客戶的損失、品牌信任與公關處理
  5. 問題解決,我們好棒!

——事情這麼順利就好了!在每次過程中我們發現兩個主要問題

  • 每天都有一堆客戶回報問題,如何辨認緊急事件的程度,決定是否要立刻解決,以及討論解法?
  • 客服回報給內部團隊後,內部團隊是誰負責?產品經理?有能力找出根本問題的工程師?最會重現問題的QA?那個人會不會忙死?

我們因此換過好幾個不同的工作方式:

【階段一】世紀大亂鬥
所有客服都可以回報,所有產品經理(當時只有三位)、工程師看到回報都一起去看問題,確認如何重現後tag熟悉那個部分的工程師出來檢查和解決問題。

接著就發現好幾位產品經理同時看同一個問題太耗時耗神,同時也會打斷工程師的工作節奏。

不過優點是因為所有產品經理同時在看,會充分討論這到底算不算是緊急事件、需不需要立即處理,也因此慢慢在客服跟產品團隊中建立出第一套簡單的緊急事件程度標準。

【階段二】產品團隊輪班制
所有客服都可以回報,但會參考過往處理的情境先稍微判斷是否為緊急事件。
產品經理(超過五人)與工程師團隊中,部分團隊成員每週/每兩週輪班擔任「值週生」,負責處理當週的問題。若是非常緊急的情況,該產品經理與工程師直接處理hotfix上線流程,若判斷沒那麼緊急,可以先放至backlog並指定給相對應的產品經理/工程師接續追蹤處理。

隨著團隊愈來愈大、產品團隊的分工愈來愈細、處理緊急事件的經驗也愈來愈多後,產品跟客服團隊認為培養「兼具客戶與產品敏感度的負責人」對團隊會有很大的幫助,除了可以一條龍的處理問題、也能夠讓客服團隊更了解產品,因此訓練了幾位資深的客服成員來負責緊急事件,並直接面對工程師溝通。產品經理因熟悉上線流程,仍舊輪班負責 hotfix 上線。

【階段三】客戶緊急事件負責人的誕生
所有客服都可以回報,並由客服團隊中的負責人判斷緊急程度、找到相對應的產品經理詢問細節、追蹤整個緊急事件。
工程師團隊中,維持每週/每兩週輪班擔任「值週生」,負責處理當週的問題。

有些大團隊最終會獨立出一個完整的 Help Desk 團隊、技術客服團隊來專門負責日常問題的處理與產品營運。無論哪種解法,重要的是,在團隊的不同階段,釐清遇到的問題、想達成的目標、所擁有的資源,找到當下大家都能接受的工作流程,並在下一次面對問題時持續優化。

▍強大的客服團隊是好產品的一部分

產品經理與客服團隊對彼此又愛又恨,來自於目標相同但面對的壓力來源與工作情境不同。我很幸運在做產品的初期有第一線面對客戶的經驗,瞭解到客戶服務並不只是要回答產品的操作問題,而是要同時理解客戶想法、理解產品限制、理解公司資源,然後找出一條可以幫助客戶解決問題的路。

對我來說,強大的客服團隊也是好產品的一部分,客戶服務是促成良好客戶體驗的重要一環,客戶的成功就靠你我來守護!

謝謝你的閱讀!如果有任何疑問或有興趣的主題,歡迎留言給我們 📒
如果單純想給我一點鼓勵,請給我 1–10 個拍手;
如果覺得文章對你有點幫助,請給我 11-20 個拍手;
如果想看更多團隊合作的文章,請盡情長按拍手(50個拍好拍滿也沒問題)讓我們知道 👏🏻
想要持續追蹤我們的最新文章,請記得追蹤「產品三眼怪實驗室」(◉◉◉)!
我們每週末都會更新乾貨文章唷!千萬別錯過了~
職場合作
產品經理
Pm
Product Management
Teamwork
Recommended from ReadMedium