企业官网建设流程全解析

官网友情链接 wechatapi.net

个人微信二次开发刚开始时，很多系统会直接拿某个微信侧标识当作客户主键。

一个账号下的好友列表中出现一个联系人，就创建一条customer。

这种方式开发快，但系统进入多账号以后很快会遇到问题。

同一个真实客户可能：

添加销售A；
添加客服B；
存在于多个微信群；
重新删除再添加。

如果每一条微信关系都被当成一个客户主体，CRM会产生大量重复客户。

所以个人微信API接入以后，需要明确区分：

平台联系人ID；
微信关系ID；
客户主体ID。

WechatApi 可以作为个人微信API接入层，把不同账号下的联系人、好友关系和消息带入本地系统。本地客户中心则为真实客户创建稳定customer_id，再让多条微信关系指向同一主体。

一、为什么 account_id + contact_id 不能直接当客户主体

它最多能唯一表示：

某个账号下的一条微信关系。

不能表示：

真实客户。

同一个人添加另一个账号，就会产生新的组合。

二、一个具体例子

客户王先生：

账号A下 relation R1。

账号B下 relation R2。

CRM里只有客户 C100。

正确模型：

R1 → C100。
R2 → C100。

而不是：

R1=C100；
R2=C200。

三、稳定主键应该由本地生成

customer_id使用：

UUID/雪花ID等本地稳定ID。

不要依赖昵称、手机号或微信展示字段直接当主键。

这些业务字段都可能变化。

四、WechatApi 在这里的位置

WechatApi负责：

账号；
联系人；
消息；
群成员。

本地客户中心负责：

真实主体ID。

五、relationship_id也要稳定

每个账号与客户的关系独立保存：

relation_id。

关系删除后不要物理删除。

状态inactive。

重新添加可以产生新周期。

六、群成员关系再次独立

membership_id。

群成员指向：

contact/relation/customer。

不要让group_member直接等于customer。

层级清晰。

七、CRM映射

customer_id ↔ crm_customer_id。

CRM客户ID也不应该直接成为本地主键。

因为未来可能切CRM或重新合并。

映射层更灵活。

八、手机号只是匹配信号

手机号很强。

但仍然不是主键。

手机号可能变更。

主键不能跟着变化。

九、客户合并

C100、C200确认同一人。

保留：

C200.merged_into=C100。

旧ID仍然可以重定向。

不要物理消失。

十、客户拆分

误合并后需要拆。

如果所有业务都直接依赖关系ID和来源，恢复更容易。

这就是主键设计的重要性。

十一、搜索使用业务字段

用户不需要记customer_id。

可以搜：

昵称；
备注；
手机号；
公司。

主键只服务系统稳定关联。

十二、消息关联

消息尽量记录：

relation_id；
conversation_id。

customer_id可以作为冗余查询字段，但来源关系保留。

以后主体纠错更容易。

十三、任务和工单

业务对象引用customer_id。

同时保存source_relation。

知道客户通过哪个微信关系触发。

十四、数据迁移

未来账号关系重新导入。

稳定customer_id让CRM、工单不需要重建。

只重新绑定relation。

十五、权限

客户主体统一以后。

仍然按relation owner和业务负责人计算权限。

统一主体不等于所有员工共享客户。

十六、数据看板

真实客户数；
微信关系数；
平均每客户关系数；
重复候选；
合并。

数据会比“好友总数”更加真实。

十七、异常

一个relation同时指向两个customer。

属于严重数据异常。

数据库层最好限制。

十八、总结

个人微信二次开发中的ID设计看起来很底层，但它会直接决定未来客户去重、CRM、群成员、工单和多账号能不能长期稳定。

WechatApi 可以把不同微信账号的联系人和群关系持续接入系统。

本地客户中心则用稳定customer_id表示真实客户，用relation_id表示具体微信关系，用membership_id表示群成员关系。

只有主体和关系彻底分开，一个客户在多个账号、多个群、删除重加以后，整个业务系统仍然能认出“这还是同一个人”。

这也是个人微信API系统从单账号工具走向长期客户资产管理必须先做对的底层设计。