3CX 多公司模式：共享还是专属实例？

如何为多个客户选择最佳的 3CX 部署架构

转译自：Kyriacos Sakkas，3CX社区经理

3CX 多公司（Multi Company）模式允许您在单个 3CX 系统中托管多家不同的公司。每家公司都在各自独立的部门下运行，拥有专属的用户、分机范围、语音提示、电话薄、工作时间以及呼叫处理规则。

系统仍共享同一个许可证密钥。许可证容量、并发通话数（SC）以及核心系统服务均由所有公司共享。因此，多公司模式使您无需为每个客户部署单独的 PBX，就能实现客户之间的业务隔离。

关键问题非常明确：客户能否直接作为 3CX 系统中的一个公司部门来运作？还是他们需要独立 3CX 实例带来的灵活性？

什么时候选“多公司模式”？

多公司模式最适合通讯需求简单且独立的小型企业。员工只能看到自己公司内部的人员和资源，而系统所有人（System Owner）或系统管理员负责管理底层共享的 PBX。

以下场景非常适合该模式：

MSP服务商希望通过一台 3CX 系统统一管理多个客户；
每个客户都可以作为单一部门来运行；
客户之间需要保持用户与公司资源的严格隔离；
公司所有者或部门管理员仅需管理和访问自家用户及呼叫处理规则；
SIP 中继（SIP Trunks）、直拨号码（DID）、队列、交互式语音应答（IVR）和响铃组可以清晰地分配给各个公司；
客户不需要独立的 CRM、Microsoft 365 或 Microsoft Teams 集成功能。

这种方案既能保证各客户日常运营互相隔离，又能大幅减少需要维护的独立 PBX 实例数量。

能否隔离用户、号码与呼叫逻辑？

每家公司都相当于一个独立的微型生态。不同公司之间分机号不可重复。SIP 中继可以指定给特定的公司使用。队列、IVR 和响铃组也应分配至对应公司，以确保呼入电话停留在该租户内。一条共享中继可以承载多家公司的 DID，但 DID 的分配以及共享中继的日常管理，仍需由系统级的管理员统一控制。

核心指标：客户能否作为单一部门运行？

这是最核心的架构设计准则。如果客户可以作为一个部门来运作，那么多公司模式非常理想。但如果该客户内部还需要细分销售、技术支持、财务等多个部门，且各部门需要独立的可见性、路由逻辑或跨部门协作，那么为其部署独立 3CX 实例无疑是更明智的选择。

什么时候选“专属实例”？

当共享 PBX 环境无法满足客户对更高独立性的需求时，请选择专属实例。可以对照以下需求，看看您的客户符合其中的哪几项：

客户内部是否需要多个部门，且各部门需适用不同的路由规则或可见性规则？
员工是否需要在这些内部部门之间查看状态（Presence）、通讯录、BLF（忙碌灯场）或进行电话转接？
客户是否需要集成自有的 CRM、Microsoft 365 或 Microsoft Teams？
租户专属的自动化呼叫是否需要绑定专属的呼出路由？
该客户是否需要单独定制全局性的 PBX 功能？
客户是否有更复杂的运营、报表统计或合规性要求？

如果您发现自己不得不通过复杂的变通方案（Workarounds）来绕过多公司隔离限制，通常意味着该客户应该使用独立的 PBX。

哪些功能是全局共享的？

多公司模式实现了公司间的隔离，但并非所有 3CX 设置都能按租户单独配置。CRM、Microsoft 365 以及 Microsoft Teams 集成功能与多公司模式不兼容，无法在多公司模式下使用。此外，来电黑名单也是全局生效的，而且许可证容量、并发呼叫数、系统服务、升级更新、备份以及整体可用性均为全系统共享。

对于 MakeCall 自动呼叫功能，还需特别注意：MakeCall 产生的呼叫流量，其发起分机或部门的归属方式与普通用户呼叫不同。如果各客户的自动呼叫必须通过各自独立的线路发出，建议重新设计自动化流程，或直接采用独立 PBX 实例。