本周,在博客圈和大众媒体上有很多关于“众包” —使业余爱好者群体能够执行以前由专业人员完成的任务。 (请参阅Jeff Howe的 有线 故事。) 初创公司将其自身的部分产品投放市场的下一个时尚机会。

技术支持(又名客户支持)位于许多高管可外包功能的列表中。不过,我一直在与多家初创公司的技术支持团队进行交流,并在一个可以帮助客户爱你的专业团队中看到真正的价值。我的反对派观点是从支持团队中获益更多。

首先,一些背景

技术支持(客户支持)是一组现场人员,可以帮助客户和潜在客户进行有效的电话和电子邮件对话。他们还拥有用于客户自助服务的在线工具:常见问题解答,聊天和支持博客。与任何其他部门相比,支持服务为已经为您的产品付款的客户提供的服务更多–并且其重复业务对明年的收入至关重要。

不过,我经常看到技术支持被忽略,装备不足并塞进组织壁橱。成本中心是一个必不可少的弊端,它负责尽快接听电话。事后才进行新产品培训,缺少指标,很少有人晋升到薪酬更高的职位。  外包,离岸外包或众包的绝佳机会。

这种方法基于以下隐含的假设:[1]我们的产品是完美的; [2]所有客户都将在线支持自己; [3]即使我们对待产品不好,客户仍然会很乐意推荐我们的产品。  在所有方面都是错误的。

根据我的经验,使支持成为战略资产需要综合以下几点: 组织计划,良好的工具产品管理思想。让我们依次应对……

组织之家

技术支持通常通过工程报告。不幸的是,技术支持对工程师的要求很多,例如批评: “我们的客户在安装新的图形应用程序时遇到了麻烦” 要么 “ UI令人困惑。” 工程技术可以解决很多问题,而不会出现技术支持方面的新问题,因此自然会忽略它所能提供的服务。 (询问质量检查人员,在提交新的错误报告时会得到什么反应。)

另一种方法是将支持移至销售组织。当他们应该专注于理解和安抚不高兴的客户时,这往往会使支持部门成为电话销售角色,推动服务合同的续订和付费升级。

我看到了一些不错的选择: Splunk 已在“产品管理”下启用了“支持”,因此新的客户输入就直接流入PM。 Cemaphore将IT支持与IT一起纳入了更广泛的运营部门,并让Support进行了产品验收测试。不论其位置在哪里,技术支持部门都需要一些行政帮助来避免模糊不清。

贸易工具

一旦团队有了家,别忘了一些基本工具。就像鞋匠的赤脚孩子一样,科技公司的技术支持团队经常缺乏必需品:

    • 客户信息。 您不需要花哨的CRM系统。实际上,新的研究表明,客户确实希望与能够真正解决问题的敬业,有才干的员工进行交流……CRM系统可能会破坏这些问题。如果您可以告诉谁需要续签支持合同,则加倍加分。

谁是下一页?

  • 案件追踪系统。 不要与CRM系统混淆,它们捕获有关客户和问题的详细信息。一个好的案例跟踪系统可以帮助您确定趋势,模式和问题的根本原因。仅供参考,PostIt©注释不是很好的替代方法。
  • 一些常规指标。 跟踪每个案例后,首先要每周报告案例负载,在首次致电时关闭的部分案例以及哪些产品产生最多的问题。不要被诱使为“每位客户所花的最短时间”提供奖励。
  • 大量的产品培训。 最好的技术支持代表很有同理心,喜欢与客户互动。如果他们 “给好电话,” 他们可能不愿坐下来进行长时间的课堂培训。探索利用多种媒体,计划外停机时间或午餐和学习课程进行产品更新的产品培训。

所有这些似乎都是显而易见的,但是许多公司都没有。他们未能找到组织上的支持者和对客户支持的系统视图。在此过程中,他们未能从技术支持部门获得整个公司的价值。

这是一些经典的产品管理技能适用的地方:我们如何 考虑支持 作为改善公司产品和市场地位的一种方式?我们从已经付款的支持组织中可以从哪里获得优势?

像产品专家一样思考

支持人员往往是技术性的,直截了当的,而且头脑冷静。很少有人了解产品规划的非技术性挑战,很少有人花很多时间在产品经理身上。注入一点产品思维可以产生一些很好的结果。

想象一下,每月进行一次产品管理和技术支持的静坐活动,两个团队都在努力解决“前十名”支持列表。从实际案例负载的报告开始,每个人都可以通过将问题分类为不同的类别来学习。

请注意,我们建议解决问题的方式取决于我们将其分配给的类别:沟通问题可以通过更好地沟通来解决;新发行版解决了软件问题。将问题放在错误的层次上会导致错误的解决方案。

这是最近一次“支持/产品管理”分类会议的分类:

    • 客户找不到答案。 例如,刚发布新软件版本后,您应该期望 “您的升级政策是什么” 查询。在下一次发布之前,请考虑将升级策略放在“常见问题”页面顶部,《客户通讯》以及您的主页和向被许可人发送的电子邮件中。

有已知的未知数…

  • 客户找不到功能。 如果用户无法找到产品中已有的菜单项或功能,则可能是用户界面或命名问题。例如,如果技术支持人员不断告诉客户您的邮件合并版本称为“自定义信函生成器”,那么也许您应该更改其名称。  在“工具”菜单下列出它。  对帮助文件中的两个名称进行交叉索引。
  • 我们的软件崩溃了。 一个错误。修复它。没有理由。
  • 定位非功能。 产品团队可能已经决定不包括请求的功能。技术支持需要帮助来解释这一点。花一些时间了解为什么不包含功能,以及支持人员应如何与客户讨论此功能,并提供诸如以下的答案 “这是做同一件事的一种更简单的方法……”“一些在这种情况下效果很好的第三方产品是……” “我们还有其他一些客户对此功能表示关注,因为……”
  • 政策问题, 例如谁可以免费获得升级,对技术支持来说是最难的—致电者总是有借口破坏您公司的规则。用最少的繁文tape节制定一些合理的规则。  (“如果前50名客户中的任何人致电并在该公司拥有有效的电子邮件地址,请向他们提供所需的所有帮助。危机结束后,客户经理将清理所有帐单问题。”)

等等。弄清楚您遇到的问题是解决问题中最困难的部分。支持和产品管理一起可以改善产品和客户体验。

SoundBytes

技术支持听起来像是您的公司应该外包或``众包''的东西,但是您可以驱逐客户。获得支持,以获取真正的客户价值所需的组织和战略帮助。