To B早已不是一个新课题，几乎每个行业都在使用产品捆绑。可对于企业市场而言，比起产品捆绑式的宣传和推销，给客户全方位浸入式的服务体验，牢牢抓住客户的心，不给竞争对手任何挖墙脚的机会，在销售漏斗之余创造更多的价值，或许更为重要。

从事to B业务工作的人大概都有这样的体会吧：

从一开始我们讲产品功能设计、用户体验、数据运营；到现今成立服务与交付团队，研讨微软销售管理流程，挖掘客户商机，协调客户、团队内部、竞争对手、合作伙伴的利益链条；并针对商务落地过程进行控制，譬如招投标、客户业务、财务、法务、IT流程、签单的控制。

那么在数字化时代，2B产品成功的秘诀是什么？几乎每个行业都在使用产品捆绑，可通常它并不是具体战略和意向战略的一部分。

回答这个问题之前，我们先来回顾一个现象。

在19世纪，统计学家恩斯特·恩格尔提出恩格尔定律：

当人们很穷时，会将其大部分收入分配给生活必需品（食物、住房等）；当收入增长后，人们会在食物的消费上投入更多，但并不会将增长的所有收入都用来消费食物，因为这种需求到一定程度会达到饱和。因此，随着收入的增长，拥有更多收入的人们倾向于将更多的钱用于购买服务，可用于购买物品的钱会减少。

当然，新兴服务业增长的背后驱动力除了人们的收入改变之外，社会和人口的变革，还有企业中日益增长的专业化和技术进步。

那什么是服务呢？《服务管理整合的视角》一书中，Paul Gemmel和Bart Van Looy将服务定义为：

所有那些无形的并通过顾客和服务提供者之间的互动来实现的经济活动。

同样的，对于2B产品而言，站在该产品服务的目标群体视角上，放眼望去，他们也同样经历着社会的变革，感受着电子信息化和数字转型的催化。比起产品捆绑式的宣传和推销，给客户全方位浸入式的服务体验，牢牢抓住客户的心，不给竞争对手任何挖墙脚的机会，在销售漏斗之外创造更多的价值，或许会更为重要。

本文基于该命题，结合微软的优秀服务管理咨询和华为的服务体系，并通过在实际产品交付的过程中，给出一些感悟和分享。

一、TO B服务体系框架

前文提到，在TO B市场上，不仅要客户导向，更是需要一套全方位的服务管理。一套优秀的服务体系远超出效率本身的范畴，而是决定客户项目成败的关键因素。而服务需要业务的滋养，才能变得更为茁壮。

通过初期的服务体系建设，投入到客户项目中进行验证和实践，再由客户项目驱动，去对服务体系进行更新和迭代。

下图是To B产品的销售管理流程，从售前服务到售中交付，再到售后服务阶段，不难看出纵使客户千人千面，但我们可以通过搭建一套通用的服务框架体系去管理和跟进客户项目。

每个客户项目均可以在上述的流程中找到对应的位置，此时，该客户我们需要投入什么资源，我们期盼客户有什么产出呢？哪怕是to B产品，我们也希望明确投入产出比。

下图是我根据产品的实际现状与展望拟定的服务管理体系框架：

不妨回想下，在早期往往一个新项目的开展除了数据可以被重复使用之外，服务却不能被重复使用。可其实服务的重用比数据重用能带来更多好处，数据是原始的生产资料，服务则包含逻辑，是工厂的加工车间。如果加工过程也一样可以复制，将带来生产效率的大幅度提升。

而服务管理体系正是充当了本软件的加工车间的角色。所有服务体系散布在销售管理流程中的方方面面，为了协助客户项目在销售管理和项目交付过程中的运行，我们通过标准的服务体系和知识管理体系为客户项目添砖加瓦，确保客户项目可以流水线、共享式地运作，无需耗费重复的劳动力。

下面我想重点根据客户在售前支持和售中交付阶段对应的服务体系一一做下解读。

二、售前服务

1. 确认商机

1）发现机会，挖掘潜在支持者

这个阶段最难也最容易被人忽视，因此你可能会看到一种现象——商务牵线客户过来后，大力吹捧客户的影响力、本产品与客户需求的完美契合度，然后就开始索取资源。

注意！此时一旦你掉以轻心，抱着“无所谓的反正也就个把时间的功夫我直接搞定就好”的态度，迎接你的将是无止境的索取和投入。

