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

推荐订阅源

U
Unit 42
博客园 - 司徒正美
V
Visual Studio Blog
博客园 - 【当耐特】
T
Tailwind CSS Blog
美团技术团队
博客园 - 叶小钗
Jina AI
Jina AI
宝玉的分享
宝玉的分享
IT之家
IT之家
Hugging Face - Blog
Hugging Face - Blog
雷峰网
雷峰网
Stack Overflow Blog
Stack Overflow Blog
博客园_首页
人人都是产品经理
人人都是产品经理
T
The Blog of Author Tim Ferriss
P
Proofpoint News Feed
Microsoft Security Blog
Microsoft Security Blog
Y
Y Combinator Blog
GbyAI
GbyAI
大猫的无限游戏
大猫的无限游戏
Martin Fowler
Martin Fowler
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
腾讯CDC

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
B端产品人可抄作业:标准型业务流程设计公式
三爷茶馆 · 2024-05-13 · via 人人都是产品经理

在上一讲中,我们通过案例分享了业务流程优化的几个步骤。这篇文章,我们继续分享一个案例,通过五个步骤,详细探讨如何设计一个标准的业务流程。

接着上一讲《业务流程优化:B端产品经理搞定产品规划的核心利器》。在B端产品中,由于是服务公司内部的信息化系统,如何让同一功能持续化发挥作用就成为在设计中绕不开的一个话题。

持续化发挥作用,用更通俗的话来讲就是如何设计一个高可复用的系统,而这发挥作用的前提就是我们要去设计一套标准的业务流程,这对于提升客户服务质量、优化内部运营流程至关重要。

下面,我们将通过五个步骤,详细探讨如何设计一个标准的业务流程。

一、5步走方法

第一步:寻找企业内共性的领域

作用与意义:识别企业中不同业务线之间可以共享的服务领域,这有助于减少重复工作,提高效率。

操作步骤:

  1. 调研分析:通过访谈的方式,收集不同业务部门的服务需求。
  2. 数据整理:将收集到的信息进行分类和整理,找出共通点。

通俗例子:就像一家大型超市,需要为不同顾客提供结账服务,通过调研发现,无论是购买食品还是日用品的顾客,都需要快速、准确的结账服务。

第二步:约谈该领域的各业务方

作用与意义:通过直接对话,深入了解各方的具体需求,为设计统一流程打下基础。

操作步骤:

  1. 准备会议:确定会议目的、参与人员和时间。
  2. 沟通协调:在会议中,让各方表达自己的需求和期望。

通俗例子:继续超市的例子,超市管理层会与食品部、日用品部等负责人开会,讨论他们对结账服务的具体要求。

第三步:设计统一化的该领域流程

作用与意义:创建一个标准化流程,确保所有业务方都能高效、一致地提供服务。

操作步骤:

  1. 流程设计:根据前期调研和会议讨论,设计服务流程。(参看上一讲业务流程设计)
  2. 模拟测试:在小范围内测试新流程,收集反馈进行优化。

通俗例子:超市设计了一个统一的结账流程,无论是哪个部门的商品,都按照这个流程进行结账。

第四步:约定各业务方运营路径

作用与意义:为不同业务方定制具体的运营路径,确保他们的特殊需求得到满足。

操作步骤:

  1. 定制化设计:根据不同业务方的需求,调整统一流程中的某些环节。
  2. 确认协议:与各业务方确认定制后的流程,并达成共识。

通俗例子:超市允许生鲜部门在结账时增加称重环节,而日用品部则不需要。

第五步:定义统一路径为该领域公司级标准流程

作用与意义:将经过测试和确认的流程正式定义为公司标准,确保长期稳定运行。

操作步骤:

  1. 文档化:将最终确定的流程详细文档化。
  2. 全员培训:对所有员工进行流程培训,确保理解和执行。

通俗例子:超市将统一的结账流程写入员工手册,并组织培训,确保每位收银员都能熟练操作。

接下来我们用一个模拟案例来看看具体如何使用这个方法去进行落地。

二、模拟案例

假设一家名为“环球科技”的公司,提供软件销售、技术支持和客户咨询等多项服务,在面对多样化服务的现状,公司希望建立通过数字化转型,以提升客户满意度和内部运营效率。

落地:构建标准化业务流程

第一步:寻找共性领域

环球科技通过内部调研,发现所有服务都涉及到客户信息管理、服务请求处理和售后服务三大环节。

