客户与商机

智造云 · 智能制造平台白皮书 ｜ 第二篇 能力篇

7.1 从这一章开始，讲系统里到底有什么

前面讲的是"为什么"。从这里起讲"什么东西放在哪里"，也就是产品事实。这一篇每章覆盖一条业务主线，写它怎么落地、卡在哪里会被拦住、哪些还是空的。

先从客户开始，是因为一家企业所有的依据都要挂到一个名字上。

老陈干这行十四年，手机里存着两百多个联系人，一半是某家公司的采购。小徐接手一个新客户时问过他："这家以前怎么让的价？"老陈想了很久，说："他们验收特别挑，光返工就返过三回。"

这句话里有两个值钱的信息：这家客户看重什么、我们为此付出过什么。 它们在老陈脑子里，不在任何一张表里。客户档案能记下电话、税号、开户行，记不下这两句。

所以我们把这一章的重心放在"怎么把这两句留下来"上——它听上去像软件功能，其实是一条管理要求。

7.2 一个客户只能有一个负责人

先解决最原始的乱：同一个客户被两家销售各报一次价。

这不是编出来的场景。客户换了个采购员，两个销售各自上门，各自报了一个价，客户拿两个价互相压——这种事每发生一次，掉的是真钱。

我们的做法很硬：同一个客户名，全公司只能有一个销售负责人。

• 你要新建一个已经存在的客户，系统直接拦下，并且告诉你负责人是谁："客户「某某」已存在，销售负责人为 张某。同一客户只能有一个销售负责人，不能重复创建。如需接手该客户，请由原负责人将其退回客户池后，再在【客户池】中认领。"
• 对方不接手、客户在客户池里（没人负责），也拦，让你去池子里认领，而不是再建一份档案。
• 批量导入同样查，还会查导入文件本身——同一个客户在表里出现两次也算冲突。
• 接手这件事有手续：原负责人把客户退回池子，别人才能认领；谁退的、退之前归谁，都记着。

客户归属这个字段本身就是三态：自有、租用、其他。"这个客户算谁的"是一个有答案的问题，不是一个在群里吵的问题。

这一条不新，但它决定后面所有事能不能成立——依据总要挂到某个人写的某一次判断上，而写的人得先确定自己是负责的那个人。

7.3 建客户是一件要有人签字的事

新客户不是录进去就算建档。销售提交的是客户创建申请：申请编号、申请人、客户资料齐全后交给销售经理，经理批了才生成正式档案；批与不批都留下审批意见和时间。

驳回不算结束。重新提交会累计次数，新旧两条申请之间挂着父子关系，第一次为什么被打回，翻得回来。

这一步在很多厂会被当成"多此一举"——建个客户还要审批？但反过来想：客户档案是全公司共用的地基，谁都能往里砌一块，地基迟早歪。 建档这道关，是我们对"依据从哪来"给出的第一个答案。

7.4 客户在池子里躺着，没人问一句

建档之后是跟进。跟进在我们这里不是一句口号，是带天数的。

客户从接触到长期维护分成六个阶段：初步接触、意向沟通、报价谈判、签约合作、长期维护、流失。每个阶段规定最长隔多少天必须动一次——初步接触七天、意向沟通十四天、报价谈判三十天、签约合作六十天、长期维护九十天；流失客户不再要求跟进。

系统按这张表去查：跟进日期到了没动，列出来提醒；某个客户太久没有业务往来，发一条通知，写明客户编码、最近一次活动是哪天、超期多少天，最后一句是"请审核是否退回客户池"。

这里必须照实补一句，因为它和上面那句话是两码事：另有一条自动的，比提醒硬。 每天早八点系统扫一遍全部客户，凡连续九十天没有任何业务往来的，不问阶段，直接清空负责人、把客户退回池子，再给原负责人和管理员各发一条通知，里面写的是"系统已自动清空销售负责人并退回客户池"。提醒那一头说的是"请审核"，动手这一头不等审核。

而且两条线用的不是同一个尺度。跟进提醒按阶段递减（最短的七天），自动退回只看一个九十天——这个数字可以配，但它不看阶段。于是一种情形是真的：一个处在长期维护阶段的客户，第九十天没人碰过，第二天早上就不归你了；而一个刚接触阶段的客户，第八天就开始收提醒，但不会被收走。

