惠州那个研发中心，老板一开始问我的不是“这家配送公司行不行”，他问的是，能不能拿一年标准直接做决定。这个问法其实挺对的。试吃那天菜热不热，谁都能说两句，真正麻烦的是，三个月后投诉会不会冒出来，夏天高温下配送车还能不能稳住，周五下午加餐申请一多，系统会不会全乱掉？
我当时盯的不是菜单，先看订单流。研发中心中午集中，十二点前后那一波最容易出事，刷卡数据、订餐人数、临时加餐人数，三个口径要对上，不然配送公司嘴上说“我们多送了”，后厨那边说“没收到”，最后谁都讲不清。这个场景我见得多了，纸面上每周都很漂亮，到了现场，保温箱一打开，汤是温的，饭边缘发硬，员工没说太重的话，刷完卡就走了，第二天退款和差评一起冒出来。
一年标准怎么做？我一般不看一条线，光看准时率没用，光看客诉率也不够。要把几个数放一起压着看，像一个简单的控制台。送达准点率，食安留样合格率，餐品温度波动，临时增减餐响应时间，月度投诉闭环时间，还有一个很容易被忽略的，菜品重复度。研发中心的人嘴上不说，连续三周吃到差不多的东西，订单掉得很快。这个掉单不是一下掉，是慢慢掉，像水龙头没拧紧。
我跟老板聊的时候，没讲什么大道理，就把一年拆成几个观察窗口。一个月看执行，一季度看波动，半年看供应链稳定性，一年看成本和体验是不是同时站住。惠州这边天气一热，配送半径稍微拉长一点，米饭就容易塌，汤也容易洒，车厢里那个味道一出来，现场的人立刻就知道这单不稳。系统里看得到异常，现场闻得到异常，这两个信号经常是同步的。
还有一个细节，很多老板会忽略。团餐配送公司不是只看餐，是看它能不能接住变化。研发中心项目型工作多，临时会议、加班餐、夜宵，数量都不大，但特别碎。配送公司如果只能按固定节奏跑，一碰到临时增单就开始卡，最后影响的是整个食堂数字化系统的结算准确性。那种“今天先凑合一下”的供应商，短期省钱，后面一定在数据里补回来，补得还挺难看。
所以我给老板的建议很直白，别拿一次试餐决定，也别只盯报价。报价低，后面服务弹性差，最后ROI也不好看。要看一年内这家公司能不能在你的数据模型里持续过线，过线的不是一句话，是一串日常动作。这个东西有时候挺枯燥的，但老板做决定，还是得靠这些枯燥的数。人很容易被第一顿饭骗到，系统不会。
原创文章，如若转载，请注明出处：https://www.zdgn.cn/33.html