第二步:约谈业务方

组织软件销售、技术支持和客户咨询部门的负责人进行会议,了解他们对服务中心的具体需求。

第三步:设计统一流程

基于会议讨论,设计一个包含客户信息录入、服务请求分配和售后跟踪的标准服务流程。

第四步:约定运营路径

为软件销售部门增加合同审核环节,技术支持部门增加问题诊断环节,而客户咨询则直接进入服务请求分配环节。

第五步:定义为公司级标准流程

将最终确定的服务流程文档化,并组织全员培训,确保每位员工都能按照新流程工作。

企业要求

·客户信息存储位置:所有业务线客户数据统一在一个地方存储(同库处理),后续所有服务都从这里调取客户信息。

·服务请求处理:建立一个内部服务请求系统,自动将请求分配给相应部门。

·售后服务:

  • 设立一个客户反馈系统,通过电子邮件或在线调查收集客户对服务的满意度评价。
  • 定期分析客户反馈数据,识别服务中的问题和改进机会。

通过以上我们可以得到一个设计好的完整流程就可以得到了,按照我之前在《中台产品经理》一书中提出的标准的流程描述公式:流程-节点-动作格式来进行描述,结果如下:

流程1:客户信息管理

节点1:客户信息录入

  • 动作1.1:收集客户信息,包括姓名、联系方式、服务需求等。(可系统化沉淀)
  • 动作1.2:验证信息的准确性和完整性。

节点2:客户信息更新

  • 动作2.1:监控客户信息变动,如联系方式变更。
  • 动作2.2:在客户信息内容中更新客户信息。(可系统化沉淀)
  • 动作2.3:通知相关部门客户信息的变更。(可系统化沉淀)

流程2:服务请求处理

节点1:服务请求接收

  • 动作1.1:通过多渠道(电话、邮件、在线表单)接收客户请求。
  • 动作1.2:记录请求的详细内容和时间(可系统化沉淀)

节点2:请求分类

  • 动作2.1:使用预设的分类规则进行服务分流,如售前将咨询服务转接到咨询部,售后转接到售后部。(可系统化沉淀)
  • 动作2.2:对于无法分类的请求,由高级售前人员进行跟进研判分类。

节点3:请求分配

  • 动作3.1:根据请求的类型和优先级,自动分配给相应的处理团队或个人。
  • 动作3.2:通知被分配人,提供请求详细信息。

流程3:问题诊断与解决

节点1:问题诊断

  • 动作1.1:技术支持人员复现客户描述的问题。
  • 动作1.2:利用诊断工具和日志分析问题原因。

节点2:解决方案提供

  • 动作2.1:根据诊断结果,从知识库中检索或制定解决方案。
  • 动作2.2:与客户沟通解决方案,获取反馈。

流程4:合同审核与签订

节点1:合同审核

  • 动作1.1:法务部门检查合同条款的合规性。
  • 动作1.2:确认合同中的价格、服务范围和交付时间。

节点2:合同签订

  • 动作2.1:将审核通过的合同发送给客户进行电子签名。
  • 动作2.2:存档合同副本,更新客户状态。(可系统化沉淀)

流程5:售后服务与反馈

节点1:服务执行

  • 动作1.1:按照合同约定执行服务。
  • 动作1.2:记录服务过程中的关键活动和时间。(可系统化沉淀)

节点2:服务满意度调查

  • 动作2.1:在服务完成后发送满意度调查。
  • 动作2.2:收集并分析客户的反馈。(可系统化沉淀)

节点3:反馈分析与改进

  • 动作3.1:定期审查客户反馈,识别常见问题和改进方向。(可系统化沉淀)
  • 动作3.2:更新知识库,改进服务流程。

我们可以看到通过这样的一套流程,我们不仅将整个公司的流程实现了标准化,更重要的一点在全局判断了整个公司内不同部门的流程后,我们可以更清楚知道哪些部分是有重大价值去进行系统化建设的(我在流程中标注的可系统化沉淀的动作)。

这些内容不仅是公共的而且是已经标准的动作,通过系统化管理可以充分发挥系统的优势:标准化。

综上,这里验证了我一直在给我带过的同学说过的一段话:B端产品人不仅仅是一位产品经理,更重要的是要成为企业内部的咨询顾问,只有这样才能路越走越宽!

本文由人人都是产品经理作者【三爷茶馆】,微信公众号:【三爷茶馆】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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