自从下定决心转岗到售前后，就开始想去了解售前这个岗位的职责，前景，以及知识技能，这本书将这些方面总结得特别好，虽然本书是国内的售前，但是核心的部分跟日本也是共通的，基于输出是最好的学习的原则，将本书中的核心部分，以及结合自己现在工作中的思考，整理在本文中，以此加强自己对售前岗位的理解。

本书是作者蒋珍波有10余年售前工作和管理经验的总结，不仅详细讲解了IT售前的全流程知识体系和工作技巧，而且还系统讲解了IT售前工程师的职业规划和职业发展要点。本书旨在快速提升IT售前工程师赢得项目的关键能力，实现快速成长。

本书具体内容分为两个部分：

第一部分，IT售前工作技能。首先非常详细地介绍了IT售前的常识、岗位职责、能力模型，然后选题地讲解了IT售前的全流程、客户需求深度挖掘、产品功能演示、技术交流、招投标等具体工作的方法和技巧。

第二部分，IT售前职业发展。作者首先分享了如何成为一位优秀的IT售前工程师，让自己的产出最大化；然后介绍了IT售前工程师如何做职业规划、如何向其他岗位转型以及如何保持持续正确地学习。此外，还总结了IT售前工作中常见的各种误区。

书接上一部分：

aiinrobot.jp

【読書】一本书讲透售前(2)-售前工作篇

🕒️2025年3月29日

