微信聊天聊完，怎么整理成能回填 CRM 的记录

教程定位

这篇教程解决什么问题

很多销售机会不是在正式会议里推进的，而是在微信里一点点发生变化。客户先问了一句“你们这个怎么收费”，隔天又补一句“我们可能下个月才看预算”，过几天在群里说“先发个案例，我给老板看看”。这些话都很关键，但最后 CRM 里往往只留下“客户有兴趣，已发资料，继续跟进”。等主管复盘、同事接手、销售休假或客户突然追问报价时，大家只能重新翻聊天记录。

这篇教程教销售运营或销售代表把微信聊天记录整理成可回填 CRM 的字段表。重点不是重新设计 CRM 字段体系，也不是把聊天记录润色成一篇销售纪要，而是从已有聊天里提取可以追溯的事实：客户需求、预算线索、时间点、决策人或影响人、异议、客户承诺、我方承诺、待确认事项。每一个字段都要能回到原话或截图位置，不能凭“感觉客户应该是这样想的”补出来。

AI 在这里适合做结构化整理：它可以帮你从多段微信聊天截图、客户资料、报价记录和会议纪要里找出相关句子，归类到 CRM 字段，并生成一段简短的原话摘要。AI 不适合替你判断客户一定有预算，不适合把“我问问领导”写成“决策人已确认”，也不适合把客户一句“可以了解”升级成明确承诺。

最终交付物是一份“微信记录转 CRM 字段表”。它最好包含三层内容：第一层是 CRM 可以直接使用的字段值；第二层是对应原话摘要；第三层是确定性标记，比如“已确认”“材料中有线索”“待人工确认”。这样销售自己能快速回填，主管能检查依据，交接人也能知道下一步为什么这么跟。

使用场景

什么情况下最适合用这一套

你可能是销售运营，负责检查 CRM 记录质量，也可能是一线销售，正在跟进多个客户。客户真正表达需求、顾虑和推进节奏的地方，常常不是 CRM，也不是正式会议纪要，而是微信私聊或小群。客户在电话后发来截图，问“这个功能能不能解决门店报备”；采购在群里说“合同模板和付款节点先给我”；业务负责人私下说“老板看的是投入产出，不太关心功能列表”；使用人又在晚上补一句“我们这边最怕一线不填”。

这些信息如果没有及时进 CRM，后果会很具体。主管看到商机只知道“已沟通”，不知道客户到底卡在预算、老板、采购流程还是产品顾虑。新同事接手时，只能重新问客户同样的问题，显得团队内部没有衔接。报价时，销售忘了客户曾经强调“先试点再采购”，结果直接发了年度报价。到了月底预测，销售说“这个客户应该有戏”，主管却找不到任何原话证据。

适合用这篇方法的场景包括：

这篇文章的边界也要说清楚。本文不负责设计一套新的 CRM 字段体系，不讨论你们公司应该用哪些阶段、哪些必填字段，也不做客户画像或销售策略。这里假设你已经有一些 CRM 字段，例如需求摘要、预算状态、预计采购时间、关键联系人、决策链线索、主要异议、下一步动作。我们只处理一件事：把微信聊天里已经出现的信息，安全、克制、可追溯地填进去。

下面会使用虚构客户“客户 A”和脱敏角色“运营负责人 B”“采购联系人 C”。所有公司名、人物、金额、时间和聊天内容均为示例，不对应真实客户。真实使用时，请先打码手机号、微信号、头像、群名、公司真实名称、订单号、合同编号和个人身份信息。

• 客户关键反馈散落在多段微信私聊和微信群里。
• CRM 里只有“已发资料”“客户考虑中”“下周跟进”等简单备注。
• 销售要交接客户，但聊天记录太长，接手人抓不到重点。
• 主管要判断商机阶段，却看不到预算、时间点、决策人和异议证据。
• 客户多次提到需求和顾虑，但销售不知道该填进哪些 CRM 字段。
• 报价记录、会议纪要和微信聊天互相补充，需要统一成一份可追溯记录。

