参观华为- 什么是“解决方案中心”
解决方案中心，在大家原有概念里，可能比较容易把它等同于“客服”。其实并非如此，客服仅仅是解决方案中心20-30%的工作内容。解决方案中心是围绕客户需求展开，为客户提供端到端（E2E）的解决方案。
（一）解决方案中心的定义
解决方案中心和传统意义上的客户中心，基于完全不同的出发点和标准。
1．解决方案是以使产品服务始终保持竞争力为目的，以客户需求为中心，通过获得、分析客户需求数据为手段，通过建立不断优化、改良、研发新的产品或流程的体系结构来实现。
2．解决方案中心不同于客服。严格来说，它和产品、销售是密不可分的，主要分析结果也是企业产品研发改进的重要依据，端到端的解决方案是指“从根本上解决”客户遇到的问题，使之“不会再次遇到”同类问题。
3．解决方案中心的衡量标准：
- cost per solution（为客户提供的每个有效解决方案是多少成本）
- 集群呼叫中心的原有财务衡量标准Costper call（每分钟多少成本）
- Cost per call minutes（每分钟多少成本）
（二）解决方案中心的衡量层次
从这里开始就像一个岔路，我们走上了从解决方案出发去思考的路。衡量一个解决方案中心的好坏，分为两个层次。
1.分析层面
首先是要构架数据的完整性。数据内容的完整，指的是要覆盖得到产品改进的所有分析和机会点，这可能不是一次性就能完成的，而是在不断遇到问题，不断把新的信息收集点“加入”到原有的原始数据中，从而丰富分析的层次。
其次从工具上看，并不需要那么高大上，尤其在架构数据初期，可以采用Execl，反而更灵活，效果更好。只是手动统计的话，一定要注意数据的可信度。建议在初期最好由一个人完成一份数据的采集、分析工作。
最后是分析的准确性。这就是我们常说的“分析到不到位”的问题。分析一定要找到出现问题的“根本原因”，也就是客户提出问题的原因背后的“真实问题”。
案例：客户投诉智能手表表带质量不好，为了维系客户免费为其更换。但开始注重数据收集后，查找根本原因，最终分析出“有小孩和宠物的家庭，硅胶的表带容易损坏”，于是增加“不锈钢表带版产品”，既满足了客户需求，又减少了服务成本，实现了双赢。
2.实施阶段
准确地分析出解决方案，必须要快速有效的抵达客户处。只确保方案有效是不够的，还要注意：解决方案的传递速度越快越好，赶在更多的用户出现问题之前，防患于未然。
除了传递，还要让客户用最少的学习成本来完成方案。衡量客户学习成本包括“时间”“理解”“操作”三部分。常用的方式包括：
- 视频：易制作，易懂，但时间成本高
- 互动动画：易懂，理解快，制作难，制作成本高
所以目前企业大多采取“图片与数字”结合展示的方式，达到双方成本的最优配比。但前两种方法企业采用的也不少，主要原因是“视频可以最快的做出来”和“互动动画年轻人喜欢”。
解决方案投放的最后环节，就是一定要有量化标准来追溯是不是有效。还要随着投放效果不断的校准，必须确保形成一个解决方案闭环。
- 解决方案中心怎么设计最“省钱”，综合投诉产出效益最高？
既然是解决方案中心，那么自然先要架构一个优质高效的解决方案仓库，在架构仓库之前，首先就要定好“优秀解决方案库”的标准：
（一）一个有效的解决方案知识库应该是：有信用（言而有信、内外一致）、有效率的体系（天下武功、唯快不破）
这里的“信用”是指外对客户、内对员工的“信用”。具体可理解为，解决方案本身出问题企业会有人对此承担责任，而不把责任丢给执行端的一线人员和客户。常见的误区是：一旦库建立，各种错误都要企业来埋单。强调“信用”的重点，在于参与其中的每个人，必须负起“责任”。
（二）方案的要求
1．量化的工作内容：比如说用什么指标来指示从XX%做到XX%
2．明确的响应时间： XX月XX日之前，XX小时之内
3．明确的负责人员，包含明确的绩效管理
（三）企业内需要关注的几个点
1.流程应重视事前，以防患于未然
企业鼓励事前多做评估，事中及时举手，不能做事后诸葛亮。要么按流程做，要么发起升级改进流程，因为很多企业根本熬不过几次“事后”。最关键的问题是，事后挽回成本往往几倍甚至几十倍于事前，效果也不一定能达到预期。
2.提升流程处理速度
对于流程的执行争议的处理速度，显示出企业的“能力”。
- 当前案例的及时响应处理：直达决策人（你的企业反应速度有多快？2小时4小时24小时？）
- 当前案例的反追溯是否需要增加解决方案：直达体系管理部门（部门效率有多高？流程问题从发现到改进，需要24小时48小时还是一周？）
（四）企业不应急于“上线”
目前有些企业急于“上线”，认为原来没解决的问题，通过购买一个成熟企业的“知识库”就能获得成熟企业的经验，这是个错误的认识。通俗点说：舒马赫的F1给我开，我不会是世界冠军，反而可能会死得很快。
上线应该是在前面所讲的工作和架构完成后，体系相对稳定，为了加速搜索（搜索引擎），加速分析（统计方案使用率）等再采用的方式。
如果前面的工作都做好，下一步才是系统上线，供更大的组织结构使用，那么要注意“多平台”和“系统整合”两个点。
- 多平台：解决方案从上线开始，就从可支持多平台的方面考虑，避免后续还要投入移植成本。
- 系统整合：一个公司一套体系和系统；保证方案统一，避免重复劳动，以权限分级为手段；一套知识库系统提供内部外部所有用户需求的信息。
其实我们看到的阿里系的企业，帮助客户和内部员工看到的解决方案库就是一个，且不仅仅是Q&A，包括账户操作都是一套系统，只是分为“我们自己”、客服代表、高级代表等，权限不同而已。在这个体系里，客户的问题要么在某一层解决，要么升级解决，整个系统高效、有序。
- 创业公司常见的问题及建议
问题：创业公司的初期，往往是多人各自带着原有公司的资源整合到一起。所以第一代产品横扫市场，最好从这时起就认识到危机，如果到第二代产品市场表现平平时，资金链会容易出现问题。
【我的建议】在第一代产品具有优势时着手建立体系。例如：采用最便宜的论坛+和大机构采购大数据的结构，保证支撑产品改进研发的数据接续，保证原有产品的升级及问题积累，保证研发下代产品的方向准确。
目前有些途径可以直接获取大数据，由是观之，大数据的出现可以让一些创业企业和大企业站在同一起跑线上，可以直接采用最合理的模型，而不用为旧有体制埋单，直接跨过传统企业的“转型”阶段。
问题：一些创业企业重视去接客户电话，忽略了解决方案部门的建设。
【我的建议】解决方案部门不可缺少，接客户电话绝不是主要工作内容。解决方案部门如果改名叫“客户维系”“产品问题分析”“客户需求点分析”可能更准确，它必须是企业决策最可靠有效的消息来源，规模不一定大，但不可缺少。
企业发展初期，非常忌讳客户部门层级过多、传递环节太多、决策速度慢、决策准确度低，对于单一产品的小企业而言，错过一个及时改进错误的机会可能是致命的问题。
问题：客户反馈满意不满意，被企业作为衡量解决方案中心效能的单一标准。
【我的建议】衡量解决方案中心效能好不好，不要仅仅盯住态度好不好、客户反馈满不满意。投诉用户平均只占不满意客户的95%，产品价值越低这个比例越小，投诉用户的问题被“迅速有效的解决”后，继续使用的最多为82%。客服部门的工作质量，取决于衡量这个部门发现了多少“产品或服务问题”，推进了多少“有效改进”。
接客服电话是为了不接，如果想所有问题都在客服解决，或依靠好的客服维系住客户，那都是梦想。
