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

推荐订阅源

U
Unit 42
K
Kaspersky official blog
L
LangChain Blog
有赞技术团队
有赞技术团队
V
Visual Studio Blog
T
The Blog of Author Tim Ferriss
Microsoft Azure Blog
Microsoft Azure Blog
Stack Overflow Blog
Stack Overflow Blog
美团技术团队
Vercel News
Vercel News
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
G
Google Developers Blog
宝玉的分享
宝玉的分享
月光博客
月光博客
爱范儿
爱范儿
The Register - Security
The Register - Security
S
SegmentFault 最新的问题
M
MIT News - Artificial intelligence
F
Full Disclosure
Engineering at Meta
Engineering at Meta
阮一峰的网络日志
阮一峰的网络日志
Hugging Face - Blog
Hugging Face - Blog
A
About on SuperTechFans
WordPress大学
WordPress大学
D
Docker
Y
Y Combinator Blog
N
News and Events Feed by Topic
P
Proofpoint News Feed
Apple Machine Learning Research
Apple Machine Learning Research
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Recorded Future
Recorded Future
IT之家
IT之家
C
CXSECURITY Database RSS Feed - CXSecurity.com
Security Latest
Security Latest
Spread Privacy
Spread Privacy
D
Darknet – Hacking Tools, Hacker News & Cyber Security
F
Fortinet All Blogs
AWS News Blog
AWS News Blog
C
Cyber Attacks, Cyber Crime and Cyber Security
P
Proofpoint News Feed
C
CERT Recently Published Vulnerability Notes
D
DataBreaches.Net
Recent Announcements
Recent Announcements
博客园 - Franky
Google DeepMind News
Google DeepMind News
小众软件
小众软件
B
Blog RSS Feed
I
InfoQ
Attack and Defense Labs
Attack and Defense Labs
云风的 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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
销售行业团队管理列表浅析
泡沫opt00 · 2025-01-20 · via 人人都是产品经理

在本文中,作者分享了销售行业中团队管理列表的设计思路和流程,供大家参考。

第0步  明确分析对象

【备注】产品的某功能

要做的重点功能: 

团队管理列表

选择原因:

现有平台业务是辅助地推销售团队进行终端设备售卖,所以平台的用户主体主要为地推销售人员。而销售的KPI一定是与整个团队的展业数据挂钩,所以团队管理列表的重要性是显而易见的。

期望收获:

能通过团队管理列表,帮助用户对下管理、了解销售重点,协助团队完成更高的销售业绩

功能介绍:

1、功能全称:地推销售团队管理列表

2、功能简称:团队列表

3、功能概述:协助用户在移动端设备上,通过直观、有效的数据,快速了解团队实际展业情况

4、功能面向的用户

  • 用户A:已经少量下单采购设备,并有个位数下级地推销售,且自身也会做地推的代理
  • 用户B:已经大量下单并需要进行招商分销的区域代理
  • 用户C:平台市场部员工
  • 用户D:平台老板

5、用户使用功能的场景

(1)用户A

ⅰ. 关注下级当日、当月的总展业数据,用于了解下级的工作状态

ⅱ. 关注下级在各个产品细类上的销售情况,用于了解下级对各类产品的关注度

(2)用户B

ⅰ. 用户A的全部场景

ⅱ. 关注下级当前已采购设备情况,用于了解是否需要引导下级补充采购或协助销售

6、功能细节

  1. 展示自有团队内全部直属下级
  2. 按照当月展业数据,倒序排列
  3. 列表进行分页,每页10条数据
  4. 列表内支持根据下级姓名、手机号、唯一编号进行搜索
  5. 提供按照产品细类、展业

第1步  创新的上一个版本

【备注】研究分析对象,找到对应的主流功能是什么

上一版的功能是什么:

功能名称:团队管理列表

功能描述:支持查看直属下级,展示固定的展业数据。仅支持单一数据类型的倒序排列。

创新功能是什么:

1、功能名称:团队量化专区

2、名称阐述:

当我们要对销售岗位进行考核评定,看其是否达到了我们想要的结果时,那就必须要有一套衡量标准, 而这个衡量标准就是用销售的展业数据量来具化。

因此,把这些能用来做量化的展业数据集中起来,并用作销售团队管理时,我们称之为团队量化专区

3、功能描述:

(1)增加多维度的快捷筛选,根据不同体量的代理,设定了不同的筛选类型,并支持自定义更改关键展业数据的关键点变量

(2)新增了多数据类型的筛选类型,并支持正序和倒序

第2步  对比分析

【备注】上一个版本和创新版本,将两个版本的差异进行记录

第3步  选择差异点

【备注】对最重要的差异点,阐述原因

差异点名称:按用户状态快捷筛选

重要的原因:

相较于提供排序、取消无数据日期/月份的展示而言,他们都是在提供一个管理抓手之后的锦上添花,而用户状态的快捷筛选,则是管理抓手真正的切入口,为平台、管理者更能带来实际的利益。

