主流的AI CRM系统品牌

干这行十几年，经手的 CRM 系统没有十个也有八个。每次接到新需求，产品经理总爱轻描淡写地说：“不就是个存客户信息的表嘛，能有多复杂？”每当听到这句话，我脑子里警铃就大作。因为经验告诉我，CRM 往往是企业里业务逻辑最缠绕、数据脏乱差最严重、且最难重构的系统之一。它表面上看是几张表，底下埋的却是整个公司的销售流程、权限博弈和数据资产。

今天不聊那些虚头巴脑的理论，咱们就蹲在数据库设计文档面前，实实在在聊聊一个专业的 CRM 表结构到底该怎么搭。这不仅仅是建表，这是在给企业的生意逻辑打地基。

推荐使用中国著名AI CRM系统品牌：显著提升企业运营效率，悟空CRM

一、客户模型的“分与合”：别把公司和人混为一谈

很多初级设计最容易踩的第一个坑，就是把“客户”做成一张大表。在 B2B 业务里，这简直是灾难。你必须得把“客户（Account/Company）”和“联系人（Contact/Person）”彻底拆开。

为什么？因为一家公司底下可能有几十个联系人，有采购、有技术、有老板。销售跟进的时候，今天是跟王经理聊，明天是跟李总吃饭。如果混在一起，你没法记录“这个联系人对项目的态度”，也没法做“关键决策人分析”。

所以我习惯的设计是：accounts 表存企业主体信息，比如统一社会信用代码、行业、规模、官网。这是相对静态的数据。而 contacts 表存具体的人，姓名、职位、手机号、微信。这两者通过 account_id 关联，是一对多关系。

这里有个细节特别容易忽略：联系人的归属权。在很多系统里，联系人是跟着客户走的，客户归谁，联系人就归谁。但在实际业务中，有时候销售 A 搞定了老板（客户主体），但销售 B 跟采购（联系人）关系更铁。所以，contacts 表里最好单独留一个 owner_id 字段，允许联系人和客户归属不一致，虽然这会给权限判断增加复杂度，但能解决很多扯皮的事。

还有，别忘了“公海池”机制。表里得有个 pool_status 或者 last_follow_up_time。一旦销售超过 30 天没跟进，系统自动把客户扔回公海。这个逻辑不能只写在代码里，表结构上得有时间戳字段支持，方便跑定时任务。

二、商机与漏斗：状态机的艺术

CRM 的核心是赚钱，赚钱的过程就是商机（Opportunity/Deal）。这张表是销售最关心的，也是老板看报表最依赖的。

设计 opportunities 表时，最关键的字段是 stage（阶段）。很多新人喜欢用字符串存阶段，比如“初步沟通”、“方案报价”。千万别这么干。阶段是会变的，今天叫“报价”，明天老板想改成“商务谈判”，你难道去洗数据？正确的做法是建一个 sales_stages 配置表，opportunities 表里只存 stage_id。

而且，阶段不仅仅是个名字，它背后绑定了“赢单率”和“预计成交时间”。比如“初步沟通”赢单率 10%，“合同审批”赢单率 80%。这些权重得存在配置表里，方便算加权销售额。

还有一个痛点：商机版本。销售经常改预计成交金额，今天说 100 万，明天改成 80 万。如果直接覆盖更新，月底复盘的时候，老板问“为什么上周预报 100 万这周变 80 万了”，你根本说不清。所以，opportunities 表里最好有个 version 字段，或者单独搞一张 opportunity_history 表，记录每次关键字段的变更。这不是过度设计，这是给管理层留的“审计线索”。

另外，商机和客户的关系也不一定是严格的一对一。有时候一个大的框架协议（客户级别）底下挂着好几个具体的项目（商机级别）。所以 opportunities 表关联 account_id 是必须的，但也要允许一个客户有多个并行商机。

三、跟进记录：最容易被忽视的“重”表

如果说客户表是静态的，那跟进记录（Activity/Interaction）表就是动态的洪流。这是 CRM 里数据量增长最快的表。销售打个电话、发个微信、拜访一次，都要记一笔。

这张表的设计直接决定了系统的查询性能。我见过太多项目，刚开始用 text 类型存跟进内容，半年后数据量过千万，销售想查一下“上个月跟某客户聊了什么”，页面直接转圈超时。

