夜雨聆风学习资料网

ARTICLE · 1107477

我正在用 AI 重做一家货代公司|Multichannel 不是 Omnichannel,这技术公司至少卖20W

发布时间：2026-10-01 03:03:15 最近访问：2026-10-01 03:03:15
我正在用 AI 重做一家货代公司|Multichannel 不是 Omnichannel,这技术公司至少卖20W
中国台湾回来一周了，论点好多，不同场景，不过区域，我把他集合起来去重，整理出最大痛点，我只解决部分问题，不能解决所有问题。你们有没有发现，货代业务里有一个很折磨人的现实：
同一个客户，上午在企业微信询价，中午用 Email 发资料，隔一天又跑到 WhatsApp 上砍价。
渠道很多，但一票业务的上下文却散落在各个地方。
销售自己当然知道这是一件事。
他知道 WhatsApp 里说“再便宜 100 美金”的客户，就是昨天 Email 发 Packing List 的那个人。
也知道他说的是哪一票货、哪个 Quote，前面找过哪几个 Agent，现在大概还有多少 Margin。
但系统未必知道。
这也是我真正把 AI Agent（业务智能代理） 往业务里面落地之后，最直观的体会：
很多问题根本没法单点解决。
不是接一个大模型、搭几个 Agent，AI 就能自动跑通业务。
业务人员多年的操作习惯要尊重，Email、企业微信、WhatsApp、LINE 各自的交互逻辑，也不能为了适配 AI 全部推翻重做。
底层还要同时搞定客户身份识别、消息归属、业务案件、权限体系和业务数据的关联关系。
往后 AI Agent 要真正干活，必须能拿到完整、可靠、且有权限边界的业务上下文（Business Context）。
这些问题，全部是交织在一起的。
这段时间我看了大量行业方案，也拿真实货代业务场景反复往系统里套。看得越多，越能发现问题。
很多架构图画得特别漂亮：
一个 AI Agent、一个统一收件箱、再接上所有沟通渠道。
看上去应有尽有。
但真正把一票真实业务放进去跑，漏洞马上就出来了：
客户身份对不上、聊天会话和业务不匹配、供应商报价散落各处、客户一换沟通渠道，前面的对话信息全部断层。
最后 AI 拿到的只是几段碎片化聊天记录，根本不是完整的业务事实。
上下文不完整，AI 再聪明，也做不出靠谱判断。
也是在反复落地的过程里，我终于认真区分开了两个被行业混用太久的词：
Multichannel（多渠道）
Omnichannel（全渠道）
字面只差两个字，落到真实货代业务里，完全是两套逻辑。

01

01｜Multichannel：渠道接进来了，业务没有接起来
多渠道的逻辑很简单：Email、WhatsApp、企业微信、LINE、网站聊天，所有渠道都能联系到客户。
但绝大多数系统的现状是：各渠道完全独立、互不连通。
Email 里的客户 Jason、WhatsApp 里的 Jason、企业微信里的 Jason，系统大概率分不清是不是同一个人。
就算识别出是同一个客户，也没法关联起所有渠道对应的业务记录。
举个最真实的日常场景。
客户上午在企业微信询价：上海到 LA，2×40HQ，月底船期。
中午通过 Email 发来装箱清单，我们邮件对接海外代理询价。
下午代理陆续回传报价，系统解析费率、完成比价，我们把正式报价单发给客户。
第二天客户不回复邮件，直接跑到 WhatsApp 问：Can you reduce $100?
人一眼就能看懂，他在为昨天那票货议价。
但只看 WhatsApp 记录的系统，完全看不懂：
不知道这句议价对应哪份报价、原始需求是什么、资料在哪里、询过哪些代理、原有费率是多少。
所以我现在很确定：Multichannel 最大的问题，从来不是渠道不够多，而是渠道通了，业务永远是断的。

02

02｜很多公司的“全渠道”，其实是销售自己在连接
现在大部分货代公司的数字化配置看着很完善：邮箱、企业微信、WhatsApp、LINE、网站聊天全都有，甚至每个渠道都加了 AI 功能。
但真实工作状态没变。
销售每天还是要逐个翻一遍所有工具，手工同步信息、手动归档业务、复制粘贴记录进度。
客户换个渠道说话，全靠销售自己的脑子串联前后业务。
我后来总结了一句很贴切的现状：系统是 Multichannel，人肉才是 Omnichannel。
真正完整的客户业务上下文，一直只存在销售的脑子里。
谁是客户、什么时候询的价、报过什么价格、谈的哪票货、下一步要跟进什么，全部靠人记。
团队小、老销售稳定的时候，这套人肉模式能撑住。
但客户体量变大、人员频繁交接、以及我们想让 AI Agent 真正参与询价、报价、跟进工作之后，这套模式彻底走不通。

