使客户服务和产品保持一致的 5 种方法

您的信用报告已更改。

这是您从流行的信用监控服务收到的电子邮件的主题行。

期待积极减少债务的赞美，当你打开它时感到惊讶。邮件内容如下：

“客户好，

您的 TransUnion 信用报告似乎有变化。

您有一个帐户拖欠付款。

你认得这个新信息吗？”

你不需要。

因此您向 TransUnion 检查了您的信用报告，证实了您的怀疑。没有错过付款。

您回复要求解释的电子邮件。当支持人员回信时，他们会要求提供信息以验证您的身份：全名、社会安全号码、出生日期。

两天后您会收到一封自动生成的电子邮件。显然，您的请求已得到解决。

很生气，你又回复了——这次是要求一个答案。该代表没有提供一个，而是加倍下注。

他发送了一份冗长的预设回复，详细说明了信用评分的计算方式，但只字未提公司的错误通知电子邮件。您也决定加倍努力——删除您的帐户。

这些场景经常发生。这并不是因为支持代表喜欢毫无成效的对话。

这是因为客户服务和产品只在必要时参与。

客户服务和产品困境

支持和产品有很多共同点。两个团队都致力于创造积极的用户体验，并且都比您组织的大多数人更了解产品。

他们也不陌生。据 待完成的工作理论，客户“雇用”产品和服务来执行特定工作。

当这些工作没有按预期交付时，客户服务会充当一个安全网——一种公司弥合客户需求与他们期望之间差距的方式实际上得到。在实践中，这通常包括：

• 在内部完成客户无法（或要求产品团队）完成的任务
• 向产品/工程团队报告问题以寻求解决
• 将客户反馈汇总并传达为功能请求

但是，尽管他们不可避免地要接触并接近产品，但大多数客户服务和产品团队不会分享他们的知识来主动改善客户体验。

相反，他们的关系是迫在眉睫的需要之一，两支球队都准备好 反应。支持通过将产品问题反馈给产品团队来对产品问题做出反应。产品通过对问题进行分类来响应支持请求，并且在许多情况下，委托开发人员寻找解决方案。

这种动态可以维持拥有适度客户群的公司，但随着业务的增长，纯粹的被动关系可能会成为麻烦。在极端情况下——比如当一家公司的产品始终无法“完成其工作”时——两个团队都会因为损害各自的生产力而互相怨恨：

• 客户服务团队可以从他们的角度来看待产品。无论他们是跟进错误还是期待已久的产品功能，他们为客户提供解决方案的能力通常取决于产品团队的及时响应。
• 产品/工程团队也可以将支持视为对他们的困境漠不关心。无论他们是想弄清楚编写糟糕的错误报告还是费力地处理不可行的功能请求，他们平衡持续开发需求与意外产品问题的能力都取决于支持人员提供的清晰简明的简报。

在这些紧张局势中，客户受到影响，产品停滞不前，每个团队的成员（以及彼此）对工作的喜爱程度大大降低。

最糟糕的是，客户想要的与组织可以提供的之间的差距越来越大，为具有类似解决方案的竞争对手铺平了道路——以及团队之间更好的协调——获得市场份额。

好消息是：当他们联合起来在客户问题发生之前解决问题时，产品可以构建得更好，支持可以提供更好的服务，您的组织可以赢得以客户为中心的声誉，这是最终的竞争优势。

方法如下：

1.简化和标准化错误报告

错误不仅仅是开展业务中不可避免的一部分。它们是客户服务和产品之间紧张关系的一个重要来源。

作为前线人员，支持人员希望像客户一样尽快修复错误，但工作压力经常阻碍。从管理第一响应时间到获取提交报告所需的信息，支持代表仍然需要跨越多个选项卡和系统。

产品团队在收到令人费解的错误报告时并不关心这一点。他们关心获得复制问题所需的信息。当支持未能提供解决方案时，他们会将问题推回去——通常是推给不知所措的代理人，他们希望他们在第一时间就足够清楚。

无论重现步骤是否过于模糊，或者一张票中塞满了两个不同的问题，太多支持代表浪费时间编写产品团队讨厌阅读的错误报告。

这里有两种解决方法：

重新配置错误报告工具

为了生成产品团队可以快速采取行动的错误报告，支持团队需要一个无缝的流程。每个输入都应该是程序化的——比如自动完成下拉菜单——这样代表就不会浪费时间考虑在什么地方输入什么。

手动数据输入应该只发生在一个字段中：重现步骤。为了更加清晰，指示代表在每份报告的结尾都包含 预期结果 和一个 实际结果。

如果您当前的工具无法与其他系统连接或无法灵活地围绕产品或功能构建报告，请考虑投资更强大的工具。

重新考虑产品开发资源

产品团队必须在错误和代码管理与新产品开发之间取得平衡，这绝非易事。

一些工程师将调试视为宝贵的经验，可以帮助他们成长为更好的开发人员。其他人则认为这个过程是一项耗时的苦差事，最好留给初级员工。还有一些人只享受破解神秘事物带来的快感。

您的组织可能在其产品团队中拥有这三者。根据他们的积压工作，他们有几个选择：

• 构建冲刺或发布 仅目标代码稳定性和错误解决
• 使用轮换时间表，让每个人在预定义的时间段内轮流处理错误
• 考虑聘请一名全职 QA 工程师，这样总有人在寻找缺陷

产品不可避免地会以大大小小的方式出现故障。为了减少客户的停机时间，每个企业都应该努力尽快解决这些问题。为此，他们必须首先减少员工的摩擦。

2.鼓励数据驱动的功能请求

功能请求也会加剧支持和产品之间的紧张关系。

如果看不到全局目标，客户服务代表可以轻松地支持他们认为会产生巨大影响的功能的想法——即使产品更了解。

他们甚至可能将自己的想法构建为完全实现的快速修复，产品可以“轻松”解决这些问题而无需意识到其他依赖项。

对于产品团队来说，这种意识的缺乏导致了对支持驱动的功能请求的怀疑。如果任其发展，他们会开始将支持的反馈视为轶事或过于受情绪驱使——因此他们可能会变得不屑一顾。

为了摆脱这些看法，客户服务和产品必须围绕提出不可抗拒的功能请求的因素保持一致。

这里有两个起点：

数据

为了认真对待他们的请求，客户服务应该尽可能多地用数据验证他们的产品推荐。有几种方法可以解决这个问题：

• 跟踪一段时间内有多少客户询问过功能 X
• 为负面 CSAT 创建“产品反馈”类别
• 使用自定义 CRM 字段或服务台标签标记具有相关产品或功能的工单

这些选项中的任何一个都可以帮助您的支持团队确定哪些产品或功能对客户造成的摩擦最大。将这些数据点附加到功能请求将有助于产品团队了解它们背​​后的业务案例。

描述而非规定的上下文

产品开发不仅仅是添加新事物。它是关于识别客户的问题并设计优雅和整体的解决方案。

这就是为什么产品团队更愿意接受描述功能请求的原因 与提问相关的问题。他们不需要支持代表开处方一个解决方案。