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

推荐订阅源

Last Week in AI
Last Week in AI
D
DataBreaches.Net
腾讯CDC
Recent Announcements
Recent Announcements
有赞技术团队
有赞技术团队
A
About on SuperTechFans
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Google DeepMind News
Google DeepMind News
Microsoft Security Blog
Microsoft Security Blog
云风的 BLOG
云风的 BLOG
罗磊的独立博客
月光博客
月光博客
MyScale Blog
MyScale Blog
U
Unit 42
Martin Fowler
Martin Fowler
Stack Overflow Blog
Stack Overflow Blog
T
Tailwind CSS Blog
Engineering at Meta
Engineering at Meta
N
Netflix TechBlog - Medium
G
Google Developers Blog
博客园 - 【当耐特】
D
Docker
I
InfoQ
雷峰网
雷峰网

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
销售转化模型分享——10X增长落地案例(浅谈CRM/SCRM产品设计注...
Allen · 2024-05-14 · via 人人都是产品经理

本文分享了作者经历过的一个10倍增长的案例,以及其中碰到的问题和解决方法,适合正在做和想要做B端产品经理或商业化产品经理的同学,以及在线教育行业从业者阅读。

VIPKID、DD英语、新东方在线你是否听过?还有好未来、猿辅导、有道,以及思维类的火花思维、豌豆思维、核桃编程、西瓜创客、编程猫、编玩边学、小码王,曾经暴雷的妙X程、贝X编程,以及后来加入的字节大力教育等。

那是一个时代,教育行业是各大广告平台的金主爸爸,资本的疯狂,让很多在线教育公司短时间从零到 过亿体量。很多公司归零,但也有一些产品力比较强的健康的公司,活了下来。

个人希望以一线从业者的视角,还原当时对产品设计和商业模式的思考。由于年代久远且涉及相关在职人员,将采用部分化名,大家当看个故事就好。

我是18年加入编程猫,那时公司才100多人,也是亲身经历了公司的飞速发展,公司从100多人增长到了最高峰有4000多人,营收也是从百万到过亿的增长。

加入时产品总监ZC也是刚入职,我是他招聘的第一个产品经理。

岗位定位是B端产品经理,主要负责CRM系统的搭建。

下面会分享我们实操的一个10倍增长案例。

第一个坑 数据治理

当时其实还没有数据治理或数据管理的概念,只知道很多重要数据都是人工用Excel表格统计的,有过这方面经验的产品就知道什么情况了。

实操建议——梳理数据口径,对齐核心指标

要梳理数据指标,首先要理解业务。当时公司分市场投放部门和销售部门,在数据指标定义上可能会有一些模糊和扯皮。

梳理视角:要求数据管理者需站在公司整体经验和战略角度,而不是单个部门的立场角度。

1. 企业组织架构

先介绍大的框架,不同公司有不一样的组织架构,但一定有负责背营收指标的部门,而这个指标大概率落到营销部门或销售部门身上。

具体案例:如投放部门和销售部门都对营收KPI负责,而投放部门要关注的不仅是线索数量,还有线索质量,也就是我们定义的“有效线索”。

2. 商业运营模型

如传统企业偏电销模型,互联网企业偏网络营销模型(公域和私域),但都可以归结为对流量的转化。

后文统一按【流量——销转——交付】体系。

图源:Kimi对流量销转交付体系来源的回答,知道的朋友麻烦告知下

为保证本文输出质量,只能对流量模式和交付模式略过,重点拆解销转模式。

流量模式:一般分为做流量、换流量、买流量、裂变转介绍。

交付模式:可分为轻交付和重交付。

销转模式:引用许毅松老师的话来说:

在流量–销转–交付这三个环节中,销转体系可以说是整个链条里面最核心的一环。流量端各家的投放成本会趋于一致,交付环节,大家也都能做到合格线以上,同时很难做出差异化,而基于自身产品特性的销转体系的打磨最考验组织能力,销转环节1%转化率的差异就能决定整个模型是否能跑通

许老师,公众号:少儿编程许毅松争取一次讲清楚在线教育公司的扩张路径和组织模式

1)电销模型图例

(注:在企业内TMK和CC可合为同一岗位)

图源:这图存了有点久了,未找到来源

2)网络营销模型:网上报过课的应该都有了解,不管是微信还是小红书引流,会有体验课老师或成交顾问加你,持续给你深化认知完成转化。

对应的模型有AARRR模型、RFM模型等。

图源:搜狗百科

3. 运营管理和销售管理

这一点为什么要单独拿出来说?因为这里涉及人员管理和绩效考核的大坑。如当时行业内小范围比较出名的XX英语刷单,销售人员都是拿提成的,而提成是阶梯激励的,是否跳点对销售人员的收入影响很大。

这时就有一个“聪明的”销售,他发现了管理机制上的漏洞。如果先刷单,等拿到足够多的提成,再离职跳槽是不是能赚更多钱?

而且销售的管理是分层的,比如分为主管、组长、组员,一般组长的绩效和该组挂钩,主管的绩效和分管的组挂钩。

销售为了利益最大化,可以互相刷单,骗取提成后再提离职。

所以行业内由于有这个经典案例,对销售提成的发放加了一些限制,如延后发放、退费倒扣绩效等。

还有投放部门如果只考核线索数量,也有很多买量的手段,具体就不说了,本文还是来分享干货的。

从风控和管理角度,管理机制既要考虑激励作用,又要避免管理漏洞规避风险。

