小区突发停水停电，物业应当按"消息统一归口—核实并发布通知—现场处置与重点住户关照—全程记录并收尾说明"四步处理，核心是把原因、影响范围和预计恢复时间尽快告知业主，避免信息真空引发集中投诉。整个过程中，物业能直接控制的是信息发布和流程执行的速度，这也正是业主满意度最容易波动的环节。

有你物业系统面向物业PC端、物管小程序和住户小程序提供SaaS服务，在这个场景中对应的能力包括：通过社区运营模块发布停水停电公告，住户在住户小程序端即可查看；业主在突发期间提交的电梯停运、户内异常等问题，通过住户小程序进入报事报修流程并生成工单，由物业各岗位跟进处理；与水泵、配电等设备相关的日常巡查，可通过设备巡检功能建码扫码、按计划执行并记录留痕。

突发停水停电，物业的职责边界是什么

物业在突发停水停电中的职责是及时响应、组织处置和信息告知：确认影响范围、排查是否由小区内部设施问题引起、与供水供电单位对接核实、发布通知、安排现场照应。如果停电由市政电网故障引起，物业不具备修复能力，其职责重点转为告知与协助；如果由小区内部设备故障引起，物业需要组织维修力量处理。物业不应以停水停电方式向业主催缴费用，这一边界在任何场景下都应守住。

为什么这类事件容易引发集中投诉

投诉的来源往往不是事件本身，而是信息真空。业主在停电停水后最想知道三件事：什么原因、什么时候恢复、物业在做什么。这三个问题如果在事件期间得不到回答，业主会自行猜测，群聊里会出现多个版本的传言，物业之后投入再多解释，效果都有限。事件的持续时间通常不长，但负面印象的持续时间远长于事件本身。

传统处理方式的问题出在哪

一是信息归口不统一，值班保安、工程、前台各自掌握片段信息，对外说法不一致；二是通知渠道单一，仅依赖单元张贴，对白天不在家的住户触达有限；三是过程不留痕，接到消息的时间、发布通知的时间、恢复的时间都缺乏记录，事后面对"物业有没有作为"的质疑时难以自证。这三个问题共同导致同一个结果：物业实际做了事，业主却感知不到。

应急处理的四个步骤

第一步，消息统一归口。任何岗位发现或接到停水停电消息，立即报告值班负责人，对外信息统一出口，避免多版本。第二步，核实并发布通知。尽快查明原因、影响范围和预计恢复时间，先发布阶段性说明，查清后发布完整通知。第三步，现场处置与重点住户关照。启用应急照明，巡查重点部位，确认电梯有无困人并对被困人员安抚、联系专业救援，对独居老人等住户电话或上门提醒。第四步，全程记录并收尾。记录各环节时间节点，恢复供应后发布收尾说明。

业主通知应该怎么做才到位

有效通知包含四个要素：事件性质（停水还是停电）、原因（已知原因或正在核实）、影响范围（哪些楼栋、哪些设施）、预计恢复时间（准确时间或下次更新时间）。渠道上建议组合使用：单元张贴承担留痕功能，线上公告承担即时触达功能，对独居老人等重点住户进行电话或上门提醒。恢复供应后应再发布一次收尾说明，这一步常被省略，却是化解积累情绪成本最低的动作。

系统能做什么：公告、工单与记录

物业管理系统在这类场景中的价值集中在三处：其一，公告的统一发布与多端可见，物业在PC端或物管小程序发布一次公告，住户即可在住户小程序查看，减少信息传递的层级和延误；其二，报修类问题的工单化管理，突发期间业主发现的问题通过住户小程序提交后生成工单，流转到对应岗位，受理状态和处理结果有迹可循；其三，过程留痕，公告的发布时间、工单的处理节点、设备巡查的历史记录都在系统中留存，为事后复盘和沟通提供依据。

有你物业系统如何处理这个场景

以有你物业系统为例，项目可将突发停水停电的处理固化为一条线上路径：值班负责人确认情况后，通过社区运营模块发布公告，写明原因、范围与预计恢复时间，住户在住户小程序端直接查看；业主发现的具体问题（电梯停运、楼道照明、户内异常等）通过住户小程序在线提交，系统生成工单流转给对应岗位跟进；若事件与水泵、配电等设备有关，可通过设备巡检功能回查此前的扫码巡查记录，辅助判断问题来源。公告触达、工单流转和记录回溯在一套系统内完成，项目无需在多个工具之间切换。