03

03｜Multichannel 和 Omnichannel，真正差在哪里？
全渠道不是新概念，只是行业一直用错了。
两者的核心差距，根本不是接入渠道的数量多少。
真正的区别只有一条：客户跨渠道沟通后，业务关系能不能持续连贯。
Multichannel 解决的是：客户可以从哪些地方找到我。
Omnichannel 解决的是：客户换渠道找我，系统依然知道他是谁、谈过什么、业务推进到哪一步。
一个系统哪怕接 10 个渠道，但各渠道数据孤立，就永远只是多渠道。
反过来，哪怕只接三个渠道，但底层共享一套客户身份、业务上下文、业务案件、权限和工作流，就是真正的全渠道。
我现在对这两个概念的最简定义：
Multichannel 是渠道都接进来了。
Omnichannel 是客户换了渠道，业务没有断。
这也是我做 BeaconQuote 时，坚决不止步于“多渠道接入”的原因。对接 API 只是最基础的第一步，真正难的，是让跨渠道的业务关系持续闭环。

04

04｜但货代比普通 Omnichannel 还多一个麻烦
打通客户身份、串联渠道信息，已经很难了。但货代业务，还有一个更特殊的行业痛点。
通用 CRM、客服系统，全部默认是会话中心（Conversation-Centric）的设计逻辑：一条聊天会话，对应一单咨询、一个问题。
这套逻辑适配零售、售后，但完全不适配货代。
货代真实场景是错乱的：
同一个客户，同一个聊天窗口里，可能同时问三票完全不同的业务：美森普船、美森加急、空运，每一票的港口、柜型、船期、成本、时效全都不一样。
一个会话，对应多笔业务。
反过来也成立：同一票业务，会横跨无数个会话。
客户微信提需求、邮件发资料、邮件询代理、WhatsApp 议价、企业微信对接内部同事。
多个独立会话，最终只对应一笔业务。
这也是通用软件永远解决不好货代问题的核心。
所以我定了一条贯穿整个产品的核心原则：
Channel 负责沟通，Conversation 负责承载消息，Case 负责承载业务。
货代系统必须从「会话中心」，升级为业务案件中心（Case-Centric）。

05

05｜这也是通用软件和垂直行业软件的核心差异
现在很多通用软件，都能做到把邮件、社交消息聚合在一个页面。
但它们只能解决一个问题：消息在哪里看。
解决不了核心问题：这条消息，属于哪一票业务。
货代场景里，每一封邮件、每一条消息、每一份附件、每一次议价，都必须精准归属到对应的询价、报价、业务案件里。
如果还要靠人工判断、手动归类，那所谓的数字化、AI 自动化都是伪命题。
通用软件重「沟通」，垂直货代软件重「业务事实」。
询价、代理费率、比价、报价单、跟进动作、业务证据，这些专属业务对象，才是货代系统真正的上下文底座。

06

06｜是不是做一个超级统一收件箱，就能解决问题？
这是大部分人的第一直觉：既然多渠道碎片化，那就把所有渠道全部收拢，做一个统一 Inbox，销售只看一个页面就行。
逻辑听着完美，但落地必死。
因为邮件和即时消息，本身就是两种完全不同的工作模式。
货代处理 Email，需要文件夹、邮件串、抄送密送、转发、归档、签名、批量附件、高级搜索、多账号管理，是一套重度、严谨的办公流程。
而 WhatsApp、企业微信、LINE，是轻量化即时沟通，核心是未读、快捷回复、实时同步。
为了“统一界面”强行把两套逻辑揉在一起，最后的结果就是：
Email 不好用，即时消息也不流畅。
到这里我彻底想通了：Omnichannel 不等于 UI 统一。
真正需要统一的是底层业务逻辑，不是表层页面样式。

07

07｜为了想通这件事，我复盘了企业微信、钉钉、飞书
我没有闭门造车臆想产品形态，而是研究了国内最成熟的三套协作工具。
它们的共同答案非常一致：
统一身份、统一权限、统一入口，但专业应用保持独立。
企业微信：消息是消息，邮箱是邮箱，CRM 是 CRM，各自独立专业，底层共享组织和权限，消息可以联动业务卡片。
钉钉：把业务动作打进消息流，聊天可以发起待办、查看业务卡片，但不吞并专业应用。
飞书：邮箱、消息、文档、会议各司其职，模块独立，但数据可流动、可跳转、可关联。
三家产品都在印证一个道理：
统一，不等于合并。所有功能，不需要强行塞进同一个页面。

