本文定位：匿名客户案例。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
这是一篇匿名客户案例。客户是一家华东 B2B 设备服务商，销售团队 18 人，客户从展会、老客户转介绍、官网表单和售后工单里来。项目开始前，老板最焦虑的不是没有线索，而是线索没人持续推进。
二、关键症状：真正卡住业务的地方
我们没有一上来做复杂 CRM，而是先把线索、客户、商机、报价、回款五张表放进钉钉入口，销售每天只填关键动作，主管只看异常。第一阶段 5 周上线，第二阶段接入报价审批和合同台账，第三阶段把 AI Agent 放在跟进节奏上。
三、落地/救火路径：先收口，再扩展
关键不是让 AI 写销售话术，而是让它每天检查三件事：重点客户是否超过 7 天未跟进，报价后是否超过 3 天未回访，预计成交本月是否缺少下一步动作。异常不是发到大群，而是生成待办给责任销售，同时抄送主管。
四、结果：能被管理动作验证的变化
上线后最大的变化是经营会从“问感觉”变成“看清单”。销售不再需要在会上临时翻聊天记录，主管也不靠记忆盯人。老板看到的不是炫酷大屏，而是本周新增线索、推进停滞、报价未回访、预计回款风险四类清单。
五、给同行的建议：别先追求大而全
这个案例的经验是：中小企业做 CRM，不要先追求字段完整，要先抓住销售行为闭环。只要能把“谁负责、下一步是什么、什么时候检查”跑起来，后续接 AI 才有数据基础。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、为什么先放在钉钉里做
这个项目没有一开始采购重型 CRM，是因为客户的销售团队每天已经在钉钉里处理审批、日报和内部沟通。把入口放在钉钉，能减少切系统的阻力，也方便主管把异常变成待办。第一阶段只要把客户、商机、报价、回款这些核心对象统一起来，就能让管理动作先跑通。
后续再接 AI Agent 时，也不是让 AI 直接替销售成交，而是让它做三类辅助：提醒销售下一步动作，帮主管发现停滞商机，给老板汇总本周风险。AI 的价值建立在稳定 CRM 数据上；如果销售过程本身没有沉淀，AI 只能生成漂亮但不可验证的建议。
八、AI 提醒为什么放在第三阶段
这个项目里，AI Agent 没有一开始就上，是因为前两阶段必须先把销售过程沉淀下来。没有客户阶段、跟进记录、报价状态和回款节点，AI 只能根据零散聊天记录生成建议，准确性和可执行性都不稳定。
第一阶段先统一线索和商机，第二阶段接报价审批和合同台账，第三阶段才让 AI 做跟进提醒。这样 AI 检查的不是抽象问题，而是明确规则：重点客户几天没跟、报价后几天没回访、本月预计成交有没有下一步动作、回款风险有没有责任人。
AI 输出也不直接群发，而是形成个人待办和主管看板。销售看到的是“今天该处理什么”，主管看到的是“哪些商机需要辅导”，老板看到的是“本周风险在哪里”。三层视角不同，系统才不会变成信息轰炸。
九、这类 CRM 项目最小可上线范围
最小版本只需要五个对象：线索、客户、商机、报价、回款。每个对象字段不要多，但必须有负责人、状态、下一步动作和更新时间。只要这几个字段稳定，管理层就能看出销售过程有没有推进。
后续再增加合同、售后、备件、续费、客户分层和 AI 话术。中小企业 CRM 成功的关键，不是第一版多完整，而是第一版能不能让销售每天少漏一点、主管每周少盲一点、老板每月早一点看到风险。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
