给印度时尚连锁用的库存承诺 OS——不靠前置仓重复备货，也能用门店现货做出 2 小时内送达承诺。

1. The Economic Times 直接把低动销、高库存需求和烧钱点名为结构性缺陷，所以眼下最急的投入，不是再做一次获客冲刺，而是把库存纪律先补上。
2. Klydo 不到一年就关停消费者业务，这会让零售商和投资人意识到：为快速时尚单独压库存，可能还没积出规模优势就先死掉。
3. 卡住的 $11-12 million 融资说明，下一批操盘手想再拿到市场的钱，得先把营运资金效率做得更好。
4. 仍有拿到融资的同行，也有新的退出者，说明需求命题还在被验证，这正好给了“卖铲子”的控制层一个窗口——不管最后哪个消费者品牌赢，它都能活。

催化因素。 Klydo 停摆、低动销和高库存需求被明确点名、后续融资又没谈成，让“为快速时尚单独压库存”这件事一下子更可疑，也把零售商往轻资产的快送软件上推。

做一层软件，把门店 POS、ERP、电商目录、骑手 SLA 和社区需求历史接到同一张快速配送可承诺图谱里。系统会针对每个 SKU、尺码和门店，估算库存可信度、预期动销、拣货打包就绪度，以及配送后的剩余毛利，再决定对用户展示 30 分钟、2 小时、当日达，还是不可售。运营侧拿到的是一整套预留、门店拣货、兜底替代、跨店调拨，以及目录下架流程——一旦某个款式大概率会把库存困死，就先从快送目录里拉掉。商品团队还会收到预警：如果快速配送曝光正在拖累周转，就赶在折价累积前，把货从快渠道撤掉或先做再平衡。时间一长，产品就会变成那块控制平面：让时尚零售商卖得起速度，却不用把同一批库存买两遍。

差异化。 这不是泛化 OMS、骑手聚合器，也不是预测看板。真正的切口，是那张把实时门店库存、尺码曲线需求、拣货可靠性和动销风险，直接绑到用户可见配送承诺上的可承诺图谱。随着数据积累，这张图谱会沉淀成一套专有数据集：哪些时尚 SKU 可以在哪些社区卖快、又不会制造死库存。纯电商工具和末端配送工具都拿不到这层护城河。

待完成任务

flowchart LR
  Buyer[Head of omnichannel] --> Pain[Fast delivery demand collides with low sell-through and duplicated inventory]
  Pain --> Product[Store-stock promise engine]
  Product --> Outcome[Sub-2-hour delivery from existing stores with better margin and lower markdown risk]

高管要点

• Klydo 和 Blip 把这个类目的失败模式摊开了：先崩的不是需求，而是库存经济账。Klydo 被明确归因于低动销和高库存需求，Blip 也直言，一套强绑定门店的快时尚模式，不到一年就会被资本强度和执行复杂度拖垮 [1][2][3][5]。
• 用户对更快拿到时尚商品的需求是真的，而且正在获得机构级验证：Myntra 称 M-Now 在已开通区域已贡献 10% 订单，Nykaa 正在扩 60 分钟 / 2 小时模式，Bain 也判断，趋势驱动消费和即时零售扩张正在重塑印度电商 [12][13][14][15][19][20]。
• 真正的空白不在于再做一个快时尚消费应用，而在于给那些扛不起前置仓重复备货的连锁补一层控制系统。连 Nykaa 自己都说，展示型门店不是好仓库；而 Redseer 和 ET 又表明，非生鲜即时零售增长快到足以逼着零售商回应 [15][22][23]。
• 眼下最接近的竞争，其实是泛 OMS 和订单承诺软件，不是 Klydo 式消费应用。Unicommerce、Fluent、Manhattan、Shopify、Salesforce、fabric 都已覆盖门店发货、多地库存和订单承诺；创业公司只有做到更懂时尚、更懂折价风险、部署更快，才有胜算 [28][29][30][31][32][33][35][36][37][38]。
• 滩头市场在战略上有吸引力，但财务空间比即时零售的宏大叙事窄得多；20-80 店时尚连锁这个切口，本质上只是一个低到中等八位数的软件市场，除非公司继续切进更大连锁、相邻类目，或融资 / 路由层 [16][17][18][19][20][25][26]。

