先看结论
先让每条询盘有稳定编号、接手人、当前状态、下一步和到期时间，再决定用表格、现成CRM还是定制。自动通知只是发出信号，销售明确接手并能追溯后续动作，才形成可管理的流程。
最小线索记录要有的字段
先对照当前状态；窄屏可左右滑动查看完整表格。
| 字段 | 业务用途 | 容易遗漏的边界 |
|---|---|---|
| 稳定编号 | 关联原始需求与后续记录 | 重复提交和再次采购如何处理 |
| 负责人/备份人 | 明确谁要回复 | 休假、离职和时区交接 |
| 阶段/原因 | 区分待联系、确认、报价等 | 不能只凭换状态宣称已成交 |
| 下一步/日期 | 把处理变成可追踪动作 | 提醒失败和超时升级 |
先定义什么算同一条线索
同一人连续补充图纸可能是同一需求，不同采购任务也可能来自同一邮箱。只按邮箱去重容易误合并；只按每次提交新建又会重复跟进。明确业务合并规则，保留原记录与变更依据。
给联系人、公司和采购任务分层思考。团队尚小时可从受控表格开始，但必须管理访问、备份与编辑冲突。工具简化不等于客户数据可以随意发到群聊。
接手需要可见确认
规定由谁分配、谁确认、多久未处理进入待办。具体时限按销售排班和市场确定，不凭空承诺全天响应。让备用人员能在权限范围内补位，而非只依靠一个人邮箱中的未读标记。
通知被SMTP接受、销售打开列表、完成首次回复是不同事件。按实际可验证能力记录，不为了显得自动化而虚构“已读”。
接口故障要有重放与对账路径
若网站连接CRM，约定稳定业务ID、字段映射、权限、失败队列和重试规则。同一需求重复发送不能在目标系统不断新增记录；删除或撤回也应有可理解的处理方式。
先用脱敏测试验证创建、更新、重复和失败，再讨论大规模接入。采购方提供某系统名称，不证明对应API、套餐和地区已允许集成；未知项要在报价前确认。
把建议变成操作
按步骤做，并留下能核对的证据
- 01
统一入口登记
用稳定编号汇集获准使用的需求来源。
留下的证据原记录仍可追溯，不丢附件权限。
- 02
定义阶段
为每个阶段写进入条件与退出动作。
留下的证据有效、报价、成交不会混为一类。
- 03
安排补位
制定接手、提醒、休假和超时处理。
留下的证据实际排班有负责人及备用人。
- 04
演练异常
模拟重复、连接失败与人员替换。
留下的证据没有无主记录，恢复后不重复建单。
可填写 / 可复制
把这份工作单带进项目
填写与勾选仅留在当前页面，不上传、不发送给统计工具，刷新后清空。请下载或打印自行保存。
我的验收清单
完成相应操作、拿到证据后再勾选；勾选不代表网站或Google已经替你验证。
这几个错误会让工作白做
全员都收邮件就算有人负责
多人收到不等于有人接手，明确主责与补位。
用CRM覆盖原始需求
应保留关键原文和变更依据，避免断链。
把提醒成功当作已经回复
提醒、接手和回复要分开核实。
开始执行前，常见的问题
必须定制CRM吗？
不一定。先验证流程和权限，通用工具能完成时无需为定制而定制。
如何评价接入成功？
应能追溯一条测试需求从来源到目标、更新与失败恢复，不能只看接口返回200。
资料与适用边界
以下一手资料用于核对文中涉及的技术规则。项目拆解、比较表、工作模板与验收流程为LJWE编辑建议，不是官方强制流程，也不是已完成项目的实测记录。采用前请结合你的产品、工具版本与权限复核。
- GA4：推荐事件与使用条件 ↗资料查阅：2026-10-21
- Google Analytics：避免发送个人身份信息 ↗资料查阅：2026-10-21
本文没有引用客户成绩、市场均价或保证获客结果。涉及账号权属、商业授权、客户数据与保密义务时，应依据实际合同、平台条件和适用要求确认。