社区服务不是一套独立的物业 App，是平台的租户侧入口
三个模块分工明确：产业招商把客户引进来，租赁运营把合同与账跑起来，社区服务承接住户搬进来之后的每一次日常接触。每一次接触都会留下记录——工单、账单、通行、评价——这些记录既要当场把事情办完，也要成为下一轮运营与租赁决策的输入。
同源同库，住户不用记五个入口
社区服务与产业招商、租赁运营共用一套资产与空间主数据、一套客户与合同档案、一套账单与工单、一套表计与设备台账。报修能带出房号与租约，缴费同时回写租赁账与物业账，访客放行能追到具体单元与责任人——没有「对接」，因为它们本来就是一份数据。
一颗模块，也能单独上
只想要社区服务？可以。独立实例、独立域名、独立数据库部署，不依赖招商或租赁模块先上线。关键在于 TPT 与 WOS 域的数据模型、字段口径、主键规则从一开始就是平台标准——将来并回平台是打开一个开关，不是做一次数据迁移。
智能体是操作者，不是聊天窗口
服务台助手受理并建单，报修与派单助手定级并跟踪，会员运营助手做分群与权益推荐，社群与通行助手策划活动、召集住户、安排访客。它们通过 MCP 直接读写平台的工单、账单与会员账本，动作在平台内留痕，受与人类相同的权限体系约束。
五条主线共用一套住户档案、一套工单编号与一套账单口径；TPT WOS CSM CMS ACS 五个域由同一个模块交付，不拆成五个产品。
四类数字员工共用同一份住户与空间档案、同一套工具契约与同一套审计日志；编排层负责它们之间的接力，模型层可替换，工具与记忆留在平台侧。
住户手机号、人脸模板、访客记录、消费记录属于分级可见信息：谁能看到什么，由统一底座的权限模型决定，不由某个业务模块自己决定。
社区服务做成独立系统，一定会在四个地方断掉
不是独立系统不好用，而是它只有自己那一半数据。四个断点都不在功能上，都在「这件事该归谁、这笔钱该记哪本账、这个人到底是谁」这三个问题上——而这些答案本来就不在社区系统里。
工单只记房号与一句描述。要判断这笔费用算租赁侧还是物业侧，得打电话问运营；要判断设备是否还在保修期，得翻另一套设备台账。
建单那一刻就带出房号、租约起止、装修责任分界、设备维保状态与历史同类工单，责任方与费用流向当场确定，前台不需要回忆。
租金在租赁系统里，物业费与停车费在物业系统里。住户面对两张口径不同的账，物业月底还要人工核对哪一笔已经收到。
账单按统一口径出具、统一收银台支付；付款成功同时回写租赁应收与物业应收，核销一次完成，不需要月底并表。
做活动要另外导一份名单，核销权益时对不上人；同一个住户在两个系统里有两种身份，谁也不知道哪一个才是准的。
住户档案、会员身份、权益账本与房屋绑定关系在一处维护；谁能看到手机号、谁能看到消费记录，按角色分级授权。
访客记录只留在门禁主机里，与租户、单元、租约无关。出了纠纷要调录像、翻登记本，事后很难还原当时是谁放的行。
访客预约由住户发起、物业审批，放行记录回到平台并按单元与租约关联；临时权限与异常通行都带完整授权链。硬件照旧，数据归平台。
社区服务最容易犯的错，是把它当成一组小程序来采购：报修一个、缴费一个、门禁一个。住户要记五个入口，物业要维护五份名单，运营永远拿不到闭环数据。
ErinOne™️ · 平台模块设计说明平台给社区服务的三样东西：一份档案、一张工单、一条回路
把社区服务做轻，前提是它不用自己造这三样东西。它们由 ErinOne™️ 平台提供，三个模块共用；社区服务要做的是把住户侧的动作，准确落到这三样东西上。
人、房、约、卡，指向同一个 ID
住户、房屋、租约、车位、门禁卡与会员身份不是六张表，而是同一个主体档案的六个面。住户换房、换租约、换手机号，服务记录不需要重建；一个人住两套房，权益也能按房或按人合并。
服务请求与费用结算，共用一套编号与状态机
报修、投诉、咨询、保洁、搬家、访客异常都走同一套工单模型：受理、定级、派单、到场、完工、核销、评价、归档。费用在核销环节分流到租赁账或物业账，而不是另起一张单。
服务动作回写档案，成为下一次运营的依据
工单时效、返工率、满意度、活动参与、通行异常、权益核销，全部落回同一份档案与同一套指标。它们既是社区运营的看板，也是租赁侧判断续约风险、调整服务包的输入。
三种部署形态：可以一起上，也可以先单独上
社区服务的上线门槛主要不在软件，而在住户档案是否齐、工单流程是否定得下来。所以三种形态的差别，本质上是「先解决谁的问题」。
一体化部署
三个模块同期规划、同一实例同一数据库。住户的一次报修能带出租赁侧的合同与责任口径，社区侧的活动、工单与通行数据直接进入集团运营看板。
- 同一住户档案、同一工单与账单编号
- 服务成本可归集到单元、业态与租约
- 租赁侧与社区侧共用一套权限与审计
- 新增模块不需要再做一次主数据梳理
独立部署
社区服务独立实例、独立域名、独立库，不依赖招商或租赁模块先上线。先解决报修、工单、通行与住户服务的效率问题，其余模块将来再并。
- 住户档案与工单流程先跑通
- 只需梳理「人 / 房 / 单」三类口径
- 预留事件接口，接入平台后自动生效
- 并回平台：打开开关，不做数据迁移
嵌入既有系统
已有物业系统或会员系统不愿迁移，ErinOne™️ 以能力层嵌入，或用双向同步并存；门户、智能体与通行策略可以单独接入，不改动既有系统的运行方式。
- 以对方系统字段为输入做映射
- 工单可在两边并存，按主系统回写
- 门禁与车场硬件照常运行
- 接管子模块：逐模块切换，历史保留
| 维度 | A 一体化部署 | B 独立部署 | C 嵌入既有系统 |
|---|---|---|---|
| 典型场景 | 新建园区 / 集团统一平台，三个模块同期规划 | 只想先解决报修、工单与通行效率，其他模块暂缓 | 已有厂商物业系统或会员系统，不愿迁移 |
| 部署与数据 | 同一实例、同一数据库、同一智能体中台 | 社区服务独立实例、独立域名、独立库 | ErinOne™️ 以能力层嵌入，或双向同步并存 |
| 模块间联动 | 实时：报修即带出合同与责任口径，服务成本可归集到租约 | 预留事件接口，接入平台后自动生效 | 按接入路径决定：同步为分钟级，能力调用为实时 |
| 硬件与通行对接 | 门禁、梯控、车场由平台统一下发权限与策略 | 先用厂商原生系统过渡，接入后由平台统一下发 | 硬件归既有系统管，平台只取通行事件与下发策略 |
| 会员与账单口径 | 会员权益与账单同一口径，缴费回写租赁与物业两侧 | 先立社区侧口径，账单可只覆盖物业与服务费 | 以既有系统口径为准，平台做映射与并账 |
| 准入工作量 | 需一次性梳理三个模块的主数据与账务口径 | 只需梳理人、房、单三类口径 | 以对方系统字段为输入做映射，改动最小 |
| 将来迁移成本 | — | 并回平台：打开开关，不做数据迁移 | 接管子模块：逐模块切换，历史数据保留 |
不同厂家的物业、门禁、缴费与会员系统，都能接得上
社区服务的接入对象大多不是软件而是硬件与外部通道：门禁、梯控、车场、支付、短信。这类对接的关键不是能不能连上，而是连上之后数据归谁、写谁、谁负责最终口径。ErinOne™️ 的做法是全部走统一接口层，规则写在一处。
| 路径 | 接入对象 | 接入方式 | 数据流向 | 适用与注意 |
|---|---|---|---|---|
| PATH-1 工单住户 |
物管 / 客服工单系统 | REST API 双向同步，按主键做幂等 | 住户档案与工单一进一出；以平台为主系统，对方为协同系统 | 适合已有客服系统且不愿更换的现场；需先约定「同一工单以谁的状态为准」，避免两边各自关闭 |
| PATH-2 通行硬件 |
门禁 / 梯控 / 车场厂商 | 厂商 API 或 SDK，配合事件订阅 | 通行事件单向进入平台，权限指令单向下发 | 硬件不动、只换大脑；临时权限必须带授权人与有效期，到期自动失效 |
| PATH-3 缴费账单 |
聚合支付 / 银行 | 支付回调 + 流水对账，必要时银企直连 | 支付结果回流平台，账单状态由平台回写 | 平台只做「记账与核销」，不碰资金池；对账差异单独挂账，不自动冲销 |
| PATH-4 会员流程 |
会员系统 / CRM / OA | REST API，授权走 OAuth2 | 会员与权益双向；审批结果单向回调 | 权益核销以平台账本为准；外部系统只读展示，不做二次发放 |
不是「加了 AI 功能」，是智能体就是模块的操作者
在社区服务里，智能体不是挂在角落的聊天窗，而是工单的第一受理人、派单的调度员、权益的推荐者、活动的召集人。它们通过 MCP 直接读写平台的工单、账单、住户档案与会员账本，动作在平台内留痕，受与人类相同的权限体系约束——人负责判断例外，智能体负责处理常规。
政策与账单问答，答案带出处
住户问「停车费怎么算」「为什么这个月多了一笔」，助手按项目政策、费用标准与公告作答，每条回答附带数据来源与取数时间；金额类问题强制指向具体账单或流水记录，不做估算。
住户自己就能办完，不必找人
报修、缴费、访客预约、发票申请、信息变更都在同一个入口完成；表单按住户身份自动预填房号与联系人，提交后立刻给出工单号与预计处理时长，进度可随时追问。
工单的第一受理人，不是转接员
识别位置、品类与紧急度，自动定级并派给合适的班组或个人（自有或外包）；接单超时自动升级，完工后按模板核验照片与材料，再请住户确认。派单规则与 SLA 由物业设定，助手只执行不解释。
不等住户开口，先把该提醒的提醒到
租约到期前提醒续租并推送权益，设备维保到期前生成计划，欠费在到期前分级提示，活动按兴趣分群召集，通行异常与深夜独行按策略提示物业。主动动作同样受权限与频次约束，可按项目一键关停。
服务数据回流到租赁与资产决策
服务成本按单元、业态与租约归集，支撑服务包定价与租赁定价；满意度与投诉趋势进入续约风险评分；通行与访客数据支撑安全策略与人流规划。指标口径与租赁运营模块共用同一套定义，不另立一套。
住户隐私与数据最小化
手机号、人脸模板、访客记录、消费记录均为分级可见信息：助手只取办理当前业务所必需的字段，人脸模板不以明文存储与传输，访客记录到期自动降权。
对外公告与通知的人工签发
停水停电、收费调整、活动公告、紧急通知这类对外文本，由智能体起草、人工确认后发布；发送范围、时间与对象可预览，发送后留档可追溯。
门禁放行与临时权限的双因子兜底
访客放行需住户发起加物业审批，临时权限带授权人与有效期、到期自动失效；异常通行（尾随、深夜、多次失败）实时告警并熔断该凭证，恢复需人工复核。
模块内部：五条主线，横跨五个业务域
五条主线不是五个产品，而是一个模块的五组能力，共用同一份住户档案与同一套工单编号；编号即边界，谈需求、报价与验收时说的是编号区间，不是模糊的概念；智能体参与度逐条标注，哪些环节由数字员工主理、哪些必须人工确认，一目了然。
| 主线 | 业务域与编号区间 | 覆盖场景 | 关键功能 | 智能体参与 |
|---|---|---|---|---|
| ① 租户一站式服务平台 | TPT 租户门户域 TPT-101～705 |
住户侧的统一入口：从入住到退租的全部自助动作 | 门户与移动端入口、住户档案与预填表单、在线报修与缴费入口、工单与账单一处可见、通知与公告、多语言与无障碍 | 服务台助手 （L1–L2） |
| ② 线上报修与工单跟踪 | WOS 工单与服务请求域 WOS-201～306 |
一句话报修到归档：受理、派单、到场、完工、评价 | 受理建单与房号带出、自动定级与派单、到场扫码签到、完工举证与材料核销、接单与完工超时升级、满意度评价与回访 | 报修与派单助手 （L3） |
| ③ 会员体系与增值服务 | CSM 会员与增值域 CSM-301～408 |
住户权益与增值经营：等级、积分、权益与商户服务 | 等级与积分规则、权益账本与核销、增值服务目录与定价、商户接入与结算、续租窗口期的权益联动 | 会员运营助手 （L3–L4） |
| ④ 社区活动与社群运营 | CMS 社区运营域 CMS-401～506 |
活动与社群：策划、召集、执行、复盘 | 活动策划与排期、报名与签到、内容发布与推送、兴趣分群与触达、舆情提示、活动结案与满意度回流 | 社群与通行助手 （L4） |
| ⑤ 智慧通行与访客管理 | ACS 通行与访客域 ACS-501～606 |
人车出入与访客：预约、审批、放行、追溯 | 访客预约与物业审批、二维码与人脸放行、门禁与梯控权限下发、车场与车位管理、通行记录追溯与异常告警 | 社群与通行助手 （L4） |
| 平台接口 | 统一底座 TPT-P |
与外部系统及平台其他域对接 | 住户与房源主数据、权限与分级可见、全量审计、集成与接口层、消息与通知通道；复用平台的合同、账务与设备台账 | 多智能体编排 （跨模块） |
五条主线，共用一个入口
住户打开的是同一个门户：报修、缴费、访客邀请、活动报名、权益查询都在这里。界面上看不出「这是五个域」，因为住户要办的是事，不是域。
谈需求时说的是编号，不是概念
「门户要加一个电子发票入口」对应 TPT 域的具体编号；「访客放行要能撤回」对应 ACS 域的具体编号。报价、排期与验收都对着编号走，避免各说各话。
先上什么，按现场痛点定
可以先只上 ② 与 ⑤（报修与通行），也可以先上 ① 与 ③（门户与会员）。五条主线之间没有强依赖，只要求住户档案先立起来——那是所有主线的共同起点。
四类 AI 数字员工，上岗前先加载 Skills 包
数字员工不是通用聊天机器人，每一个都绑定明确的业务范围、工具清单与动作权限，加载对应项目的 Skills 包后才可上岗；权限与人类一致，能建单不等于能改价，能放行不等于能改等级；随时可以只用人，关掉智能体，流程照常运转，只是慢一些。
服务台助手
门户里那个能答、能办、能追进度的人：按项目政策与账单口径作答，代住户填单建单，超时自动跟进，并把重复问题沉淀成自助条目。
动作权限：查询、建单、提醒；不可改价、不可减免
报修与派单助手
工单的第一受理人：识别位置、品类与紧急度，自动定级并派给合适的班组或个人，接单超时升级，完工按模板核验，随后回访并统计返工率。
动作权限：建单、派单、升级、回访；不可核销费用
会员运营助手
会员与增值的经营手：按消费与服务记录分群，推送权益与增值服务，跟踪核销与转化，并在续租窗口期与租赁侧联动，把服务数据变成续约理由。
动作权限：推荐与触达；发券与调级需人工审批
社群与通行助手
活动与通行一起管：策划活动并按兴趣召集，维护社群内容与舆情提示，受理访客预约、生成放行凭证、复核异常通行并提示物业。
动作权限：放行需双因子；熔断后只告警，不自动恢复
| 模板 | 报告名称 | 生成周期 | 数据来源 | 主要结论 |
|---|---|---|---|---|
| TPL-C01 | 服务周报 | 每周一自动生成 | 工单（WOS）· 满意度评价 · 排班与班组 | 报修量与类型分布、首次响应与完工时效、返工与超时工单、满意度分布与低分归因 |
| TPL-C02 | 会员与增值月报 | 每月 1 日自动生成 | 会员（CSM）· 缴费流水 · 增值服务订单 | 活跃与新增会员、权益核销率、增值服务转化与客单、续租窗口期的服务联动效果 |
| TPL-C03 | 社区活动结案报告 | 每场活动结束后 | 活动（CMS）· 报名与签到 · 费用明细 | 报名与到场率、成本分摊、参与住户构成、住户反馈与下一场策划建议 |
| TPL-C04 | 通行与安全月报 | 每月 1 日自动生成 | 通行（ACS）· 访客记录 · 异常告警 | 访客量与时段分布、异常通行与处置时长、门禁与车场设备健康度、权限到期清理情况 |
一次报修从发起到归档，8 个环节都有人负责
流程的价值不在环节多，而在每一环都有责任人与时限，超时不停留、完成后有回写。下面这条链既是工单流程，也是服务数据的采集过程。
租户发起
在小程序、电话或前台发起，住户只需说清位置与现象；系统按住户身份自动带出房号、联系人与历史同类工单。
智能体受理建单
识别品类与紧急度，带出房号、租约、装修责任分界与设备维保状态，同步确定费用流向与责任方，受理即建单。
自动定级与派单
自有班组或外包按技能、班次与距离匹配；接单超时自动升级到上级或备用班组，派单依据全程留存。
到场与服务
扫码签到记录到场时间，作业过程可拍照留痕；材料领用与工时就地登记，避免事后凭记忆补单。
完工举证与核销
按模板提交照片与材料清单；费用在核销环节按口径分流到租赁账或物业账，不需要二次录入与人工并表。
租户确认与评价
住户一键确认完成并评价；低分或选择「未解决」自动转人工复核并回访，不让住户反复催单。
回访与复盘
按周统计首次响应、完工时效、返工率与超时分布，定位到具体班组与设备，而不是只看总量。
沉淀与优化
重复问题沉淀为自助条目，高频故障进入设备维保计划，派单规则与 SLA 时限按实际数据调整。
30 天：先把门户与工单跑通，再接会员与通行
顺序不是随便排的：住户档案和工单是一切的地基，会员、活动与通行都挂在这两样上。先把地基跑通，后面的接入才有意义。
住户档案与门户先立起来
梳理人、房、约三类主数据，打通认证与门户入口。这一步做完，住户就能登录、看到自己的房与账——后面所有能力都长在它上面。
工单、缴费与通行接入
把报修流程与 SLA 定下来，接通支付通道与门禁硬件，跑通第一张工单的完整闭环；同步接入会员体系与增值服务目录。
智能体上岗与运营看板
加载项目 Skills 包，开放 L1–L3 能力；开启服务周报与通行月报，把服务数据接进租赁侧的续约与定价视图。