房源与带看：房源不放空，带看不撞单

中介门店里，房源和带看最容易出问题的地方

二手房租售门店的业务其实不复杂：把房源拿到手，把客户带到房子里，把手续办完。但真正管起来，问题几乎都出在"同一个东西被好几个人同时惦记"上。

房源不在一个人手里，而在每个人的微信里。 同一个小区 3 号楼 2 单元 501，可能被三个经纪人各录一遍，报价不一样、面积不一样、委托到底是"卖"还是"租"也说不清。业主一问"我这房子现在挂多少"，店里要先打两个电话才能答上来。

带看撞单，是最伤士气的一种内耗。 两个经纪人不知道彼此的约看安排，同一个客户在同一天被带看了同一套房；或者房源已经收了意向、进入谈价阶段，别的经纪人还在约客户看房，到了门口业主说"这套不看了"。事后争佣金归属，靠嘴说、靠群聊截图。

业主的信任来自反馈，而反馈通常没有。 带看完了客户什么意见、卡在价格还是楼层，业主永远收不到消息；下一次经纪人再打过去，业主的态度就冷了。委托到期没人跟，一套好房源就这样悄悄流到别家。

门店经理看不到真实的去化节奏。 这个月带看多少组、哪些房源 40 天没一次带看、哪个渠道来的客户成交率高——这些数据如果在 Excel 里靠人填，永远慢半拍，也说不清。

这些问题的共同点是：信息没有落在一份共同的账上，状态没有唯一的说法。 下面按"数据怎么建、页面怎么用、自动化怎么配、移动端怎么配合、上线前查什么"来讲，这条链在 Inkwell AI 构建器里怎么搭出来。它不是要买一套行业软件再改造，而是把门店自己的规则说清楚，由 AI 构建器生成一套能直接用的模块，之后改字段、加规则也用同一套对话方式继续改。

底表怎么设计：三个关键决定

房源带看的模块看着表多，其实难的不是字段数量，而是三个设计决定。决定定下来了，后面的页面和自动化都是自然结果。

决定一：房源状态必须是一个受控字典，不是自由文本

房源主表里最要紧的字段不是面积和报价，而是状态。建议固定成这几档：在售（在租）、锁定（已收意向或已下定，暂不接新带看）、成交、暂缓、失效。

关键是它要用数据字典来管，而不是让人手打。字典的意义是让全店口径一致：什么叫"锁定"，谁有权改，锁定之后还能不能排带看，都在字典和权限里说死。字典的口径统一之后，报表才有意义——否则"在售"里混着十几套已经成交没改状态的房源，去化统计全错。数据字典的建法可以参看 /docs/data-dictionary.html。

决定二：一张房源主表 + 一张带看流水，不要合成一张

常见的错误是把带看记录塞进房源主表的备注里，或者用一个"带看次数"数字字段代替流水。这样做的后果是：撞单没法判、反馈没法追、佣金没依据。

推荐的结构是：

• 房源主表：房源编号（全店唯一、可读，如"小区首字母 + 门牌"）、小区与门牌、产权性质、面积、户型、楼层、委托价与底价、委托类型（出售/出租）、委托起止日期、维护人、钥匙状态、状态（受控字典）。
• 带看单（流水表）：关联房源与客户，记录约看日期与时段、带看经纪人、带看结果（待确认 / 已确认 / 已带看 / 客户爽约 / 取消）、客户意向等级、异议摘要、带看照片。
• 业主与客户：业主一人可对应多套房，用引用引擎做软关联即可，不必在房源表里重复存业主姓名电话；客户表存预算、区域、面积需求与意向等级，房源和客户之间是一对多的意向关系。
• 成交单：关联房源、客户以及促成这次成交的那条带看记录，登记成交价、成交日期、佣金分配（主带与协作）。佣金归属有据可查，靠的就是这条链路不断。

