題:
如何告訴客戶報告的“錯誤”實際上不是錯誤,而是他們需要自己解決的問題?
Premier Bromanov
2015-09-09 23:48:27 UTC
view on stackexchange narkive permalink

上下文

我是客戶關係的新手。這是我在公司的第一年,但是即使我今年24歲,我也從來沒有從事過必須提供任何形式的客戶服務的工作。我編寫程序,很多時候我需要給客戶留下筆記或直接與他們交談。我們一起工作,每個人都有分配的任務。該程序使用XML。這樣,如果需要更改某些內容,他們不必等待我在程序中更改某些字符串,他們可以直接對其進行編輯並查看更改在構建中的存在。

每週左右,客戶在生產日誌中發現了錯誤說明,因此我可以在下一次構建之前對其進行修復。但是,經常有一些涉及副本本身的bug註釋,例如“將此單詞更改為X”或“在此句子後添加一行:”。

我想知道如何讓客戶(或這個特定的人)知道這些錯誤是他們要解決的工作。這些註釋讓我有些生氣,但是我不想讓這些內容滲入我的註釋中。我也不想自己做這些,因為我們有理由將任務分配給誰,並且我不希望這些任務被誤認為是我的。

小公司,大約十個人。這個項目是2個人,我本人和我的老闆,既是所有者又是找到我們的客戶並進行賺錢的交易的人。沒有客戶服務部門。我問老闆,他說我應該指出哪些錯誤是他們的責任,所以我想以最好的方式讓他們知道。

我如何才能巧妙地,恭敬地讓客戶知道這些筆記與我無關,實際上是其成員的工作之一?

