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

推荐订阅源

C
Check Point Blog
H
Help Net Security
B
Blog RSS Feed
Microsoft Security Blog
Microsoft Security Blog
阮一峰的网络日志
阮一峰的网络日志
Engineering at Meta
Engineering at Meta
The Register - Security
The Register - Security
U
Unit 42
Hugging Face - Blog
Hugging Face - Blog
雷峰网
雷峰网
酷 壳 – CoolShell
酷 壳 – CoolShell
IT之家
IT之家
云风的 BLOG
云风的 BLOG
腾讯CDC
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
D
Docker
T
The Blog of Author Tim Ferriss
Recorded Future
Recorded Future
月光博客
月光博客
H
Hackread – Cybersecurity News, Data Breaches, AI and More
罗磊的独立博客
G
Google Developers Blog
Jina AI
Jina AI
P
Proofpoint News Feed
J
Java Code Geeks
I
InfoQ
博客园 - 司徒正美
D
DataBreaches.Net
博客园 - 叶小钗
F
Fortinet All Blogs
The GitHub Blog
The GitHub Blog
Google DeepMind News
Google DeepMind News
L
LangChain Blog
博客园_首页
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
S
SegmentFault 最新的问题
Apple Machine Learning Research
Apple Machine Learning Research
博客园 - Franky
人人都是产品经理
人人都是产品经理
V
V2EX
F
Full Disclosure
A
About on SuperTechFans
Stack Overflow Blog
Stack Overflow Blog
Martin Fowler
Martin Fowler
MongoDB | Blog
MongoDB | Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
美团技术团队
V
Visual Studio 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混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
从电商客服接待谈一谈分流的部分设计机制
晌午 · 2023-03-20 · via 人人都是产品经理

河流分流给各个村庄,在电商中,当所需要接待的消费者过多,也可以进行分流,减少消费者咨询堆积出现的情况。本文就分流现象与大家探讨在“电商接待”在实际业务中的意义与表现,总述其分流管理机制。

分流起初是一个水文学上的专有名词,河流从上游到下游的过程中,随着下游地势平缓会从干流中分出多个水道,通常发生在下游平原或出海口地区。

这就是一个分流,是发生在自然界中的一种现象,我们也会利用河流自由分流或者人工挖掘创造分流来将上游水流量分散到不同的水道,有效减轻下游水流量集中而带来的洪涝压力。

水从上游分散到下游各个河道的流动过程,生动地解释了分流这个过程及其导致的结果。尝试对分流做出抽象的定义,分流就是元素在通道中从上游到下游运动时,被分散到多个下游通道的过程。

这个定义中也蕴含了分流解决问题的方法,分流所解决的问题是元素积累量越来越多而导致的下游承接压力,例如河流的洪涝压力就是指水流量越来越多的积累最终在下游水道酿成洪涝灾害。而分流通过在下游提供了多个通道将上游运动而来的元素分散开了,解决了元素积累压力。

我们可以通过假设一个案例来解释:

河流途经村庄 A,村庄 A 附近河道最大可承接水量为 800,但是由于村庄 A 所在地区连日来大雨天气,导致河道蓄水量已经达到 1000,并且伴随有溢出趋势。这就导致了村庄 A 附近河道存在溢出风险,随时可能会冲毁堤岸,毁坏河道沿途的农田和房屋,给村庄 A 带来极大的洪涝风险。

为解决这个问题,在村庄 A 附近河道处开挖新河道来承接水流量,新河道承接水流量为 500,这时候河道经过村庄 A 时,1000 的水流量分别被原有河道和新开挖河道承接(两河道最大承接量 1500),妥善解决了洪涝风险。

分流不仅仅是一个自然界的现象,在我们社会活动中,很多问题或者现象也符合分流运动,可以由分流来解决问题,例如消费者进线咨询就是一个典型的通过分流解决问题的社会现象。

假设没有分流,大量消费者涌入咨询时只能由 1 个客服承接,客服服务消费者的效率低下,大量咨询被堆积排队得不到解决。

开启客服分流后,就可以有效地将大量消费咨询这个累积的事物分配给不同客服,减少消费者咨询堆积出现的情况。本文就想和大家一起讨论分流现象在“电商接待”这个实际业务中的表现和意义,以及讨论部分摸索出来的分流管理机制。

一、为什么要管理分流

