企业官网建设流程全解析

官网友情链接： wecomapi.com

企业微信二次开发进入客户管理场景以后，很多团队都会维护一张“当前客户关系表”。里面保存客户对应哪个员工、当前备注是什么、有哪些标签、关系是否正常。对于日常查询来说，这样设计没有问题，因为业务人员最常问的就是：“这个客户现在归谁负责？”

但系统运行时间一长，就会遇到另一个问题：当前状态虽然准确，历史过程却被覆盖了。

例如一个客户最开始由销售 A 添加，三个月后因为销售 A 转岗，被交接给销售 B；又过了一段时间，客户备注被修改，标签也发生变化。如果数据库始终只是 UPDATE 当前字段，那么半年后回头看，只能看到销售 B、最新备注和最新标签，却不知道客户之前由谁负责、为什么转交、什么时候改过备注、哪些标签曾经存在。

对于普通通讯录，这可能不是大问题；但对于 CRM、客户归属、售后责任、群发范围、操作审计来说，历史变化非常重要。

所以企业微信二次开发API接入以后，客户关系更适合采用“当前状态 + 关系版本 + 变更事件”的方式建模。

WeComApi 可以作为企微API接入层，把客户、员工关系、标签、外部群以及相关变化事件接入业务系统。本地系统则需要在此基础上保留客户关系生命周期，而不是只保存最后一个结果。

一、为什么当前关系表仍然需要

关系版本并不意味着不要当前表。

恰恰相反，当前关系表仍然非常重要。

因为大多数实时业务都需要快速查询：

客户当前负责人是谁；
关系是否有效；
当前备注是什么；
当前标签有哪些；
最近互动时间是什么。

如果每次查询都从历史版本中计算最新状态，性能和复杂度都会很高。

所以可以保留：

customer_relation_current

用于当前业务。

同时再有：

customer_relation_history

用于历史追踪。

一张解决“现在是什么”，一张解决“以前发生过什么”。

二、一个具体例子

客户 C1001 最初由销售 A 添加。

系统记录：

版本 V1：
负责人 A；
备注“张总”；
关系状态 active。

两个月后销售 A 转岗，客户交给 B。

生成版本 V2：

负责人 B；
备注仍为“张总”；
关系状态 active；
change_reason = handover。

又过几天，销售 B 把备注改成：

“杭州ABC-张总”。

生成版本 V3。

半年后客户删除员工关系。

生成 V4：

status = inactive。

当前表只保存 V4 的状态。

历史表仍然保留 V1-V4。

这样任何时候都能还原客户关系变化。

三、版本和事件不要完全混为一谈

版本回答：

某个时点完整状态是什么。

事件回答：

具体发生了什么。

例如：

customer_added；
owner_changed；
remark_changed；
tag_added；
tag_removed；
customer_removed。

有时候一个事件会影响多个字段。

例如客户继承既改变负责人，也可能改变权限和任务归属。

所以推荐同时保留：

原始事件；
处理后的关系版本。

以后排查问题时可以从版本回到事件。

四、WeComApi 在这里负责什么

WeComApi 可以负责把企微侧的客户关系和变化能力接入本地系统。

例如：

客户新增；
删除；
员工关系；
标签；
外部群；
相关事件。

但“是否生成新版本”“哪些字段属于业务主责”“历史保留多久”，属于本地系统职责。

这就是接入层和业务模型之间的边界。

五、不是所有字段变化都必须生成完整版本

如果每一个时间戳变化都生成版本，数据量可能非常大。

可以区分：

关键字段；
普通字段。

关键字段例如：

负责人；
关系状态；
客户备注；
客户等级；
核心标签。

普通同步时间变化可以只更新 current 表，不生成业务版本。

这样历史更有价值，也避免噪音。

六、标签变化更适合单独记录来源

标签尤其复杂。

一个标签可能来自：

员工手工；
企微API同步；
CRM；
自动化规则；
外部群行为。

因此历史版本里不能只保存一个“标签数组”。