08

08｜Email 到底怎么放？我最终筛选了三套方案
落到具体落地，邮件的形态选择，是我纠结最久的问题，最终只保留三套可行方案。
A｜Beacon Mail 完全独立
邮件系统完全独立，拥有全套独立能力，即时通信渠道统一在 Connect。
优点：邮件体验极致专业，重度办公无压力。
缺点：形成两个沟通中心，长期会重新割裂业务，AI 无法拿到全局上下文。
B｜Email 全部塞进统一收件箱
所有渠道全部收拢进 Beacon Connect，单入口展示。
优点：表层最统一，看着最像全渠道。
缺点：Connect 会无限臃肿，为了适配邮件复杂逻辑，拖垮整体体验，即时通信的轻量化优势彻底消失。
C｜底层统一，上层双视图（最终选型）
Beacon Mail 保留独立专业邮件工作区，Beacon Connect 作为统一协同入口。
底层是同一份消息数据，上层是两种工作视角。
在 Connect 里，只看业务维度：客户是谁、归属哪个业务案件、AI 摘要、待办动作、业务状态。
在 Mail 里，只专注邮件本身：邮件串、抄送、附件、归档、转发、批量处理。
Connect 看业务，Mail 看邮件，数据不重复，业务不割裂。

09

09｜Connect 里的 Email，我重新定义为「邮件触点」
Connect 不能完全看不到邮件，否则全渠道闭环会断裂。
但绝对不能再做一套完整邮件收件箱。
我把 Connect 内的邮件功能，定义为邮件业务触点。
只展示核心业务信息：客户、邮件主题、AI 摘要、归属案件、负责人、业务状态，搭配高频操作：查看案件、创建动作、跳转邮件详情页。
所有专业邮件操作：转发、抄送、归档、签名、批量处理，全部留在 Beacon Mail。
延续成熟产品的核心思路：专业应用保持专业，跨应用打通业务联动。

10

10｜最终定型：BeaconQuote 整体架构
（架构图文字版，正式发布替换可视化配图）
BeaconQuote├─ CRM├─ Customer Case（业务案件中心）└─ Action（任务动作中心）│└─ Beacon Connect（协同枢纽）├─ Beacon Mail├─ 企业微信├─ WhatsApp├─ LINE└─ 网站渠道│└─ Omnichannel 全渠道会话底座
整套架构边界非常清晰：
  • Beacon Connect：用户可视的统一通信协同入口。
  • 全渠道会话底座：底层统一身份、消息、权限、上下文的核心能力。
  • Beacon Mail：专业邮件工作台，只深耕邮件场景，不重复搭建业务体系。
  • Customer Case：跨渠道、跨会话，聚合所有业务事实与证据的核心载体。

11

11｜Beacon Connect，绝不只是客户聊天窗口
很多人会默认把 Connect 当成对外客户收件箱，这是很窄的理解。
它的定位是内外协同枢纽。
不仅承接外部客户、代理、供应商、合作伙伴的沟通，同时承载企业内部团队、部门、跨部门的所有业务协同与通知。
它不是简单的 Unified Inbox，而是 Communication & Collaboration Hub。
消息只是入口，背后连接的是客户案件、业务任务、CRM 和所有业务工作台。
这也是为什么 Mail 需要独立：Connect 解决「人和业务怎么联动」，Mail 解决「邮件怎么专业高效处理」，两者关联，但不是同一套问题。

12

12｜还有一类协同，我暂时没有塞进普通外部协同
日常的客户、供应商协同，都可以归入常规外部协同。
但还有一种更深度的协同：企业与企业、集团与集团之间的业务协作。
比如国内团队接单，日本团队负责清关拖车，两地协同完成一票业务。
现在的做法依然是邮件、聊天、传文件、手动记录、各自存档。
未来的理想形态，是两端基于各自的业务案件做联动协作：
中方发起业务请求，日方接收、指派负责人、报价、更新进度、回传结果。
核心不是两边能聊天，而是两边可以协同业务，但互不泄露内部数据。
中方的利润、内部讨论，日方不可见；日方的成本、供应商资源，中方不可见。
这已经不是普通聊天协同，是真正的商业业务协同。
这一层我不在本篇展开，再往下会触及「企业间案件联动、Agent 对 Agent 协同」的更大命题，留到下篇细聊。