在开始讨论分流管理机制前,我们首先要讨论为什么分流现象需要管理,分流如果不加以管理的话,会产生一些怎么样的现象和影响。

分流如果不加以管理会产生巨大的危害。分流解决了元素在通道中运行过程中的堆积问题,当元素在通道某一位置被大量积压,超过了该通道的元素最大承接量,通过在该位置增加或扩展出新的通道以形成分流现象来释放积压的元素,以减轻该位置的元素积压量,解决元素堆积问题。

当我们不对分流加以管理时,为了解决元素堆积问题,通道会自发的寻找或形成分流现象。自发分流指的是当通道承接量超过最大值后,为了避免整个通道的毁坏,会自发形成新的通道。

自发分流虽然属于一种通道的自我保护或代偿机制,但是自发分流下产生的新通道通常是无序且不可控的,如果出现在了不合适出现通道的位置,会造成元素的大量流失,并对新通道所在地产生危害。

以河流的分流为例,如果我们不施加人为影响的话,当面临洪涝压力时,河流为了缓解当前河道的水流压力,会自发的形成分流。受到地势差异的客观条件和河流从高到低流动的自然现象,河流会流向地势较低、较平坦的位置来解决水流量堆积问题,这就造成河流改道现象。

而地势较低、较平坦的位置通常是平原等地区,河流改道平原会造成严重的经济和自然上的负面影响,历史上黄河流域就发生过多次河流改道,改道导致了周边地域家园被毁、良田冲毁、流离失所的情况,造成了经济上和生命安全的严重损失,更有甚至间接动摇或推翻了封建王朝的统治。

在我们设计的产品中,也会发生自发分流的现象。这种自发分流通常表现成业务环节因使用者的一些天性和特点朝着我们不希望出现的环节发展,如果不设计相应的机制对分流作出管理和约束,就会造成了错误的流程,导致了元素的流失。

像是我们今天要讨论的客服接待场景,是一个符合分流现象的典型社会现象,将消费者进线咨询的客服比作是一个元素在通道中运行的过程,元素就是消费者,通道就是具体的一个个客服。因为人对等待的厌烦感会导致消费者优先选择空闲的客服,就像银行柜台如果没有叫号机制的话,大家都会选择空闲的窗口。

消费者流向空闲客服的自发分流现象,就会导致空闲客服在短时间内涌入大量消费者,造成该客服突然的爆线,使得大量消费者囤积在某几个具体的客服中,拥堵进一步使得消费者因厌恶等待而离开,离开的消费者往往有问题没有被解答,只有咨询的问题被解决才能使消费者作出后续的决定购买、放弃购买等动作,影响了消费者的下一步动作被中止,潜在购买的人群流失了。

客服接待的业务环节朝着我们不希望发生的环节发展了,这就使得我们需要对消费者进线咨询客服的这个现象作出分流管理,人厌恶拥堵的天性难以改变,但我们可以通过分流管理,降低出现拥堵排队的现象,从而使得消费者作出完整的动作,作出下一步买或不买等的动作。

自发分流除了造成元素的意外流失,降低元素的使用率外。自发分流还不利于我们对元素的管理,具体的表现为对元素的定向分类和过滤使用,因为分流的本质是多个通道对元素的承接,因此我们可以通过形成特定的通道来将元素划分为多个子集,让每个通道中的元素是一个符合共同条件的集合。

而自发分流形成的通道是无序的,也就不具备了对元素做出特定筛选的条件,形成的通道中的元素不是以我们期望的条件聚合的,甚至有可能是多个不同元素的混合。

在自然现象河流分流中,自发形成的分流因为通道自身的条件使得人们往往无法对该通道内的水资源进行利用,例如分流出去的河道水流急促,而人为挖掘的河道可以满足平缓等条件,用于灌溉和生产活动。

同样的,在客服接待消费者场景下,人为管理的分流可以将咨询的消费者划分出不同类型,比如简单的划分出了售前咨询和售后咨询,有针对性的客服分别承接了不同的咨询更有利于问题被针对性的解决,而自发分流反而会导致售前咨询流向了对售后问题更加了解的客服,这就降低了问题解决率。

自发分流存在的巨大危害,导致我们需要对分流做出管理,有效的分流管理不仅可以解决元素在通道内积压的问题,更可以对元素进行充分的过滤和筛选,促进了元素的多样化、合理化使用,产生丰富的收益。