市场定义

定义中的市场，是一层面向印度时尚和鞋履零售商的承诺与分配软件：它利用实时多门店库存、本地需求和履约约束，决定某个 SKU 是否该被暴露为 30 分钟、2 小时、当日达，还是不提供快速配送。它位于电商 / POS / OMS 基础设施之上、面向消费者的陈列逻辑之下；明确排除以前置仓为核心的消费应用，以及没有显式优化时尚动销与折价风险的泛化 OMS 套件 [1][5][12][28][30][31][32][38]。

用户与买方

主要客户，是印度时尚与鞋履连锁里已经同时经营直营网店和线下门店的全渠道或商品运营团队。首日买家通常会是 COO、全渠道负责人或商品负责人，因为问题横跨目录曝光、库存周转、门店人效、骑手成本和折价风险，而不只是 IT 路由 [25][26][27][12]。

购买触发点

• 看到 M-Now、Nykaa Now 等实验在同城起量后，准备上线快速配送。 [12][13][14][15]
• 一次失败或推进缓慢的试点，先暴露出库存重复备货、本地库存不准，或还没全城铺开就出现折价压力。 [1][3][5]
• 最近刚上了 OMS 或全渠道系统，但仍然做不出可信的单品承诺，也守不住 SKU × 尺码层级的门店容量。 [29][30][31][32][35][36]

支付意愿

软件预算显然是存在的，但买家会拿它去对比更宽的商业套件，而不是把它当成全新预算科目。Shopify 的 POS Pro 公开价是 $89/location/month，Unicommerce、Fluent、Manhattan、Salesforce 和 fabric 则卖更大的 OMS / 履约栈；这意味着新产品必须证明自己能带来更少缺货、更高快送转化，或更强的毛利保护，才配拿到独立预算。 [28][30][32][34][35][36]

品类动态

增长信号 FY30 前，有组织化服饰零售年增速约 10-13%。

验证信号

• M-Now 在已开通区域已贡献 10% 订单，而且当地用户渗透率已到 20%。
• Nykaa Now 正在多个城市扩张，但管理层仍更愿意用前置仓，而不是把昂贵的 展示型门店 硬改成仓库——这同时验证了需求存在，也验证了节点 economics 受限。
• Slikk 和 Zilo 都拿到了后续融资去扩 60 分钟或 60 分钟内的模式，说明投资人仍相信某些精选场景是成立的。
• Klydo 和 Blip 都很快失败，说明运营方至今仍没找到一套耐用、又节约库存的运营模型。

监管与技术约束

• 客户、位置和订单行为数据的处理，必须对齐印度的数字个人数据制度。
• 跨店调拨和分布式履约，需要从一开始就把 GST、e-invoice 和 e-way bill 约束设计进去。
• 如果公司未来通过开放网络渠道扩张，ONDC 参与规则和交易级治理就会进入实施范围。
• 承诺准确率的前提，是多来源库存纪律和 source-selection 逻辑在用户看到“快速配送”标识前就足够可信。

竞争大致分成两拨，而且差得很远。一拨是泛化商业控制厂商——Unicommerce、Fluent、Manhattan、Shopify、Salesforce、fabric、Anchanto、Vinculum——它们已经提供门店发货、库存可视化和订单承诺。另一拨是快速时尚运营方——Myntra M-Now、Nykaa Now、Slikk、Zilo、Knot——它们证明用户确实在乎速度，但解决方式依赖自有节点、品牌精选或重资本运营。只有当创业公司能帮普通时尚连锁，在不继承库存风险的前提下逼近后一拨的速度，这个切口才真正成立 [12][13][14][15][28][30][31][32][33][35][36][37]。

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

