IT售前岗位地图

我在售前相关岗位干了 6 年，身边还是经常有人问：售前到底是做什么的？是懂技术的销售，还是不写代码的技术？每天除了给客户讲 PPT，还要干些什么？

这篇文章就从头梳理一下 IT 售前这个岗位：它为什么存在，在一个项目中承担什么工作，项目之外又在忙什么，以及不同类型公司的售前有哪些差别。

为了避免文章过于冗长，本文主要介绍售前的概念和工作全貌，具体技能暂不展开。因为我一直在 IT 公司工作，文中会以 IT 行业为例，不过其中很多工作在其他行业也有相似之处。

为什么会有售前这个岗位

售前，简单来说，就是在销售过程中，为客户解答产品和解决方案问题，并推动客户形成技术认可。这里的“技术认可”，就是让客户从技术层面确认产品和方案能够解决问题，并且具备落地的可行性。

先有售前这类工作，后来才有售前这个岗位。大多数销售过程中，都有人需要回答“这个产品能不能解决我的问题”“应该怎么用”“为什么要选你们”之类的问题，只是不同业务的复杂程度不同。

大多数标准化的 To C（面向个人消费者）业务销售路径短，产品也相对容易理解，因此通常不会单独设置售前岗位。消费者看到的广告、商品介绍，以及下单前向客服咨询产品问题，其实都承担了一部分售前功能。到了高客单价或更复杂的消费场景，也会出现产品顾问、销售顾问等类似角色。

To B（面向企业或组织）业务则不同。客户购买的往往不只是一个标准产品，而是一套与自身业务、现有环境和采购流程相关的解决方案。销售过程更长，参与人员更多，产品和方案也更专业。当这部分工作的专业性和工作量大到无法由销售独自承担时，就逐渐分化出了专门的售前岗位，例如售前产品经理、销售工程师和解决方案专家。

售前到底在做什么

如果不看具体岗位职责，我习惯用一个粗略但好记的比例概括售前的工作：

内外沟通占 50%，沟通完做材料占 40%，和沟通的人建立关系占 10%。

这是个人经验下的概括，不是严格的行业统计。不同公司、产品和项目会有差异，但售前的大部分工作基本都能放进这三类里。

不管是了解需求、做产品培训，还是开测试会，本质上都是沟通；

不管是写技术方案、做汇报 PPT、分析招标文件，还是整理产品配置，本质上都是做材料；

不管是与销售、渠道还是客户建立关系，最终都是为了让前两项工作能够顺利推进。

如果按照工作发生的场景来分，售前的工作可以分为两大类：项目中的工作和项目外的工作。

一、项目中：售前如何推动一个项目

下面是一条比较典型的 To B 项目推进链路。它不是固定的标准流程：有些项目不需要 PoC，有些项目不经过公开招投标，有些项目聊完需求就能直接报价，还有些项目会在需求、方案和测试之间来回反复。

1. 机会判断与业务梳理

销售带来一个项目机会时，售前首先要弄清楚：客户这次到底想做什么？要解决什么业务问题？现有环境是什么样的？我们有哪些产品和方案可以匹配？

客户最初说出来的，往往只是一句比较粗的需求，比如“想把现有系统升级一下”或者“准备建设一套新平台”。售前需要通过交流把这句话逐步拆开，判断这是一个真实、明确的项目，还是客户仍处于早期调研阶段；同时也要初步识别项目的技术范围、关键限制和竞争情况。

这个阶段不一定马上产出正式材料，但至少要形成对项目的基本判断，以及下一轮需要向客户确认的问题。

2. 需求交流与需求澄清

确认项目值得继续跟进后，就要进一步了解客户需求。售前通常需要和客户的业务部门、技术部门、采购相关人员分别交流，因为不同角色关心的问题并不一样。

业务部门关心能解决什么问题，技术部门关心能不能接入现有环境、是否安全稳定，管理者关心价值和风险，采购则会关注配置、价格和流程。售前要把这些零散的信息拼起来，识别哪些是明确需求，哪些只是初步想法，哪些要求现有产品无法满足。

需求澄清不是简单地记录客户说了什么，而是逐步把项目范围、使用场景、技术边界和验收要求说清楚。后续方案写偏、测试返工、配置反复修改，很多时候都能追溯到这个阶段没有问清楚。

3. 方案设计与材料准备

需求明确之后，售前要根据客户的实际场景调整产品和解决方案，确定用什么产品、采用什么架构、解决哪些问题，以及如何与客户现有环境配合。

公司统一的解决方案在一线项目中经常会出现“水土不服”的情况。售前要做的不是把标准方案原样发给客户，而是在产品能力范围内进行取舍和组合，让方案更符合客户需求，同时兼顾竞争力、实施难度和项目成本。