評論不作進一步討論;此對話已[移至聊天](http://chat.stackexchange.com/rooms/29057/discussion-on-question-by-tom-sterkenburg-how-to-tell-a-client-a-reported-錯誤)。
如果您想做出一個而不是在評論中回答,那將是一個很好的答案。
十 答案:
enderland
2015-09-10 00:21:32 UTC
view on stackexchange narkive permalink

我該如何巧妙地,恭敬地讓客戶知道這些筆記與我無關,實際上是其成員的工作之一?

您可以嘗試以下方法: / p>

  • ”“嘿,您能解釋一下這些錯誤是什麼,以便我們知道將錯誤分配給誰嗎?似乎它們與文本複制有關,這是約翰的責任。但是,如果它們是實現的,它們將是Susy的-有助於我更好地了解它們是什麼,從而知道將其分配給誰。”

從“幫助我理解”的角度來處理它。這通常是沒有威脅的,不會因為“您這個白痴停止分配我的工作”而遇到。最好親自進行此操作,這樣,如果您想最大程度地減少收信不佳的情況,可以進行對話(而不是電子郵件)。

要求這樣做的人可能會成功, “哦,您是對的,我應該修復自己(或讓John修復它)”或“我不知道如何提交代碼更改。”如果是後者,請向他們展示如何使用。

如果您想要獎勵積分,可以嘗試幫助您的客戶建立一個系統來在對話後跟踪這些請求。請謹慎執行此操作,否則可能會導致管理/諮詢。

評論不作進一步討論;此對話已[移至聊天](http://chat.stackexchange.com/rooms/29033/discussion-on-answer-by-enderland-how-to-tell-a-client-a-reported-bug-不是一個)。
Philip Kendall
2015-09-10 00:23:42 UTC
view on stackexchange narkive permalink

尊敬的客戶

感謝您的舉報。您應該可以通過登錄 http://coolstuff.example.com/的內容門戶網站來自己進行修改,結果將立即在實時站點上顯示。

如果您在使用門戶網站時遇到任何問題,請告訴我。

乾杯

湯姆

對於我的情況來說有點正式,但仍然得到了很好的回應。
除非您懷疑客戶端不了解XML,否則不會感覺到他們無權更改XML,因此我將避免使用這種語言。在它的接收端,它是相當透明的,因為它就像您試圖欺騙他們一樣,將責任推卸給他們。相反,我將直接討論該問題,作為有關責任的討論。
RubberChickenLeader
2015-09-10 00:00:08 UTC
view on stackexchange narkive permalink

這聽起來像是客戶培訓問題。與您的經理聯繫,您可以考慮成為客戶服務代理。您不能只將錯誤報告關閉為“ not bugs”,而不能以gruf答复“這是您的問題”來回應。

在一個我工作的老地方,有一些問題不斷出現,因此我們有文檔可以發送給客戶有關如何執行某些任務的信息。我們還讓客戶服務部門在客戶首次進入平台時對其進行培訓,並在每年的不同時間提供有關我們應用程序各種功能的培訓課程。這保留了某些類型的“我們認為這是一個錯誤,因為我們不知道如何使用它”。系統中的投訴。但是,如果我們收到足夠多的投訴,我們會提交一個UX錯誤,該錯誤實際上不是一個錯誤,但需要加以研究。實例。如果不清楚的話,則是需要培訓或需要通過代碼更改來糾正的UX“錯誤”。

如果您沒有文檔來發送給客戶端以指導他們完成操作,那將是我從哪裡開始。一旦文檔寫好,像

Hi Customer這樣的電子郵件,

我發現您在網站上打開了一個與副本有關的錯誤。不幸的是,由於我們已經為每個客戶端配置了此功能,因此我無法為您解決該問題。

隨附的文檔是有關如何更改副本各個部分的文檔。如果您需要其他幫助來進行更改,我很樂意向您介紹如何進行自我更改,因此在將來,如果需要進行更改,則可以盡快進行更改。

感謝湯姆

發送給客戶的

有望解決該問題。我會與您的老闆一起工作,並拿出一封正式信函,向您發送打開這些類型的bug的客戶,這樣一來,它就會向每個客戶傳達一致的信息。

這是正確的答案。如果您需要直接在這些問題上回答客戶,則將其標記為“升級為客戶關係”。
這確實不能回答我的問題。我在問題中增加了一段,希望可以清楚地說明為什麼這實際上不適用於我目前的情況(儘管我在另一家較大的公司工作似乎是正確的做法)
像這樣的UX超出了這個問題和項目的範圍
@WindRaven您只需要更改此,該,該,該另一項,以及另一項,並且如果X的工作方式不同並且...也不是一件好事。
Joe Strazzere
2015-09-10 01:18:28 UTC
view on stackexchange narkive permalink

我如何才能巧妙地,恭敬地讓客戶知道這些筆記與我無關,實際上是其成員的工作之一?

我一直在做這個工作之前的情況。這基本上是一個溝通和培訓問題。對客戶的培訓不足以理解錯誤(必須修復)和內容(必須修改)之間的區別。您可以幫助弄清事情,並為您和客戶做更好的事情。

我發現最好通過以下方式回應此類報告:

  • 指示這不是錯誤,而是一個內容問題
  • 說明由誰負責內容(甚至可能是單個客戶的姓名)
  • 演示該客戶如何製作內容他們的內容改變了。有時有一個可以參考的幫助文件。如果沒有,您可以編寫一個示例(帶有圖片)來向他們展示如何修改其內容。
  • 如果不清楚,可以提供更多幫助

基本上,您是說這不是錯誤,但是我會幫助您完成更改內容的操作。

您可以通過電子郵件,電話, webex,還是親自進行的項目,具體取決於您的項目的上下文以及通常的做法。一段時間後,他們將開始了解這些事情的工作原理。

(請盡量避免煩惱。這種事情一直在發生。)

John Hammond
2015-09-11 04:12:45 UTC
view on stackexchange narkive permalink
  1. 這不是客戶的錯。
  2. 在您的回復中包含特定於客戶報告的內容。
  3. 不要讓客戶解釋明顯的內容。您真的不能問:“當您說時,您希望將'標準'一詞替換為'默認',這是什麼意思?”
  4. 告訴客戶如何以最少的努力進一步進行。
  5. ol>

    尊敬的客戶

    我收到了您關於[問題]的錯誤報告#489。根據您的描述,您報告的不良行為不是由我們維護的代碼引起的,而是由使用中的XML文件引起的。請將問題轉發給[客戶負責人],他們應該能夠為您解決此問題。

    最誠摯的問候,
    Tom

    此可能看起來很簡單,但經過精心設計。

    此答案特別是避免了責怪客戶。並不是“他”首先使用和創建的XML文件,而是(某種程度上是神奇地)使用了XML文件。

    除非您正在嘗試,否則您不會談論財務方面的問題。出售包含維護XML文件的服務包。客戶顯然不會按小時支付您的報酬,因此他根本不在乎您公司編輯XML文件的成本效益。

    您不會告訴他他應該能夠自己解決此問題。如果這是真的,你告訴他他很愚蠢。如果這是錯誤的,則因為您對錯誤報告的理解不正確,所以您很自大。

    您不會告訴客戶您無能為力,尤其是當客戶知道您可以做到時。客戶將正確地將“我無法解決問題”解碼為“我不會為您解決問題”。

paparazzo
2015-09-10 00:19:28 UTC
view on stackexchange narkive permalink

嘗試

“將此字詞更改為X”是受客戶控制的配置。這不是錯誤,因為它不會引發錯誤並且軟件可以正確讀取配置。在配置文件中,您只需要將...更改為.....

TripeHound
2015-09-11 13:45:50 UTC
view on stackexchange narkive permalink

正如其他答案所涵蓋的那樣,從長遠來看,培訓/教育可能是有意義的,因此客戶的[所有人] 知道是他們的工作,但需要答复特定的錯誤報告您可能首先要強調他們的職責是好處

當我們建立[可編輯的內容系統] [您/您的公司]所提供的主要優點是,它使您能夠立即對副本進行更改,而不會帶來麻煩和延遲,不必提出錯誤報告。這不僅可以讓您更快地看到您的更改,還意味著我們可以花更多時間在您要求的其他改進上。

我是開發人員,但在公司成立之初(我們比您小或小)我還必須處理很多支持/客戶關係。我發現的秘密之一-特別是對於“尷尬”的客戶-是,儘管您知道他們很尷尬,但不要讓他們知道您所知道的。另外,如果它們“錯”了,您可以用一種使他們“出局”而又不丟臉的方式表達事物。

歡迎來到TripeHound網站,這是一個不錯的第一答案。對於與客戶或客戶互動的任何人,最後一段特別有用的建議。
謝謝。我對“能力較弱”或非計算機知識的人也使用了類似的方法:通過“電話”,您經常會聽到他們出了點問題,這時我會說:“ _我認為我沒有正確解釋這一點,您即使他們犯了錯誤,也需要……承擔責任。
user8365
2015-09-10 03:00:02 UTC
view on stackexchange narkive permalink

重要的是,您要專注於禮貌,因為您不習慣進行客戶服務。在大多數情況下,您所說的一切聽起來都不錯,但是以下內容:

我想知道如何讓客戶(或這個特定的人)知道這些錯誤是他們的工作照顧。

如有需要,請進行一些培訓,並集中精力在您構想的方式上,讓他們自己照顧自己以節省時間。無論如何,大多數人還是喜歡這種方式,除非他們覺得它太複雜了。

這些註釋讓我有些惱火,但我不希望這些內容滲入我的註釋中。

沒有人在乎您的小寵物,尤其是顧客。您的問題是您自己的,因此甚至不要考慮提及此問題。如果您過多地專注於此,則冒著對客戶說粗魯話的風險。抱歉,但是您必須克服它。這就是為什麼它被稱為客戶服務而不是客戶的原因。如果方便的話,我會幫助您。

我也不想自己做這些,因為我們有理由將任務分配給誰,我不希望這些任務被誤認為是我的任務。

請注意上面提到的及時性因素。一旦您對他們進行了培訓,他們就可以輕鬆地自己完成任務,只是讓他們知道您將要從系統中刪除他們的條目。另外,除了將他們輸入系統之外,還讓他們知道如果他們有任何其他此類問題,該怎麼辦。也許他們應該發送一封電子郵件,詢問培訓,使用問題以及任何其他與錯誤無關的事件。

Phil Hannent
2015-09-10 12:23:11 UTC
view on stackexchange narkive permalink

作為具有已部署系統的程序員,您將不斷遇到這些錯誤。

最快解決此問題的方法是指出所涉及的成本。我很少對客戶說“不”,但是我會正確地表述一些事情:

“我可以進行這些簡單的文本更改,但是您實際上是在付錢給程序員,以使您組織中的任何人都可以做確實。確定要讓我處理這些類型的更改嗎?“

您會發現提高成本的要點將引起所有人的注意。

我喜歡這個,但也許根本不適合談論財務。向您的老闆詢問誰應該進行此對話。
以我的經驗,這種問題會冒很大的風險,他們會說“是”。該系統是在組織中某人的輸入下設計的,他們認為他們應該編輯XML。但是,他們害怕XML。即使他們無權通過使用XML來避免使用XML,而應該只給您真正的bug,您似乎也為他們提供了機會。他們不應該將其排除在外,但他們不一定會評估情況。而且,即使此人要求您花費時間,您也不一定有權花時間(例如,客戶的錢)。
Chris
2015-09-11 15:44:06 UTC
view on stackexchange narkive permalink

明確職責

如果需要更改某些內容,他們不必等我在程序中更改某些字符串,就可以直接對其進行編輯並查看構建中的更改。

召開會議以澄清更改XML的責任。他們認為他們可能只需要在緊急情況下自己更改XML。告訴他們您對此有何看法。

您應該在開始時將其縮小。只與創建錯誤報告的人交談。也許他/她同意您的意見並改變了他/她的行為。如果您發現自己不在同一頁面上,則可能需要老闆參與,如果他們希望您的團隊來做額外的工作。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...