01 · 一条链路，而不是五个模块
盘、房、客、交易、佣金共用主数据与状态。房源成交后自动进入交易，交易佣金自动生成应收，报表不再二次统计。
不比功能数量，比每个环节的完成度
房产中介系统很容易做成“什么都有，什么都差一点”。甄房OS 的选择是：把关键链路的最后一公里做完整。
差异化主张
五件我们做得更彻底的事
02 · 楼盘字典是资产，不是下拉框
七级层级 + 批量建栋建房 + 统一编码，让底表可以跨门店、跨城市复用；新城市开城时先建字典，避免后期返工。
03 · 房源管到“钥匙”和“委托”
很多系统管到房源状态就结束。我们把举证、检核、钥匙借还、退还业主、维护、调价、外发都做成有日志的动作。
04 · 佣金一套账，不是两张表
应收台账与交易佣金双向同步，实收登记后状态回写；折佣、豁免、坏账、结算、工资条在同一条状态链上。
05 · 多租户与数据域，为连锁准备
不是给单店做一个大账号，而是从架构上支持多主体、多门店、多角色；权限点可单独配置数据域，边界清晰。
还有一件：可交付
支持容器化与私有化部署，整站可复制为定制副本；对需要独立品牌、独立数据归属的机构，这比“只能租 SaaS”更现实。
能力对照
10 个维度，逐项看完成度
下表对照的是“常见系统做法”与“甄房OS 的做法”，不针对任何具体厂商。
| 维度 | 常见做法 | 甄房OS |
|---|---|---|
| 01 楼盘字典 | 楼盘名称 + 地址，楼栋房号手工录 | 七级层级 + 批量建栋/建房 + 统一编码 |
| 02 房源作业 | 录入与状态管理为主 | 举证、检核、钥匙、维护、调价、外发全生命周期 |
| 03 录房效率 | 长表单，重复房源靠人工判断 | 字典带出、四级联动、快录拆条与自动查重 |
| 04 客源经营 | 客户列表 + 跟进记录 | 需求、带看、踩盘、公客池、智能匹配、分配留痕 |
| 05 交易履约 | 交易状态 + 附件 | 节点模板、资金、定金转定、过户、售后升级 |
| 06 薪酬财务 | 提成规则 + 结算表 | 三级分成、应收实收同步、折佣审批、个税与工资条 |
| 07 电子签 | 跳转第三方签署，状态不回传 | 主体、多经办人授权、签署状态回调、PDF 归档 |
| 08 移动协同 | 移动端只做查询或简单审批 | 录房、跟进、带看、踩盘、日报、结算全流程 H5 |
| 09 数据决策 | 固定报表，口径依赖人工 | 六类报表、成交日历、四维排行、双佣金口径、下钻 |
| 10 平台治理 | 单租户或简单角色权限 | 多租户 + 权限点 × 数据域 1-5 级 |
说明：能力描述以当前产品实际功能为准；涉及第三方平台（电子签、地图、外发渠道）的能力以对应服务开通情况为准。
适用边界
什么情况下，我们可能不是最佳选择
选型不是越全越好。以下情况建议先评估，避免上线后反复调整。
更适合甄房OS 的情况
- 以二手房、租赁为主，同时有新房渠道业务
- 有多门店、多主体，需要数据隔离与汇总
- 希望把房源真实度、客户归属、佣金结算一起管起来
- 接受分阶段上线，愿意先跑通一条业务线
- 需要私有化部署或独立品牌站点
需要先确认的情况
- 业务以海外房产为主，需要多币种、多语言深度支持
- 需要与大量自研系统做深度双向集成
- 要求完全按现有流程零调整上线，不做任何规则梳理
- 需要覆盖开发商案场销售的全套 CRM 能力
- 对特定第三方平台的强依赖尚未开通