简介：智慧社区/智慧管家物业SaaS系统平台PRD文档，面向产品经理、UI设计师及SaaS平台研发团队，提供一套覆盖业主端、物业端、平台运营端的完整产品方案，可解决智慧社区场景下人员管理、智能门禁、收费停车、报修工单等核心业务需求。压缩包共37个文件，包含核心原型文件（.rp）以及配套样式资源（less/scss/css源文件、FontAwesome字体图标库等），整体大小26.84MB，便于快速复用与二次设计。文档梳理了业主、家庭成员、租户、访客、物业人员、平台运营管理员六类角色的功能权限，涵盖手机开门、访客邀请、物业报修、智能巡检、视频监控、物业收费等典型流程，可直接作为产品评审、开发排期或项目启动时的需求底稿。已有2907人次学习，适合正在规划智慧物业或社区SaaS产品的团队参考借鉴。 这些年“智慧社区”“智慧管家”几乎成了物业行业数字化升级的标配提法，我陆续接触过的几家物业集团，都在从传统物业软件往SaaS平台迁移。但每次聊到需求，大家口中的“智慧”往往只停留在“业主能线上报修、管家能手机接单”这个层面。真正落笔写一份能指导研发、测试、运营三方协同的智慧社区/智慧管家物业SaaS系统平台PRD文档，才发现里面的坑比想象中多得多。
这篇文章就专门聊这份PRD该怎么写。我会把写物业SaaS平台PRD时最容易被忽略、也最影响交付质量的几个部分单独展开：业务边界怎么界定、状态机怎么落到字段、AI功能需求怎么描述才不算“空话”、多租户数据模型怎么设计才不会后期返工。无论你是产品经理、项目负责人，还是准备从0到1搭建这类系统的技术负责人，下面这些内容都可以直接用到你的评审会上。
1. 先看懂物业SaaS和传统物业软件的差别，再动手写文档
1.1 传统物业软件的“思维死角”
很多团队写PRD时容易犯一个错误，拿到需求就开始列功能模块，报修、收费、巡更、投诉、公告，一二三四写一大堆，看起来大而全，但实际上还是在做“传统物业软件的线上化”。传统物业软件是什么思路？本质上是财务和业务的记录工具，把原来纸质的台账、收据、派工单变成数据库里的记录。它的核心用户是物业公司的行政和财务人员，业主基本不接触系统，管家也用不顺手。
这种软件的问题在“数据孤岛”四个字上。缴费记录在收费系统里，报修记录在另一个工单系统里，业主投诉又跑到微信群和Excel表里，管家每天要打开三四个后台来回切换。所谓“智慧社区”，如果连基础的数据都打不通，后面的智能分析、主动服务根本无从谈起。
1.2 智慧社区产品的核心是“连接人”
智慧社区物业SaaS平台和传统物业软件最大的区别，在于它不再是一个封闭的“内部管理工具”，而是一个连接了业主、物业人员、集团管理层甚至三方供应商的服务平台。业主端小程序、管家端App、管理后台Web、设备端IoT，四端一体。这个定位上的变化，会直接影响PRD的每一处设计决策。
写PRD之前，我建议你的文档首页先放两张图：一张是“业务全景图”，展示平台涉及的角色和核心业务域；另一张是“核心用户场景图”，描述一个业主从入住到日常居住、再到报修缴费的完整旅程。这两张图画完，再动笔写功能模块。别一上来就抄竞品的功能清单，PRD的价值在于“为什么做”和“做出来长什么样”，而不只是“有哪些功能”。你先想清楚你的平台是给谁用、解决什么效率问题，后面所有模块的优先级和取舍都会有依据。
1.3 用户画像要具体到“某个岗位的一天”
我在PRD里不会写“业主是追求品质生活的城市居民”这种虚话，而是写“40岁左右、上班族，家里净水器滤芯需要更换，希望下班后维修工能上门，并且能通过小程序看到维修进度”。越具体，评审时开发越容易理解场景，UI设计越容易出界面，测试也越容易写用例。
2. PRD的骨架怎么搭：业务全景图先行，功能列表靠后
2.1 五张图代替“需求清单式”开头
我写物业SaaS PRD的习惯，是先画五张图，再写任何文字需求。这五张图分别是：
- 业务流程图：梳理“报修”“缴费”“巡更”等主链路从发起到结束的完整过程。
- 角色权限矩阵：明确每个角色在每条链路上的操作边界。
- 状态流转图：描述每个核心业务对象的生命周期，比如工单从创建到关闭经历哪些状态。
- 页面流转图：按用户端和Web端梳理主要页面之间的跳转关系。
- 数据关系草图：理清小区、楼栋、房屋、业主、工单、账单之间的关系。
五张图全画完，基本就筛掉了一半理解偏差。比如报修流程，业务方可能以为“业主提交后管家就能直接派单”，但实际场景里还涉及“多种预约上门时间”“维修材料费用审批”“超时自动升级”等分支，这些流程不画出来，开发只能靠猜，评审会上必然吵架。
2.2 账号权限模型是地基，不能等开发阶段再补
做SaaS平台最容易犯的错，是前期只顾着业务流程，把权限模型丢给技术团队“自己看着办”。等到客户入驻了十几家物业公司、几百个小区，才发现不同物业公司的数据互相串了，或者项目经理能看别人的财务报表，那时候再改权限体系就是牵一发动全身。
我的建议是PRD里单独拿出一章写权限设计，至少包含下面几层：
- 平台运营层：可以创建物业公司，配置计费与套餐。
- 集团管理层：管理旗下多个物业公司和项目，做跨项目数据分析。
- 项目运营层：项目经理、客服、管家、维修工，管理单个或多个小区。
- 业主层：只能访问自身房产相关的报修、账单、访客二维码。
- 供应商层：比如电梯维保公司、绿化外包商，只能看到授权范围内的工单。
数据隔离的原则也要写明：不同租户之间的数据默认完全隔离，同租户下不同项目的数据默认隔离，除非显式授权跨项目查看。这个原则写清楚了，开发做数据模型时就不会走偏。
2.3 权限模型落在字段上是“数据域+角色”
仅仅是“角色”还不够。我在实际项目里见过一个项目，客服角色能看到公司所有小区的业主手机号，这属于数据越权，不是功能问题。所以要引入“数据域”概念：每个角色绑定一个可查看的数据范围，比如“本小区”“本公司”“本集团+全部下级”。再加一套字段级的脱敏规则，例如业主手机号对维修工默认显示后四位，工单核销时才显示完整号码。这类细节写进PRD并占据一个完整章节，是SaaS产品和普通管理后台产品的关键差异。
3. 报修、收费、巡更三个高频模块：状态机和字段细节定生死
3.1 报事报修工单的状态机必须闭环
工单模块是物业SaaS里使用频率最高的功能，也是状态设计最容易出问题的地方。很多初版PRD会把工单状态简化为“待处理/处理中/已完成”三个，看似简洁，一上线就出麻烦：业主说“维修工还没来，你怎么就已完成？”客服说“我想把单子退回给工程主管，但没有撤回状态。”派单员说“维修工休假了，单子卡在已派单没人管。”
我建议工单状态至少包含以下流转：待受理、待派单、已派单、处理中、待验收、已完成、已取消、已关闭。其中几个容易被遗漏的设计点：
- 每个状态之间的转移必须写明触发条件和操作角色。比如“待派单→已派单”只能由客服或主管操作，“处理中→待验收”需要维修工上传完成照片才能触发。
- 超时升级机制要在PRD里说明。比如“已派单后30分钟维修工未接单，系统自动提醒客服重新派单；待受理超过15分钟，自动升级给项目主管”——SLA（服务等级协议）字段要在工单上体现，否则运营无法做绩效考核。
- “已完成”不等于“已关闭”。业主验收通过后工单进入已完成，如果48小时无异议自动转关闭；有异议则重新打开为待处理，并自动置顶给对应客服。这个“回旋门”机制是售后纠纷的缓冲垫。
字段层面，工单至少要有：报修来源、紧急程度、预约上门时间、维修类型（维修/换新/检测）、费用类型（免费/报价后收费）、媒体素材数组、超时次数、评价分数。列表页和详情页展示哪些字段，也建议在PRD里用原型图说明。
3.2 收费与催缴：财务字段一个都不能少，减免要有审批流
物业收费的核心对象是“账单”，账单和工单一样需要状态机：草稿、待发布、已发布、部分缴费、已缴清、已核销、已作废。这里最容易漏的是“部分缴费”和“跨期清欠”。业主可能先交了物业费没交车位费，也可能连着三个月一起补交，如果PRD里不把“部分缴费”逻辑写清楚，开发的账目表大概率要对不上。
租赁相关的小区还要注意“费用分摊”问题，比如公摊水电费是按房屋面积分摊还是按户数分摊，由谁确认、生成账单后如何通知业主。这些业务规则不写明白，财务岗上线后一定会手动改账单，一改就乱。
关于催缴，要特别说明一点：催缴功能必须内置在平台里，通过站内消息、短信、智能外呼提醒，不允许客服私自导出业主电话用私人手机轰炸。PRD里要写“催缴触达次数上限”和“时段限制”，比如催缴提醒每日不超过两次，晚上九点后不发起外呼。这个设计既是为业主体验，也是为物业公司的合规性考虑。
3.3 巡更巡检：IoT和人工流程要分开写
巡更巡检模块很多团队会做成纯打卡工具，其实不够。一个完整的巡更功能包含三部分：巡更计划配置、巡更执行与异常上报、设备状态数据回流。PRD里建议这样写：
- 巡更点：绑定到楼栋、设备房、消防通道等物理位置，支持扫码/NFC两种打卡方式。
- 巡更任务：按频次生成，比如“每日两次”“每周三次”，任务超时未执行自动生成异常工单。
- 异常上报：巡更员发现问题，可上传图片并关联设备，生成待处理工单。
- IoT扩展：如果未来接入烟感、水电表、门禁、梯控设备，需要在数据字段中预留设备ID和设备类型，同时明确“设备触发的事件”和“人工创建的工单”在同一个工单池里展示，但来源不同，用source字段区分。
4. AI功能写进PRD：不确定性需求怎么落地，才不会变成空话
4.1 智慧管家的AI应用场景哪里最值得做
物业SaaS平台的AI不是概念包装，是真实有落地价值的。结合我的经验，优先级排在最前面的通常是三类：智能客服（业主常见问题自动回复和智能分诊）、智能派单（根据工单类型、维修工位置、技能标签自动推荐接单人）、智能催缴助手（用温和的话术提醒业主缴费，并收集业主反馈原因）。排在后面的是AI摄像头识别（电动车进电梯、消防通道占用、垃圾满溢识别）。
在PRD里我会列一个表格，把AI场景和它服务的业务指标对应起来：智能客户服务的目标是减少客服重复咨询量，智能派单的目标是降低平均响应时长，智能催缴助手的核心目标不是催到钱，而是降低业主投诉率。指标不写，AI项目的价值就没法衡量。
4.2 AI功能PRD和传统功能PRD的写法差异
很多产品经理写AI功能时，就写“系统通过AI识别图片中的垃圾满溢，并自动生成工单”，一行字带过。这在评审会上会被研发挑战：“AI识别的置信度阈值是多少？”“误报了算谁的？”“识别结果人工要不要确认？”“图片数据集从哪里来？”这些问题，PRD必须提前回答。
我从自己的实践中总结了一个AI功能PRD的必写清单：
- 输入输出定义：比如“输入一张垃圾桶相机抓拍图，输出是否满溢、满溢程度的等级”。
- 体验指标：准确率预期（例如初期允许多少误报率）、覆盖率、响应延迟。
- 兜底策略：AI不可用、识别置信度低、离线情况下，自动转人工处理，不能静默失败。
- 数据回流：识别错误的结果需要有人工纠正入口，纠正后的数据反哺模型。这条是AI项目能越跑越准的命根子，但往往被PRD忽略。
- 冷启动方案：上线前没有数据，先用规则引擎（比如设定固定的满溢阈值）顶住，再用规则沉淀数据，逐步切换为模型判断。
举一个具体场景：业主在小程序端发了一条语音“我家水管漏水了”，AI客服需要完成“语音转文字 + 意图识别 + 抽取漏水地点 + 生成报修工单 + 推荐上门时段”的全流程。PRD里就要写清楚每一步失败时的兜底动作，比如语音识别失败，直接转人工客服接入，不能让业主对着机器重复说三遍。这条体验细节，比算法模型选型更影响用户满意度。
4.3 AI生成的回复内容必须有原始依据
物业行业有一个特殊性：业主对管家说的话，很多时候涉及责任认定，比如“墙体渗水是开发商的问题还是物业维护不到位”。如果AI自动生成给业主的回复内容，必须有原文或工单记录作为上下文依据，不能无中生有。
所以PRD里我建议给AI回复增加一个“引用来源”字段，AI生成的每一条对客文案，都要关联系统内的原始记录ID，人工客服可以一键跳转核实。这条写进PRD，运营团队后期会感激你——它直接决定了AI客服是帮物业加分还是给物业挖坑。
4.4 用qoder这类AI工具辅助写PRD，但别让它直接决定产品逻辑
现在不少人会用qoder这类AI工具辅助写PRD，我也在用。做法是这样的：先把业务上的口语化描述丢给它，比如“业主在门岗用手机扫个码就能放行，保安那边能看到访客信息和拜访房号”，qoder能帮你整理成结构化的需求描述和原型说明，效率提升很大。特别是那些你心里清楚、但懒得打字的业务片段，用工具转成初稿，比自己逐字敲快得多。
但有一点要提醒：AI工具能帮你把“已知需求”写得结构完整，却很难帮你发现“未知的盲区”。比如上面提到的状态闭环、超时升级、权限数据域，这些是业务经验沉淀出来的，工具不知道。所以我的用法是“人负责业务逻辑判断，工具负责把文字组织得清晰规范”，而不是反过来。
5. 主数据模型与多租户隔离：最贵的设计往往写在最后
5.1 从小区到房屋的树形结构，层级别定死
物业SaaS最核心的主数据是“房产树”，通常的结构是：区域（分公司）→ 项目（小区）→ 楼栋 → 单元 → 房屋。但实际业务里还会遇到“分期交付”的小区，项目下面还有一期、二期，或者“合院”“组团”这类物业形态。所以PRD里写数据模型时，我建议把“期/组团”作为可选层级预留出来，但这会导致查询SQL多一次join、权限配置更复杂，需要产品经理权衡。
同时房屋状态也要在PRD里约定：未交付、空置、自住、出租、装修中，这些状态影响收费规则和通知策略。比如装修中的房屋，管家巡更时要重点关注消防和噪音，这个状态如果不在数据模型里，运营规则就挂不上去。
5.2 业主和房屋的关系，一定要做版本化
一个房屋在生命周期里可能经历“开发商卖房→业主A自住→出租给租户B→卖给业主C”多个阶段。如果把业主和房屋画成一对一的关系，产权一变就覆盖历史数据，后面统计“这个小区过去三年居住率变化”就全部失真了。
所以PRD要写“房屋-住户关系表”，字段至少包括房屋ID、住户ID、住户类型（业主/家属/租户/同住人）、生效日期、失效日期、是否当前有效。业主可以做线上认证，认证后绑定到“业主”身份；租户则是经业主邀请后以“租户”身份绑定，权限范围略有不同。这个版本的“严谨”程度，直接决定后续物业费收缴率分析、疫情防控期间的居住人口排查能不能做准。
5.3 多租户隔离方案的取舍，产品经理也要懂
多租户的数据隔离有几条技术路线：独立数据库、共享数据库独立Schema、共享表加租户ID。从成本和运维复杂度排序，独立数据库最贵但隔离最好，共享Schema是SaaS的主流选择，共享表则要对查询性能和数据权限格外小心。
在PRD里不需要替开发做最终决断，但建议明确提出安全边界要求：跨租户数据访问必须是零容忍错误，任何SQL查询都强制带租户条件，建议开发采用独立Schema方案并配套自动化测试覆盖数据隔离场景。产品经理把这个要求写明，技术评审会就不会再因为“数据到底该放哪”吵一个下午。
6. 评审会前的自查清单：那些我踩过并写进教训的坑
6.1 状态机有没有“半路状态”和“终态兜底”
我评审自己的PRD时，会先把核心模块的状态转移图画完，然后用一个最刁钻的问题去问自己：“如果业主一直不验收，工单是不是永远停在待验收？” 答案如果是，就说明还缺少“超时自动关闭”的兜底逻辑。这种状态机的“半路状态”问题，是工单和账单模块最常见的坑。
6.2 金额和时间字段的精度有没有明确
物业收费会涉及分、角、元的精度，账单表里金额字段要用decimal而不是float；时间字段要统一用哪个时区存储；优惠、减免、滞纳金是否需要保留完整的操作日志。这些看起来是开发细节，但PRD里不写清楚，前期研发的“字段随便定”，后期对账时全都要还账。
6.3 异常场景写的不是“报错提示”，而是“有人接管”
异常场景的PRD描述，至少要写到“出现了什么情况、系统做什么提示、人工介入入口在哪里”。比如支付成功后回调失败，业主看到“支付中”，这时候系统要能自动查单并修复，查单也失败则给客服生成一条待核查记录，而不是让业主干等。
6.4 名词术语表是PRD里最不起眼但最值钱的部分
物业行业名词太多，同一个东西不同叫法也常见。比如“工单”和“维修单”“投诉单”有时候是并列关系，有时候又是包含关系。我习惯在PRD最后附一个术语表，把“物业费”“公摊电费”“维修基金”“业主”“住户”“租户”“临时访客”这些词的定义全部统一。评审会上很多争论，最后能归结为双方指的是同一个词但含义不同，术语表能省下一半吵架的时间。
整个项目做下来，我最深的体会是：智慧社区物业SaaS的PRD，本质上写的不只是系统功能，而是把物业公司的一套服务标准、一套责任边界、一套数据资产，用产品语言重新组织了一遍。文档里的每一个状态、每一个字段，都对应着现实中一个具体的服务承诺。你写“待验收”这个状态时，背后是业主对服务质量的一次确认；你写“48小时自动关闭”时，背后是对售后纠纷的一次规避。把这些想透，PRD就不再是流程文档，而是真正能落地的产品蓝图。
本文还有配套的精品资源，点击获取