二、如何管理分流

分流是元素从上游到达下游的过程,我们管理分流的出发点就是希望元素在上游到下游的流动过程中可以被更合适的下游通道所承接,我们在设计分流机制时就需要考虑从这个基本准则出发。本文就想和大家讨论下 2 个管理分流的机制。

首先什么是分流管理,分流管理就是人为的介入元素在通道中运行过程,通过建立特定新通道、对下游通道做出定向改造等方式。使得元素可以按照人为预期,流向特定的通道以实现对元素的特定使用。为了能达到这个定向触达的过程,我们需要通过对“元素做穷举分类”和对“通道做分类改造”。

机制1:对元素做穷举分类

在自然现象的河流分流中,水资源就是元素。我们也可以根据一些水的特征做分类,比如根据水的流动速度,某一段水流湍急,某一段水流平滑;根据水的泥沙含量,某一段水泥沙含量大,某一段水泥沙含量小等。

当我们对水资源做了充分的穷举分类后,我们才好知道水这一元素的整体情况,才可以更好的准备承接的河道,充分利用水资源。

而在我们的产品设计中,产品的服务对象是人,人通常是复杂而又多样的,不同的人会存在不同的想法,同一个人也可以划分为多个不同的片段。因此我们的用户作为一个元素在产品这个通道内流通的时候,对其做穷举分类变得更加具有意义。

那么在产品中,什么是对元素的穷举分类呢,总的来说就是对目标用户做场景分析,其中穷举指的是面对我们的目标用户,在目标用户这个范围内尽可能罗列出存在的所有行为;分类指在罗列出的场景中进行排列组合,对相同的行为归纳出场景。最终帮助我们了解到对于目标用户行为有一个清晰和正确的认识。

一起来看一个案例。店铺 A 日常平均一天会进线 100 个消费者,客服主管没有对消费者进线的问题做过穷举分类分析,拍脑袋地认为了来咨询的消费者都是咨询商品价格。

从而只针对客服做了商品价格问题方面的培训,而实际接待过程中,发现有相当一部分消费者进线来咨询的是商品使用的,由于对客服没有经过系统的培训,导致无法解答或正确回答消费者的问题,最终造成了严重的客诉事件。

这里就是对于元素-消费者咨询不够了解导致的,我们对消费者咨询这个元素作穷举分类:

第一步穷举场景,对消费者咨询可能存在的问题做出穷举。

咨询商品价格、咨询商品特征、咨询商品活动、咨询发货快递、咨询商品退款、咨询商品使用、咨询保价、咨询退运费……(不再继续赘述)

第二步分类场景,对问题找出共同点归纳总结。

这边我们可以归纳出咨询发生在订单产生前,包括咨询商品价格、咨询商品特征、咨询商品活动、咨询发货快递,总结为是一个售前咨询场景;

咨询发生在订单产生后,包括咨询商品退款、咨询商品使用、咨询保价、咨询退运费,总结为是一个售后咨询场景。

通过穷举分类能发现,消费者进线咨询可以总结出售前和售后两个大场景,因此我们在客服培训的过程中需要对他们作出全面的培训,这样才能更好的回答消费者咨询的问题。在功能升级上也要设计对应的功能,让消费者咨询这个元素在通道内顺畅流动,设计对应的功能,就是我们的机制 2 部分。

机制 2:根据场景对通道做分类改造

在对元素充分做出穷举分类后,我们就可以对通道做分流改造。为什么要这么做呢?因为通道本身存在一些缺陷,包括通道条件和元素承接所需条件不匹配;通道本身存在一些通道太小、通道破旧等自身问题。
这些通道缺陷会导致承接不住元素或者对元素承接后的利用率低。当我们充分了解元素后,就可以能对照元素特点,改造通道,从而达到承接元素,提升元素利用率的效果。

自然现象中,通道的缺陷常表现为通道本身在条件上的不足,像是河流无法承接超过一定量的水流就是河道本身的蓄水量条件有限。那么通道缺陷在产品上呈什么样的表现呢?一种表现为流程上的缺陷,用户在产品中的使用流程就可以类比元素在通道上运动,流程设计有误就是通道本身存在问题,是一种通道缺陷的表现。

