二维码不是交接，客户不该重新讲一遍
客户可能已经浏览产品页、提交表单或与网页入口聊了数轮。若扫码后销售仍问“您想了解什么”，前面的信息没有转化为可执行上下文；若系统未经说明就搬运全部浏览轨迹、手机号和聊天全文，又可能超出当前服务所需范围。
跨渠道交接要同时解决四件事：客户为什么愿意切换、哪些上下文可以带走、微信身份与网页访客如何关联、谁对下一步负责。任何一项缺失，都会变成重复提问、错认客户、无人接手或过度同步。
先判断是否真的需要换渠道
| 场景 | 优先路径 | 转接说明 | 避免 |
|---|---|---|---|
| 简单产品问答 | 官网直接解决 | 无需为了留资强制扫码 | “加微信才发资料” |
| 需要持续沟通 | 客户选择微信、企微或原渠道 | 说明后续资料与回复方式 | 默认跨渠道持续营销 |
| 明确方案、报价或演示 | 指定真人负责人 | 给出姓名或团队、预计响应和下一步 | 只发个人二维码，无人认领 |
| 投诉、复杂异议或关键承诺 | 直接人工接手 | 保留争议点与已答内容 | 让AI继续自动推进 |
| 客户拒绝切换 | 保留可用替代路径 | 尊重当前沟通选择 | 把扫码设成不必要门槛 |
《个人信息保护法》第六条要求处理目的明确、合理、与目的直接相关，并将收集限定在实现目的的最小范围。因此，渠道切换不应被理解为可以默认复制所有客户数据。实际合规口径应结合企业的数据来源、告知文本和业务场景审查；本文不替代法律意见。
最小交接包：让销售能接着做，又不过度搬运
| 字段 | 用途 | 边界 |
|---|---|---|
| 来源页面或活动 | 知道客户已看过什么 | 不附带无关浏览历史 |
| 客户明确问题 | 新渠道首句直接承接 | 保留原意，不夸大意向 |
| 已确认事实 | 避免重复询问 | 区分客户陈述与系统推断 |
| 未解决事项 | 明确下一步任务 | 不要把猜测写成结论 |
| 负责人和时限 | 防止添加后无人接 | 超时应提醒或改派 |
| 联系选择与边界 | 决定后续如何沟通 | 切换渠道不等于无限触达 |
HubSpot的公开字段把Lead Source、Lead Owner、最近互动、主要关联联系人或公司分别记录。它不是ZigoAI的功能说明，但说明“来源、负责人、互动和关联对象”应分开，而不是全部塞进一段备注。
交接摘要可以先用一屏信息呈现，原始网页会话保留在有权限的位置供核查。若摘要不足以让销售直接行动，可结合人工接手完整度评分表检查缺失项。
身份关联要允许失败：先“待确认”，再合并
网页访客、表单联系人和微信账号未必天然对应。共享电脑、代同事询价、同一公司多人采购或客户多次扫码，都可能造成错误合并。推荐把关联证据分成三层：
- 强证据：客户在新渠道主动确认，并提供与本次咨询一致的一次性关联码或已核验联系方式。
- 辅助证据：公司、项目、需求和时间能够相互印证，但仍需客户确认。
- 弱信号：昵称、头像、设备、IP或语言风格相似，只能提示疑似关联，不能自动合并。
证据不足时，系统应建立“待确认关联”，保持两个入口的可见范围和原始来源。确认错误后要能拆分，并修正由错误关联产生的标签、负责人和跟进任务。涉及代同事询价时，可参考真实需求人识别方法，不要绕过当前联系人。
转给谁：专业匹配、可用性和客户归属一起判断
二维码最好对应可追踪入口或团队，而不是无法分配的静态个人码。Microsoft公开的销售分配规则支持把记录交给符合条件的销售、团队或队列，并可按轮询、负载、工作时间和容量分配；规则按顺序执行。它说明“先定义规则，再自动分配”比扫码后临时抢客户更可靠。
| 判断维度 | 示例 | 无人可接时 |
|---|---|---|
| 既有归属 | 存量客户、在办商机、保护期 | 进入协作或裁决队列 |
| 专业匹配 | 产品线、地区、行业、语言 | 转给可处理的备援团队 |
| 当前可用 | 营业时间、排班、在线状态 | 诚实告知预计响应时间 |
| 团队容量 | 当前待办、接手上限 | 改派或升级主管 |
| 权限要求 | 报价、合同、安全评估 | 只收集必要信息，不越权承诺 |
高意向客户转入后，应继续使用路由与接手SLA区分通知送达、销售认领、首次联系和结果回写。扫描二维码或好友添加成功都不等于客户已被接住。
新渠道第一条消息，要证明上下文真的接上了
合格的承接句包含身份、来源、客户刚才的目标和唯一下一步。例如：“您好，我是负责企业销售流程评估的同事。您刚才在官网主要想确认微信/企微接入与人工接手方式，我先接着这个问题说明；若不是同一咨询，请告诉我，我不会合并记录。”
不要复述客户未授权在新渠道出现的敏感内容，也不要说“我已经掌握您的全部资料”。如果联系人关联仍待确认，应先确认项目或问题，不要先猜自然人身份。已有需求字段可使用客户状态驱动下一步，但推断必须标记，不能覆盖客户明确陈述。
验收不只看扫码率，要看交接是否闭环
| 指标 | 正确口径 | 风险信号 |
|---|---|---|
| 身份关联成功率 | 有明确证据完成关联 | 仅凭昵称自动合并 |
| 上下文完整率 | 必要字段足以继续处理 | 销售重新询问全部需求 |
| 首次人工响应 | 负责人真正联系客户 | 只统计二维码扫描或好友添加 |
| 重复提问率 | 已确认信息再次被询问 | 摘要未进入销售工作台 |
| 超时与改派率 | 无人接手后被识别并处理 | 客户添加后长期等待 |
| 退出与误触达 | 客户选择被正确执行 | 切换后持续无差别营销 |
上线前要测试客户拒绝换渠道、扫码多个入口、联系方式不一致、销售离线、摘要字段缺失、关联码过期和人工改派等异常路径。可把这些路径加入上线验收清单，而不是只演示顺畅的一次扫码。
适用条件与产品边界
本文适合官网有稳定咨询、销售主要通过微信或企业微信持续承接的一般B2B和服务型业务。涉及医疗、金融、未成年人或其他敏感信息时，应使用更严格的告知、权限和人工审核流程；企业应按自身业务获得具体法律与安全意见。
ZigoAI公开产品页说明可统一承接个人微信、企业微信和WhatsApp，围绕客户接待、意向识别、持续跟进与人工接手工作，并保留上下文。官网并未公开“网页访客与微信身份自动合并”、动态二维码、一次性关联码或任意CRM字段同步能力。本文中的官网入口、身份关联、分配规则和最小交接包属于实施方法；可用范围应以产品说明、演示、试点和合同为准，公开方案以当前价格页面为准。
常见问题
官网客户一定要转到微信或企微吗？
不一定。能在官网直接解决的问题就不必切换渠道；只有持续沟通、资料协作或人工跟进确有价值时，才向客户提供微信、企微或保留网页沟通等选择。
网页聊天全文都要同步给销售吗？
不建议默认全量同步。优先交接客户明确问题、已确认事实、未解决事项、来源和下一步；原始对话按权限保留，需要复核时再查看。
怎样确认新增的微信联系人就是刚才的官网访客？
可通过客户主动确认、一次性关联码或已经核验的联系方式建立关联。证据不足时保留待确认状态，不强行合并客户记录。
客户扫了多个销售二维码怎么办？
应暂停重复营销，保留各入口时间和客户互动证据，再由预先定义的客户归属与协作规则确定负责人；不要让多名销售同时重新询问同一需求。
引用来源
资料核查于2026年9月26日。个人信息保护法用于说明目的明确与最小范围等一般边界；HubSpot与Microsoft资料用于说明来源、负责人、关联对象和分配规则等公开产品结构，不代表ZigoAI已实现相同功能，也不代表上述机构对本文方法或ZigoAI作出背书。
Carry Context, Not Friction
让客户换渠道，不必重讲需求
带上脱敏后的官网咨询、当前二维码入口和销售接手流程，一起梳理需要保留的上下文、负责人分配与异常兜底。
预约成交诊断