线索进来之后的第一件事：分配与去重
线索模块的重点不是“存数据”，而是让每条线索尽快落到合适的销售手里。我们在金边给电商客户做系统时，对方官网活动期间一天能涌进来几百条咨询，前端同步写入CRM的话，页面提交会明显卡顿。后来改成RabbitMQ先接住请求，再异步落库，前端响应才稳定下来。这个客户的线索量在活动高峰时能把同步写库的接口打到超时，换成异步之后，积压基本消除。这件事让我意识到，线索入口的技术选型得在需求阶段就定下来，不能等上线后出了问题再补。我们团队在金边做了12年开发，28个人每年交付约100个项目，这类问题在电商和娱乐行业的项目里出现频率最高。
去重同样容易被低估。同一个手机号或邮箱在短时间内重复提交，系统不做拦截的话，两个销售可能同时跟进同一个客户，内部消耗比丢线索还难受。我们的做法是用Redis做快速去重，以手机号或邮箱为键，设一个合理的过期窗口。窗口设多长，得结合企业自己的业务节奏来定，没有统一标准。电商客户通常要求窗口短一些，因为促销期间同一个用户可能隔几天就有新的购买意向；地产客户则相反，一个号码在两个月内重复出现，大概率是同一个人换了渠道再问一次，窗口设太短就拦不住。这块逻辑不复杂，但需要跟销售主管把业务节奏问清楚，否则规则形同虚设。
商机、合同、回款：一条链路上的三个状态机
商机阶段必须做成配置项，不能写死在代码里。娱乐行业和地产行业的销售管道，从节奏到节点数量都不一样。我们给菲律宾的娱乐客户和柬埔寨本土地产客户做系统时，两套商机管道几乎没法共用。初步沟通、需求确认、方案报价、谈判签约，这些阶段名称在不同行业可能完全不同。我们的做法是把商机管道做成可配置的，每个阶段可以挂自动化动作：比如进入“方案报价”阶段时，系统自动生成PDF报价单并触发审批流，销售不需要手动导出再发邮件。菲律宾那个娱乐客户后来把管道从7个阶段改到5个阶段，只用了半天配置，没动一行代码，这种灵活性在他们调整销售策略时省了很多沟通成本。
合同模块用状态机管理生命周期——草稿、待签、已签、终止。每次状态变更都记录时间戳和操作人。这件事听着基础，但很多企业到了月底对账时才发现，合同什么时候改的状态、谁操作的，完全没有痕迹。我们在越南交付的一个项目里，客户就是因为合同状态和回款记录对不上，财务和销售扯了两天皮，后来才下决心把审批流和状态机一起做进系统。回款模块和合同绑定，支持分期回款计划。技术层面要注意合同状态与回款记录的一致性：合同已签但回款记录没同步，或者反过来，都会让财务数据失真。我们用分布式事务来保证两边数据落库的原子性，具体选型要看企业现有技术栈。金融/交易类客户对这块要求尤其高，他们月末对账时任何一条不一致都会直接触发风控流程。
数据报表方面，应收、逾期、回款率这些指标需要实时汇总，而不是月底跑一次全量查询。我们给金融客户做看板时，销售主管打开页面通常几秒内就能看到数据，不用干等着转圈。OLAP引擎在这类场景下比传统关系型数据库的查询表现要好得多，尤其在数据量达到百万级线索、几十万合同记录之后，差距会更明显。具体指标因客户数据量和硬件配置而异，但至少不会出现主管看板加载到超时的情况。团队在印尼和马来西亚的项目里也验证过类似的方案，结论是一致的：报表层要单独设计，不能直接压在业务库上。
销售团队权限：光有角色还不够
很多CRM的权限只做到菜单级别——销售主管能看到“团队业绩”菜单，普通销售看不到。但真正决定数据安全的是行级权限：同一个客户列表接口，主管返回200条数据，普通销售只能看到自己负责的35条。我们用RBAC做角色控制，再在数据库查询层注入动态SQL片段，根据当前登录人的身份和上下级关系过滤数据行。这块如果等到系统上线后才补，改动成本会很高，最好在数据模型设计阶段就定清楚。我们在老挝交付的一个地产项目里，客户最初只提了菜单权限，上线后销售发现能看到别人的客户，紧急返工改行级权限，前后多花了两周。这类教训在东南亚市场很常见，因为很多企业第一次上CRM时对权限的理解还停留在“能不能进某个页面”。
跟进流程同样需要灵活配置。电话、拜访、邮件这些节点可以拖拽组合，关键是超时规则的设定。比如超过3天未跟进，系统自动向销售发企微消息提醒；超过7天未跟进，客户自动回收至公海池。这些规则在实际运行中决定了销售团队会不会认真用这套系统。规则配置得越贴合实际管理动作，系统被用起来的概率越高。反过来，规则定得太松或太紧，销售要么无视提醒，要么被频繁打扰到麻木。我们在柬埔寨做过的项目里，有的客户把回收时间设成48小时，销售团队反弹很大，后来改成5天才稳定下来。这个参数没有标准值，只能上线后根据团队反馈调。
官网、表单、企微、短信：四个必须打通的入口
定制CRM和标准产品拉开差距的地方，往往就在接口能力。官网咨询、表单提交、企微沟通、短信回执，这四类数据如果靠人工搬运，CRM的价值就少了一半。我们用API网关统一管理外部服务调用，把接口方向和关键点整理如下：
| 接口方向 | 技术方案 | 关键点 |
|---|---|---|
| 官网→CRM | RESTful API + 异步消息（MQ） | 线索自动创建，重复检测 |
| 表单→CRM | Webhook + 数据校验层 | 字段映射，防XSS注入 |
| 企微→CRM | 企微开放平台SDK + 事件订阅 | 聊天记录同步，客户标签自动更新 |
| 短信→CRM | 短信平台API + 回调地址 | 发送状态回写，模板管理 |
举个例子：客户在官网提交咨询表单后，CRM通过Webhook接收数据，先做字段校验和清洗，再用基于Elasticsearch的模糊匹配去重服务，确认不是已有客户后写入线索池，同时触发销售通知。这条链路在电商类客户那边跑得比较多，因为电商的线索量通常比地产、金融要密集，对实时性的要求也更具体。我们在金边和菲律宾的电商项目里，这套链路跑过大促场景，高峰期消息队列的消费者数量需要提前调高，否则积压会拖慢后续的通知环节。链路能跑通是一回事，跑得稳不稳、高峰期会不会积压，又是另一回事，需要根据客户实际的并发量来调整队列配置和消费者数量。我们的客户覆盖柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚，不同市场的网络环境和第三方服务稳定性差异很大，接口层要留够重试和降级空间。
开发排期和成本怎么估算
我们在东南亚交付的项目，小项目几天就能上线，大项目通常控制在2个月左右。这里说的“小项目”指的是功能边界清晰、接口数量少的系统，比如一个内部审批工具或单模块的数据录入系统。“大项目”则是指涉及多角色权限、多系统对接、多语言支持的企业级系统。CRM属于中等偏复杂的系统，排期取决于功能模块数量和接口深度。一个合理的节奏是：
| 阶段 | 时间 | 主要工作 |
|---|---|---|
| 需求梳理与原型设计 | 2-3周 | 流程确认、数据模型设计、权限模型定义 |
| 前后端开发 | 6-8周 | 模块开发、接口对接、单元测试 |
| 集成测试与部署 | 2-3周 | 性能压测、安全审计、生产环境部署 |
这个排期是基于我们过往交付经验给出的参考值，实际项目会因为销售团队规模、接口复杂度、报表口径数量产生浮动。我们在柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚都交付过CRM或类CRM系统，东南亚本地的销售团队规模通常不大，但行业差异会导致接口和报表需求完全不同。报价方面，我们的做法是先按功能清单逐项评估，再给出总价，面谈或Telegram详谈都可以。付款方式是先付30%启动项目，验收后结清尾款。需要说明的是，支付通道由客户自己提供资源，我们只负责技术对接，不提供支付通道。系统上线后，bug修复免费；后续新增功能按工作量单独计费。服务响应上，Telegram可以做到分钟级回复，同时有AI运维辅助监控系统状态。服务语言为中文。电商类系统我们有现成成品，开箱即用，部分成品系统有几十家客户在运营使用，交付速度会快很多；CRM这类需要贴合内部流程的系统，花在需求梳理上的时间省不得。