最好还有标签关系表：

customer_tag_relation

记录：

tag_id；
source_type；
source_id；
created_at；
expired_at；
status。

这样客户标签历史才真正可解释。

七、负责人变更要和客户交接任务关联

负责人从 A 变 B，不应该只是数据版本变化。

系统还可以生成：

handover_task。

任务检查：

未完成跟进；
未关闭工单；
相关外部群；
CRM 商机；
待审批任务。

关系版本记录“负责人已经变化”。

交接任务保证业务真正完成。

两者缺一不可。

八、历史版本可以帮助群发复盘

某次群发任务在 6 月筛选：

负责人 = A 的客户。

8 月客户已经转给 B。

如果系统只看当前关系，就会误以为这个客户当时不属于 A。

历史版本可以还原：

群发执行时客户负责人确实是 A。

这对目标快照、销售绩效和运营复盘都很有价值。

九、权限审计也依赖关系历史

客户负责人变化后，原员工权限可能被回收。

如果未来出现：

“为什么 A 在 6 月能看到这个客户？”

系统可以通过历史关系证明：

当时 A 是合法负责人。

没有关系历史，权限审计很难解释。

十、旧版本不能被普通用户修改

历史一旦形成，最好只追加，不覆盖。

如果发现历史错误，可以生成：

correction_record。

说明：

原版本；
纠正值；
纠正人；
原因。

而不是直接偷偷修改历史记录。

这样审计可信度更高。

十一、关系版本和 CRM 双向同步

CRM 可能也有负责人、客户等级等字段。

所以生成关系版本前要先明确字段主责。

例如：

企微关系负责人 → 企微主责；
CRM 商机负责人 → CRM主责；
客户等级 → CRM主责；
企微备注 → 企微关系主责。

不要因为任何企微事件都生成版本后，就把CRM数据一起覆盖。

十二、版本号可以使用递增值

每个客户关系维护：

version_no。

V1、V2、V3。

写入新版本时：

当前版本 +1。

异步任务执行时携带版本号。

如果任务基于 V2 创建，但执行时已经 V4，可以判断：

任务可能过期。

这还能帮助防止旧任务覆盖新状态。

十三、对账如何与版本配合

定期对账发现：

本地 current 和企微当前数据不一致。

系统修复 current。

同时生成一个来源为：

reconciliation

的新版本。

这样历史里知道：

这次变化不是实时事件，而是对账修复。

后续可以分析回调遗漏率。

十四、异常中心也可以利用版本差异

如果同一客户一天内负责人频繁变化：

A → B → A → C。

这可能是业务异常。

系统可以根据版本历史生成：

负责人频繁变更异常。

提醒主管检查。

十五、数据生命周期

Current 表长期保留。

历史版本可以分层：

最近一年热查询；
更早归档。

但不要轻易删除关键负责人和关系状态历史。

因为它们对审计很有价值。

十六、数据看板

可以统计：

本月客户关系变更数；
负责人交接数；
备注修改次数；
标签变化数；
对账修复数；
异常频繁变更客户。

这些指标能帮助企业了解客户资产变化。

十七、日志和 trace_id

每次版本变化最好关联：

event_id；
task_id；
trace_id。

例如一次员工离职触发：

关系变化；
权限回收；
任务迁移。

都能通过同一个 trace 关联起来。

十八、总结

企业微信二次开发API中的客户关系，不应该只有一张“当前表”。

WeComApi 可以帮助客户、员工关系、标签和相关事件稳定进入业务系统，但本地系统需要同时保存“当前状态”和“历史过程”。

当前表服务实时业务。

版本历史服务审计、复盘、权限和任务判断。

事件记录解释为什么发生变化。

只有三者结合，客户关系从 A 转到 B、标签从有到无、关系从正常到失效这些变化才不会被一次 UPDATE 永久覆盖。

真正成熟的企微客户管理，不只是知道客户现在属于谁，而是随时可以解释：他为什么会变成现在这样。