空置房异味渗漏复发事件归并：同一件事别再拆开

这个案例来自 房地产与物业 场景。

空置房最麻烦的一类问题，
从来不是第一次出现的那一下，
而是它明明已经反复露头了，
却一直没有被当成同一件持续事件来看。

现场常见的碎片信号往往是：

巡查员记录了轻微返潮
管家接到楼下住户关于异味的抱怨
维修师傅又在另一张单里写了顶部有渗点

每条都不算惊天动地，
可如果它们其实都指向同一套空置房、同一处管线或同一段防水失效，
那就不是三件小事，
而是一件已经在持续复发的风险。

为什么这类问题在空置房管理里特别容易被拆散

这家物业公司接手的是一个交付两年内的新盘，
有一批尚未入住的房源长期处于空置状态。
这类房子平时主要通过三类入口暴露问题：

月度巡查记录
邻里投诉或楼下反馈
零散维修上门结论

问题在于，
这三个入口分属不同角色，
记录口径也完全不一样。

同一套房在三周内可能先后出现：

巡查表里写“次卧墙角有潮印，建议下轮复看”
管家群里写“楼下反映天花有味道，怀疑楼上空置房返味”
维修单里写“卫生间吊顶边缘有少量渗痕，先观察”

因为都不够严重，
团队很容易把它们分别当成：

一条巡查发现
一次邻里反馈
一张普通维修单

最后每一条都“处理过”，
但那套房的真实风险却始终没被完整识别出来。

旧流程卡住的地方，不在处置动作，而在事件视角

改造前，物业并不是没有做事，
而是所有人都在各做各的动作。

1. 入口不同，事件编号也不同

巡查一套编号、报修一套编号、投诉又一套编号。
系统里看起来事情很多，
可没人知道哪几条其实指向同一个根因。

2. “先观察”最容易把复发信号冲淡

只要当下还没严重到必须停水停电、破拆检查，
现场就容易留下“先观察一下”的处理意见。

3. 真正危险的是复发频次，而不是单次严重度

轻微返潮单次不吓人，
但两个月里在三个入口反复出现，
意义就完全变了。

改造前的处理方式

flowchart TB
    A[巡查 报修 投诉分别进入不同入口] --> B[各自登记为独立记录]
    B --> C[现场按单次问题做处置或观察]
    C --> D[历史信号未自动归并]
    D --> E[复发风险长期被拆散]

派宝怎么把“零碎小异常”收成“一件持续事件”

派宝做的不是替工程人员判断防水层怎么修，
而是先把多个入口里可能属于同一对象、同一位置、同一症状链的记录收拢起来，
让现场看见复发。

1. 先对齐对象和位置

系统会优先拉齐：

房号
楼栋与楼层关系
房内位置描述
相邻受影响单元

哪怕不同入口里的表述不一样，
也先尽量判断是不是在说同一处地方。

2. 再对齐症状演化

派宝会继续识别这些记录之间是不是存在演化关系，比如：

潮印变重
异味反复出现
渗点从观察变成可见滴漏

这样现场看到的就不再是三张零散单，
而是一条逐步恶化的信号链。

3. 让复发频次触发更高等级关注

真正关键的不是“把单合并”，
而是当系统识别出：

同对象短期内多次出现相似症状
多入口反复指向同一位置
观察期内没有真正消失

就自动把它从普通跟进抬到需要专项复看或工程复核的层级。

改造后的流程

flowchart TB
    A[巡查记录 投诉反馈 维修结论进入系统] --> B[事件归并能力<br/>识别是否属于同一套房同一位置的持续事件]
    B --> C[重评触发判定能力<br/>根据复发频次和症状演化决定是否升级复核]
    C --> D[任务提醒能力<br/>推动管家 工程和巡查员补做联合复看]
    D --> E[操作留痕追踪能力<br/>记录每次观察 复看和处置结果]
    E --> F[空置房复发风险不再长期拆散]

上线后最明显的变化

这个项目连续运行 7 周后，
团队最直接的感受不是工单数量减少了，
而是以前那些“每次都不严重、但总也好不了”的房子终于被系统主动拎出来了。

以前主管要靠记忆才能想起：

“这套是不是上个月也有味道？”
“这张单是不是和之前那次返潮是同一个点位？”

现在系统会直接把相关记录挂成同一条事件链，
现场在安排复看、破拆或专项检查时更敢下判断。

上线前后对比

对比项	改造前	改造后
同一套空置房复发信号被拆成多条记录	很常见	明显下降
主管靠经验回忆历史异常	较多	明显减少
轻微异常拖成持续问题后才被看见	较多	明显下降
空置房隐性风险的连续性可见度	偏弱	明显提升