共享队列
为团队提供一个地方来查看支持的对话并分配责任。
该解决方案的作用
一种操作视图，无需假装网络相同
Unified Inbox 可以将支持的入站对话规范化到团队队列中，并通过连接的提供商发送回复。它不会从路径中删除提供程序：WhatsApp、Meta 和 LINE 继续应用自己的 API、帐户规则、安全模型、元数据实践、可用性和保留。
客户保留他们熟悉的渠道
避免在团队做出回应之前强制对新应用程序或帐户进行每次初始查询。
可见的安全边界
明确对话何时在外部提供商上进行以及参与者何时转移至受保护的 Hat workflow。
核心工作流程
连接、路由、响应和升级
提供商资格、API 功能、消息类型、模板、对话窗口和地理可用性可能会发生变化，并且必须在入职期间确认。
WhatsApp Business
连接符合条件的业务消息传递设置并将支持的对话路由到员工工作流程中。
Facebook Messenger
将支持的寻呼对话放入同一操作队列中。
LINE Official Account
与其他连接的通道一起处理支持的 LINE 对话。
分配和状态
授予员工所有权并跟踪配置的工作流程中的下一步操作。
批准的响应模式
在连接的网络需要时使用与提供商兼容的响应和模板。
安全升级
当内容变得敏感时，邀请参与者进入适当的 Hat channel，而不是夸大外部渠道保护。
它是如何运作的
从公共渠道到受保护工作流程的简单路径
交接点应该是有意为之的、员工可见的，并且是与组织联系的人员可以理解的。
连接批准的企业帐户
确认所有权、提供商资格、API 访问权限、数据条款以及组织计划处理的消息类型。
路由和响应
传入的对话进入配置的队列，工作人员通过提供商集成分配并应答它们。
升级敏感工作
当外部网络不再适用时，将机密文档或对话转移到批准的安全通道。
安全和隐私
诚实的加密答案
集成无法追溯地使外部信使在 City of Hats 模型下进行端到端加密。正确的设计可以保持边界明确，并提供更安全的升级路径。
提供者保留在路径中
外部网络传输会话的客户端，并可以根据自己的条件处理内容和元数据。
Hat channels 是单独模式
City of Hats 端到端加密适用于支持的 Hat-to-Hat 通信，而不是自动应用于桥接提供者消息。
员工访问仍然很重要
组织必须控制谁可以访问共享队列以及员工如何验证、导出、复制或保留信息。
同意和渠道规则
客户对提供商政策、消息传递同意、模板、选择退出、保留和适用的通信法律负责。
范围清晰
重要边界
强烈适合时
您已经通过支持的业务消息传递渠道收到了合法的服务查询，并且需要更清晰的团队所有权和升级。
它不能取代什么
它不是绕过提供商规则、跨桥接网络保留端到端加密、导入每条历史消息或支持每个本机应用程序的每个功能的方法。
部署前确认
确认提供商帐户资格、区域、消息类型、模板、Webhooks、媒体处理、保留、删除、导出、员工权限和安全升级策略。
直接回答
团队在演示前提出的问题
产品范围审查: 2026 年 8 月 10 日
支持哪些渠道？
该解决方案是围绕支持的 WhatsApp Business、Facebook Messenger 和 LINE Official Account 集成而设计的。必须针对帐户、国家/地区和用例确认确切的提供商可用性和功能覆盖范围。
桥接消息是否经过 City of Hats 端到端加密？
不会。通过外部提供商传输的消息仍受该提供商的安全和数据处理的约束。当参与者通过支持的 Hat-to-Hat 模型进行通信时，适用 City of Hats 端到端加密。
客户可以继续使用他们现有的应用程序吗？
是的，适用于支持的连接对话。客户通过其常用的提供商发送和接收，而授权人员则从配置的 City of Hats 队列中工作。
我们可以将对话转移到安全的 Hat channel 中吗？
当更敏感的通信或文档交换开始时，工作流可以邀请参与者继续进行适当的 City of Hats 体验。
City of Hats 是否控制提供商的定价和限制？
不会。提供商费用、模板、对话窗口、速率限制、批准、中断和策略更改仍由 WhatsApp 或 Meta、Facebook 和 LINE 控制。
探索平台