文/明道创始人任向晖
“任先生，您的情况我了解了。我把您的电话接给相关负责的人，请不要挂“。
我每当在客服电话里听到这样的话，都不免好奇，对方会和负责人怎样沟通呢？会把我的情况一五一十地转告给负责人吗？
实际上，大多数情况不会有惊喜，接电话的人无非把我的电话转接给了另外一个人，我不得不把情况再和所谓的负责人再交代一遍。所以有时候，我都有冲动问第一个接电话的：“您能够负责……的事情吗？“，潜台词就是如果你不能负责，我就不跟你说了，免得到时候再重复一遍。
对我来说，关注这个问题是职业病。我知道企业内的协作是多么的困难，即使这么简单的客服电话转接也很容易掉链子，让客户心生不满。我知道，在企业和团队中，每天都会发生很多的“交接棒”工作，能够保持接力棒不掉在地上，跑完全程的情况少之又少。而且，企业协作是一场无休止的接力赛，它要不断重复。所以，如果不足够重视交接棒问题，场上一定落满了掉在地上的接力棒，摔倒的队员和输掉的比赛。
交接棒问题是协作失败的首因
客服电话的内部转接只是交接棒问题的一个极小例子。在各行各业中，因为分工和流程的必要性，跨部门和跨角色的事务交接比比皆是。因为从事协作软件开发，能够和各行各业的客户深度沟通管理和协作问题，这几年来我发现了一些协作交接棒失败的高危领域。它们是如此常见，几乎每个公司都面临类似的挑战；而且协作失败的代价都十分高昂，很多时候难以弥补。
互联网公司的产品设计与研发：
互联网产品的设计和开发是两个截然不同的专业，但又是需要紧密协作的两个团队。这两个团队的交接棒容易产生两种极端行为，一种是过度依赖文档（MRD，PRD等），另一种是过度依赖面对面沟通。依赖于文档的协作很难带入产品设计前期的客户调研和验证，管理层和业务人员参与的意见和提出的期望，研发人员容易过于机械地交付，忽视需求的本质，要么投入了不必要的开发成本，要么没有真正解决用户的需求；过度依赖面对面沟通的行为模式又忽略了沟通的透明度，让期中的变更难以知会到协作链条上的其他成员，一个产品经理和一个程序员的直接对话很重要，但是如果团队中如果全是这样的small talk就背离了协作的基本原则：透明沟通。
制造业的接单生产
中国大部分的制造业是贸易驱动的按单制造。客户的需求往往繁冗复杂，生产交付的环节也十分漫长，很多时候涉及到分包。这种情况下，承接客户订单的销售职能和生产交付环节的协同就是一个大型的交接棒。一旦丢棒不仅带来客户的不满，还会产生巨额的经济损失。
销售开发和客户服务
对于比较复杂产品的销售组织来说，往往职能是进行细分的。有的负责客户市场开拓，识别潜在客户，有的负责成交过程，还有的负责客户获得以后的服务。尤其是企业服务领域，这样的分工可能多达三到四种角色。但是这些角色所针对的客户可能是同一个。销售开发人员好不容易识别的潜在客户线索交接到销售成员手里的时候，丢棒是常见的事情。在前置的客户沟通中，客户对需求的表达有没有有效传递到成交和服务团队，对于成交率和客户满意率影响甚大。在签约过程中，给客户的解释、说明和承诺有没有完整交接到服务团队手里，也同样需要经得起考验。一个善于配合的销售组织，总能够在竞标中容易胜出。反之，如果配合失当，经常丢棒，即使拥有顶尖的销售单兵，客户依然不会买账。
这个让我想到广告公司这种重服务的行业，为了防止销售和服务丢棒现象发生，不得不尽力让所有相关成员都参与客户会议。我曾经见过广告公司浩浩荡荡10个人一起去客户那里开会的盛况。为了不丢棒的代价可真够高的。
识别交接棒区域
每个组织都有自己的高危协作点，就像4×100米接力赛就是有那三段交棒区。要想不丢棒，首先是要识别出在业务协同中有哪些明显的交接棒区域。
上文提到的只是一个概括的协作高危区域，对于每个具体企业来说，这样级别的识别是不够的。我们要定位更加具体的业务流程和明确的关联团队成员。
怎样识别交接棒区域呢？
1）第一个办法可以称为失败溯源法。这个失败可能包括客户的投诉，项目的延期，产出的明显瑕疵。一旦发生了这样的情况，理性的管理者应该克制焦虑，冷静地回溯成因。通常这个成因中就会包含A团队和B团队之间，或者C成员和D成员之间的交接棒欠缺。
2）第二个方法是观察提问法。我们可以观察两个有协作关系的团队或者成员之间的沟通密度，如果你没有条件全面观察，也可以向成员主动提问，询问他们在协作中是否有艰难之处，特别花时间的情况或者经常丢三落四的下场。
反之，不要过分信任事先设计好的工作流程图。因为实际的协作场景和事先规划的协作方案之间总是会有你想象不到的落差。没有什么协作是可以根据计划严丝密封进行的，即使在非常严谨的高端制造，建筑工程行业也有数不清的问题会商。
通过这些方法，我们能够定位的就是不再是一个笼统概括的协作问题，而是：XXX和XXX在XXX环节上的交接问题。有了这么明确的靶子，我们才能各个击破，改善协作。
要防止高危协作环节的丢棒，有很多具体的手段，包括根据问题重新设计工作流程，改进组织结构，但这些手段都代价高昂，实施缓慢。而且，每个具体的问题都需要具体的解决方案。我想介绍三个相对通行的解决方案，它们几乎普遍适合各种协作失败的场景，而且实施的难度相对低，甚至有很多现成的工具帮忙。
沟通历史正向流动
所谓沟通历史正向流动，就是要找到协作的起点，从这个点开始，将沟通过程，历史变更都在“同一个位置”记录下来，让后续协作的同事（无论来自哪个部门和岗位）都能够看到一致的记录。当然，后续岗位的参与也要同样这样做。
举一个销售开发和服务的例子：调研客户需求的销售开发人员在与潜在客户接触的过程中，要将客户沟通记录，个人的观察和总结记录在一个地方，如果这个潜在客户的需求得到确认，就要将包含这个信息的记录移交给销售人员。同样的原理，销售人员在成交过程中的客户沟通（包括承诺，客户要求，报价文件，成本询价文件等）也都记录在一起继续向服务团队交接。这是不是像极了每个人的病历卡？去医院看病，万一复诊时需要换医生，新医生一样可以根据病历和给药记录继续提供诊疗，只是医生手写的病历内容我们看不懂而已。
在信息化时代之前，西方的销售组织设计出“Lead Card“这样的东西，一方面为了给销售人员自我管理，另一方面也可以作为一个具体的交接物存在。
今天的协作软件已经能够极好地解决这个问题，无论这个协作过程有多么长，我们只要在起点建立起一个记录，逐段地加入下一环节的参与人就能够实现“沟通历史正向流动“。
在文章开头提到的例子里，每个客服部门都应该在客户呼入的第一时间建立“客服工单“，记录客户反馈问题的具体内容，然后再转接给任何同事的时候，只是将这个”工单“的负责人更换为另一位同事就行了。
上图是利用明道协作来管理一个新产品bug高发期，服务人员是如何向产品研发团队反馈问题的场景。在这个协作过程中，客户反馈是起点，但它所携带的信息和一线服务人员的评注会一直流动到具体的分工工程师那里。
进度状态反向流
进度和状态的变更还需要能够反向流动到起点位置，这是和第一点相辅相成的原则。例如在按单制造业，订单成功交付是协作的终点，客户需求信息需要跟随订单分解的过程从左向右流动。但同样在外包制造和交付的全过程中，任何的问题和进度变化也需要从右向左反向流动，尤其要让销售成员第一时间知道。无论是正面的进度完成，还是负面的质量问题，都是销售人员管理客户期望值的最核心信息。
同样，在产品设计与研发的协作中，如果开发过程中遇到的疑难和进度阻断，也应该能够及时和产品设计人员沟通。反向的沟通脱节同样是不能接受的丢棒现象。
要想保持高质量的协作，我们还需要有闭环的检查过程，“首问责任制”就是一个相关的概念，例如在客服环节接受到的工单，客服需要在一段时间之后验证问题是否得到解决。如果没有进度状态的反向流动，他则需要不停地确认工单进度，这是一个不必要的沟通成本。而如果我们利用协作工具，让进度信息可以自动通知到协作的起点，就能够提高协作的效率和质量，最终提高的是客户的满意度。
在我们自己的实践中，甚至把客户加入到我们的协作任务中。如果客户汇报了一个产品bug，我们会建立一个任务，把客户也加入为任务的成员。当这个问题在被解决的全过程中，客户都始终如一地加入在沟通闭环中。当任务完成，问题解决，客户第一时间就会收到一个状态通知。这算是进度状态反向流动的一个极致例子了。
纵观这两个原则，沟通历史正向流动，进度状态反向流动，它们像极了接力赛中的交接棒动作，前段运动员奋力向前，主动伸展左臂，后段运动员预先起跑，在交接区内向后伸出右手，在不损失速度的过程中完成完美的交棒。
减少交接棒次数是最佳方案
要想不丢棒，最好不交棒。这个道理谁都明白。只是苦于术业有专攻，而且没有分工就难以专注。这个观念来自于科学管理的特定时代背景。每个人都被训练成单一的职能机器。但是不管你愿不愿意，今天绝大多数的现代服务业中专门分工变得比以前次要，团队轻量化比过去普及。无论是阿里巴巴这样的大公司，还是初创公司都懂得业务中后台直接支持的重要性。这意味着无论多么复杂的协作，在沟通层次上都会被大幅缩短，一个业务前线的成员直接和中后台的某位成员直接沟通比什么都高效和高质。这就是所谓的“赋能”。
但这种短协作不会自动发生，首先它需要我们为这种协作成果做出组织设计上的改变，第二要重视自动化业务规则。一个业务前线成员如果要寻求一个中后台的支持成员必须能够有自动分发和自动对接的能力，如果依然依靠部门组织的人为分配，交接棒次数依然没有被减少。
寻求短协作的另外一个需要勇气的行为是“赋权“，尤其是向终端业务人员的赋权。很多协作层次的产生其实并非专业性要求，而是来自监督性欲望。如果员工具备自治力，能够依据简单的原则和工作价值观的指导自行决策，自然不需要那些狼狈的交接棒。
如果4×100米的接力赛，有的团队只需要交接一次接力棒，他们几乎是确定胜出的。
