接单前准备：市场调研、客户需求识别、项目可行性分析与风险评估

接单不是从签订合同那一刻开始的，而是从第一次接触客户、第一次看到招标文件、第一次听到“有个项目想找你们做”时就已启动。很多项目在交付阶段陷入被动，根源往往不在执行，而在接单前的准备不足——需求没摸清、可行性没验证、风险没识别，就匆忙签单，等于带着盲区上路。本章聚焦接单前的四项核心工作：市场调研、客户需求识别、项目可行性分析与风险评估，帮助你建立一套可复用的“接单前检查清单”。

上图展示了接单前准备的完整闭环：市场调研提供背景信息，需求识别明确交付目标，可行性分析验证“能不能做”，风险评估判断“值不值得做”。四步并非一次性完成，而是随着信息增多不断迭代修正，最终汇入一个明确的决策门——接，还是不接。

3.1 市场调研：看清外部环境与客户底牌

核心原理

市场调研的目的不是“了解市场有多大”，而是回答三个具体问题：这个客户值不值得跟？这个项目值不值得投？我们在这个项目里处于什么位置？调研的深度决定了后续报价的准确性和谈判的主动权。缺乏调研的接单，往往在报价环节要么过高吓跑客户，要么过低埋下亏损隐患。

调研的四个维度

操作流程

1. 信息收集（1-3天）：通过公开渠道（企查查、天眼查、招标网、行业媒体）建立客户与项目的基本画像。
2. 内部验证（半天）：召集售前、技术、交付负责人，对照自身能力清单，初步判断“我们有没有做过类似的”。
3. 竞争定位（1天）：了解至少2-3家可能参与竞争的友商，分析各自的优劣势。
4. 调研结论输出：形成一页纸的《市场调研摘要》，包含客户评级（A/B/C）、竞争态势、建议跟进策略。

3.2 客户需求识别：从“客户说的”到“客户真正要的”

核心原理

客户表达的需求往往是解决方案，而不是业务目标。例如客户说“我们需要一套OA系统”，这其实是解决方案；背后的真实需求可能是“审批流程太慢，平均需要5天，希望压缩到1天”。如果只按“做一套OA”去接单，交付后客户可能不满意，因为真正的痛点没有被解决。需求识别的核心是穿透表层，找到业务本质。

需求分类框架

需求识别五步法

1. 干系人访谈：分别访谈决策层、管理层、执行层，不同层级关注点不同——决策层关心ROI，管理层关心效率，执行层关心易用性。
2. 场景还原：请客户描述“当前是怎么做的”“哪里最痛”“期望变成什么样”，用具体场景代替抽象描述。
3. 需求优先级排序：将收集到的需求按“必须（Must）/应该（Should）/可选（Could）”分类，明确哪些是底线。
4. 验收标准对齐：与客户确认“做到什么程度算成功”，形成可量化的验收指标。
5. 需求确认书：将整理后的需求文档发给客户确认，避免口头理解偏差。

3.3 项目可行性分析：从四个维度验证“能不能做”

核心原理

可行性分析不是“我们能不能做出来”，而是“在给定的约束条件下，我们能不能按时、按质、按预算交付”。很多项目技术上可行，但资源不够、时间太紧、经济上不划算，最终变成鸡肋。可行性分析的价值在于提前暴露这些矛盾，避免签下“明知做不好”的合同。

四维可行性评估模型

案例拆解：一个“看似能做”的定制开发项目

背景：某软件公司收到客户需求——开发一套内部工单管理系统，预算30万，要求4个月内上线。客户强调“功能不复杂，就是表单+审批流+报表”。

初步判断：销售认为功能简单，技术团队评估后认为技术栈成熟，看起来可行。

深入分析后发现：

• 客户内部有7个部门，每个部门的审批流程不同，且流程规则经常变化——这意味着需要高度可配置的工作流引擎，而非简单表单。
• 客户要求与现有ERP系统对接，但ERP厂商不提供接口文档，需要逆向工程——技术风险极高。
• 客户期望的“报表”实际是实时数据看板，需要处理多维度数据聚合——工作量被低估。
• 团队中熟悉工作流引擎开发的只有1人，且该同事在项目期间有休假计划。

分析结论：按30万预算和4个月周期，实际成本预计45万、周期至少6个月。项目不可行。

处理方式：向客户坦诚沟通，提出两个方案：① 缩减范围，先做核心审批流，报表二期再做；② 增加预算至45万，周期延长至6个月。客户最终选择了方案①，双方在明确边界后签约。

复盘：如果当初直接按30万签约，项目大概率会陷入延期和亏损。可行性分析的价值不是“劝退”，而是在签约前把问题摆在桌面上，让双方基于事实做决策。

3.4 风险评估：识别“会让我们翻车”的因素

核心原理

风险评估不是“列一堆风险然后吓唬自己”，而是识别那些真正可能影响项目成败的关键不确定性，并提前制定应对策略。接单阶段的风险评估重点在于“要不要接”和“怎么接”，而不是执行阶段的细节风险。

接单阶段常见风险清单

风险评估操作步骤

1. 识别：召集项目相关方（销售、技术、交付、法务）进行头脑风暴，列出所有可能的风险点。
2. 分析：对每个风险评估发生概率（高/中/低）和影响程度（高/中/低），形成风险矩阵。
3. 排序：重点关注“高概率+高影响”的风险，这些是必须提前应对的。
4. 制定应对：对每个高风险项明确应对策略——规避（改变计划）、转移（合同条款/保险）、减轻（提前准备）、接受（明知存在但影响可承受）。
5. 写入合同：将关键风险的应对措施落实到合同条款中，例如需求变更的报价规则、验收标准、付款节点。

3.5 接单决策：综合判断与最终取舍

决策矩阵

将市场调研、需求识别、可行性分析、风险评估的结果汇总到一张决策表中，用结构化方式辅助判断：

决策规则：总分≥4.0分，建议积极跟进；3.0-3.9分，有条件接单（需满足特定前提）；<3.0分，建议放弃或大幅调整合作条件。

案例复盘：一次“放弃接单”的决策

背景：某系统集成商收到一个智慧园区项目，合同额800万，客户为某地产公司。销售团队非常兴奋，认为这是年度最大单。

调研发现：客户近两年财报显示现金流紧张，已有供应商反映回款延迟；项目要求与客户自有的弱电系统深度集成，但客户无法提供完整的接口文档；竞争对手中有一家与客户有长期合作关系的集成商。

评估结果：客户质量2分（回款风险高）、需求清晰度2分（接口不明确）、技术与资源匹配度3分（部分技术可复用）、经济回报4分（合同额大但回款周期长）、风险可控性2分（客户关系劣势+技术不确定性）。加权总分约2.6分。

决策：放弃直接投标，改为与那家长期合作的集成商沟通，争取成为其分包商，以降低风险。

结果：三个月后，该地产公司项目因资金问题暂停，直接承接的友商也未能幸免。这次“放弃”避免了公司陷入一个大概率亏损的项目。