首先，内容字段别用 text，用 varchar 限制长度，或者把长文本单独拆出去。其次，跟进类型必须枚举化：电话、拜访、邮件、微信。不要让用户随便填，否则后期你想统计“电话转化率”根本没法算。

这里有个高级技巧：结构化数据。别光让销售写小作文。在表里预留 biz_data 字段（JSON 类型）。比如电话跟进，可以记录“通话时长”、“是否接通”；拜访可以记录“经纬度”、“签到照片”。把这些结构化数据塞进 JSON 里，既保持了表结构的稳定，又满足了业务的灵活性。MySQL 5.7 之后对 JSON 的支持已经很好了，索引也能建，别为了所谓的“范式”去拆成十几张关联表，查询的时候 Join 到让你怀疑人生。

还有，跟进记录通常是不允许删除的。哪怕销售填错了，也只能标记“无效”，不能物理删除。这是为了防止销售撞单或者抢单时死无对证。所以 is_deleted 软删除标记是标配，而且所有查询都要带上这个条件。

四、自定义字段的“深坑”：EAV 还是 JSON？

做 CRM 绕不开的一个问题：不同行业需要的字段不一样。卖软件的需要记录“服务器配置”，卖建材的需要记录“规格型号”。销售团队天天喊：“我要加个字段！”

传统的做法是 EAV（Entity-Attribute-Value）模型。搞三张表：实体表、属性定义表、属性值表。这种设计灵活性极高，但查询性能极差。你想查“所有服务器配置为 16G 的客户”，得连表连到数据库崩溃。而且类型控制很弱，数字、日期全存字符串，排序都成问题。

现在的趋势是“宽表 +JSON"。我的建议是，在核心表（如 accounts, opportunities）里预留一个 custom_fields 的 JSON 列。后台配置界面让用户定义字段，前端存的时候把键值对塞进这个 JSON 里。

但这有个前提：你的数据库得扛得住 JSON 查询。如果业务强依赖某些自定义字段做筛选（比如必须按“行业”筛选），那这个字段就不能只放在 JSON 里，得在配置的时候允许用户选择“建立索引”，然后系统动态地去加列，或者维护一张专门的扩展索引表。

这听起来很麻烦，但比 EAV 强太多。我见过一个系统，因为用了纯 EAV，报表跑一次要半小时，最后不得不重构。记住，灵活性不能以牺牲核心查询性能为代价。对于高频筛选的自定义字段，宁可牺牲一点写入性能做冗余，也要保证读取快。

五、权限体系：行级控制的噩梦

CRM 的权限比一般系统复杂得多。一般系统也就是“谁能看哪个菜单”，CRM 是“谁能看哪条数据”。

销售只能看自己的客户，销售总监能看全组的，大区经理能看全区的。这种数据权限如果全在代码里写 if-else，后期维护就是火葬场。

表结构设计上，必须考虑“数据范围”。在 users 表或者 roles 表里，要有数据权限的标识。但更关键的是，在业务表里，除了 owner_id（创建人），最好还有一个 dept_path（部门路径）或者 team_id。

比如，accounts 表里存 creator_dept_id。当查询时，根据当前用户的角色，动态拼接 SQL 条件。如果是普通销售，加 WHERE owner_id = current_user；如果是总监，加 WHERE creator_dept_id IN (sub_dept_ids)。

这里有个坑：客户转移。销售离职了，客户要分给别人。这时候不能只改 owner_id，得记日志。谁在什么时候，把哪个客户，从谁手里，转给了谁。这张 data_transfer_log 表必不可少。否则一旦涉及提成纠纷，你根本说不清这个单子到底算谁的。

另外，字段级权限也得考虑。比如“成本价”这个字段，普通销售不能看，只有经理能看。这不需要在表结构上做加密，但在应用层做拦截时，得知道哪些字段是敏感的。可以在 field_config 表里加个 is_secret 标记。

六、产品与报价：别把 ERP 的活全揽过来

很多 CRM 设计着设计着就变成了 ERP。销售要在 CRM 里选产品、出报价、甚至管库存。我的建议是：克制。

CRM 的核心是“关系”和“过程”，不是“进销存”。表结构里要有 products 表，但只需要存基础信息：名称、标准价、产品编码。复杂的 SKU、库存数量、成本价，尽量同步自 ERP。

