楼栋级备用劳动力网络：当固定阿姨或即时家政 App 掉链子时，确保有经过核验的家政帮工顶上。

1. 资本已在证实，家庭愿意大规模为正规化的备用家政服务买单。
2. 最近一轮外来务工人员流动暴露出，城市家庭最痛的不是“发现服务”，而是“服务不断档”。
3. 服务发生在私人住宅里，因此赢家必须把楼栋级的信任、门禁和事件流程做深，而不止是撮合。
4. 工人核验、培训、保险和数字化打款都已成熟到够撑起一支受管理的备用劳动力网络。

催化因素。 4 月下旬的新闻同时释放了两个信号：资本继续看多即时家政，而外来务工人员流动又把服务失灵暴露得更尖锐，这让“连续性基础设施”第一次变得既紧迫又能进预算。

ReserveGrid 卖的不是一个面向单个家庭的撮合市场，而是一层面向公寓社区的兜底劳动力网络。产品会在社区周边维持一支经过培训和背景核验的备用人手池，并提前把每栋楼的门禁规则、住户偏好和安全协议录进去。社区经理在一个后台里就能看到预计缺口日、备用覆盖时段、工人实时 ETA、数字化签到签退和事件升级。住户只能通过所属楼栋下单，需求因而集中，待命人手才有经济性。时间拉长后，这家公司卖的就不止是预约工具，而是住宅社区的劳动力连续性与信任层。

差异化。 ReserveGrid 不跟现有平台正面拼“一户一户获客”。它把需求聚合在公寓社区这一层：密度一上来，待命人手才算得过账，同时安全要求本来就在这里最硬。这会围绕备用产能、楼栋集成和缺勤数据沉淀出结构性护城河——这些都是消费者 App 和线下中介没有掌握的资产。它也能给现有平台做溢出供给与信任层，而不止是替代它们。

待完成任务

flowchart LR
  买方[物业经理] --> 痛点[家政爽约引发住户投诉]
  痛点 --> 产品[备用家政供给网格]
  产品 --> 结果[保证可信补位到岗]

高管要点

• 证据支持这个痛点真实存在，不过值得投资的切口远比“大盘家政服务市场”窄：真正的机会是给高密度高端社区做连续性兜底，而不是再造一个泛用保姆 App。
• 真正卡住的地方是供给可靠性与信任，而不是需求。需求已有了；真正会在冲击中崩掉的是训练有素的人手密度、门禁放行和事件处理。
• Urban Company、Snabbit 和 Pronto 正在证实 C 端需求，不过它们优化的是家庭获客和微市场密度，不是楼栋级的备用 SLA。
• Gurugram 是可信赖的滩头市场：高端公寓供给密、社区软件已普及、NCR 又是即时家政的关键需求带。
• 市场仍很早、执行也很重：线上渗透率仍低，头部玩家补贴重，工人招募也跟不上需求增速。
• 任何赢家都必须一半像派单系统、一半像安全 / 合规基础设施：核验、数据治理、门禁日志和安全升级不是附属功能，而是产品正中心。

市场定义

ReserveGrid 位于即时家政平台和封闭社区运营软件的交叉点。这个市场的定义，是给已有正式门禁、收费和住户流程的高密度公寓社区，交付楼栋级连续性和备用劳动力。经济买家是社区运营方或 RWA 管理层，真正的日常用户则是物业办公室和住户。本备忘录有意排除了独栋住宅、泛化的美容 / 维修平台，以及传统全职住家保姆中介。

用户与买方

最适合的第一批客户，是 Gurugram 入住户数 500+ 的封闭式社区里，负责服务不断档的物业或社区运营方。日常用户通常是物业办公室、安保台或住户支持团队——固定阿姨不来时，投诉都压在他们身上。买方真正关心的，是住户满意度、门禁风险和运营稳定性，不是单纯的人力套利。预算大概率挂在社区运营、安全或住户体验开支里，不过委员会审批、供应商尽调以及数据 / 隐私顾虑，都会让采购变慢。

购买触发点

• 季节性或选举驱动的家政缺勤，让住户连一个可靠兜底都找不到。 [22][20]
• 上班族家庭在早晚高峰时段突然找不到帮工，住户投诉反复升级。 [22][21]
• 一旦出现安全事件、核验遗漏或门禁失灵，临时依靠 WhatsApp 群和中介协调的脆弱性就会彻底暴露。 [6][30][31]

支付意愿

家庭已在为紧急兜底劳动力付钱：Urban Company 公开试过 ₹49/hour，India Today 记录过总价不到 ₹200、时长约两小时的使用情境，Snabbit 也公开披露过 ₹169-₹499 套餐，Broomees 的按需家政报价是 ₹179/hour。与此同时，社区本来就在买 ERP / 安防软件，也在按月收大额物业费，因此共享连续性费用在机制上说得通——但价格敏感度很真实，因此这项服务必须真能省协调时间、降投诉，不能只是多一层方便。 [35][21][12][26][2][3]