这仅是一个客户，倘若是十个，一百个，上千个客户呢？从迎接第一个客户开始，就要做好服务于成百上千个客户的准备。最大的浪费不是重复建设，而是不断地重复建设。

客户初次登场，对商机的把握程度，决定了后续团队的资源投入。商务牵线客户过来后，如何判断该客户是我们的目标客户，并找出潜在的项目机会及可能的支持者？

1. 从客户的痛与痒入手：客户的痛点是什么？是否存在强迫机会？当前客户内部使用在使用同类型的软件？有什么不足与优点？客户对该软件的态度如何？

2. 探索客户的购买设想：客户考察的其他竞品有？当年是否有预算？采购方式确定了么？如果是公开招标，预计招投标时间？

3. 获得客户进一步的沟通意愿：该项目由客户的哪个部门负责？客户内部的决策链是？每次沟通的内容是否逐步深入？

2）确定并推动项目机会

明确该客户是我们的目标客户——这是我们单方面的考察。而客户也同样在考察着我们，他在诸多厂商中选型，或许摇摆不定，或许已有所倾向。我们需要明确得到客户决策层的支持。在得到一个明确的态度之后，开始明确售前团队。

1. 考察客户决策层的态度：你是否完全了解客户内部的关系？客户决策人的职务？他的关注点是？对我方产品的态度？

2. 明确本公司内的资源投入：商务支持、售前支持、技术支持都确定下来了吗？每种售前角色的任务分工是什么？

3. 明确公司外的资源投入：是否要引入合作伙伴？若是，则合作伙伴的权责利各是什么？与我司的合作模式是什么？

2. 方案交流&确认

此前我主要负责私有部署化产品在对外项目交付中的工作，在此以省部级政府客户为例。

常态化、多层次、立体化的政务服务体系正在逐步形成，政府治理模式正从单向管理向双向互动转变，从单纯的政府监管迈向社会协同治理，推动政务服务向基层延伸,“纵向到底、横向到边、覆盖全省（国）”的政务服务体系不断完善提升。

那么，政企机构的领导层在关心什么？全国的数字化转型如火如荼，他们有政绩压力，想打造创新标杆，百忙之中抽空去听的不是你对产品的推销，而是结合他自身的业务需求去形成的整套解决方案。

通常情况下，方案交流阶段在整个销售管理漏斗里占据较大的比例。这个环节决定了客户对你提供的产品服务的青睐程度是否够持久，够稳定。总体来说，提案制作与客户宣导的过程中布满血与泪，你进我退，你退我攻，充分发挥工农红军在土地革命时期的游击战争指导原则就对了。

考虑到政企内部的人员分布，一般来说我们会从客户内部的三个层级去考虑方案的设计：

1）方案评估与完善

• 考察各方人士对方案的态度：客户决策层对方案的建议？内部领导对方案的态度？执行团队对方案的态度？
• 客户评估方案：方案的评估结果？客户的需求与方案的匹配程度？客户决策人对方案是否认同？

2）明确客户的采购意愿

• 客户决策层的采购意愿：客户决策人对我们是否支持？客户在我司和竞争对手的投入精力比，客户的倾向？
• 招标引导：协调客户内部关系，获得客户认同的控标点，防备竞争对手，控制合作伙伴的预期。

3. 项目验证&成交

在提交满足客户需求并高于客户期望的解决方案，同时也获得了客户非正式的认可之后，利益链的协调仍在继续。

1）客户试用本软件

通常来说，尤其针对政企客户而言，除了解决方案之外，还需要进行概念验证。注意！这个节点是资源投入较为密集的关卡，需要我们严格控制客户预期，避免给团队造坑。

1. POC部署前的调研：客户的POC部署目的？计划试用时长？期望验证的功能范围？POC部署后的下一步计划？

2. POC部署：是否明确部署方案和支持方案？客户决策人对方案是否认可？POC部署是否标准化，是否可交由合作伙伴实施？

2）商务投标与合同签署

不知不觉已进入售前阶段的最后一环，此时稍有不慎就会给后续的项目交付工作埋下天坑。一方面，客户关系需要商务持续维护；另一方面，对于标书制定与合同管理也同样需要做好万全准备。

在拟定合同前，请先明确项目经理，再请项目经理扪心自问：

1. 范围：项目目标是什么？项目的边界是什么？项目的每一部分都有哪些工作？你了解客户的业务需求吗？针对客户需求你有对应的方案吗？

2. 时间：项目实施团队有哪些成员组成？完成这个项目要多长时间？项目的分工如何？团队如何跟踪实际进程？谁有权批准进度的变更？

