商务服务工作手册

对照《量潮科技商务报价章程》的实操指南。

本手册覆盖从识别客户到项目启动的售前阶段。报价、合同、谈判等环节参见对应手册。

场景一：识别客户与定义服务¶

目标客户与问题场景¶

交付风格¶

话术模板¶

「根据您的需求，我建议我们这样来配合：首先明确您需要的数据范围和交付标准，我们出具一份详细的方案给您确认。确认后我们按里程碑推进，每个阶段都有可验证的交付物。这样您在每个节点都能看到进展，也能及时调整方向。」

设计者注：服务定义的起点不是"我们能做什么"，而是"客户在什么场景下需要什么"。先搞清楚客户类型和真实痛点，再匹配交付风格。高校客户要的是可存档的方案，企业客户要的是快速出结果——用错交付风格比报错价格更致命。

你不得做的事情：

• 不得在未明确客户类型和需求场景前启动评估

• 不得对不同类型客户使用同一套交付标准

场景二：获取销售线索¶

操作要点¶

以小红书渠道为例：

线索来源：

• 主动发现：日常浏览时留意软件、数据、算法类需求帖子

• 搜索辅助：针对性搜索关键词，配合推荐流

初步判断（鉴别真伪需求）：

• 优先关注老号（信用度更高），对新号需求保持谨慎

• 通过帖子内容、用户历史笔记判断需求真实性

初步接触：

1. 在帖子下评论留言，引导私信

2. 私信沟通目标：建立初步联系，将客户引入私域（如微信）深度沟通

话术模板¶

「看到您帖子提到需要做数据采集，这个方向我们有比较成熟的案例。方便的话可以私信聊一下具体需求，我帮您评估一下可行性和大概的周期。」

设计者注：线索获取的核心不是"量"而是"质"。一个月两三个真实需求比刷一百条无效线索有用。小红书是目前验证有效的渠道，但不代表唯一渠道——重点是理解客户在哪，就去哪找。

你不得做的事情：

• 不得在未判断需求真实性时投入评估资源

• 不得在未建立私域联系前给出详细报价

场景三：评估项目需求¶

操作要点¶

与客户沟通时，逐项确认以下要素：

数据源： 明确目标网站或平台（URL）

交付成果： 客户要的是数据集（最常见）还是代码？必须确认

字段需求： 与客户逐项确认数据字段，字段的任何变更都可能影响工期和报价

数据量级： 预估数据总量（如爬取10万条商品信息），这是报价的基础

合规性与反爬：

• 合规审查：明确数据用途是否合规，避免法律风险

• 技术评估：初步评估目标网站的反爬虫机制强弱——这是影响难度和成本的关键

话术模板¶

「为了给您一个准确的报价，我需要了解几个信息：目标网站是哪个？需要采集哪些字段？大概的数据量是多少？另外您这边对数据用途有什么要求吗——比如是否用于公开发表或商业用途。这些信息确认后，我让技术同事评估一下难度和周期，再给您出方案。」

设计者注：项目评估的本质是"把客户模糊的需求翻译成可执行的工作量"。很多报价纠纷的根源不是算错了，是需求本身没对齐。字段确认、数据量级、合规审查这三项是报价的基石——任何一项不明确都不该进入报价阶段。

你不得做的事情：

• 不得在未确认目标数据源时报价

• 不得在未评估反爬虫难度时承诺工期

• 不得跳过合规审查

场景四：组建团队与协作¶

角色分工¶

协作流程¶

销售获取线索 → 商务经理深度沟通 → 技术评估员评估难度
    → 商务经理报价谈判 → 项目经理接手执行 → 实施团队交付

话术模板¶

「这个项目我们会这样安排：前期由我（商务经理）全程对接您的需求，技术评估团队同步评估可行性和周期。项目签约后会有一位专职的项目经理负责进度管理和日常沟通，您有任何问题找他一个接口就行。执行团队由资深数据工程师带队，确保交付质量。」

设计者注：角色分工不是官僚主义，是防止"一个人干所有事"导致的瓶颈。销售擅长破冰但不一定擅长谈判，商务经理擅长谈价格但不一定擅长执行。各司其职才能跑起来。初期人少可以一人兼多角，但职责边界要清楚。

你不得做的事情：

• 不得让销售在未移交商务经理前承诺价格

• 不得在无项目经理时同时推进多个项目

附录：售前检查清单¶

验收标准：客户类型判断应准确，目标数据源和字段应已确认，数据量级和反爬难度应已评估，交付成果（数据集/代码）应已明确，合规审查应已通过，团队角色分配应清楚。

手册使用建议¶

1. 首次对接客户：按场景一到场景四的完整流程走一遍。

2. 具体团队人员、各角色当前人选以各业务线档案为准，手册不维护规则数据。

3. 手册不替代章程：章程条文是正式依据。当手册表述与章程条文出现差异时，以章程条文为准。