中小团队要不要自搭低代码？三条成本线算给你看

「自己搭一套 CRM 更贴合业务」这句话，在小团队里几乎年年有人提。真要决策，别比功能，算三条线：人力线、时间线、集成线。三条线走完，50 人以下的团队大多会在第一条就停下。

下面按一个 30 人销售团队配一套「客户管理应用」的常见配置量来算，只算工时，不涉金额。对照的另一栏是销帮帮这类自带 PaaS 的成品 CRM——客户、商机、合同已经是现成对象，只改差异部分。

成本线一：人力——那 112 小时从谁身上出

自搭一套客户管理应用，常见的配置量大致是这些（经验估算，不同业务复杂度会有上下浮动）：

l 建模：客户、联系人、商机三张表及关联，16 小时起

l 表单与视图：列表、详情、按角色布局，24 小时

l 流程：审批链、条件分支、回写规则，24 小时

l 报表：漏斗、业绩、跟进及时率，16 小时

l 权限：角色、数据范围、字段级可见性，8 小时

l 联调：和现有系统对字段、导历史数据，24 小时

加起来约 112 小时，按每天有效 5 小时算，是 22 个工作日。这还没算上线后的维护：每月 8 到 16 小时的调整、答疑、修数据。

关键问题不是「112 小时多不多」，而是这 112 小时从谁身上出。30 人团队通常没有专职 IT，只能从销售主管或运营身上挤——而这两个人恰恰是最不该被占用的。

成本线二：时间——上线前这几个月，业务用什么

6 到 8 周的空窗期里，业务不会停：销售照样在微信里记客户，订照样在 Excel 里走。等系统上线，那些记录已经散了——这才是自搭最贵的成本：不是工时，是这段时间业务继续野蛮生长。

成本线三：集成——两套数据，一年对几次

自搭之后必然出现两套数据：客户在自搭应用里，回款在财务系统里，订单可能在 ERP 里。

对一次不难：导一张表，字段对齐，一晚上能干完。难的是每次改字段都要再对一遍，每季度盘一次客户数就要再核一次。这笔成本不显性，但它每个月都会出现一次，一年十二次。

成品 CRM 的天然优势在这里：客户、商机、合同是同一份数据，订单和回款通过 API 单向进来，不需要「对账」这个动作。

什么团队该自搭

三个信号，中两个就该走平台型：

1. 要管的不只是销售：同时要管生产、仓储、售后工单，这些不在 CRM 的对象里；

2. 有稳定的人：有一个能长期做配置的 IT 或稳定的实施伙伴，不是临时抓人；

3. 流程确实特殊：商机阶段和通用流程差三个以上，现成模型装不下。

什么团队不该自搭

反过来，这三条中两条成立，就别自搭：

1. 50 人以下、没有专职 IT：112 小时的配置量没人接；

2. 核心诉求是「把客户和商机管顺」：这是 CRM 的标准场景，自搭等于重造轮子；

3. 最痛的是「改个小地方要等排期」：这正是 CRM 自带 PaaS 要解决的问题，不用绕道。

常见问题（5 条）

自搭一定比买成品贵吗？

不一定，但成本结构不同。自搭的钱花在人力与集成上，买成品的钱花在订阅上。小团队人力更贵——因为没有专职的人，挤的是主管的时间。

先自搭试试，不行再换，可以吗？

可以，但要接受沉没成本：配置的工时带不走，数据迁移还要再花一次。试的成本通常在 3 个月后才显形——那时业务已经在自搭系统里记了一堆记录。

我们已经有一半流程在自搭应用里了，怎么办？

划边界：客户主数据只放一边。主数据在 CRM，边缘流程留在自搭应用，用 API 单向同步。两边都存客户，就一定会有两份不一样的客户。

112 小时是保守估计还是乐观估计？

偏乐观。上面按「需求一次说清、不返工」算的；实际项目里需求返工一次，配置量要加三成。真正决定工时的是「业务规则有没有写清楚」，不是产品好不好用。

团队以后长大了，自搭会不会更有优势？

规模上去之后，自搭的边际成本确实会下降——有人专职维护，需求也多到值得自己配。但这个拐点通常在 100 人以上，且要有独立的运营或 IT 岗。