3. 成本：完成这个项目需要花费多少成本？这个项目预算是多少？如何跟踪控制成本？谁能授权改变预算？

每个项目都会在不同程度上收到范围、时间和成本的约束，这些限制条件在项目管理中通常被成为三项约束。如果等项目正式开始实施的时候才开始考虑这些因素就晚了，在合同签署前，就应该给出一个大体的项目计划书作为合同附件，与客户对齐要求，作为后续项目交付的原始根据。

三、售中交付

合同签署完毕，正式进入售中交付阶段。此时项目计划书作为项目交付的战略地图，它指导并管理项目执行，确保项目的交付成果满足预先定义好的质量度量标准。

1. 项目计划

前文提到，项目管理中的三项约束需要在合同拟定前大致确定下来，那么，如何避免在达到范围、时间和成本目标的同时却忽视了质量或客户满意度而产生的问题呢？

因此，基于合同里的粗粒度项目计划书，项目经理需要再进行细化。

下图是项目管理框架：

基于上述的项目管理框架，项目经理不仅要实现三项约束，还必须协调整个项目过程，以满足项目参与者、客户的需求和预期。

一般来说，一份完整详细的项目计划书包含如下内容：

• 项目概述
• 项目范围
• 实施服务范围
• 项目计划和交付项
• 项目资源规划
• 项目组织和条款
• 项目变更控制流程
• 项目验收
• 服务水平
• 责任与义务
• 违约责任
• 保密协议
• 附件：本软件产品和服务目录列表

2. 项目交付

若本项目引入了服务合作伙伴，则项目交付环节需严格按照我司与合作伙伴之间的分工边界来运作，避免造成后续资源报价、费用结算的问题。

注意，每个项目参与的角色是固定的，但分配到该角色的人员是流动的。因此，根据角色去定义服务内容项会更为可靠。

基于设计好的流程，我们将项目实施团队（含本公司&合作伙伴）里的每种角色的职责分工通过wbs定义清楚，每项任务分别配备对应的资料库（表单、标准配套文档等），便于每种角色除了明白自己要做什么，还懂得如何做。

3. 项目结案

每个项目都可以划分为多个项目阶段，每个阶段的投入可以通过定性或定量的方式来衡量，而每个阶段的产出均可视为一个里程碑事件，需要项目经理定期输出项目里程碑总结。

同时，在最终客户正式验收后，不仅可以对项目成员（含合作伙伴）进行考核评估，还可以向客户进行满意度调查，以此推进服务的持续改善。

四、小结

做to B产品，商业解决方案往往比产品本身有着更长的生命周期。不仅脸要贴着客户，服务也要照顾到方方面面，才能避免解决方案迟迟无法落地和交付。

回顾上述内容，对服务提供者而言，从售前、售中到售后阶段，每个环节都需要标准化的流程布局，并配备相应的资料参考，确保有序并高效地服务于客户。

对被服务者而言，与服务者的每一次接触点都影响着他们的采购意愿和价值传播。

在此以“满意镜”的形式说明客户与服务提供者的关系。

我也承认这套服务体系肯定会存在不足之处，但通过在实际业务中的持续滚动和改善，定能真正辅助客户项目的流畅运行。

一套好的服务管理体系并不依赖于产品本身，它具有强大的重用性。我负责过多款软件的服务管理与交付支持工作，在实际的客户项目中几乎都验证了这一点。如果以后能拍着胸脯说，这套服务管理体系适用于所有的TO B产品就好了。

毕竟，未来的前景不是由购买产品的消费者决定的，关键在于使用服务的客户。

参考文献

1. 刘通，梁敏，梁娅，王前.ITIL 2011服务管理与案例资产详解[M].哈尔滨工业大学出版社，2014年：151.

2. Paul Gemmel，Bart Van Looy，Roland Van Dierdonck.服务管理整合的视角[M].清华大学出版社，2017年：6-8.

3. James A.Fitzsimmons，Mona J. Fitzsimmons.服务管理运作、战略与信息技术[M].机械工业出版社，2017年：197.

4. 钟华.企业IT架构转型之道[M].机械工业出版社，2018年：9.

5. Kathy Schwalbe.IT项目管理[M].机械工业出版社，2015年：5-7.

作者：林壮壮，腾讯高级产品经理，微信公众号：健壮的大姐姐。专注于To B服务项目管理和行业分析，欢迎各路好汉一起探讨。感谢阅读，鞠躬。

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

题图来自Unsplash，基于CC0协议