• 云端商业平台. Shopify 和 Adobe 让多来源库存、门店发货在操作上成为可能，但它们离“按时尚特征做需求闸门、感知折价风险地下架目录、并给到社区级承诺智能”还差一层。
• 企业级 OMS 与承诺套件. Fluent 和 Manhattan 已经能建模门店容量、路由和承诺准确率，但它们更像系统底座，部署也往往比一家中型时尚连锁为单一城市上线所愿意承受的更重。
• 印度本土使能栈. Unicommerce 已经在卖门店发货和同城即时配送，但泛化的订单 / 库存管理层，并不等同于一套和动销风险绑定的时尚快速选品控制系统。
• 垂直快时尚运营商. M-Now、Nykaa Now、Slikk 和 Zilo 证明速度有价值，但它们依赖的资本、前置仓和品牌 / 节点控制力，远强于大多数 20-80 店连锁所具备的条件。
• 人工作业流. 默认替代方案仍然是 ERP 导表、门店电话和 WhatsApp 协同；可一旦快速配送目录需要在 SKU × 尺码层级持续更新，而库存盘点又不可靠，这套办法就会先垮。

Fashion-stock-promise-engine 应该先做一层覆盖软件，卖给那些想用现有门店做 2 小时内送达、但又扛不起前置仓重复备货的印度服饰和鞋履连锁。核心客户，是一家在 Bengaluru 或 NCR 有直营网店和实时门店库存的 30-60 店连锁，正准备上线或补救快速配送。研究证据支持这个痛点：Klydo 和 Blip 都不是因为用户没需求而倒下，而是库存周转和营运资金纪律先崩了；与此同时，Myntra M-Now 和 Nykaa Now 又说明，只要供给在，消费者确实会用更快的时尚配送。公司因此该卖的是“承诺 + 预留”的控制层，不是消费 App、泛化 OMS 替代品，也不是骑手网络。第一个 验证点 应该是一笔付费城市试点：在 8-10 家完成核验的门店里，提高承诺准确率和快速配送转化，同时不把折价风险推高。眼下输入里最缺的事实，是 20-80 店连锁真实的 SKU × 尺码库存准确率基线，所以前 90 天必须先做盲盘，再谈大规模自动化。滩头市场在战略上有价值，但体量不大：研究测到的 TAM 约 $31.5M ARR，第 3 年滩头 SOM 约 $1.8M，且还没算用量费，所以投资故事最后能不能成立，要看公司后续能否切进更大连锁、相邻类目，或更上层的路由与规划。现阶段更像一笔纪律严明的 pre-seed，而不是可以直接放大预期的项目；在团队证明付费试点、目标定价和可复制的覆盖式部署动作之前，投资判断应维持 观察。

问题

• 印度时尚连锁被推着去做快速配送，但长尾尺码和款式库存让前置仓重复备货既吃资金，又很容易碰上低动销。
• 手工 OMS 规则、POS 导表和门店 WhatsApp 协同，根本来不及决定 SKU × 尺码 × 门店是否适合承诺快速配送；于是零售商不是过度承诺、把用户体验砸穿，就是把库存藏起来，白白损失需求，还把折价风险扛在自己身上。

解决方案

• 接入 POS、ERP、电商目录和骑手 SLA 数据，为每个 SKU × 尺码 × 门店 × 社区组合打分，判断它到底适不适合给出 30 分钟、2 小时、当日达，还是干脆不做快速配送承诺。
• 给运营团队一整套预留、拣货打包、兜底替代和目录抑制流程，在缺货和折价风险开始复利之前，先把脆弱库存撤出快渠道。

为什么我们会赢

• 这个切口比整套 OMS 窄，却比骑手工具更贴近经济账，因为它把承诺逻辑直接绑到动销、库存可信度和毛利上。
• 首个客户在单一城市、单一商品切片里就能看到结果，因此证明速度会比“卖一整套全链路零售转型”快得多。
• 护城河会从 SKU × 尺码 × 门店 × 社区的结果数据，以及门店异常数据里不断复利；这些细节，既有厂商通常不会专门为印度时尚快送去调。

里程碑

