请注意,本文编写于 39 天前,最后修改于 22 天前,其中某些信息可能已经过时。
目录
商机-销售侧
客户需求调研
客户需求收集-售前侧
需求分析
需求分析结果
解决方案设计
需求初步构象
解决方案需要思考以下问题
方案细化
商业价值分析
产品演示
技术答疑
可能存在的流程
概念验证(POC)
需求大小之分
如果是“大的需求”
概念解答
可量化
售前支持一个项目完整的生命周期
商机-销售侧
市场会将商机推给销售,
销售会与商机客户进行初步交流,评判是否为我司目标客户;
如果是,深入跟进需求。
客户需求调研
客户需求收集-售前侧
- 与客户沟通:交流并明确需求内容
- 客户侧人员:可能是业务人员、IT人员
- 沟通方式:电话、线上会议、线下面谈
- 需求支撑材料:
- 我方提供需求收集问卷
- 客户侧提供需求文件、招标文件等
经验建议
- 需求收集框架,尽量形成自己的思维框架,这样保证需求收集的完整性与高价值
- 沟通人员优先级:业务+IT > 业务 > IT,因为业务侧更清楚需求点,IT侧更清楚软件系统情况
- 沟通方式优先级:线下面谈 > 线上会议 > 电话,见过面的人与线上网友终究有信任差异,当然也要考虑线下面谈的成本(差旅、人员工时)
需求分析
- 明确客户痛点:将客户提出的需求细化为可量化的问题
- 优先级排序:区分核心需求和次要需求
- 验证需求:需求分析后,再与客户确认,确保理解一致
需求分析结果
- 需求完全满足:分析公司现有产品,是否可直接满足客户需求
- 需求部分满足:
- 分析无法满足的需求是核心需求,还是次要需求;
- 无法满足需求,是否可通过其他方式实现;
- 无法满足需求,是否可不实现;
- 需求完全无法满足:
- 评估是否为公司预期客户
- 评估无法满足的原因
- 评估客户是否为公司未来的战略客户
解决方案设计
基于需求分析结果,设计解决方案
需求初步构象
- 需求完全满足:直接采用公司产品
- 需求部分满足:
- 公司产品 +定制化开发
- 放弃无法满足的功能
- 对标分析,了解竞品的解决方案,分析其优缺点
- 方案差异化,突出自家方案在某些方面的独特优势
解决方案需要思考以下问题
- 解决方案,是否关注了客户核心需求点
- 解决方案,是否能打动客户
- 解决方案,是否能说服客户购买
方案细化
- 业务架构设计
- 功能模块分解
- 技术架构设计
- 集成与兼容性
商业价值分析
- ROI分析:预测方案的投资回报率
- 成本效益分析:帮助客户理解方案在成本节约、效率提升、风险降低等方面的价值
产品演示
- 准备演示环境
- 定制化演示流程
- 演示过程中讲解
经验建议
-
实时演示环境极易出现异常,准备双保险
- 两套环境
- 提前录制演示视频
-
演示流程,一定是和客户交流过,客户十分关注的,否则毫无价值
技术答疑
- 提前准备
- 提前和客户沟通,关注那些方面的问题
- 针对方案,平时积累些客户提问点
- 现场回答
- 知道的,如实回答
- 不知道的,可以浮夸些回答,但不要过度;客户也都是身经百战的职场人,一眼就能看出;
可能存在的流程
概念验证(POC)
- 试点方案实施
- 试点数据收集与反馈
- 优化调整
需求大小之分
如果是“大的需求”
所谓大的需求,统指系统规模大,合同标的大些;
大也是相对的,比如客单价平均在在2-3w的企业,10w算是大的的需求了;
- 可能会存在多次沟通
- 因为B端购买是多人决策,每次参会人员可能存在差异,故会有多次会议情况
概念解答
可量化
是指将某些事物或工作通过一定的方式转化为具有明确数学值或可测量的指标,例如业务部门的工作可通过时间、数量、质量、成本等指标来实现量化。 对于无法直接量化的工作,如与人打交道、服务性、制度文本类等定性工作,可以通过设立明确的评价标准来实现可衡量。 比如对工作标准、工作产出进行明确描述和层级划分,以区分好坏优劣。
本文作者:bob
本文链接:
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA
许可协议。转载请注明出处!