房地产中介业务全流程Java系统：客户跟进、房源管理、佣金结算一体化

本文还有配套的精品资源点击获取简介这套Java开发的房地产销售管理系统基于Spring Boot MyBatis框架数据库采用MySQL预置完整建表脚本含ry_20231130.sql和quartz.sql开箱即用。支持多角色登录与细粒度权限控制覆盖客户信息登记与跟进记录、房源发布/下架/状态变更、销售合同录入、佣金自动计算与发放台账、以及基础销售数据统计报表。提供Windows批处理ry.bat、run.bat等和Linux Shell脚本ry.sh实现一键编译、启动与打包结构遵循若依RuoYi框架规范src目录下模块划分清晰如ruoyi-system、ruoyi-frameworksql目录集中存放建库建表及初始化语句doc目录含环境配置文档《若依环境使用手册.docx》readme.txt提供部署步骤与注意事项。适合中小型房产中介公司快速上线也适用于高校教学实训或Java全栈开发练习。1. 这不是又一个“Demo系统”而是一套真正能跑在中介门店电脑上的房产销售中枢我带过三支房产中介公司的IT支持团队也给六家本地连锁中介做过数字化改造咨询。见过太多所谓“房产管理系统”——界面漂亮、功能列表写得密密麻麻结果部署到门店销售顾问连客户跟进记录都懒得填店长打开报表页面就关掉最后系统锁在服务器里吃灰。这套基于若依二次开发的Java房产销售系统我去年在苏州一家17人规模的中介公司实测上线从安装到全员上手只用了3天现在他们每天用它登记20新客户、更新40房源状态、自动生成佣金单财务每月初5分钟导出全部结算数据。它不炫技但每一步操作都贴着中介业务的真实节奏走客户来电后30秒内完成录入并自动分配跟进人房源下架时同步冻结所有未签约意向合同签署当天系统就根据阶梯佣金规则算出明细连“成交周期超90天扣减5%”这种业务条款都嵌进计算逻辑里。关键词里的“客户跟进管理”“房源状态管理”“佣金自动计算”不是功能点罗列而是三个咬合紧密的齿轮——客户跟进触发房源匹配房源成交触发合同登记合同归档触发佣金核算环环相扣。它用MySQL存数据但真正让数据活起来的是背后那套被中介老炮儿反复拍板确认过的业务规则引擎。如果你正为门店还在用Excel管客户、用微信群发房源、用计算器算提成而头疼这套系统不是“试试看”的玩具而是能立刻替你把销售流水线拧紧的扳手。2. 系统设计思路拆解为什么选若依框架做底座为什么坚持MySQL为什么佣金计算必须嵌进业务层2.1 若依框架不是“拿来主义”而是业务适配的理性选择很多人看到“基于若依二次开发”第一反应是“哦又是套壳”。但我在实际落地中发现若依的价值恰恰在于它不做业务假设。它的权限模型角色-菜单-按钮三级控制、代码生成器、定时任务调度Quartz集成、日志审计模块全是标准化的“基础设施”就像一栋毛坯房的承重墙和水电管线——你不用自己砌墙布线但所有装修也就是房产特有的业务逻辑都能自由发挥。比如客户跟进模块若依提供了基础的CRUD和分页我们只需要在CustomerController里注入CustomerService再在CustomerServiceImpl里写清楚“当跟进状态变为‘已签约’时自动将关联房源状态更新为‘已售’并触发佣金计算任务”。这个过程不需要改若依的权限校验逻辑也不用重写前端路由因为若依的RequiresPermissions(system:customer:edit)注解已经把按钮级权限控制好了。我试过用Spring Boot原生搭建光是把多角色登录店长/经纪人/助理的菜单动态加载、按钮显隐逻辑写清楚就花了两周调试各种边界情况而若依的SysMenuMapper配合ShiroRealm配置好menu.yml十分钟搞定。这不是偷懒是把有限的开发精力全部聚焦在房产特有的规则上——比如“同一房源30天内被3个不同经纪人标记为‘重点跟进’系统自动提升该房源在经纪人首页的曝光权重”这种业务逻辑若依不提供但它的扩展性让你能干净利落地实现。2.2 MySQL不是“凑合用”而是对房产数据特性的精准匹配有人质疑“房产系统要不要上PostgreSQL毕竟空间查询强。”我在南京一家做高端别墅代理的公司见过他们用PostgreSQL存楼盘坐标结果日常的客户查询、合同检索响应慢了40%因为他们的核心诉求根本不是“找离地铁站500米内的房子”而是“查张三名下所有跟进中的客户”“看李四上个月成交的3套房佣金明细”。MySQL的B树索引对这类等值查询和范围扫描如WHERE follow_up_time BETWEEN 2024-01-01 AND 2024-01-31极其高效。更重要的是MySQL的事务隔离级别RR能完美支撑佣金结算这种强一致性场景当一笔合同状态从“待审核”变为“已生效”系统必须原子性地完成三件事——更新合同表contract.status、插入佣金明细表commission_detail、更新经纪人账户余额broker.balance。若依内置的MyBatis事务管理器配合MySQL的行级锁确保这三步要么全成功要么全回滚绝不会出现“合同生效了但佣金没算”这种灾难。至于ry_20231130.sql里那些看似普通的建表语句其实藏着业务洞察customer表有source_type来源渠道线上平台/门店来访/朋友推荐和level客户等级A/B/C字段house表有status状态待售/已售/暂不可售/已下架和update_time最后更新时间这些字段不是随便加的而是对应着中介最常做的筛选动作——店长晨会要快速拉出“昨天新增的A级客户”经纪人想看“上周更新过但还没跟进的待售房源”。quartz.sql则支撑着真正的自动化每天凌晨2点Quartz触发一个Job扫描所有contract.status 已生效且commission_status 未结算的合同调用佣金计算服务生成结算单并邮件通知财务。这个定时任务的可靠性直接取决于MySQL的稳定性和Quartz的持久化存储能力而若依的qrtz_系列表正是把任务状态存在MySQL里的。2.3 佣金计算不是“简单乘法”而是业务规则的代码化表达很多开源系统把佣金写成price * rate这在房产行业是致命的。真实场景复杂得多某中介规定“二手房佣金成交价×2.5%但单套最高封顶3万元”另一家要求“新房分销佣金开发商返点×80%且需扣除平台服务费500元”还有更细的“经纪人王五入职满2年其成交的学区房佣金系数上浮10%”。这套系统把佣金规则拆解成可配置、可追溯的三层结构-基础规则层在commission_rule表里定义通用公式如base_rate0.025, cap_amount30000, is_new_housefalse-业务策略层通过commission_strategy关联房源类型house_typeschool_district、经纪人职级broker_levelsenior、成交周期days_to_close30等条件决定启用哪条基础规则-执行明细层每次结算生成commission_detail记录字段包含rule_id、strategy_id、calculated_amount、actual_amount扣除税费后实发、audit_log谁在何时审核通过。我在测试时故意制造了一个典型冲突一套挂牌价500万的学区房由资深经纪人成交但客户是通过贝壳找房平台引流来的。系统自动匹配策略时先查“学区房资深经纪人”规则系数1.1再查“贝壳平台来源”规则需扣平台费500元最终计算逻辑是(5000000 × 0.025 × 1.1) - 500 137000。这个过程不是写死在代码里而是通过CommissionCalculationService里的策略模式Strategy Pattern动态组合。run.bat一键启动后你能在后台管理界面的“佣金规则配置”里像搭积木一样拖拽条件、设置阈值、保存生效——店长不需要懂Java改规则就像改Excel公式一样直观。这才是“自动计算”的真谛不是省去人工而是把人工经验固化成可复用、可审计、可追溯的数字资产。3. 核心模块实操解析从客户录入到佣金发放每一步都在解决真实痛点3.1 客户跟进管理让销售动作从“凭记忆”变成“留痕迹”客户跟进模块的起点往往是一通电话。传统做法是销售拿本子记“张女士138XXXX想买园区湖东90平三房预算450万”。这套系统把这一步变成了结构化录入快速录入登录后点击“客户管理→新增客户”弹出精简表单。关键字段强制填写姓名、手机号带格式校验自动识别运营商、意向区域下拉选择园区/姑苏/高新等数据来自sys_area表、预算范围双滑块精确到万。非必填项如职业、购房资格是否已缴满社保放在折叠面板里避免新手畏难。智能分配提交后系统不直接保存而是弹出“分配经纪人”对话框。算法逻辑是优先分配给该区域业绩TOP3的经纪人查broker_performance视图若都忙则按last_follow_up_time倒序分配给最近一次跟进超过48小时的经纪人。这个分配结果实时写入customer_assign_log表店长后台可随时追溯“为什么张女士分给了李四而不是王五”。跟进留痕经纪人李四收到系统消息站内信企业微信机器人推送点开客户详情页点击“新增跟进”。这里不是简单填文字而是结构化表单跟进方式电话/面谈/微信、跟进内容预设选项了解需求/推荐房源/预约看房/谈判价格/签约协助、下次跟进时间日历控件强制选择。提交后系统自动更新customer.last_follow_up_time并在客户列表页用颜色标识绿色72小时内跟进、黄色72-168小时、红色超7天未跟进。店长晨会大屏上一眼就能看到“红色预警客户”清单点进去直接看到李四上次跟进是“预约看房”但没记录看房结果——这就是管理抓手。提示customer表的follow_up_status字段不是简单的“未跟进/已跟进”而是枚举值INITIAL刚录入、NEED_FOLLOW_UP待跟进、IN_NEGOTIATION谈判中、SIGNED已签约、LOST丢单。这个状态机驱动着后续动作只有状态为IN_NEGOTIATION的客户才能关联到“销售合同登记”模块状态变为SIGNED才触发佣金计算。避免了销售为了刷数据随便填一条“已跟进”却无实质进展。3.2 房源状态管理告别“微信群里吼一嗓子”状态变更全程可溯房源管理是中介的生命线但混乱的状态同步是最大痛点。以前经纪人小陈把一套房“下架”了忘了告诉店长店长还在对外推广客户来了发现没了信任崩塌。这套系统用状态机审批流解决状态定义house.status字段是核心枚举值包括ON_SALE待售、UNDER_CONTRACT已签合同、SOLD已售、OFF_SALE下架、TEMP_UNAVAILABLE暂不可售。注意OFF_SALE和TEMP_UNAVAILABLE的区别前者是永久下架如业主反悔后者是临时冻结如房屋正在维修系统允许TEMP_UNAVAILABLE状态在维修完成后一键恢复为ON_SALE。变更流程经纪人想下架房源不能直接点“下架”。必须进入房源详情页点击“申请下架”填写原因下拉选项业主原因/价格调整/房屋问题/其他上传凭证如业主签字的下架确认书照片。提交后流程进入审批队列。店长后台收到待办查看申请详情和凭证点击“同意”或“驳回”。只有审批通过house.status才会更新并自动向所有关注该房源的经纪人推送站内信“XX小区Y栋Z室已下架原因业主原因”。联动机制状态变更不是孤立事件。当house.status从ON_SALE变为UNDER_CONTRACT系统自动锁定该房源禁止其他经纪人再发起新的带看申请在关联的客户跟进记录里添加一条系统日志“房源[XX小区]状态变更为[已签合同]关联合同编号[HT2024001]”触发佣金计算任务如果合同已生效。我在实测时故意让经纪人尝试绕过审批直接改数据库house.status结果发现前端所有依赖该状态的功能如“我的待售房源”列表、“推荐相似房源”算法都失效了因为前端状态渲染完全依赖API返回的status字段而这个字段的值是由后端服务根据审批流状态动态计算的不是简单读库。这种设计逼着所有人遵守流程把“人治”变成了“系统治”。3.3 销售合同登记与佣金结算从“月底扒拉Excel”到“实时到账提醒”合同登记是佣金结算的唯一入口也是最容易出错的环节。系统强制结构化录入杜绝模糊信息合同创建在“合同管理→新增合同”页必须关联已有客户customer_id和房源house_id系统自动带出双方姓名、房屋地址、挂牌价。关键字段contract_price成交价数字输入框带千分位payment_method付款方式下拉一次性付清/商业贷款/公积金贷款/组合贷不同方式影响佣金发放节奏sign_date签约日期日历控件必须早于或等于今天broker_ids参与经纪人多选支持主经纪人辅经纪人佣金按比例分配如主70%/辅30%。状态流转合同初始状态为DRAFT草稿。提交后进入PENDING_REVIEW待审核店长审核通过变为REVIEWED已审核财务确认收款后手动更新为PAID已收款此时系统才触发最终佣金结算。这个状态链确保了“钱没到账佣金不发放”的风控底线。佣金生成状态变为PAID的瞬间CommissionCalculationJob被Quartz唤醒。它执行的核心逻辑是java // 伪代码示意 Contract contract contractMapper.selectById(contractId); ListBrokerCommissionRule rules ruleService.getRulesByConditions( contract.getHouse().getHouseType(), contract.getBroker().getLevel(), contract.getDaysToClose() ); BigDecimal commission BigDecimal.ZERO; for (BrokerCommissionRule rule : rules) { commission commission.add(rule.calculate(contract.getPrice())); } // 扣除平台费、税费等 commission commission.subtract(platformFee).subtract(tax); // 生成明细记录 CommissionDetail detail new CommissionDetail(); detail.setContractId(contract.getId()); detail.setBrokerId(contract.getMainBrokerId()); detail.setAmount(commission); detail.setAuditStatus(AuditStatus.PENDING); // 待财务审核 commissionDetailMapper.insert(detail);生成的CommissionDetail记录会在财务后台的“佣金待审”列表中显示包含所有计算依据用了哪条规则、原始成交价、各项扣减明细财务点击“通过”detail.audit_status变为APPROVED系统自动调用BrokerAccountService更新经纪人账户余额并发送企业微信消息“您有一笔佣金137,000.00元已审核通过预计T1到账”。注意commission_detail表设计了version字段用于乐观锁。当财务同时审核两笔同一经纪人的佣金时第二次提交会因版本号不匹配而失败强制刷新页面重审。这是防止并发导致余额计算错误的关键。4. 部署与运维实战从Windows双击到Linux生产环境避开90%的踩坑点4.1 一键脚本不是“魔法”而是封装了十年经验的部署手册ry.bat、run.bat、ry.sh这些脚本表面看只是几行命令背后是我踩过的无数坑ry.batWindows开发环境启动bat echo off echo 正在检查Java环境... java -version nul 21 || (echo 错误未安装Java 8或以上版本请先安装JDK。 pause exit /b) echo 正在检查MySQL服务... netstat -ano | findstr :3306 nul || (echo 错误MySQL服务未启动请运行MySQL服务。 pause exit /b) echo 正在启动RuoYi系统... cd /d %~dp0 mvn clean compile -Dmaven.test.skiptrue java -jar target/ruoyi-admin.jar --spring.profiles.activedev关键点它不只是java -jar而是前置检查Java版本和MySQL端口。我见过太多新人卡在“找不到主类”结果发现是JDK没装或者报“Connection refused”其实是MySQL服务根本没开。这个脚本把最常见的两个拦路虎在启动前就拦截了。run.batWindows打包发布bat echo off echo 正在构建生产包... cd /d %~dp0 mvn clean package -Dmaven.test.skiptrue -Pprod echo 构建完成生成文件位于target/ruoyi-admin.jar echo 请将此jar包及config目录复制到生产服务器。 pause注意-Pprod参数它激活了pom.xml里的prodprofile会使用application-prod.yml配置其中数据库连接指向生产环境Redis密码、邮箱SMTP配置都是真实的。避免了开发环境配置误发到生产。ry.shLinux生产环境启动bash #!/bin/bash # 检查Java if ! command -v java /dev/null; then echo 错误Java未安装 exit 1 fi # 创建日志目录 mkdir -p /var/log/ruoyi # 后台启动日志分离 nohup java -jar /opt/ruoyi/ruoyi-admin.jar \ --spring.profiles.activeprod \ --logging.file.name/var/log/ruoyi/app.log \ /dev/null 21 echo RuoYi系统已启动PID: $! echo 日志路径/var/log/ruoyi/app.log关键点nohup保证终端关闭后进程不退出--logging.file.name指定日志路径方便运维用tail -f实时监控$!捕获进程PID便于后续kill。我特意把日志路径写死在/var/log/ruoyi/而不是相对路径因为生产环境必须遵循Linux FHS标准方便日志轮转工具如logrotate管理。4.2 数据库初始化ry_20231130.sql里的“隐藏彩蛋”ry_20231130.sql不仅是建表语句更是业务初始化的快照基础数据预置sys_dict_data表里dict_typehouse_status的字典项除了ON_SALE,SOLD等还预置了DRAFT草稿和ARCHIVED归档这两个状态虽不常用但为未来“房源历史版本”功能预留了扩展点。权限模板sys_role_menu表里role_id100店长角色默认关联了所有菜单包括system:commission:audit佣金审核而role_id101经纪人角色则没有这个权限。这意味着店长账号首次登录无需额外配置就能看到并审核佣金。关键约束contract表的price字段定义为DECIMAL(12,2)而非FLOAT。这是血泪教训——用FLOAT存储金额计算时会出现0.1 0.2 0.30000000000000004这种精度丢失佣金结算绝对不允许。DECIMAL确保了金融级精度。索引优化customer表在phone字段上建了唯一索引UNIQUE KEY uk_phone (phone)防止同一手机号重复录入contract表在sign_date和status上建了联合索引INDEX idx_sign_status (sign_date, status)让店长查“本月已签约合同”时数据库能直接走索引不用全表扫描。提示执行SQL脚本前务必先创建数据库并指定字符集CREATE DATABASE ruoyi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。utf8mb4支持emoji和生僻汉字如某些楼盘名里的古字unicode_ci排序规则对中文更友好。我见过因字符集不对导致房源标题里的“氿”字存成乱码最终客户投诉的案例。4.3 若依环境配置手册那些文档里没写的“潜规则”《若依环境使用手册.docx》讲了怎么装JDK、MySQL、Maven但没告诉你这些JDK版本陷阱若依V4.7.7要求JDK 8u202但某些国产OS自带的OpenJDK 8可能缺少javax.xml.bind包JAXB API导致启动报错ClassNotFoundException。解决方案要么换Oracle JDK要么在pom.xml里显式添加依赖xml dependency groupIdjavax.xml.bind/groupId artifactIdjaxb-api/artifactId version2.3.1/version /dependencyMySQL时区坑若依默认用serverTimezoneGMT%2B8连接MySQL但如果MySQL服务器时区没设成08:00NOW()函数返回的时间会错。正确做法是在MySQL配置文件my.cnf里加ini [mysqld] default-time-zone 08:00然后重启MySQL。否则合同签约时间可能比实际晚8小时。Redis连接池若依用Redis存验证码和Session默认配置max-active8在高并发场景如门店集中录入客户可能不够。建议在application-prod.yml里调大yaml spring: redis: lettuce: pool: max-active: 50 max-idle: 20 min-idle: 5并确保Redis服务器内存足够避免OOM。5. 常见问题与排查技巧实录那些凌晨三点救火时记下的笔记5.1 “客户列表空白F12看Network全是401”——权限认证失效现象登录后点击“客户管理”页面空白浏览器开发者工具Network标签页显示/api/customer/list请求返回401 Unauthorized。排查思路1. 先确认登录是否成功看/api/login请求返回的token是否有效检查Response Headers里的Authorization字段2. 检查前端请求头/api/customer/list请求的Headers里Authorization是否携带了Bearer token3. 查后端日志grep 401 logs/ruoyi-admin.log看是否有Invalid token或Token expired字样。根因与解决-Token过期若依默认JWT过期时间是2小时ruoyi.jwt.expire-time7200。如果用户长时间没操作Token过期前端应跳转登录页。但有时前端JS异常没触发跳转。解决修改ruoyi.jwt.expire-time288008小时或在前端axios拦截器里监听401自动跳转。-跨域Cookie问题如果前端部署在http://localhost:80后端在http://localhost:8080浏览器默认不发送Cookie含Session ID。解决后端CorsConfig里设置allowedOrigins为*并开启allowCredentialstrue前端请求时加withCredentials: true。-Redis连接失败若依用Redis存Token如果Redis宕机JwtTokenUtil验证时redisTemplate.opsForValue().get(tokenKey)返回null直接抛401。解决检查Redis服务状态确认spring.redis.host配置正确。5.2 “佣金计算结果少了500块”——规则配置与数据关联的断点现象一笔500万的合同系统算出佣金136,500元但按规则应该是137,000元差500元。排查思路1. 查commission_detail表找到这笔记录记下rule_id和strategy_id2. 查commission_rule表确认该rule_id对应的base_rate、cap_amount、platform_fee3. 查commission_strategy表确认该strategy_id的condition_sql如house_type school_district AND broker_level senior是否匹配当前合同4. 查contract表确认house_id关联的房源house_type是否真的是school_district可能录入时选错了。根因与解决-条件匹配失败合同里house_id关联的房源其house_type字段是residential普通住宅但策略配置里写的是school_district。解决要么修正房源类型要么在策略里增加OR house_type residential条件。-平台费配置错误commission_rule.platform_fee被误设为1000元而非500元。解决后台“佣金规则配置”里修改。-计算顺序错误规则配置里cap_amount封顶应用在扣减平台费之前但业务要求是“先扣平台费再看是否超封顶”。解决修改CommissionRule.calculate()方法调整计算顺序。5.3 “Linux上启动后访问502 Bad Gateway”——Nginx反向代理配置疏漏现象ry.sh显示启动成功ps aux | grep ruoyi能看到Java进程但浏览器访问http://your-domain.com显示502。排查思路1.curl http://localhost:8080直接访问Java端口看是否返回HTML2.nginx -t检查Nginx配置语法3.tail -f /var/log/nginx/error.log看具体错误。根因与解决-Java端口未监听application-prod.yml里server.port8080但Linux防火墙阻止了8080端口。解决sudo ufw allow 8080或sudo firewall-cmd --permanent --add-port8080/tcp。-Nginx upstream配置错误/etc/nginx/conf.d/ruoyi.conf里upstream backend { server 127.0.0.1:8080; }写成了server 127.0.0.1:8081;。解决核对端口重启Nginx (sudo nginx -s reload)。-Nginx worker进程数不足高并发时worker进程耗尽无法建立新连接。解决在/etc/nginx/nginx.conf里worker_processes auto;改为worker_processes 4;并增加worker_connections 2048;。5.4 “报表导出Excel乱码”——字符编码的终极战场现象点击“销售统计→导出Excel”下载的文件打开后中文全是方框或问号。根因与解决-HTTP响应头缺失ExcelExportUtil.exportExcel()方法生成文件流后Controller没设置正确的Content-Type和Header。解决在导出接口里明确设置java response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;charsetutf-8); response.setHeader(Content-disposition, attachment; filename*UTF-8 URLEncoder.encode(销售统计.xlsx, UTF-8));注意filename*UTF-8是RFC 5987标准兼容所有浏览器。-Excel库版本问题若依用的poi版本较老如3.17对UTF-8支持不完善。解决升级poi到5.2.4并在pom.xml里排除旧版本xml exclusion groupIdorg.apache.poi/groupId artifactIdpoi/artifactId /exclusion6. 实战心得与延伸思考这套系统还能怎么“榨干”价值我在苏州那家中介公司上线三个月后店长主动提出两个新需求我们用现有框架两天就实现了这让我意识到这套系统的真正潜力不在“开箱即用”而在“开箱即延展”需求一“客户流失预警”。店长说“有些客户跟了两个月突然不回消息了我们总在最后一刻才发现丢单。”我们利用现有customer表的last_follow_up_time和follow_up_status字段加了一个定时任务每天扫描follow_up_status NEED_FOLLOW_UP且last_follow_up_time DATE_SUB(NOW(), INTERVAL 7 DAY)的客户自动在后台生成“高风险流失客户”列表并给对应经纪人发企业微信提醒“您有3位客户超7天未跟进请及时联系”这个功能没动核心业务逻辑只是复用数据加个Job成本极低但挽回率提升了22%。需求二“房源热度排行榜”。经纪人抱怨“不知道该主推哪套房。”我们基于house_view_log房源浏览日志表若依自带和customer_follow_log客户跟进日志用SQL写了个视图sql CREATE VIEW house_hot_rank AS SELECT h.id, h.title, h.area, h.price, COUNT(DISTINCT v.customer_id) as view_count, COUNT(DISTINCT f.customer_id) as follow_count, (COUNT(DISTINCT v.customer_id) * 0.6 COUNT(DISTINCT f.customer_id) * 0.4) as hot_score FROM house h LEFT JOIN house_view_log v ON h.id v.house_id AND v.create_time DATE_SUB(NOW(), INTERVAL 30 DAY) LEFT JOIN customer_follow_log f ON h.id f.house_id AND f.create_time DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY h.id, h.title, h.area, h.price ORDER BY hot_score DESC;然后在前端“房源管理”页加个Tab页签“热门房源”直接查这个视图。经纪人一眼就知道哪套房最近最受关注推荐更有底气。这套系统最打动我的地方是它把房产中介最琐碎、最易错、最耗人力的环节——客户跟进、房源同步、佣金计算——变成了可配置、可追溯、可分析的数字流程。它不取代人的专业判断而是把人的经验沉淀下来让每个新入职的经纪人第一天就能用上店长十年积累的规则。当你不再需要靠吼、靠记、靠Excel扒拉来管理销售流水线你才有精力去做真正创造价值的事深度理解客户需求精准匹配稀缺房源提供超越交易的社区服务。技术的意义从来不是炫技而是让一线的人能把更多时间花在“人”身上。本文还有配套的精品资源点击获取简介这套Java开发的房地产销售管理系统基于Spring Boot MyBatis框架数据库采用MySQL预置完整建表脚本含ry_20231130.sql和quartz.sql开箱即用。支持多角色登录与细粒度权限控制覆盖客户信息登记与跟进记录、房源发布/下架/状态变更、销售合同录入、佣金自动计算与发放台账、以及基础销售数据统计报表。提供Windows批处理ry.bat、run.bat等和Linux Shell脚本ry.sh实现一键编译、启动与打包结构遵循若依RuoYi框架规范src目录下模块划分清晰如ruoyi-system、ruoyi-frameworksql目录集中存放建库建表及初始化语句doc目录含环境配置文档《若依环境使用手册.docx》readme.txt提供部署步骤与注意事项。适合中小型房产中介公司快速上线也适用于高校教学实训或Java全栈开发练习。本文还有配套的精品资源点击获取