案例 · D2C 服装零售

11 家门店,3 个线上渠道,每天早上一套数字。

业务
D2C 服装品牌,班加罗尔
规模
4 个城市的 11 家门店,3 个线上渠道
此前依靠
门店收银系统、2 个电商平台、自有网站
团队
两位创始人

一个在 4 个城市拥有 11 家门店和 3 个线上渠道的服装品牌。月末要花一周核对三份报表,结果还是对不上。

原来哪里出了问题

创始人只想知道一件事:品牌昨天卖了多少。要得到答案,得三个人分别导出三份报表。门店收银软件给出一个数字。2 个电商平台各给一个,对一笔销售何时算数、退货怎么处理,各有各的算法。网站又给出第三个。从来没有人让这三个数字对上过,等它们被粘贴进同一张表,一天已经过去了。

月末更糟。它要花掉大半周,靠一位分析员的电子表格运转,得出的数字,财务团队和采购团队心里都暗暗不信。退货是最痛的地方:电商平台的退货在销售发生几周后才出现,而且出现在另一份报表里,所以大家早已据此行动的销售数字其实是错的,只是谁也看不出来。

底下的采购决策,就建立在这样的数字上。某个城市因为看起来卖得好而被补货,而同一尺码却在 200 公里外的另一家门店里积压着。打折开始得太晚,那时当季早已过去。

我们做了什么

一个所有渠道统一汇报的地方,放在品牌自己的账户里。每个渠道照原来的方式销售;改变的是,每一笔销售、退货和取消都以同样的格式汇入,同一件商品无论从门店、电商平台还是网站卖出,都是同一件商品。每个数字的规则只写一次,所以“销售额”对财务和对采购意味着同一件事。

每位店长都有一块自己门店的看板:卖了什么,什么快缺货了,什么一直没动。创始人看到的是同样的全景,覆盖全部 11 家门店和全部 3 个渠道,每天早上在门店开门前就已就绪。

一块看板显示昨天所有渠道的情况:售出件数、退货、每个渠道都与其自身报表一致、各渠道的件数趋势,以及哪些该调货、打折或补货的建议。
根据文中描述绘制的界面示意图,并非截图。

在此之上,还有一个补货视图,替大家做了原本没人有时间做的阅读。它会标出哪些该补货,哪些该调到同一尺码正在热卖的门店,哪些该抢在季节替您拍板之前打折。系统提出建议,采购团队做决定,他们的每个决定都有记录,所以建议的好坏,是对照采购实际怎么做来评判的,而不是凭一句说法。

老板最后得到了什么

每家门店、每个渠道一套数字,每天早上就绪。月末结账在一个屏幕上完成,财务签字确认的数字,就是采购团队看到的数字。每份报表都有书面定义,所以新来的分析员可以直接被告知某个数字是什么意思,而不用从离职同事留下的东西里去摸索。

创始人最看重的是并行运行:每一份报表,旧版和新版都并排运行,直到两者一致,或者差异得到解释并签字确认。任何人信任的东西,在替代品赢得信任之前,都不会被关掉。

交接复盘坦诚地写明了局限。补货建议的好坏,取决于它底下的库存数据,这就是为什么先做数字、后做建议,也是为什么整套系统的运行成本在开发前就写了下来。

改变了什么,改变了多少。

  1. 节省时间

    月末结账

    6 天 变为 1 个上午

    从当月最后一个营业日,到拿出一套老板愿意据此行动的数字

  2. 消除差错

    各渠道之间对不上的报表行

    每 5 行有 1 行 变为 每 100 行不到 1 行

    同一天、同一件商品,两个来源,两个答案

  3. 堵住流失

    一家门店缺货、另一家门店却有货的商品

    每月 180 次 变为 每月 25 次

    顾客要的尺码没买到,而同款同码正在别的门店卖不出去

每项指标都在开发前书面约定,起始数字也在开工前测得。从“6 天”到“1 个上午”,是同一项指标在完工后按同样方法统计的结果。

数据与分析:完整介绍

全部案例

开始

写一段话。创始人会在 1 个工作日内回复。

随后是与两位创始人的 30 分钟通话。不放幻灯片,也不套方案模板,只是先初步判断:我们是否适合解决这个问题。

也可以通过邮件、电话或 WhatsApp 联系: hello@netogrit.com · +91 94330 54299 · WhatsApp(在新标签页中打开)