围绕「客户」相关B端产品如何建设(一)

随着国际海洋公法的建立和发展,杰克船长的海盗生涯逐渐落寞,为了保障船员和水手们的生活,杰克准备转战做运输。

经过几年沉浮,杰克的运输生意发展的还不错,于是他又买了几艘船,逐渐扩展为拥有50艘船只、2000名船员的商队,为了方便管理,杰克成立了「加勒比远洋运输公司」,设立了财务、市场、运输、客户、科技、行政、人资等七大部门,负责推动公司不同事务的发展。

科技部的老大威尔为不同的部门成立了一对一支撑的科技团队,其中财务科技部、市场科技部、运输科技部、客户科技部分别对应支撑财务部、市场部、运输部、客户部,综合科技部对应支撑行政部和人资部。

伊丽莎白是客户科技部的产品负责人,为了让所在团队的价值最大化,她准备先去走访下客户部的老大,了解下业务部门的理念和想法。

产品经理,产品经理网站

客户部的老大认为,公司设立这个部门的初衷,是希望客户部能够建立客户对公司的好感,愿意在公司持续消费。在没有更多新增客户的情况下,为公司留住更多的已有客户,持续挖掘已有客户的消费潜力。

作为一家运输公司,客户最关心的问题应该是运输的价格、时效、质量和服务,如何降低运输的价格,更多需要从运输部的角度去控成本提效能,客户部所能作用和发挥的空间比较有限。

所以他准备将主要的精力放在时效、质量、服务几个方向上,另外从成本和利润的角度来讲,客户部不直接产生利润,需要尽力用更小的成本达到目标最大化。

接下来,客户部会做的事情是根据当前的建设方向,制定部门核心目标,并进行一定程度的拆解落地。

其中,可以明确的是,客户部的一级核心业务指标为「客户忠诚度」,二级核心业务指标为「时效达成率」、「质量达成率」、「客户满意度」。

然后通过渐进明细的方法,将这些指标落地拆解为可衡量的基础指标(比如客户忠诚度可以通过消费频次、客单价、累计交易金额、留存率等几个维度来衡量)。

之后测算当前企业这些基础指标的的达成值,并根据同行调研、内部测算等方法设立一个可通过努力实现的目标值、挑战值;这些指标及目标,将成为客户部接下来开展所有工作的一个前提。

产品经理,产品经理网站

客户科技部通过这次调研,基本已经获取到了以上基础信息。

那如何通过技术手段为业务赋能,辅助达成业务目标,是伊丽莎白接下来需要去思考和解决的问题。基于以上背景,我们也来尝试回答围绕「客户」相关B端产品如何建设的问题?

首先,我们尝试回顾下客户在公司的生命路线和客户部需要介入的阶段,如下图:

产品经理,产品经理网站

我们站在客户部的角度,追溯下面对这些场景和情况,通常都需要怎样去开展工作,并根据不同阶段需要做的事情,罗列下科技可以发力的点:

第一阶段:针对当下客户问题的解决,客户部需要明确哪些信息:

  • 客户是谁?——需要有客户资料库,明确不同的客户身份等客户基础信息;
  • 客户的问题是什么?——需要有健全的问题反馈、查询通道;
  • 客户的诉求是什么,能接受的下限是什么?——需要明确客户托寄物的价值和损失;
  • 为了解决问题,公司能够给予客户标准和上限是多少?——需要一套健全的客诉处理及赔付标准。

第二阶段:为了避免再次产生相同的问题,客户部还需要做哪些事情:

  • 调查因为什么原因产品了这样的问题?——需要知晓开始发生问题的环节;
  • 有什么方法可以避免这样的问题再产生?——需要提前做风险预判预警;
  • 再有相同问题的产生,如何更快的解决?——需要有一定的奖惩机制。

接下来,我们将这些诉求点,转化为对应的产品并整理成表格的形式(如下图)。

产品经理,产品经理网站

这些内容,组成了客服部核心业务场景下所需的系统辅助工具,是我们系统支撑从无到有阶段最基础的搭建需求。

下一步,需要将这些系统进行合理的组合,输出客户科技部的功能架构蓝图。就像盖房子,现在我们拿到的信息只是明确知道需要几间卧室、客厅、厨房。

架构蓝图需要回答的是,应该在几层建客厅几层建卧室动静线才更合理,是否需要游泳池后花园,应该怎么布局这些功能区的问题。

通常架构蓝图应该考虑到,底层哪些服务可共用共建,中层哪些系统信息需要互通互联,上层如何提供一致化的服务体验。

我们通过「问题发生——问题解决——杜绝问题再次发生」这个角度,尝试将上文提到的核心系统串联丰富起来:

产品经理,产品经理网站

  • 渠道:客户投诉渠道解决客户投诉无门的问题,对公司的客户提供统一的沟通查看渠道,当客户对运输不满意时,可在对应渠道上联系公司;内部问题渠道用来在运输过程中,船员自发的发现货物问题,需要将问题上报并转交专业部门处理的情况;
  • 服务中心:接收内外部的问题,下发到对应的部门进行处理,并对处理结果进行监控、对不合规行为进行处罚;
  • 客户中心:统一录入管理客户信息,并对客户的发货、服务、产品、价格偏好等进行分析;
  • 基础服务:将所有系统都可能用到的权限控制管理、信息查询健全、消息下发、工作流等公用的服务,抽到底层统一提供,避免重复建设带来的标准不一致、能力参差不齐的问题;
  • 数据底层:将客户、工单等核心数据放到最底层,统一提供服务,方便各个环节提取;
  • 预警大盘:对运输过程中易发生问题的环节做监控预警播报,方便各部门提前做好预防方案。

到这一步,已经基本解决了当前最棘手的问题,构建哪些系统工具可提升业务解决问题的效率,每个系统功能的边界和划分方式。

但是这份蓝图,仅仅是站在客户部的角度,针对当下的问题所输出的解决方案。当和运输、市场、财务等部门进行相互配合时,放到公司整体的角度去看,又出现了新的问题。

同时,随着公司业务的进一步发展,所面临的场景远远不像上面列举的这么简单,这些管控工具显然会远远不够。

公司会如何发展,业务会如何做精细化管控,这些问题的答案会随着时间发展而变化。但系统的建设需要时间,频繁的重建重构不利于系统稳健性持续性的发展。

所以这套蓝图还值得推敲,如何建设一套在2-3年亦或是3-5年内可扩展的系统?

回答这个问题,需要结合行业可能的发展方向、同行及市面上竞争对手的做法、市面成熟化的sass产品或技术等等信息。下篇我们再慢慢展开来说。

本文内容仅代表一种解决问题的思路,所有的内容和信息都是虚拟,不具备直接复制参考的价值。

 

本文作者 @Grace吖 

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部