材料准备

开始前先把材料和边界备齐

开始整理前，先准备四类材料。材料越干净，AI 输出越少胡编。

第一类是微信聊天记录。可以是截图转文字，也可以是你手动复制的聊天片段。建议按时间顺序整理，并标注来源，例如“私聊”“客户项目群”“销售转述”。如果来自截图，最好保留截图编号，例如“截图 01”“截图 02”，方便后续追溯。不要把真实手机号、微信号、头像、二维码、精确地址、身份证件、个人隐私和客户内部敏感截图原样发给 AI。能脱敏就先脱敏成“联系人 B”“客户项目群”“报价截图已脱敏”。

第二类是客户资料。至少包括行业、客户规模、当前商机阶段、已有联系人角色、线索来源、历史沟通摘要。客户资料的作用是帮助 AI 理解聊天里的指代关系，比如“老板”“总部”“门店”“财务那边”分别可能对应哪些角色。但如果聊天和资料里没有明确说谁是决策人，AI 只能标记“疑似决策相关人”，不能直接写“决策人是某某”。

第三类是 CRM 字段。你需要把这次要回填的字段列出来。比如：客户需求、使用场景、预算状态、预计采购时间、决策人/影响人、主要异议、客户承诺、我方承诺、下一步动作、阶段建议、证据摘要。字段名最好沿用你们 CRM 现有字段，不要让 AI 自己新增一堆字段，否则输出看起来很完整，但无法落到系统里。

第四类是报价记录和会议纪要。微信里常有很多简写，例如“按上次那个版本”“老板还是嫌贵”“先照会里说的发”。如果没有报价记录和会议纪要，AI 很难判断“上次那个版本”是什么，也不能知道客户嫌贵是嫌总价、付款方式、功能范围还是 ROI 不清。相关材料可以只给摘要，不要贴完整合同或真实报价单。

正式整理前，还要给 AI 设定三条硬边界：

1. 没有原话证据的字段必须标“待确认”。
2. 预算、决策人、采购时间和客户承诺不能由 AI 推测补全。
3. CRM 字段值要和证据摘要分开，避免把聊天原文直接塞进系统。

实操流程

按这套步骤把工作跑起来

第一步，先做聊天清洗，不要直接让 AI 写 CRM 备注。把聊天按时间顺序放好，删除表情、寒暄、重复确认、无关闲聊，但保留客户对需求、时间、预算、角色、顾虑、材料、报价和下一步动作的表达。清洗不是改写客户意思，而是减少噪音。比如“好的好的，周三可能看下，你先发我”可以保留成“客户表示周三可能查看材料，并要求我方先发送资料”，但不要改成“客户承诺周三评估方案”。

第二步，给每段聊天标注说话人和来源。微信聊天最容易混乱的地方，是“这句话到底谁说的”。同一句“老板觉得贵”，如果是采购说的、使用人转述的、还是销售自己总结的，可信度完全不同。建议格式是：“时间 + 来源 + 说话人 + 原话/摘要”。这样 AI 才能把“客户原话”“客户转述”“销售判断”分开。

第三步，建立字段映射表。把 CRM 字段放在第一列，把可用原话放在第二列，把字段值放在第三列，把确定性放在第四列。例如“预算状态”对应客户原话“今年预算不一定能加，要看 8 月专项”，字段值就可以写“预算未确认，可能等待 8 月专项”，确定性为“中高”。如果没有预算原话，只能写“未提及预算”，不能因为客户问报价就写“有预算”。

第四步，提取客户需求。需求字段要尽量来自客户自己的问题和痛点，不要来自销售的产品卖点。客户说“现在每周靠手工汇总，领导要看漏斗变化”，可以写成“需要减少手工汇总，并让管理层看到销售漏斗变化”。客户只问“你们有看板吗”，还不能直接写成“客户需要销售管理看板”，更稳的是“客户询问看板能力，具体需求待确认”。