flowchart LR
  Wedge[Metro launch pilot] --> MVP[Promise and reservation engine]
  MVP --> Proof[Higher conversion and lower markdown risk]
  Proof --> Expansion[Chain rollout and adjacent workflows]

创始团队

实验路线图

风险评估

必须成立的条件

• 前 10 家完成资格审查的连锁里，至少有 2 家会在等 OMS 厂商路线图之前，先为付费 试点 掏钱。
• 完成核验的试点门店，只靠轻量流程改动，就能把 SKU × 尺码库存准确率稳定在 92% 以上。
• 一小块快速配送商品池，能在不推高折价暴露的前提下，把转化或服务水平拉高到明显优于对照组。
• 正式生产定价能够守在研究测得的每个活跃门店每年约 $6,000 基础费，再加用量费附近。
• 首个正式生产客户会在 12 个月内扩到更多门店或第 2 个工作流，证明这不只是咨询收入。

待尽调问题

• 20-80 店时尚连锁在真实大都市里，SKU × 尺码层级的库存准确率和拣货纪律到底是什么水平？
• 哪些品类和消费场景真的需要 2 小时内承诺，而不是当日达或自提？
• 为什么 Unicommerce、Fluent、Manhattan、Shopify 或内部团队，不能足够快地满足首批买家？
• 现实里，到底是哪项 KPI 最能最快释放预算：更高转化、更少缺货，还是更低折价？
• 在客户真正感受到它是一层覆盖软件之前，到底要做多少集成工作？

模型合理性

• 收入引擎. 基准情形的收入，来自 14 个付费试点喂出的 9 家转正连锁和 1 个仍在进行的试点；成熟账户会逐步扩到每家约 30 个活跃门店。
• 必须跑通的事. 公司必须让完成核验的试点转化率明显高于 50% 底线，并在首家连锁里跑出账户内扩张，因为模型要到 Q4Y3 才会接近 EBITDA 转正。
• 模型会在何时失灵. 如果正式生产 ARPU 最后更接近 $180K，或转化率往 downside 情形滑，现金会在公司拿到一个干净的 可拿 seed 的 证明点之前先转负。
• 下一轮证明点. 只有当团队做到 5 家正式生产连锁、1 次现有账户内扩张，以及受支持技术栈部署少于 4 周时，下一轮融资才真正站得住。

情景

敏感性

flowchart LR
  Outreach[Target-chain outreach] --> PaidPilots[Paid metro pilots]
  PaidPilots --> Production[Production chain rollouts]
  Production --> Stores[Active stores and workflows]
  Stores --> Revenue[Subscription and usage revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash runway]

警示项: 基准情形要求 69% 的已完成付费试点转正式生产，高于 BP 底线，对盲盘结果不佳的容错空间并不大。 · 第 3 年按年末 FTE 算，人均收入只有约 $150K；如果 铺开 时间不能稳定压到 4 周内，模型看起来仍然太像实施服务。 · Q4Y3 的退出 run-rate 已经逼近研究里的 $1.8M 滩头 SOM，因此独立公司后续要继续上行，就必须切进更大连锁、相邻工作流或伙伴分发。

• 门店库存准确率噪音太大. 很多连锁的门店级库存和拣货纪律并不可靠，第一批试点里，快速配送承诺很可能先在这里翻车。 缓解措施: 先从完成核验的门店起步，配上可信度分数和保守阈值；等系统证明准确率和门店执行都稳住后，再逐步放开。
• 买家可能觉得慢一点也够用. 部分零售商可能会认定当日达和到店自提已经够好，从而削弱对一款“专做快速配送”的产品的紧迫感。 缓解措施: 把平台卖成一层守毛利的承诺与库存分配系统；它不仅能改善快送，也能顺带优化当日达、BOPIS 和调拨决策。
• 既有 OMS 打包进来. 订单管理和电商供应商可能会补上一些基础的 门店发货 规则，然后宣称这个问题已经解决。 缓解措施: 吃下更难的那一层——SKU 级动销风险、尺码曲线资格和感知折价的目录抑制——这些都不是通用路由规则能建模的。