从一开始我们讲产品功能设计、用户体验、数据运营；到现今成立服务与交付团队，研讨微软销售管理流程，挖掘客户商机，协调客户、团队内部、竞争对手、合作伙伴的利益链条；并针对商务落地过程进行控制，譬如招投标、客户业务、财务、法务、IT流程、签单的控制。
那什么是服务呢？《服务管理整合的视角》一书中，Paul Gemmel和Bart Van Looy将服务定义为：
所有那些无形的并通过顾客和服务提供者之间的互动来实现的经济活动。
一、对客户的分析
有共同需求的群体才是同一个层级的用户
客户层级至少有5重：
1）关注功能体验的【使用者】
2）社交因素影响较大的【影响者】
3）关注情感因素的【推荐者】
4）关注预算的【购买者】
5）关注风险的【决策者】
针对决策者，很多时候不是卖产品，而是要向他传递价值，重点是产品的未来，而不是产品的本身；
面对推荐者和影响者，更多时候你要谈的是技术大方向和产品特性；
面对购买者，你要了解他对预算的心理预期，再给出合时宜的报价；
而面对使用者，你可能要深入到具体产品和实施细节，了解他的痛点和偏好。
在与客户想接触的过程中，我们需要了解到哪些信息呢？从哪几个方面进行入手呢？
1、从客户的痛与痒入手：客户的痛点是什么？是否存在强迫机会？当前客户内部使用在使用同类型的软件？有什么不足与优点？客户对该软件的态度如何？
2、探索客户的购买设想：客户考察的其他竞品有？当年是否有预算？采购方式确定了么？如果是公开招标，预计招投标时间？
3、获得客户进一步的沟通意愿：该项目由客户的哪个部门负责？客户内部的决策链是？每次沟通的内容是否逐步深入？
传统行业的市场规模早已成熟，客户所属的行业与互联网行业存在天然的区隔，如果你没有从事过这个领域，那么你是无法通过只言片语了解到客户真正的用意。
怎么办？要么请这个领域的专家去对话，要么就在尊重专业的基础上去洞察需求，持续交换想法，对齐思路，才能真正做出客户需要的东西。
同样，只有深度使用你的产品的客户，才能给你提供最大价值的反馈，从而帮助产品的迭代和进化。
产品的生命周期不是从研发的那一刻开始，而是从客户使用的那一刻开始，视客户为外部产品团队，共同去打磨产品，才能持续地解决“你在为谁解决什么问题”的问题。
二、项目评估
1、范围：项目目标是什么？项目的边界是什么？项目的每一部分都有哪些工作？你了解客户的业务需求吗？针对客户需求你有对应的方案吗？
2、时间：项目实施团队有哪些成员组成？完成这个项目要多长时间？项目的分工如何？团队如何跟踪实际进程？谁有权批准进度的变更？
3、成本：完成这个项目需要花费多少成本？这个项目预算是多少？如何跟踪控制成本？谁能授权改变预算？
三、方案评估与完善
考察各方人士对方案的态度：客户决策层对方案的建议？内部领导对方案的态度？执行团队对方案的态度？
客户评估方案：方案的评估结果？客户的需求与方案的匹配程度？客户决策人对方案是否认同？
四、服务标准化
评估客户所提的定制化功能，是否是这个行业内的通用诉求。项目中的定制功能转化成产品标准功能的比例越高，说明产品路线是越健康的。
站在客户的角度去梳理本产品的相关流程和推进策略，每一个流程里需要配备的资料和工具，变更事件的风险控制和问题升级等，将服务模板化和场景化。
首先明确我们的交付服务对象：
客户&客户的服务商
公司合作伙伴（渠道商、服务合作伙伴、ISV）
架构师团队
公司内销售上下游
公司内其他业务团队
交付物：
系统体验帐号
产品方案--结合客户的业务需求、服务商的实力和产品自身的标准能力进行评估
相关测评证书--专利证书、软著证书、等保三级测评证书、压测报告
招投标--按标准产品控标参数的投标技术方案
其它包括产品文档、技术文档、部署文档、运维手册、竞品分析文档、市场调研报告、用户操作手册