下午 4 点。 某个周四。 一位销售代表正在浏览某人最近发布的 LinkedIn 帖子——又一篇"Slack 与电子邮件"的对比文章——这时，她最大客户的名字突然出现在了收件箱里。 这封邮件十万火急,她必须先听取两位同事的意见才能回复。 她的团队日常都在 Slack 上沟通。 她正在读的那篇文章建议"内部用 Slack，外部用邮件。"但当她现在需要拉入这场对话的人不是外部利益相关者，而是同事时，这条准则又有多实用呢？
这是每一篇 Slack 与电子邮件对比文章都会提出却从未真正解答的问题。 这些建议都假定你可以自主选择沟通渠道。 但对于大多数面向客户的专业人士来说，你根本无从选择。
Slack 与电子邮件之争，预设了一个你并不拥有的控制权
人人都在重复的那条经验法则——内部用什么、外部用什么——把何时使用 Slack、何时使用电子邮件的问题，包装成了一个你可以自由选择的命题：为每项任务挑选合适的团队协作工具、优化你的工作流程，并培训团队成员熟悉各个平台的用途。 如果你沟通的对象全都在公司内部，这套逻辑确实行得通。
但如果你的工作涉及销售、客户支持、咨询，或需要管理任何外部关系，那么沟通渠道就不是你能决定的了。 你不能直接对潜在客户说"在 Slack 上联系我就行"。 尽管你可以将外部成员添加到 Slack 组织中，但许多客户并不愿意为了一个外部账户和另一个应用而费心。 他们希望按照自己的偏好与供应商合作。 于是工作就出现在你的收件箱中，因为那是客户发送邮件的地方，任何内部政策都改变不了这一点。
因此，许多组织面临的真正问题并不是哪个工具更好。 而是如何管理那些通过关系所决定的渠道送达的工作。 如何在不让一切支离破碎的情况下，让团队保持同步？
谁才是真正被这个问题困扰的人
那些卡在 Slack 与电子邮件孰优孰劣之争中的人，日复一日地切身感受到这一点，远非领英文章中那些整洁的假设场景所能比拟。 他们是这样一群人：
- 销售人员。 销售管道存在于电子邮件中；团队协作则在 Slack 中进行。
- 客户支持人员。 工单进入共享收件箱；协调工作则在 Slack 频道中进行。
- 顾问与代理机构。 客户通过电子邮件发送交付物和问题；内部沟通则在 Slack 线程中来回穿梭。
- 客户经理与合作伙伴负责人。 外部利益相关者发送电子邮件；内部协调则完全发生在另一个地方。
如果你的工作涉及那些不使用你团队首选沟通工具的外部人员，你早已深知其中的代价。 你需要同时关注两个渠道，在它们之间来回切换，祈祷不要有任何事情被遗漏。
当上下文被拆分时，实际会发生什么
以下是任何对比文章都未曾描述的失败模式。 客户通过电子邮件提出问题。 你在回答之前需要征询意见，因此你会做以下三件事之一：
- 将邮件分别转发给三位同事。 现在，关于同一个客户请求出现了四条回复链。
- 在 Slack 中粘贴截图。 线程会丢失邮件头、附件和回复历史。 后加入的人完全没有真正的上下文。
- 在 Slack 频道中总结邮件内容。 你的总结会模糊掉细节差别，而最终的回复所引用的讨论，客户却永远看不到。
然后过了一会儿，有人问出了每个分布式团队都听过的那句话："有人回复那封邮件了吗？" 一半的团队查了电子邮件。 另一半查了 Slack。 没人确定谁看到了什么，或者被问的是什么。 客户因为两天没收到回复而再次跟进。
这并不是工具的问题。 这是上下文的问题。 关于工作的讨论与工作本身被分离开来，每花一分钟把两者重新拼接在一起，客户就多等待一分钟。
为何对比文章总是忽略了这一点
大多数 Slack 与电子邮件的对比指南将这个问题当作纯粹的优化问题来处理。 它们罗列功能，列出优缺点，并建议你"善用两种工具"。 这种建议悄然地假设了一个封闭的系统，由你和同事们决定使用什么工具。
但在面向外部的工作中，你无法拥有一个封闭的系统。 客户选择渠道。 你的团队选择 Slack。 现在，连接两者的负担每次都落在了你身上，全靠手动完成。 当邮件已经躺在你的收件箱等待回复时，再问 为什么要用 Slack 替代电子邮件 已经没有意义了。
那些标准建议——"发更短的邮件"、"把讨论转移到 Slack"、"设定沟通规范"——都解决不了这个问题。 所有这些做法仍然让你在不同平台之间复制内容，并祈祷在迁移过程中不会丢失任何重要信息。 更好的做法是，在工作实际发生的地方与你的团队协作。
一个更值得思考的问题
与其在 Slack 与电子邮件之间制造一个错误的选择，面临此类困境的专业人士不如问问自己：
我该如何在保持对电子邮件——它不会消失——及时响应的同时，在工作真正发生的地方与团队协作？
这种重新审视会改变你寻找的方向。 与其纠结何时使用 Slack 还是电子邮件，不如开始寻找 Slack 与电子邮件的集成方案，让团队讨论与邮件本身紧密相连，而不是在另一个独立的应用中围绕邮件打转。
以下几条实用原则能够提供帮助：
- 接受电子邮件作为面向客户的渠道。 这不是可选项。 与之抗争只会浪费你本可以用来更快响应的精力。
- 让团队讨论与邮件上下文保持一致。 当同事们可以直接在客户邮件上发表评论时——使用 @提及、客户永远看不到的私密备注，以及对话的共享视图——你就不必在工具之间来回转换了。 Spark 的共享线程让这一切成为可能：你与同事的来回讨论仅供内部使用，但显示在客户邮件旁边，上下文完好无损。
- 与团队设定明确的期望。 客户沟通保留在邮件线程中。 关于该沟通的内部讨论也在同一线程内进行，而不是在另一个平行的 Slack 频道中。 像 Spark for Teams 这样的工具可以很好地协助管理这一切。
- 不要把客户拉进你的工具栈。 如果你的潜在客户不愿意再安装一个应用，那这件事就到此为止。 到他们所在的地方与他们沟通。
重点不在于挑出赢家
只有当你能自由选择时，Slack 与电子邮件之争才有意义。 大多数与客户、潜在客户或外部合作伙伴打交道的专业人士，从来就没有这种选择。 收件箱不会从他们的生活中消失，任何生产力文章都无法把它论证消亡。
真正要做的工作，是让这个无法回避的渠道更易于应对——让团队的协作紧贴邮件信息，而不是散落在另一个应用中。 当这种连接得以维系时，无论客户选择什么工具，你都能从容应对。 一款合适的邮件应用能够保持上下文完整、团队协调一致、客户满意。 这比四条邮件回复链加上一个 Slack 线程能做到的要干净利落得多。
The Readdle Team 