品类动态

增长信号 线上家政服务到 FY2030 的 CAGR 约 18-22%

验证信号

• Urban Company 表示，InstaHelp 在 2026 年 3 月的月交付订单已突破 100 万。
• 据报道，Snabbit 在 3 月累计任务数已突破 100 万，并在 6 个月内把日订单从 10,000 拉到 40,000+。
• Pronto 称自己日订单约 24,000-25,000 单，且 NCR 贡献了约一半订单。
• 社区运营软件已服务数百万家庭，这说明公寓社区既可触达，也愿意为软件付费。
• 公开报道越来越把安全协议和核验视为决定性运营问题，而非边缘顾虑。
• Gurugram 主导的高端住宅密度仍在 NCR 上升，这会提高备用人手在局部地理片区被充分利用的概率。

监管与技术约束

• 在 Delhi / Haryana，家政核验已是显性的流程要求，一旦出事，这件事只会更重要。
• 家政用工仍只是部分被正规化；劳动法覆盖在纸面上存在，不过完整的家政工政策还没真正落地。
• 封闭社区 App 会收集敏感的行动轨迹和身份数据，因此任何楼栋级产品都天然背着隐私和数据最小化责任。
• 楼栋进场流程和安检会直接影响工人准点率，这会进一步打击 SLA 可靠性。
• 备用劳动力网络必须接上现有的工作人员出勤、访客审批和事件日志流程，否则只会变成又一层运营负担。

竞争来自四路：C 端即时家政 App、传统中介、非正式阿姨关系网，以及社区管理软件。拟议中的创业公司最强的位置，恰恰在这些类别交叉、但谁都没彻底解决的问题上——在封闭社区里，给出有确保的兜底补位，同时把门禁预审和事件可追溯性一起做完。

为什么现有厂商不会默认胜出

• 消费者平台. Urban Company、Snabbit 和 Pronto 赢在家庭侧需求，不过当多户同一时间掉链子时，它们并不掌握楼栋级 SLA、备用人手池或住户治理流程。
• 社区 ERP 与门禁 App. Mygate 和 NoBrokerHood 已掌握访客、收费和工作人员进场流程，不过并不确保劳动力供给；因此它们更像渠道和集成面，而不是默认赢家。
• 传统中介与本地关系网. 中介和住户 WhatsApp 群看似覆盖更广，也会承诺替补，不过速度更慢、可审计性更差，更谈不上实时产能规划或标准化门禁控制。
• 社区自建人手. RWA 当然能自己养一支机动人手，不过招人、核验、处理缺勤和提高利用率，很快就会变成多数社区根本不擅长的人力资源问题。

ReserveGrid 要解决的是印度快速增长的即时家政赛道里一个很具体的失灵情境：固定阿姨一缺席，高端公寓社区就没有可信赖的楼栋级兜底。Snabbit、Pronto 和 Urban Company 同月的报道说明，C 端需求是真的，不过一遇到劳动力迁移冲击，供给就会塌，同时由于服务发生在私人住宅里，安全门槛也只会更高。公司计划从 Gurugram 入住户数 500+ 的封闭式社区启动，卖给物业运营方的是备用劳动力 SLA，不是又一个家庭撮合市场。MVP 是一套社区运营产品：已预审的备用人手池、楼栋专属门禁流程、数字化签到签退以及事件处理，全都放进一个后台。GTM 从手握多栋楼盘的区域物业经理切入，由于一纸合同就能撬动高密度需求，采购也比一栋楼一栋楼去卖 RWA 更短。研究测出的首个切口市场不大——TAM 约 $73M、SAM 约 $5.1M、第 3 年 SOM 约 $0.9M——因此这是不是 VC 案子，取决于它能否证实自己能扩到相邻的受管理住宅劳动力品类和平台溢出基础设施。最能证伪这个故事的两点也很清楚：社区会不会用共用预算为“连续性”买单；早晚高峰的备用排班能否在不打穿毛利的前提下守住 >90% 的补位率。在 Gurugram 付费试点把这两件事跑通之前，预算归属和合作方意愿都只能当假设，不能当事实。

问题

• 固定阿姨、厨师或保姆一旦爽约，高端公寓社区就得吞下住户投诉和安全风险，不过现有兜底方案仍零散地散在 WhatsApp 群、本地中介和消费者 App 里。
• 同一时间窗口的报道说明，即时家政 App 在劳动力迁移冲击下也会失灵，因此真正卡住用户的点不是“发现服务”，而是“服务不断档”和“可信通行”。
• RWA 和物业经理早就把访客和工作人员流程做成正式制度了，不过在备用用工规划、补位率可视化和事件响应上，依然没有一套经得起审计的系统。

解决方案

