前言

上一篇《智能客服的最后一公里，我把企业微信消息链路跑通了》发出去之后，消息链路是稳了，新问题跟着业务一起长了出来。
青萍这个平台不再只有一个产品，已上线的有青萍 AI 图床、青萍 AI 视频、青萍 AI 语音，另外青萍生图也于近期上线了，后面还会有新的。
产品一多，客服入口也跟着多，麻烦就来了。
所有咨询都汇进同一个客服账号，消息长得一模一样，我分不清对面是语音的用户还是生图的用户。
有用户咨询合成总是失败，我连他用的是哪个产品都得先问一句，这不像话。
所以这篇把渠道这件事补上，还是那套微信客服通道，不用加好友，不用迁移系统。

先分清两种渠道

动手之前我先花了点时间分概念，企微里的渠道有两种，场景完全不同。
第一种是客户联系侧的渠道码，客户扫码加成员好友，一个渠道码挂一条欢迎语，加上好友那一刻自动打上来源标签，这是基于好友关系的玩法。
第二种是我用的微信客服侧，客户不用加好友，点开链接直接聊，渠道区分靠的是给每个入口发一条带参数的客服链接。
两条路都能做渠道，形态不一样。
前者沉淀好友关系，适合门店和私域。
后者沉淀会话，适合咨询和售后。
我的客服体系架在微信客服上，所以这篇讲的是第二种，概念别混了。

一个渠道一条链接

微信客服官方文档里有这么一句，企业可通过此接口获取带有不同参数的客服链接，不同客服账号对应不同的客服链接。
同一个客服账号也能生成一堆不一样的链接，差异在参数。
接口名叫获取客服账号链接，参数 open_kfid 指定客服账号，再传一个 scene 场景值，调一次拿回一条链接。
真实链接长什么样？
里面带着 enc_scene 参数，场景信息就编码在这里。
于是，语音小程序的客服按钮背后放链接 A，scene 写 qingping-voice。
生图入口放链接 B，scene 写 qingping-image。
公众号、官网各一条。
渠道数量随意加，客服账号始终是一个，后台还是那一套系统。

欢迎语按渠道说

链接解决了客户从哪来，欢迎语解决第一句话怎么接。
微信客服原生就支持配置欢迎语，客户进入会话自动发出，不开发的话，管理后台配一条通用就够用。
要按渠道区分，就得回到 API。
客户点开链接会触发进入会话事件，回调里带着关键字段，入口 event.entrance 的值就是生成链接时的场景参数。
服务端拿到 entrance 做分支，走发送欢迎语等事件响应消息这个接口。
语音来的用户收到语音的引导，生图来的用户收到生图的使用提示。
欢迎语还能带附件，一段文字加一个主推动作，别堆。
这套逻辑和上一篇的消息链路是同一条河，回调通知有事件，服务端拉内容，只是这次多看了一眼来源。

渠道数据怎么回收

区分渠道不光为了一句欢迎语，更重要的是数据。
官方在统计侧提供客户数据统计接口，有企业汇总和接待人员明细两层，咨询量、消息量这些大盘数字都有。
不过统计的维度是账号和接待人员，粒度没有细到每条链接。
所以我自己的做法是双轨，大盘看官方报表，渠道归因靠自己的服务端。
每条消息都带着入口场景值进来，落库的时候顺手记一列，哪个渠道咨询多少、问的是哪个产品，SQL 一跑就出来。
不需要多复杂的埋点，字段在事件里是现成的，缺的只是当初有没有把链接分开建。

什么阶段值得做

先自曝一句局限，渠道建设不是客服上线第一天就该做的事。
只有一路流量的时候，一个客服链接走天下，后台配一条通用欢迎语，完全够用。
什么时候值得补？
两个信号。
一个是产品线多了，咨询开始混来源，你答一句都得先问对方在用哪个产品。
另一个是你开始做投放，得知道哪个入口带来的咨询多。
满足任何一条再动手。
一两个渠道的话，把链接分开建就够了，场景值都不必分得很细。
为配而配，多出来的链接只会变成以后对账的负担。

我理出了四个渠道

落地到我自己的平台，目前理出四个入口。
青萍语音小程序里的专属客服，一条链接，这是咨询量最大的来源。
青萍生图的客服入口，一条链接，新上线的产品。
公众号青萍叙事菜单里的咨询入口，一条链接，承接文章读者。
官网和其余页面放一条公共链接，做兜底。
每条链接对应一条欢迎语，语音的直接给合成教程，生图的给新手示例。
数据侧每个渠道的咨询量单独记一列，上线头两周，语音和生图已经明显拉开，哪类问题占比高，不再靠猜。
渠道这层补齐之后，客服才算真正认识自己的客户，他知道你从哪来、带着什么问题，第一句话就说在点上。
我最近在做的，是盯着这四个渠道的欢迎语做迭代，哪句开场白接得住人，来源报表会给我答案。