房源与客户、业主之间不要手工抄 ID，用引用引擎建立跨模块的选项数据源，选房号时直接下拉带出，改一处到处一致。委托书、产权证扫描件、带看照片这类凭据走文件模块，挂在房源或带看单下，谁传的、什么时候传的都有记录。

决定三：撞单规则要在数据层就说清，别指望事后追

撞单判定必须先定口径，常见两种：按房源 + 时间窗（同一房源同一时段不能被两个人同时约），按客户 + 房源（同一客户对同一房源只能有一次有效带看，重复出现的归首次带看人）。

推荐两者都设：时间窗防现场冲突，客户维度防佣金扯皮。口径定下来之后，做成带看单提交时的校验——校验不通过就不许保存，或者提示"该房源已被某某在 14:00–15:00 约看，是否发起协作带看"。这一步做在数据层，比任何群规都管用。

页面怎么用：一个角色一个视角

同一份数据，不同的人不该看到同一个页面。这是这套模块好不好用的分界线。

经纪人视角：我的房源 + 我的带看。 进来先看到自己维护的房源清单，按状态分组，每条显示在售天数、累计带看次数、最近一次带看时间。列表上最直接的按钮是"发起带看"：先选客户（或新建客户），再选房源，系统自动带出该房源已排的时段并做冲突校验，提交即生成带看单并进入待确认。带看回来后在同一张单上填结果与意向等级，手机端就能做，不用回门店开电脑。

门店经理视角：房源池 + 带看日程 + 去化。 房源池看全店房源状态分布与滞留时长，能一眼挑出"超过 30 天零带看"的房源，直接指派或调整维护人。带看日程最好做成按日期与经纪人的双维度视图，谁在哪天带谁看哪套房清清楚楚，这也是撞单最直观的一道人工防线。去化统计按小区、按价格段、按渠道来源看成交与带看转化，月底复盘不用再拼表。

前台与钥匙管理视角：钥匙借还登记。 钥匙状态是中介最容易被忽略的一环——钥匙在谁手上、什么时候借出、什么时候归还，房源表里挂一个钥匙状态字段加一条借还记录就够了，超时未还自动提醒。

成交登记视角（经理或指定角色）。 成交单必须从带看记录出发，系统自动带出该房源与客户的历史带看，选哪一条作为促成带看由经理确认。这样佣金分配有依据，也避免了"谁先说就是谁的"这种争法。谁能改价、谁能手改房源状态、谁能确认成交，交给角色与权限去控制，不必为此另造一套账号体系，做法见 /docs/roles-permissions.html。

自动化：四类规则，把"记得做"变成"系统会做"

页面解决的是"看到"，自动化解决的是"不会漏"。这套模块里有四类现成的自动化机制可以用。

一、审批流：把有风险的动作用流程卡住。 建议至少三条上线：成交价低于委托价一定比例、独家委托变更、佣金分配调整。这些事一旦口头决定，后面全是纠纷。审批流按节点配，请假报销那套机制同样适用于这里，参考 /solutions/oa-approval-flow.html。工作流的配法见 /docs/workflow-visual-editor.html。

二、数据流规则：状态一变，关联数据跟着变。 最典型的三条：

• 带看单改为"已带看"→ 自动累加房源的带看次数，并把客户的最后跟进时间刷新；
• 房源状态改为"锁定"→ 该房源后续的带看单提交受阻，已有待确认约看自动提示维护人与约看人；
• 房源状态改为"成交"→ 自动归档，其余待确认带看单统一关闭并通知，避免还有客户白跑一趟。

这类"条件触发、自动改数据"的规则不需要写代码，配好条件和动作即可，机制说明在 /docs/workflows-scheduler.html。

三、定时任务：让提醒自己长出来。 三条最见效果的：

• 委托到期前 15 天与前 7 天，分别提醒维护人与门店经理，把续签走访排进日程；
• 房源连续 30 天零带看，提醒维护人给出降价或调价建议——房源放到没人看，比降价更贵；
• 每周一给经理推一份上周带看与成交摘要，不用开会前临时统计。

