物业报修系统怎么设计：派单、返工、材料与项目权限

先让一张报修单从受理走到验收

以“公共走廊漏水”为例，业主提交位置和照片，客服判断是否公共设施，安排维修；维修上传处理结果后，由指定人员确认解决。完工和验收是两个不同节点。

• 首版保留分类、位置、联系人、责任人和状态历史，巡检、设备保养可单独规划。
• 验收示例：维修报完工后业主仍反馈漏水，工单进入返工且保留第一次处理记录。

报价按项目数、角色端和离线条件拆分

只做客服录单与维修网页，和同时提供业主小程序、维修端、总部后台、巡检及收费，交付范围不同。地下设备间弱网、照片压缩与断点补传也应单独确认。

• 报价注明房屋导入、历史工单迁移、消息接口和物业既有系统对接是否包含。
• 拿一张涉及转派、返工与收费的工单，请开发方说明每一步由哪个端完成。

房屋档案和维修照片必须能交接

房屋、楼栋、联系人、历史工单与图片应能按项目关联导出。物业换班或更换服务团队时，需要保留维修依据，而非只拿到一张工单汇总表。

• 交接材料包含字段说明、照片访问方式、状态字典和项目管理员清单。
• 抽取一个楼栋导出工单，核对照片、材料和返工记录能否跟着工单编号找到。

按园区和房屋限制数据范围

业主只查看自己关联房屋的报修，维修人员查看分配给自己的任务，客服按项目处理，总部按授权汇总。转派工单不能顺便开放全部业主通讯录。

• 公共区域报修由客服确认位置，房屋绑定与解绑留有审核记录。
• 用两个项目、两名维修人员测试互相不可见，再验证主管跨项目汇总权限。

先区分保修内维修与需要收费的服务

有偿服务应在施工前确认项目、材料、数量和价格；新增材料需要补充确认。公共设施维修不应机械套用业主在线付费流程。

• 材料记录关联领用、使用和退回；支付状态与工单维修状态分别管理。
• 测试业主拒绝新增报价、部分材料未使用和支付成功后维修取消三种情况。

通知围绕接单、改约和验收触发

派单提醒发给责任人，改约结果发给报修人，完工后邀请验收。平台通知未送达时，后台任务仍应显示待处理，不能把发送成功当成已接单。

• 记录触发原因、接收对象、发送结果和必要的人工联系记录。
• 模拟消息失败，确认客服仍能看到逾期未接单任务并重新安排。

报修时长要区分等待和实际处理

受理、派单、到场、完工和验收时间分开记录，才能解释耗时来自等待备件、业主改约还是维修处理。返工不应算作一张全新的成功工单。

• 先约定统计按首次报修还是验收时间归属月份，以及挂起时段是否扣除。
• 用一张跨月、挂起后返工的工单核对报表，避免重复计数。

上线前在真实园区走一遍流程

选择一个楼栋或一类故障试运行，验证地址选择是否准确、维修人员是否能在现场上传照片、物业客服是否能交接未结工单。

• 准备房屋导入表、维修人员名单、故障分类和一组不含真实住户信息的测试数据。
• 用真机走报修、拒单改派、约时、验收和返工，检查每一步记录。

先稳定派单，再扩展巡检和设备管理

扩展巡检时要区分主动检查任务与住户报修，并明确巡检发现的问题是否生成维修单。设备保养计划不能覆盖已有维修历史。

• 照片存储量、工单积压和通知失败应纳入日常维护。
• 恢复备份后抽查历史照片和未结任务，验证状态、责任人没有错位。

导出、解绑和删除要留下理由

住户联系方式和房屋信息只供授权服务使用。批量导出、修改归属、删除照片等操作应限制角色并记录处理理由。

• 对外分享维修结果时，按需隐藏联系电话、门牌和人物照片。
• 模拟维修账号离职停用，确认其旧登录会话也不能继续查看住户任务。

需求讨论中的问题