这个阶段会产生大量材料，包括汇报 PPT、技术方案、产品资质文件和配置清单等。配置清单，就是项目需要使用哪些产品、型号、数量和组件的明细。普通项目可以使用模板，但大项目或重要交流的材料往往需要反复打磨，一版材料修改十几轮并不少见。方案怎么讲、参数怎么写、哪些能力可以承诺、哪些话不能写进去，都有讲究。

4. 汇报交流与技术认可

汇报交流是售前的核心工作。前面做的需求分析和方案设计，最后都要通过交流传递给客户。

售前需要把方案的价值讲清楚，回答客户对产品和技术的疑问，也要处理客户拿竞品进行比较时提出的挑战。一次正式汇报的效果，往往会直接影响客户对一家公司的技术印象，进而影响项目走向。

这里的目标不是“把 PPT 讲完”，而是让客户理解并认可方案。一次交流之后，客户很可能会提出新问题或暴露新需求，项目也可能因此重新回到需求澄清和方案修改阶段。

5. PoC 测试

对于客户仍有疑虑，或者必须用实际结果验证的项目，通常会安排 PoC。PoC 是 Proof of Concept 的缩写，也就是“概念验证”：客户在正式采购前，通过测试确认产品或方案能否达到预期效果。

售前需要同时保障测试的内部组织和外部沟通。对内，要协调测试人员、确认测试环境、制定测试用例、准备产品和资源；对外，要和客户确认测试目标、验收标准、时间安排和现场条件。

测试过程中出现问题，客户通常会先找售前。售前未必亲自解决所有技术问题，但必须知道问题发生在哪里、应该找谁处理，以及如何向客户解释和推进。测试通过本身不是终点，形成双方认可的测试结论，才算完成了这一阶段的任务。

6. 产品配置与报价

当方案逐渐确定后，售前需要把解决方案落实到具体产品和配置上，并配合形成报价。

这部分工作看似机械，实际会占用很多时间。解决方案发生变化、客户数量调整、技术参数改变，配置单和报价单都可能需要重新修改。销售拿一份其他厂商的配置，让售前整理出自家对应方案，也是常见情况。

硬件行业还可能遇到更多意外：上个月配置的产品这个月停产了，客户此时刚好准备采购，只能寻找新的替代型号，同时还要尽可能控制在原有预算内。配置不只是把型号填进表格，还要保证产品之间能够配合、数量合理、方案可落地。

7. 招投标支撑

一些项目会进入正式招投标流程。招标方会发布招标文件，说明采购需求、技术参数、评分方法和投标规则；参与方则需要根据要求制作并提交投标文件。

售前主要负责其中与产品、技术和解决方案相关的部分。销售拿来一份招标参数，让售前逐项判断哪些能够满足、哪些存在风险，这一找一标就可能花掉几个小时。发现不合理参数时，还要评估是申请澄清、提供替代方案，还是明确提示投标风险。

临近投标时，招投标工作往往会变成重要且紧急的任务。技术参数、资质文件、方案内容和配置报价需要反复核对，一份投标文件检查五六遍并不夸张。所谓“封标”，就是在正式提交前完成投标文件的签章、封装和最终确认。干到投标前一天凌晨才封标，是很多售前都经历过的场景。

8. 客户项目支撑与交接

在正式采购之前，客户内部通常也有自己的项目流程。客户可能需要写可行性研究报告、申请预算、参加内部评审，或者向管理层汇报。可行性研究报告通常简称“可研”，用来说明一个项目为什么要做、能不能做以及准备怎么做。

这些材料中涉及产品和解决方案的部分，往往需要售前提供内容或协助完善。客户的项目向前走一步，销售机会才会跟着向前走一步。

项目中标或签约后，售前还要把已经确认的需求、方案范围、测试结论和对客户做出的技术承诺交接给实施或交付团队。售前不等于实施，但交接不清楚，前期承诺就可能在后期变成项目风险。

用一个项目把这些工作串起来

假设某企业准备建设一套新的业务系统。销售最初得到的信息只有一句：“客户明年要做系统升级，最近正在看方案。”

售前第一次和客户交流后发现，客户表面上说的是系统升级，实际还涉及旧系统数据迁移、与现有平台对接，以及在指定时间前完成上线。参与决策的也不只有技术部门，业务部门关心使用效果，管理者关心投入和风险，采购部门则有自己的预算与流程。

售前根据第一轮信息整理出需求和问题清单，回到公司协调产品、研发和交付人员，形成初步架构、汇报材料和产品配置。第二次交流时，客户又提出了一个此前没有说明的接口要求，原来的方案因此需要调整。

方案修改后，客户对其中一项关键能力仍然不放心，于是要求做 PoC。售前需要和客户共同确定测试用例和通过标准，再协调内部人员准备环境并完成测试。测试中暴露出的问题解决后，双方确认了测试结果，客户才开始正式申请预算和准备内部评审。