第二个坑 CRM产品架构设计

1. 用户预期管理

具体案例:

公司原来用的是外采的销售易SaaS系统,后来目标是公司自建CRM,尽快在SaaS系统续费前替代销售易。

而我的初版方案基于实际调研,当时销售部门要完成整个约试听流程需要至少10个步骤并横跨多个系统模块(旧系统),我们的V1.0版本能解决这一问题,但我希望做好业务部门的预期管理工作,所以再三和负责人确认是否要切换V1.0版本的CRM系统。

基于业务负责人的承诺,业务开始切换,并且收到了一线人员的好评。但逐渐我们就被更多需求淹没了。

总结:虽然创业公司资源限制,需要小步快跑快速迭代,但我在预期管理中还是有一定失误的。

2. 转化率提升成功案例

销转体系应该如何设计才能提升10倍、100倍转化率?

具体案例:

原来对于销售线索(Leads),是销售负责人在手动分配线索。而随着公司规模扩大,需要设计一套线索流转方案。

框架上我按“策略——规则——方案”拆解。

1)策略

人工分配的策略是怎样的?系统分配有什么优势?

2)规则

规则应该怎么制定?如何兼顾效率和公平,提升转化率?——涉及管理学和心理学。

3)方案

基于“数量公平、质量有区分”的原则设计,即好的线索优先给到好的销售转化,以提高整体转化率。

方法论:多看多聊,一个是竞品调研和行业调研,一个是和行业内和一线人员去聊,有些系统不对外介绍的话,能拿到操作手册也是很好的参考资料。

对比人工:规则透明,且更有时效性。

线索分区:私域(或者叫私海,个人库)、公海、藏金阁(参考了英语和保险行业CRM的设计,藏金阁线索优于公海,属于个人库未完全利用资源)、冻结库(强烈表示不要再联系的客户)、新线索(只要用户重新预约,就会进入新线索池子)

分配时机:如一小时触发一次。

销售排名的结构设计:按上下金字塔分布,保证上下流动性起到激励作用,如资源一般或同样的资源做的比别人好,需要浮上去;更好或同样的资源做的比别人差,需要沉下来。

线索质量如何评分:按维度和权重评分(如渠道来源、地区维度)

销售如何评分:即排名(如成交转化率、成交金额)

具体还有新线索配置和销售新人保护期策略等,就不展开讲了。

算法如何设计:当时还没有AI助理可以查,我主要是自己琢磨还有和研发沟通。主要分3个步骤:

  1. 计算每个人的预分配数量(确保数量公平)
  2. 预分配决定哪些leads给哪些销售(确认质量有区分)
  3. 实际分的时候填格子(播种),记录位置,比如C少一个,则下次分配从C开始;

如何监控效果:做了一些可视化监控报表

落地效果:整体转化率100X的提升(可理解为若人工分配只有万分之一转化率,系统分配策略能到百分之一转化率;并且当时公司最高4000多人有四分之一是销售,每天的新线索量还是很大的)。

总结:其实整套设计没有什么值得吹的地方,还是基于商业逻辑和业务常识来做优化,并且也是5年前的案例,现在依靠AI理论上能做的更好。

后续我们也做了智能外呼的尝试,与猎户星空合作了真人录音电话等,在机器人电话普及前享受了一定红利期。

3. SCRM案例

场景:公司是直播课起家,后来录播课作为第二增长曲线,涉及录播课业务如何支撑的问题。

方案设计:底层数据互通,录播课系统基于录播课私域业务设计,支持SCRM功能。

这里涉及一个做私域运营都会面临的问题:拥抱企微还是继续个微?

个微的优势是便于做转化,风险是容易封号;

而企微当时涌现了很多服务商,如微盛、尘锋、卫翎、微伴等,有数据监控等功能,看起来要全面替代个微;

但我们实际试用下来的判断是企微还是替代不了个微,因为目前私域的重心还是线索培育,而企微生态还在建设中,SCRM更像企微的第三方插件。

所以我们当时采用个微培育客户,企微售后交付的做法,目前看几年后目前业内的主流做法也是如此。

纯企微私域基本做不起来,并且线索培育是一套SOP的管理,基本逻辑是内容——触达——转化,本质还是做SOP管理,走内容为王的路线。

说白了我们还是优先把数据管起来,分析发哪些内容,什么时候发更有效果。

还有一个就是保证服务质量的情况下,扩大班主任的服务半径,在我另一篇文章中有提到AI自动批改作业的案例。

全篇总结

总的来说所有行业的最终逻辑是要赚钱。

教育行业和SaaS行业的获客模型都可以用CAC(获客成本)与LTV(客户生命周期价值)来衡量。

一个简化的 ROI 公式可以表示为:

ROI=(LTV−CAC/CAC)×100%

两者都很重视续费率指标。

差别在于教育行业的核心指标还包括完课率,以及素质教育普遍面临的行业标准与效果外化的核心问题。

而SaaS行业更关注确实为客户解决了什么问题,能否跑通让客户赚到的钱>客户付给SaaS公司的钱>SaaS公司的成本这一核心商业模式。

致谢:感谢当年ZC、DY、YM、GS、LZM的支持。

参考资料:

1、争取一次讲清楚在线教育公司的扩张路径和组织模式

2、“少儿编程”不只是新奥数,而是新英语|初心行研

本文由 @Allen 原创发布于人人都是产品经理。未经作者许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。