13

13｜Case-Centric 不代表 AI 可以全自动归票
这里必须讲清楚一个关键边界。
很多人理解的案件中心，是 AI 自动识别客户、自动匹配业务、自动归票，全程无人干预。
真实业务根本做不到百分百纯净。
公用邮箱多人共用、一个会话多票业务、客户一句话咨询两条航线，这些场景比比皆是。
单靠 AI 自动判断，一定会出错。
所以我定下的落地原则非常克制：
高置信度场景自动归票，模糊场景智能建议，核心业务关系必须人工确认兜底。
系统必须保留完整手动能力：手动绑定案件、解除关联、跨案件迁移消息、一条消息关联多案件、确认/驳回 AI 建议。
已经人工确认的结果，绝不允许 AI 自动覆盖。
Omnichannel 的价值是减少重复劳动，不是消灭人的业务判断。
一旦归票错误，AI 会基于错误上下文持续推演，偏差会越滚越大。

14

14｜我的最终选型：底层统一，前台专业，业务居中
复盘下来，我避开了两个最容易踩的坑：
没有做成多套孤立渠道系统（伪全渠道）；
也没有做成大一统超级收件箱（体验塌陷）。
最终收敛成一套稳定架构：
  • 架构层：Omnichannel 全渠道底座统一
统一身份、权限、上下文、工作流和任务体系。
  • 体验层：渠道原生专业化保留
邮件保持专业邮件体验，即时消息保持轻量化沟通体验。
  • 业务层：Case-Centric 案件居中
沟通渠道、聊天会话，全部服务于业务案件，而非反过来。
  • 协同层：Connect 做统一枢纽
承载内外协同，聚合业务触点与轻量操作。
  • 专业层：Mail 独立深耕
保障重度邮件办公场景的效率与严谨性。

15

15｜为什么现阶段依然是 Email First？
很多人会疑惑：通篇讲全渠道，为什么落地优先做邮件？
这不是矛盾，是「架构方向」和「落地顺序」的区别。
Omnichannel 是长期架构目标，Email First 是现阶段最稳妥的迭代节奏。
目前货代行业的正式询价、资料传输、代理对接、费率确认、正式报价、清关文件，核心闭环依然全部跑在邮件上。
先把邮件这条完整业务链路跑通、跑稳、跑闭环，是最高性价比的落地方式。
我后续验证架构是否成立，只有一个标准：
当客户从邮件切换到企业微信、WhatsApp 发起同样的询价，后端的案件、询价、比价、报价、跟进流程，是否完全不受影响。
渠道可以换，业务不能换，架构才算真统一。

16

16｜重新定义：Multichannel vs Omnichannel vs Case-Centric
写到这里，两个概念的区别已经非常清晰：
  • Multichannel：只是把所有沟通渠道接进系统。
  • Omnichannel：客户跨渠道沟通，业务上下文全程连续。
针对货代行业，我再加一层专属定义：
Omnichannel 解决跨渠道碎片化，Case-Centric 解决跨会话碎片化。
两者叠加，才是适配货代、且能支撑 AI Agent 长期落地的完整底座。

17

17｜最后：我为什么非要把这件事想透？
不是为了把系统做复杂，恰恰是为了未来更简单。
如果每新增一个渠道，就要重新做一遍业务适配、重新搭一遍 AI 逻辑、重新同步一遍客户数据，系统只会越做越乱、债务越积越多。
我现在卡死所有边界，只为一个目标：
渠道可以无限新增，业务主干绝不重构。
表层页面、交互方式可以不同，但底层的客户身份、业务事实、推进进度、下一步动作，必须是唯一且连续的。
比起统一页面，我更在意的是：统一上下文。
写到这里为止，我们梳理完货代场景下多渠道与全渠道的核心差异，也完成了通信底座上层产品形态的完整选型：底层搭建统一的 Omnichannel 会话底座，上层保留邮件独立专业工作区，由 Beacon Connect 承担企业内外协同枢纽。
但这套架构思考，目前还只停留在单一企业内部的消息与业务聚合。
一旦视野向外延伸，更多核心问题会浮出水面：跨企业如何完成无损业务协同？AI 消息归票的边界到底在哪里？AI Agent 的真正瓶颈，是大模型能力，还是一套可信、连续、有权限约束的业务上下文？
这些更深层的架构与 AI 落地思考，我们留在下篇继续展开。

相关学习资料