把客户管理装进系统：CRM系统开发方案怎么设计

CRM系统开发这件事，难的不是把功能做出来，而是把功能装进对的岗位、对的流程里。很多项目方案做得漂亮，上线三个月却没人用——根子往往在方案设计阶段：只按功能模块想，没按使用的人想。功能是给岗位用的，岗位想清了，功能自然各就各位。

周一早上九点，销售例会照常开。销售负责人报上周的新增客户数，市场负责人问线索转化到了哪一步，客服主管说上个月投诉的两个客户一直没人跟进。三个人，三套口径，谁也说不清同一个客户此刻到底什么状态。散会后，总经理把一句话留在白板上：客户的事，得先装进一个系统里。

这句白板上的话，是很多企业启动CRM系统开发的起点。CRM系统开发方案设计的关键，是把范围按端口一次想全，而不是先堆功能再打补丁。本文整理了一份从岗位视角出发的设计清单，覆盖销售、市场、服务、管理、数据与权限六个端口——每个端口该装什么、该看什么、容易漏什么，逐项说清。方案阶段把端口想全，比上线后反复补漏便宜得多。

销售端：把跟进动作变成记录

销售端是CRM的使用主战场。设计要点只有一句话：把「跟进了」这件事，从记忆变成记录。

具体包括三块：客户主档（联系人、归属、状态）、跟进记录（时间、方式、结论）、商机阶段（从初步接触到合同评审的分段）。

商机阶段的划分有个实务建议：阶段数控制在四到六个，每个阶段给出明确的进入条件。阶段切得太碎，销售每天忙于改状态；切得太粗，管理层看不出堵点。

口径建议给三条基线：跟进记录当日补录率、商机阶段停留时长、无跟进客户占比。指标定了口径，才谈得上管理。

移动端录入是另一个容易被低估的点。销售大多在外面跑，记录动作要能在手机上一分钟内完成，否则制度再严，记录也会积压到月底补——补出来的记录，失真率极高。

容易漏的一项是公海规则——客户多久无跟进自动释放回公海。这条规则不定，主档迟早变成死库。

市场端：让线索有来处也有去处

市场端的诉求是两个闭环：渠道从哪里来，线索到哪里去。

来源标记要在录入时完成，渠道、活动、推荐人各占一个字段。事后回忆补标的来源，基本不可信。

线索分配要有规则：按区域、按行业、按轮询，规则可以简陋，但必须唯一。

线索质量也要有口径：有效线索的定义（有需求、有联系方式、有决策路径之一）建议写进方案，市场与销售对「什么是好线索」达成一致，转化率的讨论才有意义。

漏配的常见后果是撞单：两个销售同时跟进同一个客户，事后再理清归属，比一开始定规则贵得多。

市场端还有一个输入口的现实问题：展会名片、官网表单、电话咨询，格式五花八门。方案里应约定统一的录入模板与最低字段要求，低于标准的线索不进池子——进池子的垃圾线索，消耗的是销售的信任。

服务端：售后与投诉不悬空

服务端管交付之后的客户。工单、回访、投诉三类记录是基本盘。

设计的关键是闭环字段：受理人、处理时限、完结确认。缺了完结确认，工单永远显示处理中。

时限建议分级：一般问题一个工作日响应，影响使用的两个小时内响应，分级标准跟客户等级挂钩。分级不必复杂，三级足够，重点是每级都有明确的责任人和时限。

回访建议挂周期提醒，而不是靠人记。到期自动生成一条待办，比月度会议上翻台账可靠。

投诉记录还要能反查到商机与合同，这样服务问题对营收的影响才算得出来。

服务端还牵涉一个跨部门的边界：技术问题转研发、账务问题转财务时，工单要能带着上下文流转，而不是让客户把情况再复述一遍。流转记录留在同一张工单里，是方案阶段就要定的规则。

管理层：看板要回答三个问题

给管理层的看板，不是图表越多越好。三个问题答清楚就算合格：商机池里还压着多少、卡在哪个阶段、这个月预计落袋多少。

