自托管 CRM：为何我们放弃了 SaaS
价值主张何时发生逆转
SaaS CRM 在三种情况下效果良好：当你的销售流程与工具的默认假设相吻合时，当你的团队规模使每席位费用合理时，以及当你不需要与供应商集成目录之外的工具深度集成时。
一旦这些条件中任何一个发生变化，计算就会改变。我们遇到的问题既有定价问题，也有功能问题：我们希望将 CRM 数据直接连接到我们的运营工具——n8n 工作流、自定义仪表板、以及已在自托管基础设施上运行的 Supabase 实例。每一个集成点都需要 API 密钥、速率限制谈判，以及供应商关于可接受使用方式的不透明规则。
为什么选择 Twenty
Twenty 是一款开源 CRM，在设计上遵循熟悉的 SaaS CRM 模式，同时完全可自托管。数据模型是可扩展的——你可以在不编写迁移脚本的情况下添加自定义字段和关系。API 是标准的 GraphQL。
部署是标准的 Docker Compose 栈：Twenty 后端、Twenty 前端、PostgreSQL 和 Redis。整个栈可以在一台普通服务器上运行，资源消耗适中。
实际迁移
从 HubSpot 迁移的过程包括导出联系人和公司数据（CSV 格式），清理重复项，然后通过 Twenty 的导入工具导入。历史互动记录没有迁移——我们决定从一个干净的数据集开始，将旧数据存档在别处。
自定义字段设置需要约半天时间：将我们的销售流程映射到 Twenty 的数据模型，添加 HubSpot 中不存在的字段，并配置管道阶段。
一年后的情况
运营开销低于预期。Twenty 稳定运行，数据库备份到对象存储，n8n 工作流通过 API 直接写入联系人记录。我们迁移到了不需要每用户许可证的定价模型，并完全控制了数据模型。
最大的缺点是缺少 SaaS 工具的某些内置功能——电子邮件追踪、序列、自动数据丰富。对于我们的用例来说，这些都不是关键功能。对于依赖这些功能的销售团队，权衡会有所不同。