第五步，提取时间点。时间点包括客户提到的评估时间、内部会议、预算窗口、上线期望、试点周期、合同流程节点。要特别区分“确定时间”和“模糊时间”。“下周三我们开会，可以会后再聊”是较明确的跟进窗口；“最近忙完再看”就是模糊时间；“可能下季度”不能写成“预计下季度采购”。CRM 里可以填“预计时间点：下季度待确认”，证据摘要里写清客户原话。

第六步，提取预算线索。预算字段是高风险字段，必须克制。客户问价格，不等于有预算；客户说贵，不等于没有预算；客户说“预算要领导看”，不等于领导已批准。可以把预算拆成三种状态：已明确、出现线索、未确认。已明确需要客户说出预算区间、审批口径或已立项信息；出现线索可以是“要看专项”“今年预算排满”“先试点再申请”；未确认就是聊天里没有可靠依据。

第七步，提取决策人和影响人。微信里常见“我问下老板”“采购那边要看合同”“使用部门觉得可以”“总部要确认安全”。这些都是角色线索，但不是完整决策链。AI 可以输出“疑似预算审批相关人：老板，来源为 B 转述”，或“采购流程相关人：采购联系人 C，来源为群聊要求合同模板”。除非材料明确写出“最终由某角色审批”，否则不要写“决策人已确认”。

第八步，提取异议和顾虑。异议通常藏在轻描淡写的句子里：“你们这个会不会太重”“我们销售不一定愿意填”“之前系统推不起来”“这个价格老板可能不太好过”“数据能不能不出域”。这些都应该进入 CRM 的主要异议字段。异议不是负面标签，而是下一步跟进要回应的问题。

第九步，提取承诺。承诺必须有主体、动作和时间或条件。客户说“我看看”不是承诺；“我周五前把试点门店名单发你”才是承诺。销售说“我今天发案例和报价范围”是我方承诺，也要记录。CRM 里最好分开写“客户承诺”和“我方承诺”，否则后续很难追责到底是哪边卡住。

第十步，生成可追溯摘要。最后让 AI 输出一份短摘要，适合粘到 CRM。摘要要包含字段值和证据，不要只写结论。好的写法是：“客户 B 表示当前靠手工汇总销售漏斗，领导希望看到周变化；预算需看 8 月专项，未确认；B 会在周三内部会后反馈是否安排演示。”这比“客户有需求，预算待定，继续跟进”更有用。

输入示例

可以直接参考的输入材料

下面是一份脱敏后的输入样例。真实使用时，可以把截图文字、客户资料、CRM 字段和会议摘要按这个结构贴给 AI。

这个输入里有真实需求，也有明显风险。客户讲了门店反馈慢、总部看闭环、门店怕复杂；也提到预算不确定、老板未参与、去年系统没推起来。AI 的任务是把这些信息放进正确字段，而不是把客户包装成“强意向”。

任务背景：
我是销售代表，需要把微信聊天记录整理成可回填 CRM 的字段表。请只基于以下材料提取，不要编造预算、决策人和客户承诺。

客户资料：
- 客户：客户 A，连锁服务行业，约 60 家门店，名称已脱敏。
- 当前阶段：初次沟通后，已做过一次线上产品介绍。
- 已知联系人：运营负责人 B，采购联系人 C。
- 产品方向：销售跟进和门店问题闭环工具。

CRM 需要回填的字段：
1. 客户需求摘要
2. 预算状态
3. 预计推进时间
4. 决策人/影响人线索
5. 主要异议
6. 客户承诺
7. 我方承诺
8. 下一步动作
9. 原话证据摘要

微信聊天记录，已脱敏：
[截图 01，私聊，周一 10:18，运营负责人 B]
B：我们现在门店反馈问题主要还是在群里，区域经理每周要手工汇总，老板看起来很慢。

[截图 02，私聊，周一 10:23，运营负责人 B]
B：你们有没有那种门店不用填太多，但总部能看到闭环进度的案例？

