在对讲机，我们非常关注两件事：我们的产品和我们的客户。保持这两个业务部门之间的紧密联系对我们的成功至关重要。但是，对于一家成长中的初创公司来说，保持产品和支持之间的联系是很困难的。你的客户支持团队越大，你需要处理的对话就越多。你的产品越大，就越难把这些信息记在一个人的脑子里。你得到的bug和特性请求越多，就越难让产品团队对它们进行筛选和排序。谢天谢地，近几个月来，我们发现了一种新的方式，使支持和产品始终保持同步。我们现在正在将客户支持嵌入到产品团队中。等等-客户支持代表和工程部坐在一起？！如果你的第一反应是"那永远行不通"，那就忍受我们吧。这听起来可能有些牵强，尤其是如果你是一家快速成长的初创企业，而且你最不能承受的就是失去一名代表。但这种方法是建立在任何以客户为中心的公司都能同意的一些强有力的断言的基础上的。优先事项：客户支持是贵公司的重中之重，永远是。反馈循环：伟大的产品是直接获得客户反馈的结果。观点：工程师，设计师和产品经理应该有一个清晰的客户视角来做所有的决定。如果你正在阅读上述任何一篇文章并点头表示同意，请继续阅读，看看如何在你的组织中实施这种独特的方法。一个嵌入式角色的旅程从事客户支持工作是一种激动人心的经历。你被拉向了很多方向（以最好的方式）。因为你的任务是回答这么多不同类型的问题，你是个多面手。但是，随着时间的推移，你逐渐掌握了专业领域的知识，你几乎意外地成为团队中某些类型问题的解决者。对我来说，这就是信息。我成为打击垃圾邮件和确保我们的客户的信息被传递的权威。一开始只是一些小责任的过渡性兴趣。我开始在"支持收件箱"中回答越来越多与交付相关的问题，并发现客户在这方面遇到的问题，例如邮件会变成垃圾邮件或邮件没有按预期发送。这在短期内效果良好，但在一次严重的交付事件（我领导了事后分析）之后，很明显产品团队需要全职的客户支持。为了使客户支持和产品关系充分发挥作用，我必须参与到每一次会议、每一次站立和每一次紧急事件中。自然而然，在一个工程团队度过我的日子是一个令人望而生畏的前景（谈论冒名顶替综合症？）但随着时间的推移，事情变得容易了。我仍然向客户支持团队汇报工作—保持您的手指掌握客户脉搏很重要—但我也与工程团队坐在一起，并参加所有会议。两全其美在产品团队中有一位前支持代表会让你对双方都有独特的见解。支持客户大多数团队应该（希望）在他们的路线图中有某种形式的客户输入，但是在产品构思过程中让客户支持是非常强大的。你可以直接听到客户的声音，所以不可能忽视。我在计划会议上为客户的情况辩护，从而将许多项目推到了我们的团队路线图上。例如，我为我们的产品做了许多小的改进，比如允许客户过滤他们的主用户列表，以查找无效电子邮件地址的用户。我们有一个技术限制，一次只能从消息统计页面标记10000个用户。这一点对于大的发送者来说尤其受到限制，因为他们本可以收到成千上万条消息？将其移动到主用户列表意味着大型发件人可以更轻松地管理其列表卫生。这是一项乏味的工作，如果没有人支持客户的原因并解释这种限制对客户的直接影响，就不会优先考虑这些工作。如果客户支持不在房间里，这些挫折很可能就没有答案了。嵌入式支持可以过滤这样的客户请求，并更好地支持那些让客户沮丧的有影响的更改。客户支持与我们的产品和工程团队之间的反馈回路比以往任何时候都更紧密！支持产品如果嵌入式支持可以提高产品团队，那么它也可以帮助改进支持团队。我们的产品支持工程师（这就是我们所谓的自己？）对缺陷报告进行分类和优先排序，并作为工程团队的过滤器，解决因客户困惑或缺乏调查而产生的问题。通过这种方式，问题数量减少，解决速度更快。在发生停机时，客户支持人员很难从客户反馈中找出答案。有了嵌入式支持，我们可以告诉客户支持在遇到操作困难时做好准备。

我经常对我们的基础设施和代码有足够的背景和知识，以便在客户需要时为他们提供帮助，而不必等待产品工程师的到来。我不满足于给你我的观点，我问了构建我们messenger的团队的工程经理Aidan Lynch和团队交付的产品工程师Raph Estrada，他们觉得这些好处是什么：在所有会议上都是客户拥护者，在所有讨论中都能从客户的角度出发。维护客户支持和产品之间的良好"社会资本"质量更好的bug报告。更好地了解工程团队的产品知识。对支持团队有更好的工程知识。问题解决得更快。更具影响力的路线图工作。为您的支持团队提供更多职业发展选择。我们还在对讲机上试验和开发这种方法，但到目前为止，我们对结果非常满意。事实上，不是我自吹自擂，而是有人甚至听到我们的一位工程经理向他们的团队索要自己的"便士"？。如果你想为你自己的团队实施这样的项目，或者想知道我们是如何做到的，我们很乐意听到你的意见。