# 一、为什么客户成功很重要 客户是任何组织的命脉。虽然我们中的许多人倾向于认为客户服务宣传是为有才华的销售人员、营销人员、成长专家、社区经理，当然还有卑微的服务台工作人员保留的角色，但事实上，从首席执行官到清洁工，每个被组织雇佣的人都是潜在的客户服务宣传者。甚至软件开发人员。 开发人员必须有效地生产高质量的代码，并创建使组织更加高效和精简的系统，这将改善业务流程。因此，开发人员通常被放在一个受保护的气泡中，不会直接暴露给最终用户或客户。 然而，有些组织(通常是初创公司)要求每个新员工都开始在支持服务台工作，无论他们被雇佣担任什么角色。与更传统的公司和层级组织相比，这可能看起来很激进，但事实是，让人们感受到客户的需求是让每个人都与公司的愿景、使命和方向保持一致的好方法。 客户的成功很重要，因为它支付薪水并保持业务的发展。你的老板最终是顾客。 对于软件开发人员来说，客户的成功应该意味着更少的 bug 出现，改进的 sprints 和 releases，以及在使用应用程序和软件产品时更好的整体客户体验。 到本章结束时，作为开发人员和更大的开发团队的一部分，您应该理解为什么面向客户的思维会有利于您生成的代码的质量，并减少未来的故障排除工作。作为开发团队成员，您应该能够模糊什么是支持，什么是开发(编码)。这将使您的团队变得更加敏捷，并对客户问题做出更好的响应。 对于客户来说，服务台是进入组织的门户。它是客户提出问题并解决问题的切入点，而不是试图尽快转移其他部门(尤其是软件开发团队)问题的挡箭牌。 帮助台的作用应该是适当地量化开发团队进行调整或为特定问题提供正确的修复和解决方案所需的信息，并将其转化为技术语言。 在一个完美的世界中，服务台和开发团队都应该能够使用相同的技术术语进行“交谈”，并且都应该对产品及其路线图有清晰的理解。然而，情况并非总是如此。 表 1 显示了报告问题时服务台和开发团队之间的典型流程。 表 1:典型的帮助台到开发团队流程 | one | Two | three | four | five | six | | 客户向服务台报告问题。 | 帮助台将问题转达给开发团队。 | 开发团队为报告的问题分配优先级。 | 服务台通知客户。开发团队正在解决问题。 | 开发团队将修复程序交付给服务台。 | 服务台检查修复并将其发送给客户。 | 绿色的项目通常发生得很快。橙色的项目通常需要更长一点的时间，因为给报告的问题分配优先级可能会涉及部分开发团队在一段时间内偏离当前冲刺或总体路线图。大多数开发团队倾向于在产品路线图上优先解决问题。 通常，第 4 项(开发团队进行修复)将消耗该流程中最多的时间。开发团队可能还需要额外的信息，并需要请求帮助台询问客户额外的细节，从而延迟了整个过程。 这种方法不仅耗时，而且让服务台在知道开发团队需要多少时间或精力来制作修复程序并提供明确的解决方案之前，就要管理客户的期望。 在此“修复”时间内，服务台只能通知客户他们正在“与开发团队跟进”与此同时，顾客有时会变得紧张不安。 展望未来，这一点可能会对客户对公司的看法产生负面影响。如果“修复”过程比最初预期的时间长，客户可能会感到被忽视。 那么问题来了，为什么这么多软件公司一直用这个流程？ 答案是产品路线图推动开发团队前进。整个公司都接受了同样的愿景:发布新软件和/或具有更多功能的现有软件是推动业务向前发展的动力。 我们应该在这里承认，在当今的竞争环境中，客户消息灵通，能够快速做出决策，这导致企业竞争加剧，并面临持续的仓鼠轮竞赛的压力，以发布下一个大事件或其产品的最新功能。 当然，公司必须保持创新，但这一过程往往会导致客户的成功被忽视，如果服务台问题得不到迅速解决，公司甚至有失去长期客户的风险。一种解决方案是模糊支持和开发之间的界限。 为了更有效地响应客户问题并提供更快的修复，需要重新考虑目前关于如何支持服务台和开发团队的僵化观点。 模糊界限的一个简单方法是在服务台雇佣软件开发人员，他们不仅仅对 R&D 项目或产品管理结构感兴趣。相反，雇佣更喜欢内部项目或自己项目的人。内部项目可以是任何有助于组织更高效运作或改善内部业务流程的软件相关项目。 许多知道如何编程和编写代码的潜在员工会喜欢这种方法，并希望继续这样做。 公司经常会犯这样的错误:认为任何有能力编写代码的人都想坐在 R&D 架构的后面，接受产品管理。但是有很多软件工程师在他们自己的项目中表现出色，无论是内部项目还是帮助和指导他人的机会。 为什么不利用现有的人才库，创建一个支持服务台，让不属于 R&D 或产品管理领域的软件工程师在他们热爱的领域——编码——出类拔萃，同时还能从事内部和个人项目，让他们成为客户的拥护者？ 如果你是一个经营小型独立软件供应商商店的个人秀，你肯定会熟悉解决关键客户问题的概念，并认为这对于保持你的声誉和业务运营至关重要。你已经模糊了你的支持和开发操作之间的界限。 但是，如果您所在的组织在 R&D 和产品管理结构中有一个或多个开发团队，服务台可能会更传统，因为它包括支持专家(通常不创建代码修复)而不是软件开发人员。 实际上，模糊支持和开发之间的界限意味着您的帮助台团队有能力提供产品修复或至少变通办法(代码解决方案)，让客户满意，同时让开发团队处于专注于产品路线图的 R&D 和产品管理结构之下。 表 2 显示了服务台和开发团队之间的典型流程，此时服务台还雇佣了可能对在 R&D 和产品管理结构中工作不感兴趣的软件工程师。 表 2:面向错误修复和解决方案的帮助台到开发团队流程 | one | Two | three | four | five | six | | 客户向服务台报告问题。 | 帮助台重现并尝试修复问题(代码解决方案)。 | 服务台至少向客户提供了一种解决方法。 | 如果客户需要一个完整的解决方案(不是一个变通方法)，这将交给开发团队。 | 因为客户已经有了解决方法，所以问题不再紧迫。 | 当开发团队提供了明确的解决方案时，服务台会将其交付给客户。 | 来自表 2 的流程具有与表 1 相同的步骤数，但是有两个细微的区别。 首先要注意的是，这里的前提是帮助台将尽其所能(它必须雇用开发人员)为客户提供至少一个解决方案(即使这意味着解决方案或临时修复是代码修复，例如 DLL)。 这样做是为了最大限度地减少对客户的影响(减少焦虑和等待时间)，并允许 R&D 和产品管理架构下的开发团队专注于产品路线图。 另请注意，只有当客户需要永久修复或明确要求修复来自开发团队(由 R&D 认证)时，服务台才会求助于开发团队。但是，如果客户对帮助台提供的代码解决方案感到满意，就没有必要让开发团队参与进来(除了验证和认证由帮助台雇佣的开发人员提供的解决方案)。 服务台也是赢家，因为不是编码员的支持专家获得了专门知识，服务台雇佣的开发人员开始从事内部项目(客户的问题)，允许他们发挥创造力和想象力。 请记住，目标是解决客户的问题，避免使用开发团队，除非绝对必要。 归根结底，客户想要的是快速、主动的响应和问题解决方案。无论解决方案来自哪里，他们都会重视它。 赢得客户的心需要敏捷性。当您通过雇用软件开发人员作为支持服务台的一部分，将您的支持服务台设计为面向客户的 R&D (CORD)时，您不仅可以更快地解决问题，还可以让您的核心开发团队按计划工作。 表 3 显示了在贵组织的服务台内采用这种心态的优势。 表 3:传统和面向客户的 R&D 服务台的比较 | `Traditional Helpdesk` | `Customer-Oriented R&D Helpdesk` | | 充当中间人。 | 充当研发的缓冲 | | 不涉及代码修复。 | 提供核心代码修复或解决方法。 | | 要靠 R&D 来解决一个核心问题。 | 不依赖研发 | | 不能重现问题。 | 能够重现问题。 | | 可能会让 R&D 偏离路线图。 | 不要让 R&D 偏离路线图。 | 了解这两种方法对您的业务的巨大影响非常重要。当您的帮助台乐于接受逆向工程问题和提供定制解决方案的挑战(不依赖于 R&D 或产品管理结构下的开发团队)时，您的组织会突然变得异常敏捷，能够更快地响应客户问题，同时仍能根据产品路线图加速开发。 这两种方法的关键区别在于，当在传统模式下运行时，除了配置问题之外，您的服务台还需要开发团队的输入(对于任何与代码相关的问题，这意味着任何时候客户的紧急问题涉及到代码修复，您都有可能破坏开发团队的冲刺势头)。 使用 CORD 方法，您的服务台可以由不一定喜欢坚持严格路线图的开发人员来提供支持，相反，他们喜欢黑客代码和提出创新的解决方案。这使得开发团队能够专注于他们的路线图。 我们已经看到，对我们看待传统软件服务台的方式做一点小小的改变，就能彻底改变您的组织，让您更加敏捷，更快地响应客户问题，同时坚持您的路线图，不会出现重大偏差。 我们已经引入了这种思维模式，这样我们接下来就可以专注于如何将这种方法与一些客户关系管理(CRM)代码类和一些反向工程半自动化。 稍后，我们将探讨客户服务的策略和机会，帮助您拓展业务和公司价值。