[截图 03，客户项目群，周二 16:40，采购联系人 C]
C：合同模板和付款节点先发一下，我们内部要看流程。

[截图 04，私聊，周三 09:12，运营负责人 B]
B：价格老板可能会问，去年我们看过一个系统，门店说太复杂，后来就没推。

[截图 05，私聊，周三 09:18，运营负责人 B]
B：预算现在还不好说，8 月可能有专项，但要看老板怎么定。

[截图 06，私聊，周三 09:21，运营负责人 B]
B：你先发一个同规模客户案例和大概报价区间，我周五内部会后看看能不能约老板一起听一下。

报价记录摘要：
- 我方曾在会上口头说明基础版和标准版区间，但未发送正式报价。
- 暂无合同或正式报价单。

会议纪要摘要：
- B 在会上强调门店不愿多填系统。
- 我方承诺补充“轻量使用案例”和“闭环看板截图”。

请输出一份微信记录转 CRM 字段表，并为每个字段附原话证据摘要和确定性。

提示词

可复制使用的提示词

你可以复制下面这段提示词，把自己的脱敏材料替换进去。建议每次只处理一个客户或一个商机，不要把多个客户聊天混在一起。

如果聊天记录很长，可以分两轮。第一轮只让 AI 做“证据清单”，把所有相关原话按需求、预算、时间、角色、异议、承诺分类。第二轮再让 AI 做 CRM 字段表。这样能减少遗漏，也能让你先检查证据是否准确。

你是我的销售运营记录整理助手。请根据我提供的微信聊天记录、客户资料、CRM 字段、报价记录和会议纪要，整理一份“微信记录转 CRM 字段表”。

工作目标：
1. 从聊天记录中提取客户需求、时间点、预算、决策人/影响人、异议、客户承诺和我方承诺。
2. 把每条信息映射到我给出的 CRM 字段。
3. 每个字段都要附原话证据摘要，说明来自哪条聊天或哪份材料。
4. 区分客户原话、客户转述、销售判断和 AI 推断。
5. 对证据不足的内容标记“待确认”，不要补成确定结论。

硬性规则：
- 不要编造预算。客户问价格、嫌贵、要求报价，都不能自动写成“已有预算”。
- 不要编造决策人。客户说“老板看看”“领导问一下”，只能写成决策相关线索，不能写成决策人已确认。
- 不要编造客户承诺。“我看看”“先发我”“回头聊”不是承诺。承诺必须包含客户方主体、动作、时间或明确条件。
- 不要把销售判断写成客户事实。销售感觉客户有兴趣，只能放在“销售判断”，不能放进“客户原话”。
- 不要输出真实手机号、微信号、头像、地址、身份证件、合同编号等敏感信息。
- 如果材料互相冲突，请列出冲突点，不要替客户做最终解释。

请按以下格式输出：

A. 微信记录转 CRM 字段表
| CRM 字段 | 建议填写内容 | 原话证据摘要 | 来源 | 确定性 | 需要人工确认的问题 |

B. 原话证据清单
| 证据编号 | 来源 | 说话人 | 原话或脱敏摘要 | 可支持的字段 |

C. CRM 简短备注
控制在 200 字以内，适合直接粘贴到 CRM。必须包含“待确认”的风险，不要只写积极结论。

D. 下一步跟进清单
区分客户承诺、我方承诺、销售需要确认的问题。

材料如下：
[粘贴客户资料]
[粘贴 CRM 字段]
[粘贴微信聊天记录]
[粘贴报价记录]
[粘贴会议纪要]

输出样例

AI 应该输出到什么程度

下面是基于前面虚构输入生成的一版输出样例。它展示的是结构，不代表真实客户判断。

这版输出的优点是有证据、有确定性、有待确认问题。它没有把“老板可能会问价格”写成“老板反对价格”，也没有把“看看能不能约老板”写成“老板已同意见面”。这就是微信记录结构化时最重要的克制。

