使客戶服務和產品保持一致的 5 種方法

您的信用報告已更改。

這是您從流行的信用監控服務收到的電子郵件的主題行。

期待積極減少債務的贊美，當你打開它時感到驚訝。郵件內容如下：

“客戶好，

您的 TransUnion 信用報告似乎有變化。

您有一個帳戶拖欠付款。

你認得這個新信息嗎？”

你不需要。

因此您向 TransUnion 檢查了您的信用報告，證實了您的懷疑。沒有錯過付款。

您回復要求解釋的電子郵件。當支持人員回信時，他們會要求提供信息以驗證您的身份：全名、社會安全號碼、出生日期。

兩天后您會收到一封自動生成的電子郵件。顯然，您的請求已得到解決。

很生氣，你又回復了——這次是要求一個答案。該代表沒有提供一個，而是加倍下注。

他發送了一份冗長的預設回復，詳細說明了信用評分的計算方式，但只字未提公司的錯誤通知電子郵件。您也決定加倍努力——刪除您的帳戶。

這些場景經常發生。這并不是因為支持代表喜歡毫無成效的對話。

這是因為客戶服務和產品只在必要時參與。

客戶服務和產品困境

支持和產品有很多共同點。兩個團隊都致力于創造積極的用戶體驗，并且都比您組織的大多數人更了解產品。

他們也不陌生。據 待完成的工作理論，客戶“雇用”產品和服務來執行特定工作。

當這些工作沒有按預期交付時，客戶服務會充當一個安全網——一種公司彌合客戶需求與他們期望之間差距的方式實際上得到。在實踐中，這通常包括：

• 在內部完成客戶無法（或要求產品團隊）完成的任務
• 向產品/工程團隊報告問題以尋求解決
• 將客戶反饋匯總并傳達為功能請求

但是，盡管他們不可避免地要接觸并接近產品，但大多數客戶服務和產品團隊不會分享他們的知識來主動改善客戶體驗。

相反，他們的關系是迫在眉睫的需要之一，兩支球隊都準備好 反應。支持通過將產品問題反饋給產品團隊來對產品問題做出反應。產品通過對問題進行分類來響應支持請求，并且在許多情況下，委托開發人員尋找解決方案。

這種動態可以維持擁有適度客戶群的公司，但隨著業務的增長，純粹的被動關系可能會成為麻煩。在極端情況下——比如當一家公司的產品始終無法“完成其工作”時——兩個團隊都會因為損害各自的生產力而互相怨恨：

• 客戶服務團隊可以從他們的角度來看待產品。無論他們是跟進錯誤還是期待已久的產品功能，他們為客戶提供解決方案的能力通常取決于產品團隊的及時響應。
• 產品/工程團隊也可以將支持視為對他們的困境漠不關心。無論他們是想弄清楚編寫糟糕的錯誤報告還是費力地處理不可行的功能請求，他們平衡持續開發需求與意外產品問題的能力都取決于支持人員提供的清晰簡明的簡報。

在這些緊張局勢中，客戶受到影響，產品停滯不前，每個團隊的成員（以及彼此）對工作的喜愛程度大大降低。

最糟糕的是，客戶想要的與組織可以提供的之間的差距越來越大，為具有類似解決方案的競爭對手鋪平了道路——以及團隊之間更好的協調——獲得市場份額。

好消息是：當他們聯合起來在客戶問題發生之前解決問題時，產品可以構建得更好，支持可以提供更好的服務，您的組織可以贏得以客戶為中心的聲譽，這是最終的競爭優勢。

方法如下：

1.簡化和標準化錯誤報告

錯誤不僅僅是開展業務中不可避免的一部分。它們是客戶服務和產品之間緊張關系的一個重要來源。

作為前線人員，支持人員希望像客戶一樣盡快修復錯誤，但工作壓力經常阻礙。從管理第一響應時間到獲取提交報告所需的信息，支持代表仍然需要跨越多個選項卡和系統。

產品團隊在收到令人費解的錯誤報告時并不關心這一點。他們關心獲得復制問題所需的信息。當支持未能提供解決方案時，他們會將問題推回去——通常是推給不知所措的代理人，他們希望他們在第一時間就足夠清楚。

無論重現步驟是否過于模糊，或者一張票中塞滿了兩個不同的問題，太多支持代表浪費時間編寫產品團隊討厭閱讀的錯誤報告。

這里有兩種解決方法：

重新配置錯誤報告工具

為了生成產品團隊可以快速采取行動的錯誤報告，支持團隊需要一個無縫的流程。每個輸入都應該是程序化的——比如自動完成下拉菜單——這樣代表就不會浪費時間考慮在什么地方輸入什么。

手動數據輸入應該只發生在一個字段中：重現步驟。為了更加清晰，指示代表在每份報告的結尾都包含 預期結果 和一個 實際結果。

如果您當前的工具無法與其他系統連接或無法靈活地圍繞產品或功能構建報告，請考慮投資更強大的工具。

重新考慮產品開發資源

產品團隊必須在錯誤和代碼管理與新產品開發之間取得平衡，這絕非易事。

一些工程師將調試視為寶貴的經驗，可以幫助他們成長為更好的開發人員。其他人則認為這個過程是一項耗時的苦差事，最好留給初級員工。還有一些人只享受破解神秘事物帶來的快感。

您的組織可能在其產品團隊中擁有這三者。根據他們的積壓工作，他們有幾個選擇：

• 構建沖刺或發布 僅目標代碼穩定性和錯誤解決
• 使用輪換時間表，讓每個人在預定義的時間段內輪流處理錯誤
• 考慮聘請一名全職 QA 工程師，這樣總有人在尋找缺陷

產品不可避免地會以大大小小的方式出現故障。為了減少客戶的停機時間，每個企業都應該努力盡快解決這些問題。為此，他們必須首先減少員工的摩擦。

2.鼓勵數據驅動的功能請求

功能請求也會加劇支持和產品之間的緊張關系。

如果看不到全局目標，客戶服務代表可以輕松地支持他們認為會產生巨大影響的功能的想法——即使產品更了解。

他們甚至可能將自己的想法構建為完全實現的快速修復，產品可以“輕松”解決這些問題而無需意識到其他依賴項。

對于產品團隊來說，這種意識的缺乏導致了對支持驅動的功能請求的懷疑。如果任其發展，他們會開始將支持的反饋視為軼事或過于受情緒驅使——因此他們可能會變得不屑一顧。

為了擺脫這些看法，客戶服務和產品必須圍繞提出不可抗拒的功能請求的因素保持一致。

這里有兩個起點：

數據

為了認真對待他們的請求，客戶服務應該盡可能多地用數據驗證他們的產品推薦。有幾種方法可以解決這個問題：

• 跟蹤一段時間內有多少客戶詢問過功能 X
• 為負面 CSAT 創建“產品反饋”類別
• 使用自定義 CRM 字段或服務臺標簽標記具有相關產品或功能的工單

這些選項中的任何一個都可以幫助您的支持團隊確定哪些產品或功能對客戶造成的摩擦最大。將這些數據點附加到功能請求將有助于產品團隊了解它們背??后的業務案例。

描述而非規定的上下文

產品開發不僅僅是添加新事物。它是關于識別客戶的問題并設計優雅和整體的解決方案。

這就是為什么產品團隊更愿意接受描述功能請求的原因 與提問相關的問題。他們不需要支持代表開處方一個解決方案。