把 48 条平台数据，
变成一张帮扶清单。
门店外卖做得好不好，后台只看得到单店、单平台、单月的数字。我把它做成了两个工具： 一个是团队每天能用、能看到跟进状态的在线系统，一个是压进单个文件、双击就能演示的离线版。 后面这个现在就能点开。
外卖弱店诊断台
把美团外卖、淘宝闪购的门店月度数据分开打分，自动生成一张可排期的弱店帮扶清单。它不是数据大屏，只回答三个运营问题：哪家店弱、弱在哪个平台哪个维度、本周先帮谁。
- 角色
- 指标口径 · 产品设计 · 全栈实现
- 形态
- Python 服务 + SQLite + 原生前端
- 范围
- 24 家门店 × 2 平台（演示数据）
- 交付
- 可部署包 + 18 页项目说明书
01问题WHY
- 两个平台后台只能看单店、单平台、单月，看不出"这家店在某个平台已经失守"。
- 月度帮扶会排期靠感觉：按分数最低排，还是按 GMV 最大排？同样缺 10 分，月销 11 万和月销 4 万的店不该一样对待。
- 帮扶动作、负责人、跟进结果散在 Excel 和群里，两周后没人复盘。
02做法HOW
- 同平台分位打分。每个指标只和同平台、同月份的深圳门店比较：低于 P10 记 0 分，高于 P90 记 100 分，中间线性折算，成本型指标反向。极端值绑架不了全组，两个平台的流量口径也不会被混着加。
- 五维加权。流量获客 25%、转化客单 25%、复购口碑 20%、履约体验 20%、经营稳定 10%；门店综合分按两个平台的 GMV 占比合成。
- 单平台失守单独标红。观澜店综合 59.4 分看着是绿的，但淘宝闪购只有 23.6 —— 这种店必须从绿牌里拎出来。
- 优先级不按最低分排。60% 看经营缺口，40% 看 GMV 分位，把"有限的人力"投到"分低且体量大"的店上。
- 一店一策 + 14 天目标。按"权重 × 与目标分的差距"选主短板，给出 4 步动作；目标只追"当前值到同平台中位"的一半，是行动目标，不是增长承诺。
- 闭环写回数据库。跟进状态、负责人、备注存进 SQLite，同事打开看到的是同一份，不是各自的 Excel。
帮扶优先级 = 60% × 经营缺口 + 40% × GMV 分位
风险缺口取"综合分缺口"与"最弱平台分缺口"的较大值；GMV 只用于排序和影响面测算，不进入健康分，避免大店靠体量把分数拉高。
03结果WHAT
- 12 家需帮扶的门店里，排出本周 5 家，覆盖这 12 家 GMV 的 60%。
- 观澜店综合 59.4 分、淘宝闪购 23.6 分 —— 识别为"单平台失守"，优先级第 1；只按综合分排，它会漏掉。
- 沙井店综合 33.0 分、月 GMV 11.1 万，排第 2；蛇口店 47.0 分但 GMV 11.8 万、履约短板明显，也进本周 5 家 —— 不是机械按最低分。
- 换真实数据不用改代码：下载 Excel 模板 → 按门店×月份填 → 导入预览校验 → 全站指标、评分、清单自动重算。
04实现BUILD
- 没有前端框架、没有 CDN 依赖：Python 3.12 标准库 HTTP 服务 + SQLite + 原生 HTML/CSS/JS，内网机器断网也能跑，手机端同一套页面。
- 公网入口有密码：签名 Cookie + 登录限流，配合 Cloudflare Tunnel 给同事临时访问；另有 Docker / Caddy 部署包做固定地址。
- 导出即交付：一张 Excel 含帮扶清单、门店全量、平台明细、方法口径四张表，能直接发群里。
- 说明：这一版要 Python 服务端和数据库，所以作品集里放的是截图；能亲手点开的是项目 02 的单文件版。
双击就开的诊断台
同一套诊断模型，做成了一个 236 KB 的 HTML 文件。面试和客户现场最怕两件事：网断了、电脑不是自己的。所以它不联网、不装环境、数据不出浏览器，双击就开。
- 角色
- 模型复用 · 交互重写 · 现场讲法设计
- 形态
- 单文件 HTML · 无任何外部依赖
- 体积
- 236 KB（含 24 家 × 2 平台演示数据）
- 场景
- 面试现场演示 / 离线给客户看
01取舍TRADEOFF
在线版适合团队长期用，但演示时是负担：要 notebook、要 Python、要同一个网。面试只有 5 分钟，所以我把服务端能做的事全部搬进浏览器 —— 分位折算、权重合成、优先级排序、一店一策，全部在前端算，关掉页面什么都不留下。
025 分钟讲法PITCH
- 总览 30 秒：24 家门店里 7 家红牌、7 家单平台失守，但本周只打 5 家 —— 人力有限，先解决"分低且体量大"的。
- 门店 60 秒：曾厝垵综合 81.6 分，细看淘宝闪购的流量获客只有 7.5 分 —— 综合分会骗人。
- 帮扶 90 秒：马巷店曝光 35,817，同平台中位 68,783，14 天只追一半，给出四个动作。
- 口径 60 秒：P10–P90、GMV 不参与打分、样本少于 8 家只作方向参考。
- 迁移 60 秒：换成茶饮，履约和复购的权重必须重做，不能照搬便利店。
03结果WHAT
- 从"我做过门店运营"变成"我现在就能打开给你看"：讲完对方能自己点、自己导一份 CSV 重算。
- 离线 + 零依赖，投屏、借别人电脑、断网会议室都能开。
- 同一套公式在两座城市跑通，说明它不依赖某一家公司的数据口径。
这就是那个文件，现在就能点
不需要登录、不联网、不装任何东西。页面上是 24 家厦门门店的演示数据；点右上角「导入数据」换成自己的 CSV，所有分数和清单会当场重算。
现场演示经常是"把手机递给对方"，或者会议室投屏。
单文件版本没有构建步骤，直接响应式适配到 390px；同一个文件，电脑和手机都能开。
这两个工具只是结果。背后是同一套循环：从数据定位问题，用策略解决，再靠复盘推进下一轮。
数据诊断
从曝光、进店、下单、履约、复购里定位"卡在哪一环"，先分清是流量问题还是转化问题。
策略设计
按目标用户和场景选动作：券包、套餐、活动，还是改产品流程，明确转化路径和衡量口径。
落地执行
推进平台配置、门店规则、社群触达和工具上线，让方案真正进入业务，而不是停在 PPT。
复盘迭代
跟转化率、GMV、客单价、复购，把有效做法沉淀成报表模板和 SOP，下一轮接着用。
数据边界（请先看这一段）
作品集里出现的门店、GMV、分数，都是构造出来的演示数据：24 家门店 × 2 个平台 × 一个月，用来展示计算和帮扶流程，不是美宜佳的真实经营数据。它证明的是"方法和工具能跑通"，不是"我做出过这些数字"。
- 健康分是同平台、同周期的相对分，换城市、换月份，分数会整体平移。
- 同平台样本少于 8 家时，P10 / P90 不稳定，页面会提示只作方向参考。
- 完整度低于 60% 的门店先补数据再诊断，缺指标会降权而不是按 0 分硬算。
- 相关性不等于因果；14 天目标只追一半差距，必须做前后对照。
- 月度汇总看不到日级波动，活动、天气、运力、竞品开店都可能影响结果。
- 下一版才接平台 API / 数仓，做周维度趋势和活动归因。
想聊门店运营、外卖增长，或者想看某个页面的实现，直接发邮件给我。
yewentao421@163.com ↗电话和详细经历在简历里，发邮件就能拿到。
页面是手写的原生 HTML / CSS，没有框架、没有外部字体和 CDN —— 断网、内网、旧浏览器都能打开。