本模板采用「四模块法」：实体、关联、状态、关键运营指标，专为代管业务设计。内容以管理12套房源的托管公司为例完整填充——具体示例远胜空泛框架，因为它清晰展现了所需细节的合理深度：仅需一页，而非四十页。
区分托管公司与房东的关键，不在于房源数量，而在于资金归属：您代收的是他人的钱，从中提取佣金，并须每月按房源逐笔留存可验证的收支证据链。因此，「房东」必须作为独立实体存在；而月度报表也绝非简单导出——它是该职业的核心交付成果。
第二项关键特征：您并非事必躬亲。两单入住之间的房屋清洁常外包执行，且自身具备完整生命周期——待排期、已排期、已完成、需返工。当两单入住时间紧邻时，正是清洁环节最容易出问题，故其跟踪必须独立于入住订单。
如需适配您的业务，请保留结构框架，仅替换内容：按您实际采用的佣金模式、服务类型、以及入住订单在您公司内部真实流转顺序，更新对应的状态序列。界面将自然由此结构衍生，无需额外描述。
用您自己的语言填写后，此文既可作为开发人员的需求简报，也可直接提交至 Blueprint Maker——系统将据此生成待确认的应用方案，继而自动生成完整应用：含数据库结构、各实体专属操作界面、数据看板及演示数据。
可直接复制的模板
我的业务：短租托管，共管理12套房源 为7位房东提供服务，团队2人，清洁服务外包。 需跟踪的实体： - 房源（名称、地址、容纳人数、所属房东、佣金比例、入住指引） - 房东（姓名、电话、邮箱、打款信息） - 入住订单（房源、房客、入住日期、退房日期、入住人数、收款金额、预订渠道） - 清洁任务（房源、日期、服务商、耗时、费用） - 服务商（名称、电话、专长、小时费率） - 佣金（对应入住订单、扣留金额、打款月份） 实体间关联： - 一套房源归属于一位房东。 - 一单入住订单对应一套房源。 - 一次清洁任务用于两单入住之间准备房源，且由某位服务商执行。 - 一笔佣金关联至一单入住订单。 入住订单的状态：咨询中、已确认、已入住、已退房、已收款、已打款。 清洁任务的状态：待排期、已排期、已完成、需返工。 每日晨会需关注的关键数值： - 当日退房与入住数 - 下次入住前需排期的清洁任务数 - 当月累计收款额及已扣佣金额 - 各房东待结算余额
如何适配此模板至您的托管业务
- 房东必须是独立实体，而非文本字段——这是不可简化的关键点。在房源记录中仅添加一列‘房东姓名’足以显示信息，却完全无法回答‘本月应付某房东多少钱’这一问题。一旦某位房东拥有两套及以上房源，唯有通过实体建模才能实现自动汇总。
- 佣金规则由您定义：本模板将佣金比例置于‘房源’实体下，因多数托管协议均如此约定。若所有房源佣金率统一，可将其移至‘房东’实体或设为全局固定值；若随淡旺季浮动，则应置于‘入住订单’实体中。本模板不进行任何未明确描述的计算。
- 清洁任务值得独立成实体：若仅作为入住订单上的一个勾选框处理，便会丢失其日期、服务商及费用等关键信息——而这恰恰是房客抵达未清洁完毕的房源时最易引发投诉的根源。若您自行完成清洁，请删除‘服务商’实体，保留‘清洁任务’实体即可。
- 布草更换、设施维修、欢迎接待等服务，与清洁任务同属一类，建议统一纳入‘清洁任务’实体，以‘服务类型’字段区分；仅当其生命周期（如周期频率、审批流程、责任方）存在本质差异时，才考虑单独建模。
- 本模板明确不支持的功能（对本行业至关重要）：该应用不对接任何预订平台。它不会同步您的 Airbnb 或 Booking 日历，不自动导入订单，也不向房客发送任何消息——预订渠道仅为人工录入的一项信息。此外，它亦不生成具有法律效力的财务凭证：房东报表属于经营状况说明，而非合规发票。