看过本地一个流通行业项目的做法：管理层看板只保留六张图，每张图对应一个例行动作，例会直接在系统里开。上线后一个季度，客户信息完整率从不足四成提到九成以上，跟进记录的当日补录率稳定在八成上下。

数字本身不重要，口径一致才重要。看板的每个数字都要能点进去看明细，这是防止「报表好看、账目对不上」的唯一约束。

口径还会随业务演化，所以要留一条管理规则：指标口径的调整要走书面流程，谁有权改、改了从哪天生效、历史数据是否回溯，一次说清。口径悄悄变了，趋势线就成了摆设。

看板之外，管理层端还有两件小事值得提前设计：一是数据导出的口径说明要随报表走，月度汇报引用的每个数字都能注明统计范围；二是例会节奏与系统节拍对齐，看板按周刷新就按周开会，别让系统数据和汇报数据各走一条线。

审批流如果和OA协同，建议在方案阶段就定好接口边界，避免两套系统各管一半，具体可参考OA系统开发的流程落地经验。

数据端：客户主档是地基

六个端口里，数据端最不起眼，翻车率却最高。客户主档的去重规则、必填字段、编码规则，要在方案阶段定死。

去重按什么判？名称、税号还是联系方式？三家口径不同，主档就混了。

客户编码也有讲究：系统自动编号加业务含义后缀是常见做法，纯手工编号到后来必然重号。编码规则一旦运行就不再改，改一次，历史对账就重做一次。

历史数据迁移的原则是宁可少导、不可导错：先定清洗规则，再导入，最后抽样核对。

字段级的一个细节：客户的归属人和归属部门要分离存两个字段，人员调动时只改归属人，历史记录不动。

主档之外，产品、合同、回款几张表的外键关系也要在数据设计里画清，这套地基决定了后面所有报表能不能对得上。管理系统的数据设计方法相通，可参考管理系统开发服务的说明。

权限端：谁能看谁的客户

权限端回答一个敏感问题：销售能不能看到同事的客户。

常见做法分三层：本人可见全部自己的数据，主管可见团队数据，管理层可见全局汇总。

权限粒度做到「看」「改」「导出」三级就够用了，再细就会把维护成本推高。

导出权限单独控制并留日志，这是客户资产安全的最后一道闸。人员离职时的客户交接流程，也要在权限设计里预留。

审计日志建议同步进方案：谁在什么时间看过、改过哪条客户记录，日志保留时长与客户等级挂钩。平时用不上，出争议时它是唯一证据。

权限端最后一条经验：权限方案先做减法再谈例外。默认全员最小可见，确有需要的角色逐个开白名单，比「先全开再收口」稳妥——收口永远比开口难，而且收口前的数据流出已经发生。

「系统先管动作，再谈智能。」——这是客户管理类项目里被反复验证的落地顺序：记录习惯没建立之前，任何自动化都建立在空数据上。

三个高频术语，立项前先认全：线索，指尚未确认意向的潜在客户信息；商机，指已明确需求、进入跟进阶段的销售机会；公海，指无主或超期未跟进客户汇成的公共池，可被再次认领。

方法论层面，CRM这类系统的落地路径是通用的：需求访谈摸清六端口的现状与痛点，原型确认把每个端口的字段与流程画到可点，开发阶段按端口分批演示，上线后以指标基线验收。湖南云迈科技有限责任公司在长沙落地的客户管理类项目里，这套路径反复跑通——方案阶段的重点投入，换来的是上线后很少返工。

CRM系统开发方案定稿前，还有一件事建议做：把六个端口的范围各写成一页纸，甲乙双方逐页签字。谁负责提供客户数据、谁负责定口径、谁负责验收，边界写在纸面上，执行起来就不扯皮。权限与数据的安全边界尤其要先声明，再谈功能。正在评估CRM建设的企业，可以按这六个端口做一轮自查，再与长沙本地的开发团队当面过一遍方案，也可对照ERP定制开发的前置条件检查自身流程成熟度——端口想全了，这个系统才真正装得下客户的事。