为了帮助客户立项，售前继续提供技术方案、产品参数和可研所需内容。项目进入招标阶段后，售前又要分析招标参数、准备技术投标文件，并根据最终方案更新配置。中标以后，再把需求、方案、测试结论和承诺边界完整交给实施团队。

这个例子看起来有一条先后顺序，但真实项目很少一路向前。客户每提供一条新信息，都可能让项目重新回到需求、方案、测试或配置阶段。售前的很多工作，就是在这种反复中把信息补齐、把分歧解决，并让项目继续向前推进。

二、项目外：售前还要做什么

售前并不是只有出现具体项目时才工作。很多项目能够顺利推进，依赖的是项目之外长期积累的产品能力、解决方案和合作关系。

1. 市场与需求洞察

售前长期工作在客户一线，能够直接听到客户对产品和解决方案的反馈，也更容易发现新的业务场景和政策变化。

销售同样了解客户，但通常更关注商务关系和项目节奏；实施更熟悉产品落地后的具体问题，但工作重点在交付。售前处在产品、销售和客户之间，因此更适合把一线需求整理后带回公司，帮助产品和解决方案团队判断市场变化。

2. 解决方案沉淀与优化

单个项目中调整过的方案，如果具有共性，就不应该只留在一个项目里。售前需要把典型场景、常见问题、配置方法和材料模板逐步沉淀下来，形成可以复用的解决方案。

这些积累既能减少后续项目重复劳动，也能帮助公司发现标准方案在哪些场景下存在不足，进一步调整产品能力、方案竞争力和交付成本。

3. 销售与渠道培训

新产品发布、产品政策调整、解决方案更新，都需要向一线销售和渠道进行培训。这里的渠道，是帮助厂商触达和服务最终客户的合作伙伴，例如总代、分销商、经销商和集成商。

培训的目标不是把产品资料念一遍，而是让销售和渠道知道产品适合什么客户、能解决什么问题、项目中应该收集哪些信息，以及遇到技术问题时如何继续推进。

4. 渠道发展与持续支持

售前通常会参与渠道的产品和方案导入。面对新渠道，需要帮助对方认识公司、理解产品、判断合作场景，并推动第一批项目落地；面对已经合作的渠道，则要持续提高渠道人员的产品能力，更新公司政策、解决方案和新老产品信息。

一些重要渠道和重点客户会长期向售前咨询问题。售前甚至会产生一种“我被卖给这个渠道或客户了”的感觉。持续响应的目的不只是维护关系，也是让对方在出现新项目时，能够更快地想到并采用公司的产品和方案。

5. 市场活动支撑

渠道答谢会、渠道培训会、客户行业沙龙和产品发布活动，也经常需要售前参与。有些公司有专门的市场团队负责组织，但产品和解决方案内容通常仍需要售前准备和宣讲。

活动看起来不属于具体项目，却可能帮助公司影响一批客户和渠道，为后续项目创造机会。

不同业务角色中的售前

同样叫“售前”，在不同业务角色中的工作重点会有明显差别。这里说的原厂、集成商、分销商和经销商，是公司在业务链条中承担的角色，不代表公司的规模大小；同一家公司也可能同时承担多种角色。

业务角色	在业务链条中的位置	售前工作的侧重点
原厂	拥有产品或解决方案的研发能力和所有权	要求深入理解自家产品，负责产品交流、方案设计、配置、PoC、招投标和渠道赋能，并把一线需求反馈给产品团队
系统集成商	根据客户整体需求，组合多个厂商的产品并完成系统集成	更重视客户业务理解、总体架构、跨厂商协调和综合方案能力；招投标和项目统筹工作通常较多
总代／分销商	连接原厂与下游渠道，承担产品分销、渠道覆盖和部分项目支持	更重视选型配置、产品政策、渠道培训、项目报备和上下游协调；是否配置完整售前团队取决于产品复杂度和业务模式
经销商／渠道商	面向最终客户销售和服务一个或多个厂商的产品	工作深度取决于项目复杂度；简单项目可能主要依赖原厂或分销商售前，复杂项目也会建立自己的售前和方案团队

因此，判断一个售前岗位具体要做什么，不能只看职位名称，还要看公司在业务链条中的位置、产品复杂度、客户类型和项目模式。

收尾

至此，IT 售前的岗位地图基本介绍完了。

如果只用一句话概括：售前就是连接客户需求与公司产品能力的人：对外让客户理解并认可方案，对内让公司理解需求并组织资源，最终推动项目向前。

这篇文章只介绍了全貌，还有很多内容值得单独展开，例如《如何更好地理解和获取客户需求》《招投标能力全解》《如何做好一场 PoC》，以及 To B 业务里原厂、总代、分销商、经销商和集成商之间到底是什么关系。后面会逐一分享。