### A. 微信记录转 CRM 字段表

| CRM 字段 | 建议填写内容 | 原话证据摘要 | 来源 | 确定性 | 需要人工确认的问题 |
|---|---|---|---|---|---|
| 客户需求摘要 | 客户希望减少门店问题在微信群里分散反馈和区域经理手工汇总的工作，并让总部看到问题闭环进度；同时要求门店端不要填写太多。 | B 表示“门店反馈问题主要还是在群里”“区域经理每周要手工汇总”“总部能看到闭环进度”“门店不用填太多”。 | 截图 01、截图 02、会议纪要 | 高 | 需要确认总部最关注哪些闭环指标。 |
| 预算状态 | 预算未确认，可能与 8 月专项有关，需老板判断。不能写成已有预算。 | B 表示“预算现在还不好说，8 月可能有专项，但要看老板怎么定”。 | 截图 05 | 高 | 8 月专项是否已立项，预算审批口径是什么。 |
| 预计推进时间 | 周五内部会后可能反馈是否约老板听方案；不是已确认会议。 | B 表示“我周五内部会后看看能不能约老板一起听一下”。 | 截图 06 | 中高 | 周五会后是否能给出明确下一次沟通时间。 |
| 决策人/影响人线索 | 老板可能参与预算和方案判断；B 是运营侧推动人；C 参与采购流程。决策人尚未确认。 | B 多次提到老板会问价格、预算要看老板怎么定；C 在群里索要合同模板和付款节点。 | 截图 03、截图 04、截图 05、截图 06 | 中 | 老板是否为最终审批人，C 是否只负责流程。 |
| 主要异议 | 价格可能被老板关注；客户去年看过系统但因门店觉得复杂未推行，落地复杂度是主要顾虑。 | B 表示“价格老板可能会问”“去年看过一个系统，门店说太复杂，后来就没推”。 | 截图 04 | 高 | 去年系统失败的具体原因是什么，门店端能接受哪些动作。 |
| 客户承诺 | B 表示周五内部会后看看能否约老板一起听方案。该项是弱承诺，需要会后确认；C 要求我方先发合同模板和付款节点。 | “周五内部会后看看能不能约老板一起听一下”；“合同模板和付款节点先发一下”。 | 截图 03、截图 06 | 中 | 周五后是否确认老板参会；采购是否需要正式报价。 |
| 我方承诺 | 我方需发送同规模客户案例、大概报价区间、合同模板、付款节点、轻量使用案例和闭环看板截图。 | B 要求发送案例和报价区间；C 要求合同模板和付款节点；会议纪要记录我方承诺补充案例和看板截图。 | 截图 03、截图 06、会议纪要 | 高 | 是否需要销售运营或法务确认材料版本。 |
| 下一步动作 | 今天内发送脱敏同规模案例、报价区间说明、合同模板和付款节点；周五内部会后跟进 B，确认是否安排老板参与下一次沟通。 | 对应 B 和 C 的材料请求，以及周五内部会后反馈窗口。 | 截图 03、截图 06 | 高 | 跟进时先确认老板关注点和预算专项情况。 |
| 原话证据摘要 | 客户当前痛点是微信群反馈和手工汇总，总部希望看闭环；预算未确认，可能看 8 月专项；老板可能关注价格；历史顾虑是门店嫌系统复杂；下一步是我方发材料，B 周五会后看是否约老板。 | 多条聊天共同支持。 | 截图 01 至 06、会议纪要 | 高 | 回填 CRM 前需人工核对截图编号。 |

### B. 原话证据清单

