泛微的客户模块，走到订单和回款就断了
泛微起家于 OA。审批、公文、流程、门户，这套东西它做了二十多年，成熟度是行业里公认的。很多企业的第一套系统就是它，员工请假、报销、用章，全在里面走。
于是出现一个很自然的想法：既然人都在里面了，客户也放进去吧。客户台账、联系人、跟进记录，确实建得起来。问题出在往后走的那一步。
断点在订单和回款
OA 的骨架是流程，流程有起点也有终点。请假单批完就结束了，合同审批批完也不算完，后面还有发货、验收、开票、收款、质保。这后半段不是流程，是状态，而且状态会来回变——验收打回来整改，质保金退一半，订单拆成三期收。
OA 里表达这种"长时间、多状态、带回溯"的东西，通常靠表单加附件。能用，但每加一个场景就要新做一张表，做十张之后数据之间不通。想查"这个客户一共回了多少钱"，得把几张表导出来手工对。
这不是泛微的问题，是产品定位的问题。它解决的是"事怎么办"，CRM 解决的是"钱怎么回来"。两件事的组织方式不一样。
销售会绕开它
我见过一家做工程的公司，客户台账在泛微里，销售真正用的还是自己的 Excel。原因很朴素：在 OA 里填一条客户记录，要点五次，附件传三个，字段有二十多个，其中一半不知道怎么填。填完还得等流程走完才能改。
销售的耐心是按秒算的。一个动作超过三十秒，他就会找替代方案。这跟纪律无关，跟工具的密度有关。
两条路可以并存
已经有泛微的公司，不必推翻。行政、人事、公文、用章留在泛微，销售过程放到 CRM，两边的接口对人不对系统——员工在 OA 里审批，在 CRM 里跟单，客户名称这一个字段保持一致就行。
硬要合成一套的结果，通常是两边都不好用。OA 加了客户模块，变得臃肿；CRM 加了审批流，变得死板。各有各的强项，别互相将就。
判断标准很简单：如果一个需求的关键词是"审批、归档、留痕"，放 OA；如果关键词是"跟进、报价、回款、续约"，放 CRM。泛微自己也在做客户管理的能力延伸，具体版本和报价以官网最新报价为准。至于项目型销售那条链怎么走，项目型销售CRM那页讲得比较实；投标型业务的分叉，招投标CRM里也有对照。
OA 里的客户台账，通常长这样
一张表单，字段二十来个：客户名称、所属行业、联系人、电话、地址、客户等级、负责部门、备注。提交之后走一条审批，部门经理看一眼，通过，数据入库。查的时候按名称搜，或者导出一张 Excel 筛。
这套结构能解决"资料集中"的问题，解决不了"跟进节奏"的问题。一条客户记录躺在那里，跟没跟、跟到哪、下一次什么时候联系，表单里没有位置。于是销售在备注里写，写着写着备注变成了一篇日记，三个月后没人翻得动。
移动端体验的差别
OA 的移动端是为审批设计的，打开第一屏是待办。销售在客户现场想记一条跟进，要点进应用、找到模块、新建表单、填字段、提交，五步。这个路径在办公室里可以忍，在工地上忍不了。
CRM 的移动端第一屏是客户和日程。这个差别看着小，实际决定了销售会不会在车上补记录。用得起来和用不起来，往往就差这两次点击。
并行的成本要提前说清
两套系统并行，最贵的不是软件钱，是核对的人力。客户名称在两套系统里不一致，对账就要人肉核。定一条规矩：CRM 里建档时用营业执照全称，OA 里也一样，谁改谁同步。这条规矩执行三个月，后面就顺了。
如果一定要在一套里做
也有公司选择只留一套。做法是把 OA 当主系统，客户模块做深：表单加字段、加子表、加关联，再配几个统计报表。这条路能走通，前提是有一个人愿意持续维护它，而且业务三年内不会有大的变化。
风险在扩展。第二年要加"回款计划"，第三年要加"续约提醒"，每一次加都是在原有结构上打补丁。补到第五个，维护的人一走，整套东西就没人敢动了。
所以判断标准不是现在够不够用，是三年后还改不改得动。这一点比功能清单重要得多。
顺带说一句代价。两套系统并行，员工要登两次，数据要对一次。这个成本真实存在，人少的时候忍一忍，过了三十人就得有人专门管接口。