table { width: 100%; border-collapse: collapse; background-color: #ffffff; box-shadow: 0 4px 10px rgba(0,0,0,0.05); border-radius: 8px; overflow: hidden; } th, td { padding: 14px 16px; border-bottom: 1px solid #e0e0e0; text-align: left; vertical-align: top; } thead { background-color: #0073aa; color: white; } tbody tr:hover { background-color: #f1f1f1; } .priority-high { color: white; ba...

🟩 工作篇-如何顺利通过PoC

PoC突出的是验证。既然是验证，那么就先得有一个验证的对象和范围，也就是PoC的需求，关键是准确理解客户的需求和出发点。

非常棒的内容！这段是关于 「什么时候该做PoC」以及如何判断是否值得投入」，我已经为你整理成逻辑清晰＋结构见やすい的格式，并配合表格和絵文字，让内容更直观易读 👇

什么情况下需要做PoC？

🏗️ PoC不是轻量级的工作！

💡 PoC 需要跨部门配合：

• 销售 & 售前 ➕ 研发团队 ➕ 实施团队
• 成本高 💸，资源重 🧑‍💻，周期长 📅

✅ 是否做PoC的判断标准

⛳ 目标：投入产出比合适，才值得启动 PoC

🧑‍💼 客户PoC流程中的关键人物

• 🔧 系统使用工程师：
• 话语权很高，往往 由他们撰写PoC报告
• 对结果评估具有决定性作用！
• 🧑‍💼 决策层负责人：
• 发出正式PoC邀请，供应商会面临多家竞争者。

⚔️ 供应商面临的三大挑战

🧠 售前策略建议

📍 什么时候可以主动建议客户做PoC？

✅ 满足以下条件时建议主动出击：

• 客户需求和我们产品高度匹配
• 对项目有信心
• 竞争对手明显不如我们

🎯 目的：提前占据客户心智，赢得先机

📣 客户为什么想做PoC？——锁定关键干系人！

🔍 分析发起PoC的人是谁？

🎯 明确受众 → 有的放矢 → 留下深刻印象！

📝 小结一句话

PoC是挑战，也是机会。明确投入价值，了解干系人角色，才能决胜于过程之中。

🔁 PoC的完整流程（6+1 步骤）

PoC通常分为以下 6 个主要步骤 + 补充注意事项：

🔍 ① 沟通需求（关键一步）

📌 目标：明确客户“想验证什么”＋“做到什么程度才算成功”

📝 建议：

• 正式会议+邮件确认需求 ✅
• 防止“PoC完成≠客户满意”❌

🧭 ② 设计PoC方案（售前主导）

📂 内容包括：

✔️ 和客户确认后再进入下一阶段！

🛠️ ③ 准备环境（提前两周沟通）

🖥️ 客户自建环境，我们只需提供软件能力

🔧 提前说明资源要求（如服务器配置）：

• 操作系统版本
• CPU / 内存 / 存储容量
• 网络和安全标准

📌 避免资源申请中断项目节奏！

👨‍💻 ④ 功能开发（小步快跑）

⚙️ 快速实现验证性功能 → 多轮测试 → 减少现场演示失误

❗注意：

• 时间紧、开发强度大
• 返工成本高，要尽量一次成功

🎤 ⑤ 现场演示（核心表现时刻）

📣 售前可以请技术协助演示，自己负责说明

🎬 四句话总结演示技巧：

📊 ⑥ 总结报告（影响最终结果）

📝 客户方：由工程师写报告，提交给负责人
📩 我方：形成总结文档，发给客户＋公司内部（销售、管理层）

📌 与客户主动沟通：

• 哪些做得好 👍
• 哪些需改进 👀
• 还有什么疑虑未解 ❓

🎯 每一次PoC都是一次宝贵的学习机会！

⚠️ ⑦ 补充注意事项（细节决定成败）

📌 总结一句话

PoC不是演戏，是实战。流程专业 + 细节周全 + 逻辑清晰 = 赢得客户信任。

✅如何保障 PoC 的质量？

虽然 PoC 看起来是个“小型临时项目”，但想要做好它，必须从以下 三大方面着手：

🧱 ① 平时的积累 = 成功的地基

📌 不做PoC时就要主动准备！尤其注意这两点：

📦 A. 搭建完整+可移植的PoC环境

• 完整：功能齐全、数据完备
• 可移植：支持快速部署到任意客户服务器（☁️容器化部署如 Docker 等）

♻️ B. 推动PoC结果的可复用性

• 将PoC开发中的代码、场景、脚本模块化、封装
• 建立PoC模块库（知识库）📚，下次可快速复用！

🎯 售前要推动公司建立 PoC知识库，不仅是帮公司，也是在帮自己提升效率！

🧩 ② 集结一切可用的力量 = 成功的组织力

PoC = 售前的实战指挥场！

💡 售前要成为 PoC 的 总指挥 & 协调者：

但即便不能全靠自己，也要：

✅ 拉研发支援
✅ 请实施部门协助
✅ 协调测试资源

💬 资源整合力决定PoC成败！

🔄 ③ 沟通与技术同样重要

PoC不是默默做完，而是持续对齐、演示呈现的全过程。

🗣️ 沟通贯穿全过程：

📌 千万不要只关注“技术实现”，忽略了“信息传递”！

📌 小结一句话

PoC做得好，靠的不只是技术，更靠日常积累、资源整合力与高效沟通。

🧾 本章小结

💬 这句俗语点出一个核心现实：

✅ 客户在没“亲眼看到”你的产品跑起来之前，是不会完全放心的。

🎯 PoC = 一次真实实力的验证

它不仅是 技术活，更是对 售前综合能力 的全面考验：

❗ 厂商常见心理：不想做PoC的3个理由

但❗不做PoC，可能连参与资格都没有！

🏗️ 售前必须明确三大PoC目标感：

🔧 PoC成功的核心保障：

1. 🧠 公司产品力要过硬（解决真实问题）
2. 👨‍🔧 技术人员要专业靠谱（执行力强）
3. 🧑‍💼 售前要不断沟通、持续对齐

📌 总结一句话

PoC是厂商真正“上场比武”的时刻，没有准备、协调、技术与产品力的全方位支撑，难以打动客户。

🟩 工作篇-正面较量：招投标

本节招标是国内的流程，与日本不同，就不做小结了