| 证据编号 | 来源 | 说话人 | 原话或脱敏摘要 | 可支持的字段 |
|---|---|---|---|---|
| E01 | 截图 01 私聊 | 运营负责人 B | “门店反馈问题主要还是在群里，区域经理每周要手工汇总。” | 客户需求摘要 |
| E02 | 截图 02 私聊 | 运营负责人 B | “门店不用填太多，但总部能看到闭环进度。” | 客户需求摘要、主要异议 |
| E03 | 截图 03 客户项目群 | 采购联系人 C | “合同模板和付款节点先发一下，我们内部要看流程。” | 我方承诺、采购流程线索 |
| E04 | 截图 04 私聊 | 运营负责人 B | “价格老板可能会问”“去年系统太复杂，后来没推。” | 主要异议、决策人线索 |
| E05 | 截图 05 私聊 | 运营负责人 B | “预算现在还不好说，8 月可能有专项，但要看老板怎么定。” | 预算状态、决策人线索 |
| E06 | 截图 06 私聊 | 运营负责人 B | “先发同规模客户案例和大概报价区间，周五内部会后看看能不能约老板。” | 下一步动作、客户承诺、我方承诺 |

### C. CRM 简短备注

客户 B 反馈门店问题仍靠微信群反馈，区域经理每周手工汇总，总部希望看到闭环进度，且门店端不能太复杂。预算未确认，可能看 8 月专项，老板会关注价格。B 要求发送同规模案例和报价区间，C 要合同模板和付款节点。周五内部会后确认是否可约老板听方案。

### D. 下一步跟进清单

- 客户承诺：B 周五内部会后反馈是否能约老板一起听方案，属于弱承诺，需确认。
- 我方承诺：发送同规模客户案例、大概报价区间、合同模板、付款节点、轻量使用案例和闭环看板截图。
- 销售需要确认的问题：
  1. 老板是否为最终预算审批人，还是只参与方向判断？
  2. 8 月专项是否已立项，预算区间是否有口径？
  3. 去年系统复杂的具体问题是什么，门店最多能接受哪些填写动作？
  4. 周五内部会后能否约定下一次沟通时间和参会人？

人工验收

人要怎么检查和改到可用

AI 输出后，不要马上复制进 CRM。先做一遍人工检查，尤其是预算、决策人和承诺三类字段。

第一，检查字段是否都有原话证据。每个字段都应该能对应到截图编号、聊天时间、说话人或会议纪要。如果“决策人”字段只写了“老板”，但证据只是客户说“老板可能会问”，那就要改成“老板为预算/价格相关影响人线索，最终决策角色待确认”。CRM 里宁可多写一个“待确认”，也不要写一个看起来很确定的假结论。

第二，检查 AI 是否把客户转述当成客户本人表态。微信里常见“老板觉得贵”“财务说流程麻烦”“使用部门可能不愿意”。这些大多是联系人转述，不等于老板、财务或使用部门本人已经表达。字段里要写清“由 B 转述”，而不是直接写“老板认为价格过高”。如果后续要推进，这种转述正好可以变成确认问题。

第三，检查预算字段有没有被过度解释。客户问报价，只能说明客户需要价格信息；客户说“贵”，可能是预算不足，也可能是价值没讲清；客户说“等专项”，也不等于专项一定会批。预算字段建议写成“已明确”“有线索”“未确认”三档。没有原话支撑时，不要填预算金额、采购概率或预计成交日期。

第四，检查客户承诺是否满足标准。承诺至少要有主体、动作和时间或条件。比如“C 要求我方发送合同模板和付款节点”是明确请求，但不是客户推进承诺；“B 周五会后看看能否约老板”是弱承诺，不是已约定会议；“客户说回头聊”不是承诺，只能算下一步线索。承诺字段越严谨，月底复盘越少争议。

第五，检查 CRM 简短备注是否可读。CRM 备注不要复制整段聊天，也不要只留下结论。建议控制在 150 到 250 字，包含需求、风险、下一步和证据口径。例如“预算未确认，来源为 B 表示 8 月可能有专项”，比“预算待定”更有价值。接手人看到这句话，知道下一次要问什么。

第六，检查隐私和权限。回填 CRM 前，删除微信号、手机号、二维码、头像、客户内部个人评价、未授权截图和非必要群聊成员信息。CRM 不是聊天备份工具，不要把整段私聊原文全部塞进去。你要保存的是对销售推进有用的字段和证据摘要，而不是客户所有聊天细节。

