编辑导语：围绕「客户」相关的B端产品应该如何建设呢？在开始之前，本文作者先通过行业背景、业务部门、业务价值、现状及诉求这几个方面为我们简单的介绍了一下故事背景，对于这个话题你有什么想法呢？欢迎大家留言探讨。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文由 @Grace吖 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议