四、审计日志：改了什么，谁改的。 房源改价、手改状态、删除带看单，这些动作都在审计日志里留痕。这不是为了查人，而是业主或客户质疑报价变动时，能拿出准确时间线。合同与委托这类关键日期的提醒思路，可以对照 /docs/seo-qa-contract-expiry-reminder.html；房源委托本质上也是一份有到期日的合同。

移动端怎么配合：经纪人的主机在手机上

经纪人一天大部分时间在外面，移动端不是"顺带看一下"，而是主要工作面。模块发布时移动端伴同页面会一并生成，不需要另做一套，使用方式见 /docs/mobile-guide.html。对这条业务链最实用的几件事：

• 出发前查冲突：在路上发起带看单，选好房源就能看到当天该房源已被约的时段，避免到门口才发现撞单；
• 现场采集：到现场拍房屋现状照，直接挂到这条带看单下；房屋有问题（漏水、空置损坏）当场留证，日后与业主沟通有凭据；
• 路上填反馈：带看结束在楼下就把客户意向等级与异议摘要填掉，趁记忆新鲜；填写字段建议控制在五个以内，多了就没人填；
• 业主确认结果：业主侧的确认不必单独做业主端，把确认结果、反馈摘要由经纪人录入并在通知里推给业主即可——通知走站内信与消息通道，业主能不能收，取决于门店自己的沟通方式，不夸大承诺。

上线前必须查的六件事

模块点发布之前，这几条没查清，上线一周就会被绕开：

1. 房源编号规则：能不能全店唯一、口头上念得出来？重复编号是脏数据之源，建议编号里带小区与门牌，不要纯流水号。
2. 状态字典是否锁定：在售、锁定、成交、暂缓、失效五档够不够用，谁来改？字典不许自由输入，否则统计口径必崩。
3. 撞单口径：按房源 + 时间窗，还是按客户 + 房源？两者都要的话，冲突时提示什么、允许不允许强行提交？规则写清再配校验。
4. 权限边界：谁能改委托价、谁能手改状态、谁能确认成交。默认给得太宽，审计就失去意义。
5. 提醒的接收人与提前量：委托到期提前 15 天还是 30 天、发给维护人还是经理，涉及门店节奏，不是技术选择。
6. 存量数据怎么进：老房源表整理成 Excel 导入，字段映射对不上就先改表；初始状态建议统一置为"在售"，历史带看记录能补多少补多少，从上线日起算新流水——Excel 导入的做法见 /docs/excel-to-module.html。

发布前还要过一次预检，把页面挂到菜单、确认移动端同步到位，流程在 /docs/module-test-publish.html。

之后可以往哪里延伸

这条链跑顺之后，延伸几乎是顺着业务自然长出来的：

• 成交往合同与收款走：租赁合同台账、租金收缴与押金退还，与 /solutions/property-lease-tenant.html 讲的是同一类账；售后长租业务可以直接接过去。
• 客户侧沉淀成客源池：客户档案、跟进记录与商机漏斗，与 /solutions/crm-customer.html 的通用客源管理同源，把带看记录作为跟进证据挂上去。
• 渠道与人员绩效：按渠道来源统计带看量与成交率，按经纪人的带看转化做绩效，数据已经在系统里，加一个统计页就能出。

这套模块不做什么

把边界说清楚，比把功能说满更有用：

• 不做房源自动估值和价格预测，这需要行情数据模型，不在 AI 构建器能交付的范围内；
• 不做房源自动分发到外部信息平台，那是外部平台的接口与规则问题，需要单独对接；
• 不做电子签约与资金存管，成交之后的合规环节仍由线下与专业系统承担；
• 不替代判断：系统能做的是把状态说清、把冲突拦住、把提醒送到，房子值多少钱、客户会不会买，仍然靠人。

一句话记法：房源状态是唯一真相，带看流水是证据链，撞单校验是护栏，提醒是记忆。 这四样立住，门店的房源与带看就管起来了。