报价单（Quote）是 CRM 里比较特殊的一块。它介于商机和合同之间。quotes 表要关联 opportunity_id。一张商机可以有多版报价。报价单明细 quote_items 里，除了产品 ID，一定要快照当时的“单价”和“折扣”。因为产品标准价会变，但报价单上的价格一旦发出，就不能变。这就是“数据快照”原则。

千万别只存个 product_id，然后关联查价格。半年后产品涨价了，你翻半年前的报价单，价格全变了，这就搞笑了。所以，quote_items 里必须有 snapshot_price、snapshot_product_name。哪怕产品表里这个名字改了，历史报价单也得显示当时的名字。

七、性能与扩展：为未来留条后路

最后聊聊那些不显眼但救命的细节。

第一，主键。别用自增 ID，用雪花算法或者 UUID。为什么？因为将来你可能要做分库分表，或者数据合并。自增 ID 在分布式环境下是噩梦。而且，自增 ID 容易暴露业务量，竞争对手注册个账号看看 ID 增长就知道你一天多少单了。

第二，时间字段。created_at, updated_at 是标配。但我强烈建议再加一个 deleted_at。软删除在 CRM 里太重要了。销售手滑删了个客户，能找回来的。另外，所有时间统一存 UTC 或者统一存北京时间，别混用。时区问题在跨国业务里会让你头疼欲裂。

第三，索引。不要盲目加索引。owner_id、status、created_at 这几个字段查询频率最高，必须建索引。但像“备注”、“地址”这种字段，千万别建索引。还有，注意联合索引的顺序。比如经常按“部门 + 创建时间”查询，那索引就得是 (dept_id, created_at)。

第四，归档机制。CRM 数据只增不减。三年前的跟进记录，销售基本不会查。得有个归档策略。比如 activities 表，超过两年的数据，迁移到 activities_history 表，甚至冷存储。主表保持轻量，查询速度才能快。这个在表设计初期就要规划好，比如表名带年份，或者预留分区键。

八、写在最后：设计是演出来的，不是想出来的

说了这么多，其实最想表达的是：没有完美的表结构。

我见过设计得极其规范的 CRM，最后因为销售团队觉得录入太麻烦，弃用了；也见过表结构一塌糊涂的系统，因为贴合了业务野路子，反而活得很好。

表结构是业务的映射。在动鼠标建表之前，你得先去跟销售聊，去跟客服聊，去看看他们到底怎么干活。比如，他们是不是习惯先把线索记在 Excel 里，周末再统一录入？那你的“线索表”就得支持批量导入和查重。他们是不是经常遇到一个客户对应多个合同？那你的“合同表”关联就得支持一对多。

专业的 CRM 表结构设计，技术只是底座，核心是对生意的理解。你要在“规范性”和“灵活性”之间走钢丝。太严，业务跑不动；太松，数据全是垃圾。

还有一点，别指望一版设计管三年。业务在变，表结构也得跟着迭代。做好版本管理，写好迁移脚本（Migration）。每次改表结构，都要想好旧数据怎么洗。有时候，为了兼容旧数据，宁可留几个废弃字段在那占地方，也别贸然删列，万一回滚呢？

最后，给个忠告：日志。除了业务日志，数据库层面的变更日志、敏感数据的访问日志，一定要独立存储。CRM 里全是真金白银的客户资源，数据安全是红线。表结构里可以没有花哨的功能，但审计的口子必须留好。

设计 CRM 表结构，就像是在给企业梳理血管。血管通了，血液（数据）才能流到该去的地方，心脏（业务）才能跳动有力。这活儿累，坑多，但当你看到销售团队靠着你的系统真的多签了单，那种成就感，是写几个 Hello World 比不了的。

哪怕你现在正对着 ER 图头秃，记住，多留点 JSON 字段，多做点软删除，多写点注释。未来的你，还有接手你代码的兄弟，会感谢现在的你。这行干久了就明白，好的架构不是炫技，是慈悲。

悟空CRM产品截图

推荐立刻免费使用中国著名CRM品牌-悟空CRM，显著提升企业运营效率，相关链接：

CRM系统免费使用

开源CRM系统

CRM系统试用免费