惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

L
LangChain Blog
B
Blog RSS Feed
阮一峰的网络日志
阮一峰的网络日志
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
H
Help Net Security
MyScale Blog
MyScale Blog
WordPress大学
WordPress大学
Microsoft Azure Blog
Microsoft Azure Blog
GbyAI
GbyAI
小众软件
小众软件
大猫的无限游戏
大猫的无限游戏
Martin Fowler
Martin Fowler
Vercel News
Vercel News
S
SegmentFault 最新的问题
M
MIT News - Artificial intelligence
Microsoft Security Blog
Microsoft Security Blog
G
Google Developers Blog
Last Week in AI
Last Week in AI
Hugging Face - Blog
Hugging Face - Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 【当耐特】
Google DeepMind News
Google DeepMind News
Engineering at Meta
Engineering at Meta
云风的 BLOG
云风的 BLOG

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
构建【业务预测模型】,这个方法绝了
接地气的陈老师 · 2025-01-16 · via 人人都是产品经理

在数据分析和业务决策中,构建有效的业务预测模型是关键。本文将详细介绍如何将业务与算法结合,构建可靠的业务预测模型,帮助业务部门更好地理解预测结果,并指导具体的业务操作。

做预测模型,难;

做完预测,让业务知道下一步干什么,难上加难。

今天带大家看一下,如何将业务与算法结合,做出可靠的预测。

一、为什么要做业务预测模型?

上述问题,是预测方法选择不佳导致的。算法模型类预测,无论算法的简单或复杂,都有一个通病:无法反应业务过程。导致业务方想基于预测调整业务行为的时候,不知道从哪里下手。

在这种情况下,就需要构建业务预测模型。今天,我们就系统讲解一下。

首先看个具体问题场景——

某toB类原料供应企业,下游需求方包括:

  • 大型客户,且签订框架合同,循环采购
  • 大型客户,无框架合同,每月分批采购
  • 中小型客户,无固定合同,有需求就采购
  • 每个月新开发客户(以中小型客户居多)
  • 每个月有主动开发的客户/被动上门的客户

现在业务方需要预测下个月客户采购量,并且希望指导到大客户销售/中小客户销售/新客户广告投放等部门的具体工作。问:该如何预测?

二、业务预测模型,该怎么做?

业务预测模型,即把业务假设作为输入变量,预测业务走势的方法。这和算法模型不同,算法模型的输入特征,常常是没有业务含义的,因此无法指导具体业务操作,业务预测正是为弥补这个缺憾而设计。

比如本场景中,客户需求的最大影响因素,是客户本身的生产计划/我司与客户关系这两个维度。

但这两个维度很难拿到准确数据,如果是中小型客户,很有可能根本就没有生产和采购计划,他们自己就是风雨飘摇,有单子就做。如果是没有签框架合同的大型客户,每一期采购都得重新走招标流程,很有可能被其他供应商半路截胡。因此如果想直接从两个方面进行预测,是很难下手的。

此时要做的工作,分为三个部分:

第一:梳理业务流程,找可监控的数据指标

第二:梳理业务特点,区分稳定/不稳定因素

第三:梳理业务假设,输出预测结果

第四:跟踪预测结果,纠正过程问题

第一步:梳理业务场景

在本案例场景中,业务流程相对简单清晰,就是客户一手交钱,我司一手交货。但是不同类型客户的订单金额不同,交货难度不同因此可以分开考虑(如下图所示)

第二步:梳理业务特点

这一步是关键,通过对各条线业务特点的梳理,能找到其中每个时间周期内稳定因素/不稳定因素,稳定部分是预测的依据,不稳定部分是控制预测结果的手段。

在本案例场景中,就采购需求而言:

  • 签框架的大客户≥未签框架的大客户≥中小客户
  • 发展趋势好的行业≥发展一般的行业≥发展差的行业
  • 老客户≥老客户转介绍的新客户≥主动开发的新客户≥被动上门的新客户

因此,先把客户打上相应标签,再按不同标签类型分组看数据,就能计算出下面关键指标的数值,以及通过历史趋势观察其走势是否稳定。

  • 老客户的续订率
  • 老客户的续订金额
  • 新客户线索开发数量
  • 新客户线索转化率
  • 新客户首单金额

注意,这里有些因素无法直接量化,需要做转化。比如“行业发展趋势好”,至少有2种方法来确认:

