售楼管理系统数据模型拆解：房源、客户、判客、交易四张主表怎么设计

不少技术团队第一次接售楼系统需求时都会低估它的复杂度：不就是客户表加房源表吗？等做到销控、判客、退换房这些环节，才发现状态流转和归属裁定比想象中难缠——两份合同引用同一套房的并发冲突、渠道报备和自然到访撞单时的裁定依据、退房后佣金回冲的账目处理。这篇从数据模型角度把售楼系统的骨架拆开讲清楚，供自己动手搭系统的团队参考。

一、为什么售楼系统的数据模型不好设计

房产交易的本质特征是：标的物唯一、流程长、参与方多。这三点 translated 成数据设计难题就是三件事。

• 房源是慢变主数据：一套房从取得预售到交付，属性基本不变，但状态高频流转，状态机设计错了后面全是坑；
• 客户是快变交易数据：一个客户从到访到成交要经历多次到访、多轮跟进、可能多次换房，行为记录持续累积；
• 归属关系横跨两者：判客规则涉及渠道报备、首访记录、保护期、老带新等多个事实，裁定逻辑天然复杂。

通用CRM直接套售楼场景水土不服，多半是栽在房源状态机和判客这两块。

二、四张主表：整个系统的骨架

再复杂的售楼系统，核心数据实体就四张主表加若干从表。先把主表和它们的关系定义清楚，系统就立起来一半。

四张表的关系：交易表连接房源和客户（多对多被交易收敛为一对一），判客记录表挂在客户维度，记录归属裁定的完整事实链。

三、房源状态机：销控正确的技术保障

销控表的本质是房源状态机。状态定义各家略有差异，核心集合大致是：可售→锁定→已认购→已签约→已网签→退回（异常分支）。

第一步：定义状态与合法迁移

每个状态明确允许的后继状态，非法迁移直接拒绝。比如已认购只能迁往已签约或退回可售，不能直接跳到已网签。状态迁移全部写日志，谁在什么时间把房源从什么状态改成什么状态，事后可查。

第二步：并发控制防一房两卖

技术手段就两个层次：数据库层面对交易表的房源外键加唯一约束（未退房的有效交易一个房源只允许一条），应用层面对状态变更加乐观锁或行锁。两手都要有，光靠前端按钮置灰挡不住并发提交。

第三步：退房与换房的补偿逻辑

退房意味着状态回退加交易作废，关联的佣金计算、回款计划要联动冲销；换房则是原子性的两条状态变更。这两块是缺陷高发区，测试用例要覆盖足。

四、判客规则引擎：把裁定逻辑从代码里解耦出来

判客逻辑每家开发商、每个项目的约定都不同，写死在代码里意味着每次改规则都要发版。合理做法是把规则做成可配置的引擎。

1. 事实先行：报备、到访都是事实表记录

渠道报备（渠道、客户电话、报备时间、有效期）、客户到访（到访时间、接待顾问、来源声明）全部作为事实记录，只增不改。裁定永远基于事实而非口头陈述。

2. 规则可配置：窗口期、保护期、优先级

常见规则参数：报备有效窗口（如提前30分钟至7天）、客户保护期（30~90天）、多渠道撞单优先级（首报优先或到访优先）、老业主永久归属。参数存配置表，运营人员可调。

3. 裁定结果可解释

每次裁定输出结论和依据链：依据哪条报备记录、哪次到访记录、命中哪条规则。仲裁时把依据链调出来，争议自然平息。这一点是判客模块有没有灵魂的分水岭。

五、低代码平台上的实现路径

这类数据模型用低代码平台实现效率很高，因为核心工作是定义实体、关系、状态机和表单，恰好是低代码的强项。以搭贝这类平台为例（以下为典型实施节奏，供评估参考）：

1. 第一周：建四张主表和从表，配置字段、约束和关联关系；
2. 第二周：配置房源状态机、判客规则参数表、报备与到访流程表单；
3. 第三周：搭角色视图（顾问、案场经理、渠道端）、报表看板和消息提醒。

三周左右核心框架可用，之后按项目实际约定微调规则参数。相比从零开发两三个月起步的周期，优势主要在表单、权限、移动端这些基础设施不用重造。房产销售的行业方案可以直接参考其字段和流程设计；想快速起步的团队，拿售楼管理应用模板改造也是务实路线，改字段和规则比从空白搭快得多。

六、三个容易被忽略的技术细节

最后补三个实施中容易被忽略、出事后代价不小的细节。

• 手机号规范化：建索引前统一去除空格横线、转半角，否则去重失效，撞单检测形同虚设；
• 金额精度与节点拆分：房款、佣金全程用分存储或定点小数，回款计划按节点拆分记录，别用一个总额字段糊过去；
• 日志与对账：状态变更、裁定结果、佣金计算全部留不可变日志，月度对账和审计都以日志为准，可追溯性是这类系统的生命线。

把四张主表、一个状态机、一套规则引擎这三件事做扎实，售楼系统的骨架就稳了。剩下的报表、提醒、移动端体验，都是在稳骨架上的增量改良。