物业报修这件事，卡在哪
小区和园区的报修，业务本身不复杂：业主发现楼道灯不亮、水管渗水、门禁失灵，报给物业，物业派人去修，修完回访确认。但真实跑起来，问题几乎从第一个环节就开始积累。
报障入口散。 有的打物业前台电话，有的在业主群里说一句，有的直接找保安，还有的写纸条塞进物业办公室。同一个渗水问题，可能在三个地方留下过痕迹，最后没有一个地方是完整的。
派单靠人转。 前台接到电话，记在纸上或脑子里，再打电话找师傅。师傅在不在、手里还有没有活、会不会这个工种，全靠前台自己心里有一本账。前台一调休，那本账就断了。
进度没人盯。 业主第二次打电话来问"什么时候来修"，物业才发现单子还挂在纸上。谁的活、派下去多久了、卡在等料还是等人，没人说得清。
修完没留痕。 修没修好、换了什么件、是不是同一处反复坏，都只在师傅的记忆里。到季度做费用分摊、到年底做设备更新预算时，拿不出可用的记录，只能凭印象。
这些问题不是"人不够努力"，而是没有一条从报障到完工的通路。电话和微信群能传递消息，但传递不了状态：一条报修现在是什么状态、下一步该谁动，必须落在一个所有人共用的地方。
用 Inkwell AI 构建器做这件事，交付出来的不是一个大系统，而是几个能串成链的模块：报修单是主线，房源和业主是档案，师傅与工种是派工依据，完工与回访是闭环凭证。下面按"数据怎么建、页面怎么用、手机端怎么配合、上线前查什么"来说。
数据怎么建：五张台账撑起一条链
搭建时最容易犯的错，是一上来就做"报修单"一个表。报修单当然要有，但它周围的四张档案不建好，后面必然靠手填、靠记忆。
第一张：楼栋与房源档案。 记录楼栋、单元、房号、房屋类型、建筑面积、所属项目。这张档案有两个用处：一是报修时选房号而不是手打地址，地址口径统一了，事后按楼栋统计维修频次才有意义；二是把"公共区域"也作为一类位置登记进来，比如某栋的大堂、某层电梯厅、园区主干道，公共设施的报修同样要能定位。
第二张：业主与租户档案。 姓名、联系电话、绑定房号、身份（业主／租户）、是否常住。报修单关联到人，才能做回访、才能区分"这位业主本月第三次报同一处漏水"。租户与业主分开标记，是因为涉及入户维修的责任和费用口径常常不同。
第三张：维修师傅与工种。 姓名、所属班组、可做工种（水电、土建、弱电、电梯、保洁协同）、在岗状态、当日可接单量。工种的选项建议放进数据字典统一管理，别让每个人在文本框里自由填写——"水暖"和"水电"和"水管"，一旦自由填写，后面就按工种筛不出人。
第四张：报修单（主线）。 这是整个方案的骨架。核心字段包括：单号、报修来源（业主自助／前台代报／巡检发现）、报修人、联系电话、位置（关联房源或公共区域）、问题类型、问题描述、紧急程度、期望上门时间、受理人、受理时间、指派师傅、派单时间、上门时间、完工时间、处理结果、更换物料、费用归属（物业承担／业主承担／公共维修）、验收状态、回访结果。
第五张：物料与领用。 物料名称、规格、单位、库存数量、领用单关联的报修单与领用人。师傅换了三个水龙头、两米管，如果只在报修单里写一句"已更换"，物料消耗和成本就永远对不上。做成领用记录关联报修单，月末自然能算出每个项目、每类工种的物料消耗。
还有一个容易被忽略的字段：故障标签。同一处位置、同一个问题类型反复出现的，标签会把它暴露出来——比如某栋三层卫生间一个季度报了七次渗水，这条线索比任何单张工单都值钱，它指向的是该做改造而不是继续修。
以上这些表都是普通的业务台账，用 AI 构建器描述清楚字段和关联关系就能生成。用一句话说清你要什么，比如"建一个报修单模块，包含报修人、房号、问题类型、紧急程度、指派师傅、上门时间、完工时间、处理结果"，构建器会先出一版可用的表单和列表，你再按现场口径调整字段。字段口径的维护方式可以看 数据字典这篇，工种、问题类型、紧急程度这类选项都应该走字典而不是自由文本。## 页面怎么用：受理、派单、盯进度
数据建好之后，物业人员日常只用几个页面。这里的关键不是功能多，而是让"这条单现在该谁动"一眼可见。
受理台：一张待指派列表。 按"状态=待指派"筛出来的列表，按紧急程度和报修时间排序。前台每天上班第一件事就是看这张列表，而不是等电话。列表上要能直接看到位置、问题描述、报修人电话、报修时间，这样大部分单子不用点开详情就能判断派给谁。
派单动作：把"找谁修"变成可见的条件。 打开待指派单子，按工种筛选在岗师傅，看到对方当前在手单数，选定后填写预计上门时间。派单这一步最好用工作流来做，而不是手工改状态字段——工作流的好处是每次状态变更都留痕，还能在派单后自动触发通知，把消息推到师傅手机上。工作流的节点配置方法见 工作流可视化编辑器，审批与状态流转的常见做法可参考 审批流落地。
超时盯办：让"没人管"自己浮出来。 报修最容易出问题的不是难修的单，而是被忘掉的单。做法是给每种紧急程度定一个响应时限（比如紧急单两小时内必须上门），然后用定时任务每天扫描一遍：超过时限仍未上门的单子，状态自动标记为"超时"，同时给受理人和物业主管发通知。定时任务的配置方式见 工作流与定时任务。这条规则一旦跑起来，"这单怎么还没人去"就不再靠业主打电话来提醒。
完工与验收：留痕的地方。 师傅填写完工信息时，要点是三样东西必须录进系统：处理说明（做了什么）、更换物料（关联领用记录）、现场照片（完工后的状态）。验收环节可以做成两步：物业内部验收（班组长确认工艺合格）与业主确认（回访结果记录），两步都过了才算闭环。对于需要业主承担费用的项目，验收通过后再走一张收费或记账单据，避免修完没人收钱、月底扯不清。
台账与统计：给管理者的视角。 有了完整的报修单记录，可以做出几类对管理真正有用的视图：按楼栋或项目统计报修量与平均处理时长；按问题类型统计占比，判断是哪个系统老化；按师傅统计在手量与完工量，用于排班参考；按物料统计消耗，用于采购计划。这些统计不用另做一套报表系统，在同一个业务台账上用筛选条件与汇总字段就能看到。
角色与权限要先想清楚。 业主看到什么、前台看到什么、师傅看到什么、主管看到什么，是四种完全不同的视野。业主只应看到自己的报修单和进度；师傅只应看到派给自己的单；前台看全部但不需要改物料价格口径；主管额外能看到超时与统计。这类按角色的数据视野，在平台里用角色与权限配置来做，配置思路见 角色与权限配置。这一步在上线前不做，后面就会出现师傅看到业主张三全部报修历史这样的尴尬。
移动端怎么配合：真正贴在现场的那一端
物业报修是典型的"人在现场、电脑在前台"的场景。真正决定这套东西能不能用起来的，是手机上那一段。
业主端：报障入口收窄成一个链接或二维码。 把报修表单做成移动端页面，在楼栋大堂、电梯厅、物业前台贴二维码，业主扫码就能填：选楼栋房号、选问题类型、写描述、拍一张照片、留电话。第一次填写后，房号与电话可以作为默认值带出，避免每次重填。这一步做完，原本散在电话、微信群、纸条里的报障，全部收到同一个入口。
师傅端：只做三件事的极简页面。 师傅在手机上要能干的就三件：看派给我的单、填上门与完工、拍照上传。页面越简单越好——一屏能看完的单子，才会有人真的去看。完工时现场拍照直接上传，不用回办公室补录，这是整套方案里回报最直接的一环。
两端怎么同步。 Inkwell AI 构建器里，PC 上做好的业务模块会同步出对应的移动端页面，不用为手机另做一套。手机端的页面组织、工作台入口与同步机制见 移动端使用指南，模块挂载到菜单与移动端的操作见 模块的测试与发布。上线前记得在真机上把流程走一遍：扫码能不能打开、拍照能不能上传、弱网下提交会不会丢，这三项在现场都是真问题。## 上线前查什么：七条核对清单
模块做出来和模块能用起来，中间隔着一轮核对。以下是物业报修这套东西上线前值得逐条过的几件事。
一、字典先定死。 问题类型、紧急程度、工单状态、费用归属这几组选项，必须走数据字典统一管理。凡是让填表人自由输入的选项字段，一周之内就会长出十几种写法。
二、每条状态都要有"谁动"。 待指派、已派单、已上门、待验收、已完工、已回访——每一个状态都要对应到一个明确的责任角色和一个明确的触发动作。核对方法很简单：把状态列表拿出来，逐个问"这个状态下单子停住了，应该谁先看到"。答不上来的状态就是流程里的暗坑。
三、超时规则要落到定时任务上。 光在制度里写"两小时响应"没有用，要配成可执行的扫描规则，并在扫描后真的发出通知。这里最容易漏的一步是通知的接收人：发给了受理人但没发给主管，超时单依然会躺平。
四、权限逐个角色对一遍。 用业主、师傅、前台、主管四个身份分别登录，各走一遍完整流程。重点看三件事：业主能不能看到别人的单、师傅能不能改派单信息、前台能不能看到不该看的费用口径。
五、必填项和照片要设成硬要求。 完工说明和现场照片设成提交前必填。软提示的结果是十单里三单没照片，而恰恰出问题的那三单就在其中。
六、历史数据想好怎么进来。 如果现场已经在用 Excel 登记报修，可以把存量表格导入成初始数据，导入的用法见 用 Excel 一步建模块。导入前先把列名和字典选项对齐，否则会导进一堆对不上的历史分类。
七、先在真机上走一遍，再发通知给业主。 发布前用平台的发布预检跑一遍，确认没有阻塞问题；然后在真机上用业主和师傅两个身份各提交一单，走完全程。业主动员是不可逆的——二维码贴出去之后如果表单打不开，第二次再推就要多花十倍力气。
之后怎么延伸：一条链能接上更多场景
报修这条链跑顺之后，往外延伸的成本很低，因为底层的档案（房源、人员、物料、状态流转）已经在了。
延伸一：公共设施巡检。 巡检发现的问题直接生成报修单，把"发现"和"处理"接上。设备点检巡检的做法可以直接参考 设备点检巡检，园区的设备台账与点检思路和工厂是相通的。
延伸二：维保计划与到期提醒。 电梯、水泵、消防设施都有法定或厂家要求的维保周期。把这部分做成计划表加到期提醒，和报修单共用同一套设备档案，就形成了"计划保养 + 临时报修"的完整维修记录。整体结构可参考 设备维保与维修工单。
延伸三：费用分摊与结算。 有了物料领用与工时记录，可以做按项目、按楼栋的维修成本归集；涉及向业主收费的部分，延伸成应收账款的记录，对账逻辑可参考 应收应付。
延伸四：满意度与投诉联动。 回访结果不只存一个"满意／不满意"，遇到明确投诉的，直接流转成投诉处理单，形成整改闭环。这套受理到整改的结构在 客户投诉与质量异常 里有完整说明。
延伸五：租户与企业服务。 如果园区里有入驻企业，报修之外还会出现入驻办理、装修报备、访客通行等需求，这些都可以在同一套组织与权限体系上继续加模块。
从哪一步开始
不必一次做完。最小可用版本是三张表加两个页面：报修单、房源档案、人员档案，以及一张受理台列表和一个完工填报表单，先在移动端跑起来。
先让业主扫码能报、师傅手机能收、前台能看到进度——这三件事成立，剩下的统计、费用、维保计划都可以在用的过程中逐步补。如果现场还有面向外部客户的设备维保业务，可以把两条线合并在同一套工单模型里，外部报修的处理方式可参考 售后工单。
要更快一点，可以直接把需求讲给 AI 构建器：说明你管几个项目、有多少个师傅、现在报修靠什么记录，它会先给你一版可点的模块，你在上面改比空想快得多。构建器的整体用法见 AI 构建器操作手册。