另一种表现为设计功能和流程不匹配或缺少流程所需要的功能,流程无误的情况下,没有设计与流程相对应的功能或为流程服务的功能,导致功能与流程不匹配,这也是一种通道缺陷在产品上的表现。

了解了通道缺陷在产品上呈现的方式后,我们应该怎么去解决这个问题呢?在机制 1 中我们提出,对元素按场景穷举是对元素的详细了解,这就为我们对通道做出改造提供了依据。

通道的分类改造就可以依此在产品上调整流程并设计对应功能,具体表现为根据元素穷举分类后总结出来的场景来对我们产品的流程做调整,不同的流程对应不同的场景,以此来设计合适的产品功能,做到有的放矢。

依旧是店铺 A 的案例,像是在店铺 A 的进线分流现象中,我们对元素作出穷举分类后,发现消费者的咨询可以分为售前场景咨询和售后场景咨询,具体的占比为 70% 和 30%。其中售前咨询和售后咨询的内容是不同的,可以通过是否下单来区分这个消费者咨询的场景是售前还是售后。

了解完这个场景后,在设计客服接待类产品时,我们就可以做出一下调整。

  • 增加客服类型,包括售前客服,售后客服。这里是对通道做出了调整,原来只有客服一个通道,该功能实现了对通道做到一分为二
  • 当有消费者咨询后,查看消费者仅 30 天内是否有订单产生,以此识别消费者咨询意图,并根据其意图分配给具体的客服

这里就是通过对消费者咨询这个流程做出了改造,从消费者咨询—>分配客服,改成了消费者咨询—>意图分析—>分配特定客服

更进一步的,如果我们对目标用户的行为,穷举的条件足够多,分类归纳的更细致,我们对产品流程的改造也会更全面。在对消费者咨询这个穷举增加了商品条件,最后分类组合得出了 A 类产品售前咨询、A 类产品售后咨询、 B 类产品售前咨询、B 类产品售后咨询这 4 个场景。

那么我们在设计客服接待类产品的时候可以增加,指定产品咨询分配给指定客服组的条件。

总之,对元素的穷举分类做的更全面,更细致,那么我们对通道的改造依据就更多,就能更细致的对通道作出特定的改造,进而通道就可以更精准地承接住元素,减少了元素在通道运行中的浪费,很好的提升了利用率。

从这里我们可以了解到,想要管理分流我们可以从对元素进行穷举,再对穷举后的场景作为分类总结,以此总结作为依据对通道方作出合适调整,使得资源利用率得到最大的提升。

通过一个案例再来回顾一下这两个机制:

公司 B 是一个汽车销售公司,现在有 10 名不同能力的销售,每天从该公司投放的广告中可以收回 100 个潜在消费者线索。现在需要设计一个规则把这些线索分发给销售。

这里也是一个典型的社会活动中的分流现象,潜在消费者线索分发给销售,就是一个从元素(消费者线索)在通道(销售)运动的过程,设计线索分发规则就是管理分流。

如果对分流不加管理,就会导致重要的客服资源分配到了能力不匹配的销售手上,从而错失了成交机会。

我们可以做出如下产品设计:

  • 对目标用户做出穷举分类:对元素(消费者线索)进行穷举分类后,从购买车型、购买预算、购买紧急度这 3 个角度出发穷举,并最终按 3 个角度的不同权重占比组合成 4 类消费者,分别为“H-A-B-C”,其中 H 代表消费者购买意图最高,A、B、C 消费者购买意愿逐次降低
  • 对通道(销售)做出划分,分类出高级销售标签和初级销售标签
  • 识别 H、A 两类消费者时,自动分配给高级销售标签的销售;B 类消费者时,分配给初级销售标签的销售;C 类不划分

一般来说越是重要的消费者就会派给能力强的销售,这样会更有利于重要客户的成交。这里我们就通过了一个简单的分配机制设计,帮助促成销售。

总结

分流现象在大自然和社会活动中普遍存在,是一个元素在通道中运动的过程。如果不对分流进行管理,会造成严重的负面影响,我们可以通过对元素穷举分类,然后在通道按分类场景做出调整,以达到更好承接和利用元素的结果,实现有效的分流管理。

专栏作家

晌午,微信公众号:晌午自习室,人人都是产品经理专栏作家。4年产品经验,专注于数据方向,目前是电商客服领域的产品 。

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

题图来自 Unsplash,基于CC0协议

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