1、降低平台管理成本

平台因为管理成本、沟通沟通等多重问题,不便对一线销售直接管理,所以需要分化出团队管理者充当平台与一线销售之间的管理媒介,对应协助管理者向下管理便是变相降低平台管理成本;

2、提升团队管理者收益转化率

团队管理者的收益核心来源于下级销售的展业情况,当一个团队管理者有团队,但管理不善时,则不足以保证一个管理者的有效收益,所以需要支持管理者更便捷、更高效的向下管理,以保障管理者获得更高的收入;

3、协助扩大团队管理者的收入来源

一线销售能够有良好的业绩,一定离不开一个会管理、懂扶持自己的团队长,所以支持团队管理者更有效的管理团队有助于其壮大自身团队的规模

第4步  分析差异点

【备注】谁是差异点的受益主体,对应获得了什么价值

差异点名称:按用户状态快捷筛选

差异点的收益主体:团队管理者

受益主体获得的价值:

差异点的本质是在团队管理列表中提供对一线销售人员各关键维度的指标化快速筛选。

对于团队管理者来说,用户状态筛选功能,是提供一键化找到团队问题切入点的能力。即一键化代表管理者得到了缩短管理团队的时间,提升管理效率。协助管理者找到问题切入点则代表管理者获得了更加精准找到团队问题的能力。

第5步  分析受益主体

【备注】为什么差异点,会给受益主体,带来这些价值

团队管理一定是基于对团队内销售的了解,这种了解需要针对每位销售在实际作业中的真实情况(即大量的数据),根据一定的规则和条件来进行筛查、判断,其作业是否符合正向发展。但这个过程需要整理每位一线销售的作业数据,例如设备的采购、流转、售卖,设备安装成功后,C端用户的使用率、遗弃率、重购率等。这些数据的整理也是繁琐费时的。

但这些数据全部都在系统的工作流中有留痕,所以系统可以通过大量数据的对比和分析,知道哪些维度的数据是利于管理者向下管理的。

所以,在团队管理列表中提供了多个销售核心关键维度的筛选,能让团队管理者减少管理筛选思考,缩短管理者管理团队的时间。

各维度的筛选标题直接用对应的解决方案命名,则在协助管理者找到问题后,直接提供了解决的能力

第6步  分析客观事实

【备注】重新回到新旧方案进行对比,找到有明显变化的客观事实

在两个不同的产品方案中,存在以下几点有变化的客观事实

1、管理者在团队管理中所投入的时间较长、效率较慢

原始方案中,团队管理者需要自行通过微信沟通,来收集团队成员的各项销售数据,并需要自己使用excel等工具进行归纳、分析,少则几个小时,多则1~2天,有时需要了解最新动向,甚至会需要长期消耗大量的时间和精力。

而在创新方案中,团队管理者则可依靠系统已有的大量数据,外加高效运算的加持,仅需要不到1分钟的自定义筛选,即可得到想要数据,对比原始方案即能充分减少在数据归纳、分析应用上所用的时间。

2、未及时跟进出货的设备数减少

在原始方案的团队管理中,一般团队小则10来人,多则近百人,管理者没有工具加持,仅能依靠自己每日跟进团队成员的销售情况,来记录下级当前的出货情况,并借此来判断自己是否还需要给下级出货。但因为统计需要过程,难免跟不上实际销售情况,未能向需要补货的下级及时出货,导致出货设备数降低至50台/人/月。

在创新方案中,管理者可以通过系统大数据的实时响应,一键筛选出当下需要补货的下级,这样一来,管理者就能及时跟进补充出货,即能大幅度提高出货台数,预计可提高至100台/人/月。

3、采购后未及时销售的囤货量增大

当团队人数较多时,在管理上难免就会遗漏一些成员,而这些成员曾经也是花钱采货的一员,但因为原始方案未能协助管理者及时关注到这类成员的销售情况,导致采货又不消货的囤货量上升至1万台左右。

而在创新方案中,管理者同样可借助系统大数据的实时响应,立即得到有采购,但未能销售出货的下级,这样管理者可以及时跟进该类成员的情况,并辅助解决,即可影响囤货量有效降低。

第7步  定性问题

【备注】重新判定哪一个客观事实,是主要问题

在原始方案中,已知有3个客观事实,而在3个客观事实中,又可从实际影响及可能带来的后果,外加相对紧急性来对比哪个更为主要。

  1. 客观事实A:管理者在团队管理中所投入的时间较长,导致效率较慢。主要影响的是管理者本身,因为管理分析时间较长引发效率较慢,管理者不能做到实时跟进每位成员,则会让部分成员认为管理者不能给予团队帮助而有抱怨。
  2. 客观事实B:因未能及时跟进需要补货的团队,导致每月人均出货数降低。主要影响需要补货的团队不能及时得到出货支持,直接导致团队不能更多的售货,团队和平台也会失去更多的销售利润和现金流。
  3. 客观事实C:出货后有滞销情况未能及时协助解决,导致囤货量上升。主要影响的是采货人本身,采货需要资金投入的,但滞销就意味着资金无法迅速回流,则采货人就会面临长期承担垫付成本的压力,也间接会让平台失去一个有好的现金流的采货人。