失败反例

这些失败反例要提前避开

【反例 1：把“问报价”写成“有预算”】

错误写法：

问题在于，客户问价格只是信息收集，不代表预算已经存在。尤其在微信场景里，客户可能只是想判断是否值得继续聊，也可能是替老板先问个范围。正确写法应该更克制：

【反例 2：把“我问下老板”写成“决策人确认”】

错误写法：

这类写法会让主管误判商机已经接近决策。事实上，“我问下老板”只说明老板可能是影响人或审批相关人，也可能只是联系人需要内部请示。正确写法应该是：

【反例 3：把“先发资料”写成“客户承诺推进”】

错误写法：

“先发资料”通常只是一个低成本动作，可能是客户真的要内部讨论，也可能是礼貌结束聊天。它不能直接变成推进承诺。正确写法应该是：

【反例 4：把销售判断混进客户原话】

错误写法：

如果客户没有说“认可方案”，这句话就是销售判断，不是客户原话。正确写法要拆开：

这四个反例的共同问题，是把微信里的模糊信号写成确定结论。CRM 记录不是为了显得商机很好看，而是为了让团队知道下一步该确认什么。

预算状态：客户已有预算，正在比较价格。
证据：客户问“大概多少钱”。

预算状态：预算未确认。客户询问大概价格，说明需要价格信息，但未提供预算区间或审批状态。
需要确认：是否已有预算口径，预算由谁审批，预算时间窗口是什么。

决策人：老板。客户已进入老板确认阶段。
证据：B 说“我问下老板”。

决策人/影响人线索：老板可能参与预算或方案判断，来源为 B 转述“我问下老板”。最终决策人和审批流程未确认。
下一步问题：如果老板要看，最关心价格、效果还是落地风险？是否需要一页版材料辅助 B 转述？

客户承诺：客户同意推进，要求先发资料。
下一步：等待客户确认采购。

客户承诺：客户要求我方先发送资料。暂未承诺下一次会议、采购动作或明确反馈时间。
我方承诺：今天发送同规模案例和功能摘要。
下一步：发送后确认资料是否用于内部讨论，以及是否能约定下一次沟通时间。

客户原话：客户很认可我们方案，只是担心价格。

客户原话：客户问“你们有没有同规模案例”“大概报价区间是多少”。
销售判断：客户愿意继续了解，但认可程度和价格接受度待确认。

主题边界

它和相邻主题的区别

这篇主题和“电话沟通后补齐客户原话和风险信号”很接近，但处理对象不同。电话记录通常来自一次完整通话，信息相对集中；微信聊天往往跨多天、多段、多角色，原话碎片化，更容易出现指代不清、转述不清和承诺边界不清。因此本文更强调截图编号、聊天来源、字段映射和可追溯证据。

它也不同于“多联系人商机，画出决策链和阻塞点”。决策链主题要判断一个商机中不同角色的影响力、态度和阻塞位置；本文只在微信聊天材料里提取“决策人/影响人线索”，不会把整个客户组织关系画出来。比如客户说“老板要看”，这里只能回填为线索和待确认问题，不能扩展成完整决策链图。

它还不同于“客户拜访纪要整理”。拜访纪要会关注会议议程、参会人、现场讨论、会后任务和客户承诺，通常信息更正式。微信记录转 CRM 字段更像是把散落在日常沟通里的事实捡起来，放到系统字段中，让后续跟进不靠记忆。

最后，它不是 CRM 字段设计教程。你不需要在这篇里创造新的销售方法论，也不需要重新定义商机阶段。你只要把现有聊天里能证明的内容，准确映射到已有字段，并清楚标注哪些内容是已确认、哪些只是线索、哪些必须人工再问。这样微信聊天才不会只停留在手机里，而能变成团队可交接、可复盘、可行动的销售记录。