这两个词背后都没有规范。 市面上的定义由供应商和分析机构维护，作为其自身市场分类的一部分。这些定义彼此不同，其中几份术语表甚至不对外公开。
人们在指的到底是什么区别？
各渠道是否共享客户记录。
- Multichannel 指你通过多个渠道触达用户。邮件、SMS、WhatsApp、推送。每个渠道有自己的列表、自己的工具和自己的历史记录。
- Omnichannel 指各渠道是同一段关系的不同侧面。无论消息通过哪个渠道发出，联系人相同、对话历史相同、偏好设置相同。
这是一个关于状态的主张，而不是关于覆盖范围的，所以数渠道数量永远无法得出结论。一家公司通过六个互不关联的工具在六个渠道上发送消息，只是列表很长的多渠道。另一家在两个渠道上发送，但共享联系人记录和退订，这才是第二个词所描述的事情。
如何验证这个说法？
询问系统允许你做什么，因为每个答案都是可验证的。
| 问题 | 共享状态的系统能做什么 |
|---|---|
| 每个人一条记录，还是每个渠道一条？ | 一个联系人，渠道标识挂在该联系人下 |
| 在一个渠道退订，其他渠道能收到吗？ | 当收件人要求如此时，可以 |
| 能看到跨渠道的统一对话吗？ | 可以，按时间排序而非按渠道 |
| 发送时能知道另一个渠道上最后一条消息是什么吗？ | 可以，因为历史记录是同一份 |
| 所有渠道的事件都汇入同一个流吗？ | 是的，一个订阅而非每个渠道各一个 |
在 Bird 上，这些对应到具体的功能面。联系人保存人员信息及其邮箱地址和电话号码。一次读取即可返回该联系人在所有渠道的偏好设置，按每条声明所涉及的地址或号码索引，而非按联系人本身。更改邮箱地址后返回的是另一组记录，旧地址保留其已有的声明。每条声明标注了自身的渠道，因此退订只有在收件人也在另一个渠道上做了声明时才会传递过去。Webhooks 通过一个订阅投递所有渠道的事件。
客户能感知到这种差异吗？
他们感知到的是失败。
状态未共享的表现是常见且熟悉的：一条关于你已通过邮件回复过的订单的 SMS，一条推广你上周已经购买的商品的促销，切换渠道后被要求重新验证身份，以及退订了邮件通讯后仍通过短信收到同一活动。
以上每一种都是一个渠道不知道其他渠道已知的信息。
边界到底在哪里？
在同意授权，没有任何架构能将其合并。
收件人同意接收邮件并不等于同意接收短信。在美国，自动化营销短信需要明确书面同意，这是一个有其自身披露要求的法律术语。明确书面同意介绍了需要满足的条件。TCPA（美国电话通讯消费者保护法）介绍了缺少同意的后果。
因此，统一的客户记录是可以实现的，统一的权限则不行。一个从 WhatsApp 回退到 SMS 的系统是有用的，但回退仍然要求你有权发送该 SMS。共享联系人记录让这件事更容易做对，因为每个渠道的同意授权记录在同一个人名下，而不是分散在各个工具中。但它永远不会合并权限本身。
哪个更好？
共享状态更好。但标签不是它的证据。
统一状态带来更少的矛盾消息、一个符合收件人预期的退订机制，以及出问题时只需查看一个地方。这些都不取决于供应商怎么称呼它。
因此，与其看标签，不如测试你实际使用的渠道，因为一个平台可能在两个渠道之间共享状态，但第三个渠道并不在内。什么是 CPaaS 介绍了另一个相关术语，它同样没有正式定义。
简而言之
这两个术语都没有可以援引的正式定义。
没有任何标准机构定义过这两个词，因此所有定义都只是某方的用法，而非规则。
可验证的区别在于是否共享状态。
多渠道指使用多个渠道。全渠道则声称各渠道共享联系人、对话和偏好设置。
无论架构如何，同意授权不会自动合并。
收件人同意接收邮件并不等于同意接收短信。在美国，自动化营销短信需要独立的明确书面同意。
根据它能让你做什么来判断一个说法。
一份联系人记录、一个跨渠道的退订机制、一个统一的事件流，这些是可以验证的。名称本身不能。