将3个客观事实共同比较,在影响涉及方面,客观事实A影响的是管理者,可对于管理者来说效率慢并不等于不管理,只是相对部分成员慢。客观事实B的影响不仅是管理者,还有平台,而涉及影响到的是管理者和平台既得利益的直接损失。客观事实C主要影响涉及的是采货成员,间接影响的是平台,采货成员的回款周期拉长,是采货人直接的利益损失,而对于平台则是丢失可采货人的长期损失。

所以通过影响、结果和相对紧急性来看,客观事实B最为重要,其次是客观事实C,再者是客观事实A。

第8步  定性结果

【备注】这个问题在创新功能里,是什么样的结果

在创新功能中,系统为团队管理者提供了对大量数据高效运算的能力,仅需要管理者根据自我需要进行自定义筛选,则可在短短数秒内一键得到分析后的数据,让管理者可以做到实时关注需要各类展业帮助的下级代理。

第9步  激活自己的积累

【备注】是什么样的底层原因,导致了变化的产生

由原始方案到创新方案,让管理者的管理时间缩短,效率提高,底层原因是因为平台系统通过多年积累,拥有大量各类情况的数据,而大量的数据可以关联历史相似的情况从而发现其中的规律,即各类情况的趋势。外加实时的数据追补,能让我们在已有的分析上进行动态调整,最终提供更快更准确的决策。

第10步  寻找证明材料

【备注】找有背书的研究结论,来佐证思考结论

数据的大量积累一定可以对后续的判断带来一定的预见性。

来自政法大学一篇关于《大数据预测能力对公共决策的影响》学术报告中就有阐明。决策的内容往往是面对综合的复杂性问题就行决策,那么就需要各类不同层面的信息就行辅助判断,而自身已知信息又不足以进行准确、全面的判断,所以,大量数据的挖掘、积累、分析,可以让有相同特征的数据建立更加紧密的关联性,而这类关联性即可以帮助决策者做出一定的预见性。

例如,全球知名的零售业巨头沃尔玛也会运用大数据技术对销售数据进行挖掘与分析。他们收集了所有门店的商品销售数据,及对应购买人的顾客信息、购买偏好等,在这个过程中就通过数据发现了一个有趣的场景,如果是男性顾客来购买婴儿尿不湿的时候,通常会顺便搭配几瓶啤酒一同结账,这一数据上的发现让沃尔玛意识到婴儿尿布与啤酒存在一定的关联性。于是他们调整了两种商品的货架的距离,让“顺便”更加顺手,结果则是尿布和啤酒的销量都有明显的提升。

所以对数据的大量积累、发掘,并对大量数据进行有效的分析,发现他们之间的关联性,就一定可以辅佐我们做出更多预见性的判断及决策。

第11步  收获与启发

【备注】整个思考过程的复盘

1、不用序列表达,改为标题分割

如果用序列的表达方式容易范式化,这种范式化的拘束会限制思维和表达的扩展,即序列式表达容易简化思考。

用标题分割的意图是先概述一个点的讨论核心,在针对这个标题(即核心)进行深度化、扩展化的思考和表达。更利于的问题的思考和探索。

2、认识到客观事实

之前对需求的理解仅是为了解决一个问题,现在理解解决问题的更深层次是客观事实的数值差异带来的情绪导向。例如空调有声音大小、温度高低、电费多少等客观事实数值上的变化,这些客观事实数值上的变化所带来的就是静音空调、匹数大小、节能空调等不同的需求。

3、每个单独项的独立剖析不能作为最后各单独项的综合比对判定依据

在第7步定性问题的思考过程中,一开始下意识的把每个单独问题项的剖析结果直接当做最后各个单独项综合评判、对比的结果,这个的确是不划等号的,因为各单独项的剖析仅能作为每个单独项的分析结果,就算把单独项的独立剖析结果用作合并比较,也一定会各有优劣,不能作为最终判定依据。真正的比对应该是看各个单独项的分析结果与当前期望的目标哪个契合度更高、更有性价比来做评判。

4、摒弃常识性理解

从认知A到认知B很多都是习惯性的认为“不就应该是这样的”常识性理解,总是不经大脑的没有过多、过深讨论的必要,但实际恰恰是疏忽了A到B的本质理解,而这个理解的过程,才是真正个人知识体系方法库的的底层核心,可以用作未来举一反三的基础。

5、找有背书的认知结果佐证自我认知

找他人的研究,尤其是有背书的研究结论,来证明自己的认知,是加深自己对认知的理解,而且在这个过程中,极大可能会是对该项认知进行更多扩展的一种重要途径。

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

题图来自Unsplash,基于CC0协议

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