• 向公寓社区出售楼栋级备用家政网格——一边配好已预审的备用工人，一边接上楼栋专属门禁规则，并在缺勤高峰时负责派单补位。
• 给物业团队一个统一后台，把需求受理、ETA 跟踪、数字化签到签退、事件日志，以及按楼栋和时间窗拆分的 SLA 报表全收进去。
• 把住户需求收回到楼栋体系里，而不是放在独立消费者 App 上，让高密度塔楼内部先沉淀出需求池，待命产能才有规划空间。

为什么我们会赢

• 这个切口把需求聚在社区层：只有密度起来，备用人手才跑得动经济账，而安全控制也恰好在这一层最重要。
• “消费者 App 优化的是逐户获客；社区 ERP 优化的是门禁和收费；ReserveGrid 夹在中间，补的是两边今天都没承诺的一件事：在封闭社区里确保有人兜底补位。”
• Gurugram 是天然的集中启动区：高端住宅供给、社区软件普及度和 NCR 的家政需求，本来就都堆在这里。
• 只要试点跑通，公司就能持续沉淀缺勤模式、高峰窗口、补位率和门禁摩擦等专有数据，后面的排班准确率会越滚越强。

里程碑

flowchart LR
  Wedge[Sell continuity pilots to multi-tower Gurugram operators] --> MVP[Reserve bench + dispatch + gate workflow MVP]
  MVP --> Proof[Prove fill rate, complaint reduction, and safe operations]
  Proof --> Expansion[Expand to more towers, more categories, and overflow partnerships]

创始团队

实验路线图

风险评估

必须成立的条件

• 多楼栋物业运营方必须把备用家政当成值得集中预算解决的共享运营问题。
• Gurugram 至少有一个微市场，能靠预审备用工人把高峰时段补位率连续 8 个试点周守在 >90%。
• 付费试点必须把投诉量或投诉解决时长降到够让运营方续签年约。
• 工人招募和保底备勤窗口必须带来稳定留存，而不是靠高补贴堆出大量闲置时间。
• 社区 ERP 和门禁流程要够可接入，不能让 ReserveGrid 反而增加不可接受的运营摩擦。

待尽调问题

• 住户投诉固定阿姨缺勤时，今天到底是谁出预算：RWA、物业经理，还是根本没人出？
• 在 7-10 am 和 6-9 pm 的高峰时段，不打成负贡献毛利的前提下，究竟能做到什么补位率和响应 SLA？
• 是物业经理会先买单，还是大多数目标社区最终仍由 RWA 委员会拍板？
• 在封闭社区里安全地跑这项服务，真实需要收集多少住户和工人数据？
• 如果试点起势，Mygate、NoBrokerHood 或大型消费者 App 会多快抄走流程，或卡死渠道？

模型合理性

• 营收引擎. 基础情形的营收，来自签约社区从第 1 年的 6 个扩到 Q4Y3 的 26 个，同时每社区年收入约 $42K。
• 必须跑通的环节. 模型成立的前提，是试点能顺利转成年约、承诺窗口内的补位率能守住 >90%，由于这两个杠杆同时决定社区数增长和毛利率改进。
• 模型崩溃条件. 最大的现金风险，是销售周期变慢叠加毛利率掉到 64% 以下；一旦如此，下行情形的现金低点会打到约 -$1.45M。
• 下一轮融资依据. 只要公司在 Gurugram 切口上做出 12-15 个社区、2 个多楼栋运营方，以及片区级毛利改进，下一轮融资就有了依据。

情景

敏感性

flowchart LR
  Leads --> Pilots
  Pilots --> AnnualContracts
  AnnualContracts --> Communities
  Communities --> SubscriptionRevenue
  Communities --> ShiftUsage
  ShiftUsage --> UsageRevenue
  SubscriptionRevenue --> Revenue
  UsageRevenue --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

警示项: 如果融资不落地，基础情形在 M3 就会掉到零以下，因此必须在试点全面启动前把钱融到手。 · 第 3 年的账面毛利率只到 66%，说明备用人手池利用率还得继续抬，才能摸到 70% 目标。 · 由于这是连续性服务、重运营，不是纯软件模型，因此人均营收偏低。 · 在至少两家多楼栋运营方账户真正上线并进入续约前，客户集中度都还很高。

• 供给流动性. 如果公司在每个微市场都招不到够多、训练合格的机动工人，兜底覆盖就会失灵。 缓解措施: 先只在同一城市的高密度社区启动，并为备勤时段交付保底收入。
• 买方碎片化. RWA 和物业经理的采购链路可能又慢又乱，同时谁有权拍板共享服务也未必一致。 缓解措施: 先通过物业管理公司销售，让一个区域运营方用一份合同就打开多栋楼。
• 安全事故尾部风险. 一旦发生工人不当行为或住户骚扰事件，这个本就被高度审视的品类会很快失去信任。 缓解措施: 从第一天起，就把强制身份核验、一键报警升级、签到日志、保险和快速事件复盘做进核心服务。