1、数据法:对所有企业打行业标签,再查该行业统计数据,再看我司签约企业发展数据。

2、人工法:所有销售,定期回访新客户/拜访老客户,拜访时间必须大于5分钟,且回收数据。

该怎么选用方法?答:既然是业务预测,就优选业务能施加影响的方法,即人工法。因为用人工法收集数据,不但能收集客户信息,更能收集业务动作和业务判断能力这两个关键信息。

试想:如果销售连回访/拜访都敷衍了事、漫不经心,那还能有订单吗,肯定没有。因此衡量业务行动力,本身也业务预测的重要组成部分。

如果在这个过程里,发现某些业务部门就是:

  • 人员离职率高
  • 人员执行力差
  • 有效拜访次数少
  • 拜访和客户瞎聊一通
  • 反馈的判断十次错九次

那问题就很明显了:业务能力不行,导致业务不好。

这一点非常重要,同学们切记,既然要基于业务行为做预测,就要把业务行为考虑到底,不要试图掺杂一半业务考虑、掺杂一半数据自己计算,这样又把水搅浑了,很难评价好坏。

第三步:输出预测结果

有了清晰的分类,就能输出预测结果了。输出的方法很简单:

  • 有稳定参数的,直接套用
  • 没有稳定参数的,业务自己填预计参数

这样汇总计算出结果(如下图):

注意,业务自己填预计参数不是乱填,需要有依据。如图所示,明显违背发展规律的预计结果是无效的。并且这种行为本身也能成为模型的输入:业务方能力不足,不会评估自己能力及所需资源。

这样再给出业务预测结果的同时,也顺便给出了需要保证结果的假设,比如:

  • 假设1:XX行业客户需求不受出口汇率影响
  • 假设2:新线索转化率不低于5%
  • 假设3:业务执行有效性在90%以上

这些假设,可以直接作为跟踪阶段的考察指标,也能提前准备应对预案,这样即使发生一些小问题能直接纠正,发生大问题也能提前感知到,节省了跟踪和复盘的工作量。

第四步:跟踪预测结果

在实际发生时,可以基于预测假设,跟踪结果。

  • 当业务走势不好的时候,可以提前预警问题。
  • 当问题实际发生的时候,可以排查假设找到问题点。
  • 对于有应对预案的问题,可以直接启用预案解决问题。

这样就能很好的指导业务行动了(如下图):

注意,以上6种情况,只有客户预计外问题,属于预测失灵。为什么大客户打压价格这么重要的信息,居然没有提前预知,业务部门和数据部门都要反思。真碰到黑天鹅问题,很可能是客户内部人士变动或者对手下了黑招,此时确实会预测失效,但和预测本身无关。这些因素无法预知,此时只能在复盘的时候,再想办法。

三、业务预测模型,优势与不足

业务预测模型最大的优势,就是能彻底终结:“到底是预测不准,导致业绩不好;还是业绩不好,导致预测不准”这个鸡生蛋、蛋生鸡的问题。它明确地告诉大家:就是因为业务没做好,所以才预测不准!

并且能很细致地告诉大家,是因为以下业务原因,导致业绩不好,从而指导业务开展。

  • 新客户线索跟进不到位
  • 老客户拜访不到位
  • 老客户没有申请优惠价格
  • 重点行业开发能力差

业务预测模型最大的劣势,在于预测依赖人的判断。因此,预测结果特别受团队士气的影响。

一般团队士气高涨的时候,给出来的预测数值偏大,给出的纠错能力评估也偏大;团队士气低落的时候,给出来的预测数值偏小,纠错能力压根就不存在。过于偏激的判断,会影响模型的落地执行,从而达不成效果。

因此业务预测和算法预测,两者都不宜偏废。算法模型可以基于过往发展趋势直接给出个整体数据,所以用来辅助判断:当前业务方是高估/低估了局面,从而让领导层在施展管理手段的时候有依据可用,敲打业务部门做出正确判断。

业务预测模型适宜用在业务方能主动施展影响,改变结果的时候。但有些场景,业务方是被动接受,比如客服、售后、生产线等等。客户呼入,受促销活动、新品上市、广告宣传等诸多影响,偏偏这些影响一个都不是客服能控制的。此时就不适宜使用业务预测模型,而是算法模型,直接估算下个月话务总量,来评估人力安排。

本文由人人都是产品经理作者【接地气的陈老师】,微信公众号:【接地气的陈老师】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。