这件事没有对错，只有一句话要说在前头："多久不动就归公"这条规矩，在当前版本里是系统自己执行的，不是只能靠人判。 厂里若不接受这个力度，就得把那个天数按你们的节奏调大；接不接受都得先知道它会跑。销售外出一个月回来发现客户被人分走，就是这条定时任务跑完的结果——而假的跟进比没跟进更坏，它会污染你后面所有判断，所以调大天数不等于取消跟进。

阶段每次变化都记一条：从哪一阶段到哪一阶段、谁改的、为什么改、是不是系统自动推进的。"为什么改"这一格，就是依据。 一个客户从报价谈判掉回意向沟通，理由写的是"客户预算砍半"，这条信息三个月后值一趟出差。

7.5 报价之前，工艺部得先说话

客户走到报价，就进了前面讲过的那条链：询价 → 报价 → 审批 → 成交。这里补一段之前没讲的：能不能做，谁来说。

系统里有一张可行性评估单，挂在询价上。它要求逐格判定：技术上做不做得到、经济上划不划算、产能排不排得下、质量保不保得住、交期赶不赶得上，结论分能做、不能做、有条件做三种。

关键是签字的人不止一个。销售部门要出结论和意见，工艺部门的评估意见是必填项，结论、评估人、日期一并记录。代码里还留着一处旧痕迹：曾经有一个字段叫"是否需要工艺部协助"，默认不用；后来删掉了，注释写明"工艺部必须参与评估"。一个判断的升级过程，被留在了系统里。

中标之后是合同。合同上有交付周期、含税金额、双方与开票信息、技术与质量要求、检验标准、付款与交货条款，明细里每一项带着零件图号和加工要求。合同还配一张评审表：技术、商务、质量、交付四栏意见，一个综合结论，签的人和日期记在表上。

这张表现在的分量要说清楚。四栏是四段可以自由写也可以不写的文本；按下"通过"的那一刻，你的名字和当天日期被记下，四栏全空也能通过。结论写着三档，而"通过"这个动作只会给出"通过"——"有条件通过"只能由人在表单里自己选出来，按钮按不出这一档。 它暂时不拦任何一单，它拦的是事后说不清：老陈凭经验点一次头，和四栏都写清楚，区别不在签得快慢，在半年后客户投诉时你能不能说出当时谁认可过什么。评审与下单的先后关系，第五篇跟着一张合同走一遍时会讲得很直白。

7.6 一张台账，把两种单子并成一排

销售想知道"我手上这些单子都到哪一步了"，看的是销售台账。它把两类东西并在一排：正式订单（分首批和批量）、以及已经转生产的首件。

首件是个特殊情况：打样走的是报价单那条链，不生成订单记录。 台账按业务要求把已转生产的首件报价单并进来看，编号仍显示报价单号，类型标成"首批订单"。如果这张报价后面已经挂了真订单，就只保留订单那一行，不重复出现。

这个处理不算漂亮，但真实：同一个"客户让我们做的第一件事"，在两个地方各有一次记录。与其在系统里假装它们一样，不如定一条合并口径，让人只看一张表。这类口径怎么来的、什么时候定的，本身也该被写下来；我们把它写在了接口文件的第一行注释里。

7.7 这一章能定的一件事

读完这一章，今晚能定两条规矩，不需要任何软件配合：

第一条，一个客户只归一个人，换人要办手续。 定完你会发现，过去半年至少有两次报价是白费的。

第二条，给每类客户写下"最长几天必须动一次"，并且单独定一条"多久不动归公"。 跟进天数由你们自己定，我们那组（7/14/30/60/90）只是机加工行业的常见节奏；而归公那条线现在只有一个全局天数，它比跟进线粗得多，也硬得多——定完立刻能回答"客户到底会不会被系统收走"。

至于客户档案、跟进记录、评估单、评审单——那是让这些规矩不用靠人记的容器。

也要老实说一句边界：客户关系不在系统里产生。 它保证该被看到的人别被晾着、该留下的话别丢，它不会替你把客户处好。这一篇后面讲的每一条主线，都是这个意思。