ARTICLE · 1039568
我正在用AI重塑一家货代公司 | AI 时代,一家货代公司真的还需要这么多部门吗?
我正在用AI重塑一家货代公司 | AI 时代,一家货代公司真的还需要这么多部门吗?这段时间我一直在拆系统。看看AI时代，到底一家货代哪个节点可以被优化，更智能。 前面拆过 CRM，拆到最后，我的判断是：未来 CRM 可能越来越不像一套销售每天必须打开的软件，而是变成 Customer Context，长进 Inquiry、Quote、Email、Shipment 这些真实业务里。 系统拆到这里，我突然想到一个更麻烦的问题： 软件可以重新拆，组织架构为什么不能？ 做货代十几年，我们早就习惯了一家公司应该有这些部门：销售部、航线部，有些公司叫市场部、海外部、客服部、操作部、单证部、大客户服务部。 公司再大一点，继续往下分。美线、欧线、东南亚线；海运、空运；进口、出口；FCL、LCL。 时间久了以后，这套组织结构变得太理所当然，很少有人再问一句： 一家货代公司，为什么一定需要这么多部门？ 这些部门到底是业务天然需要的，还是过去因为一个人做不过来、记不住、信息传不过去，我们不得不一层一层加出来的？ 这个问题我现在没有标准答案。 接下来一段时间，我可能会把自己现在的组织方式无数次打乱，再无数次重新组合。 销售和大客户要不要合？航线和海外要不要合？客服、操作、单证应该怎么拆？哪些岗位应该保留？哪些工作可以交给 AI？哪些事情哪怕 AI 能做，我也暂时不敢给它？ 我想拿真实业务一点点试。 不是为了追求一个看起来最 AI Native 的组织架构，而是想找一个 AI 时代真正能跑、能赚钱、出了问题还能兜得住的答案。 01｜一票货，在一家货代公司内部到底要“旅行”多少次？ 先不谈 AI，就拿一票很普通的业务来说。 客户发来 Inquiry： 20 台 Golf Cart，上海到 Los Angeles，带 Lithium Battery，需要做到门。 销售先补资料：Battery Specification 有没有？SDS 有没有？UN38.3 有没有？重量、尺寸、数量是多少？上海哪里提货？美国送到哪个 ZIP Code？什么时候要走？ 资料差不多以后，真正有意思的事情开始了。 Ocean Freight 问航线部；美国 Destination Charge、Customs、Delivery 问海外部；锂电池 Carrier 能不能接、需要什么资料，可能再问危险品同事、操作或者航线。 客户突然问一句：Free time 有几天？ 销售再去找操作或者航线。 几边 Rate 回来了，销售整理 Cost，算 Selling Rate，做 Quote。客户嫌贵，再来一轮。 成交以后，业务交给客服或者操作。操作 Booking，单证接 SI、核 BL，报关处理 Customs，拖车安排 Pickup，海外部继续协调 Destination Agent。客户中间问进度，又回到销售或者客服。 所以一票货表面上走的是：Shanghai → Los Angeles 实际上在公司内部先走了一圈： Sales → Pricing → Overseas → Operations → Documentation → Customs → Sales 有时候客户只是问了一句话，这个问题却在公司里旅游了一圈。 把这套流程重新摊开以后，会发现一个挺尴尬的事情： 货代公司很多时候不是在处理业务，而是在让信息从一个部门传到另一个部门。 02｜但以前这么分部门，完全合理 这里不能为了讲 AI，就把传统货代组织说得一无是处。 过去这么分，是有原因的。 一个销售不可能同时记住几十家 Carrier 的 Rate，也不可能知道所有航线的 Free Time、Local Charge、Cut-off，更不可能同时维护几百个 Overseas Agent，熟悉美国、欧洲、日本、东南亚不同的 Customs Requirement。 白天谈客户，晚上自己做 SI、核 BL、盯 Booking、追 Trucking，也不现实。 人的知识有限，注意力有限，一天只有 24 小时。 所以公司业务增加以后，只能专业分工：销售负责 Customer，航线部负责 Carrier 和 Rate，海外部负责 Agent，客服、操作负责 Shipment，单证负责 Documentation。客户再复杂一点，一个销售扛不住，就成立 Key Account Team。 说到底，这套组织解决的是几个很现实的问题： 一个人记不住，一个人做不完，一个人无法同时掌握这么多专业信息。 过去没有统一 Knowledge，没有 Customer Context，没有今天这种 AI、Workflow 和 Agent。用部门解决人的能力边界，是最现实的办法。 所以问题不是过去为什么这么设计。 真正值得问的是： 今天这些前提已经开始变化了，我们还要不要原封不动地保留过去的组织？ 03｜AI 来了以后，我想先把“部门”拆成“工作” 这是我现在做这件事最重要的方法。 我不会一上来问：海外部要不要取消？ 也不会问：单证部能不能全部用 AI？这种问法太粗。 我会把一个部门每天真正干的事情全部拆出来，再重新分类。 比如海外部。 如果一个海外同事熟悉美国 Customs，知道不同 Port 的情况，清楚哪个 Agent 靠谱，能判断 DDP 风险，能设计 Destination Solution，这个人当然非常值钱。 但如果一天大量工作只是：销售把需求发过来，转给 Overseas Agent，等回复，Agent 回价，整理一下，再转回销售，那么这里真正创造价值的是哪一步？ 航线部也一样。一个真正懂 Carrier、舱位、航线、市场波动和 Rate Strategy 的 Pricing，非常值钱。但如果大量时间花在找 Rate、复制 Rate、整理 Rate、回答“这个价格还有没有效”，这里面有多少事情必须由人完成？ 单证更明显。复杂 BL、Manifest Risk、特殊 Cargo、改单、异常文件当然需要专业经验。但正常票里，大量工作仍然是读取 Booking、复制 Shipper / Consignee、核 SI、生成 Draft BL、检查字段、比较 Version。 所以“AI 能不能干掉海外部”“单证部会不会消失”，这种问题我现在基本不讨论。 部门只是外壳。先把里面的工作拆开，答案自然会出来。 04｜我会先按“安全程度”重新分一次 这可能是我接下来反复试验的重点。 AI 能做，不代表我就敢让它做。 所以我现在会把工作至少分成三类。 第一类：低风险、高重复、结果容易检查 这类我会最激进。 比如资料识别、字段提取、历史 Case 检索、Supplier Rate 整理、版本比较、SI 初步检查、BL Draft 检查、Shipment Status 汇总、Follow-up 提醒、Customer Context 自动更新。 做错了，大部分还能在人真正执行以前发现。 这种工作不给 AI，我反而觉得浪费。 第二类：AI 可以做，但必须有人确认 比如 Solution Draft、Quote Draft、Supplier 推荐、异常 Rate 提醒、客户回复 Draft、Requote 建议、风险识别。 AI 可以把 80% 的准备工作做完，但最后那一下留给人。 这里追求的不是无人化，而是：人不要再从零开始。 第三类：高风险、不可逆、涉及责任 最终 Selling Rate、重大赔付、Credit、重大 Compliance、Supplier Blacklist、关键客户商务承诺、重大异常处理。 这些事情哪怕 AI 判断已经很好，我现阶段也不会轻易把最终权限交出去。 因为判断错一次，可能不是返工的问题。 可能直接赔钱、丢客户，甚至产生合规责任。 所以我现在做组织重构，有一个很重要的原则： 先把最安全、最重复、最容易验证的工作交出去，再一点一点往高价值、高风险的地方走。 我不追求一步到位。 我会无数次拆，无数次组合。 哪里跑不通，就退回来。 哪里 AI 的准确率还不够，就继续让人守着。 哪里已经稳定，再往前放一点权限。 我想找的是可以进入生产环境的组织，不是 Demo 里最漂亮的组织。 05｜如果一定要先砍一样东西，我第一刀不会砍人，也不会砍部门 我会先砍： Handoff 客户问销售，销售问航线，航线问船东；船东回航线，航线回销售，销售再回客户。 Destination 不清楚，再跑一遍海外部。海外部问 Agent，Agent 回海外部，海外部回销售，销售再回客户。 客户又补一句：Can you also include customs clearance? 很好，再来一圈。 一个问题在公司里转了五个人，最后所有人都很忙。 但这五个人里面，可能只有一个人在真正做判断，剩下四个人都在传话。 每多一次 Handoff，就多一次等待、多一次信息损耗、多一次理解偏差，也多一次： “我已经发给某某了，在等回复。” 很多公司内部所谓的“协同”，其实就是同一份信息不断 Copy、Forward、Wait、Reply。 所以 AI 对组织最先产生的价值，我认为不是少一个员工。 而是：少一次 Handoff。 如果 Inquiry 进来以后，系统能够先识别需求、检查缺失信息、调用 Knowledge、找到 Historical Case、读取 Supplier Rate，再把真正需要人判断的地方送到对应的人面前，那么很多“传话工作”自然会变薄。 这比一上来研究裁掉哪个部门健康得多。 06｜航线部和海外部，我会先试着打通 如果让我在现有组织里选两个最先尝试打通的部门，我会选航线部和海外部。 原因很简单。 客户根本不知道你公司内部为什么 Ocean Freight 要问航线部，Destination Charge 又要问海外部。 他只问：Door to Door 多少钱？ 客户买的是 Solution，不是你的组织架构。 还是那票 Golf Cart。真正需要解决的是 Cargo Requirement、Battery Compliance、Origin、Ocean Freight、Destination Charge、Customs、Delivery、Risk、Cost、Selling Rate。 过去这些信息散在几个人手里。 未来更合理的方式，是 Inquiry 进来以后先被拆解，再调用 Knowledge、Historical Case、Carrier Rate、Supplier Rate、Overseas Agent Rate，把 Solution Draft 准备出来。 然后人来处理真正有价值的部分：判断方案、选择 Supplier、判断异常、确认 Margin、决定 Selling Rate、承担商务责任。 这时候 Carrier 是 Supplier，Overseas Agent 也是 Supplier，Customs Broker 是 Supplier，Trucker、Warehouse 同样都是 Supplier。 它们共同组成：Supplier / Solution Network。 过去按照供应商类型划开的航线部和海外部，边界自然会开始变淡。 07｜客服、操作、单证，我会先拆“正常”和“异常” 这三个部门我不会粗暴合并。 我会先做另外一件事：把正常票和异常票拆开。 正常业务里很多动作其实非常确定：Booking、资料检查、SI、BL Draft、Status Update、Document Check、Milestone、Reminder。 这些适合 Workflow、AI 和确定性的 Business Rule。 真正需要人的，是甩柜、查验、客户突然改单、目的港异常、Carrier 临时变化、文件冲突、重大延误和投诉。 所以以后一个单证最值钱的能力，可能不是一天手工敲 80 票，而是： 系统挑出 5 票异常以后，这 5 票他一票都别判断错。 正常票让系统跑。 人盯异常票。 人的经验应该花在异常上，不应该浪费在 Copy / Paste 上。 客服和操作也一样。 未来 Fulfillment 的核心价值，会从：Process Everything 逐渐往：Manage Exceptions 移动。 08｜大客户服务部，最应该保留的是关系，最应该拿掉的是信息协调 为什么很多货代公司会有 Key Account Department？ 因为大客户太复杂。 Shipment 多、联系人多、航线多、报价多、异常也多。一个销售根本记不住，所以公司给他配 Key Account Manager、Customer Service、Operation、Pricing，甚至一整支专门 Team。 一个优秀的大客户经理，很多时候像一个活的 Customer Context。 他知道这票到哪里了，那个 Quote 回了没有，哪个 Shipment Delay，客户投诉谁在处理，财务有没有问题，下周有什么事情。 但这里面其实有两种完全不同的价值。 第一种是：Relationship Owner。 他了解客户，知道客户内部关系，知道什么时候该老板出面，知道哪些问题不能只看价格。 这个价值非常高。 第二种是：Information Coordinator。 每天在几个群里追：“这票到哪了？”“Rate 回了吗？”“客户投诉谁在处理？”“这个 Shipment 为什么 Delay？” 这部分我希望系统拿走。 如果系统连一票 Shipment 到哪、Quote 有没有回来、谁没回复都不知道，那是系统的问题。 不应该靠一个大客户经理每天在群里追。 AI 不会让 Key Account 不重要。 恰恰相反。 越是把信息协调拿走，大客户经理越应该把时间还给“大客户”。 09｜销售也不会原封不动 后台岗位变化以后，销售也不可能照旧。 今天很多货代销售其实同时干着好几份工作：销售、内部 Coordinator、数据录入员、半个客服，有时候还是半个 Pricing。 真正用于客户关系、判断和谈判的时间，可能没有想象中多。 客户问一个问题，先内部问一圈；Rate 没回来，去催；Quote 做完，自己整理；报价发出去，录 CRM；客户问 Shipment，又去找操作。 如果 Knowledge、Customer Context、Workflow、Task、AI 把这些外围工作逐渐承接下来，销售没有被削弱。 他只是终于可以回去做销售了。 找到对的人，建立关系，理解真实需求，判断机会，谈判，拿订单。 未来好的 B2B Sales，可能反而比今天更像 Sales。 10｜所以我不会先问：AI 到底能裁多少人？ 老板看到这里，第一个问题大概率是： 那能少多少人？我也关心。 毕竟公司不是实验室，最后一定要算账。 但如果第一天就拿“裁员人数”作为 AI 项目的 KPI，很容易把系统做歪。 我会先算另外几笔账： 一票业务在公司内部被转手多少次？同一个字段被录入多少遍？一个 Pricing 每天有多少时间真的在做 Pricing？一个 Key Account Manager 有多少时间在经营客户，又有多少时间在追内部进度？一个单证每天有多少时间在判断异常，又有多少时间在 Copy / Paste？一个销售每天有多少时间真的在谈客户，又有多少时间在催内部？ 先把这些账算清楚，再谈人。 最后可能出现三种结果。 原来 100 个人的业务，以后 70 个人能做。 也可能还是 100 个人，但可以承接过去 150 个人才能做的业务。 还有一种特别适合中小货代：今年不裁人，但明年业务增长 30%，不用再按照过去的方式同步增加 30% 的组织。 第三种其实很有价值。 因为 AI 对中小企业最大的意义，未必只是少发几份工资。 它可能是：业务增长以后，组织不用按照原来的比例一起变重。 这叫组织弹性。 11｜最后，一家 AI 时代的货代公司到底应该长什么样？ 这个问题，我现在没有答案。 甚至我不准备太早给自己答案。 今天我可能认为航线部和海外部应该合。 跑一段以后，发现某些专业边界必须重新拆开，那就拆。 今天觉得客服、操作、单证可以按照正常 / 异常重新组织。 真正跑进生产环境以后发现责任边界不清，那就重新组合。 一个 Agent 能做到 90%，但剩下 10% 一旦出错就可能丢客户，那就把权限收回来。 一个 Workflow 跑了三个月，发现比人工稳定，那就再往前放一点权限。 我会不断打乱，再不断组合。 不是为了折腾组织。 而是因为我们正在面对一套过去没有出现过的生产能力。 以前组织围绕人的能力设计。 现在多了 AI、Knowledge、Workflow、Agent、Customer Context。 旧答案不一定还是最好的答案。 但新答案也不可能靠我坐在办公室里画一张组织架构图就自动出现。 只能拿真实业务去跑。 如果今天非让我画一个 Version 0.1，我大概会先画一票业务： Customer → Inquiry → Solution Quote → Won / Lost → Fulfillment → Shipment → Revenue 然后再看这条业务真正需要哪些能力，而不是先决定公司需要几个部门。 我现在暂时会把它分成四层： Customer / Growth负责客户关系、获客、需求理解和成交推进。 Solution / Commercial负责 Supplier、Rate、Pricing、Compliance、方案和商务判断。 Fulfillment负责订单执行、流程推进和异常处理。 Control负责 Finance、Risk、Credit、Permission、重大赔付和 Governance。 下面再铺一层共享能力： Customer Context + Knowledge + Workflow + Task + AI Runtime 这张图不是最终答案。 甚至我估计过几个月以后，自己都会把它推翻一部分。 但这正是我现在想做的实验。 12｜我真正想找的，不是“最 AI”的组织，而是“最安全又最省事”的组织 这一点我想特别说明。 现在聊 AI 重构公司，很容易追求一个特别性感的目标： 无人化。 全 Agent。 全自动。 一个人管理几十个 AI 员工。 我没有那么激进。 至少在货代行业，我不敢。 因为不同工作的错误成本完全不一样。 AI 把一份内部资料整理错了，人重新整理一下。 AI 把一个客户的 Selling Rate 报错了，可能直接赔钱。 AI 漏掉一个 Lithium Battery Requirement，可能影响 Shipment。 AI 对一个大客户做了公司根本无法履行的承诺，损失的可能不只是一票货。 所以我不会用同一套自动化标准去处理所有工作。 我现在更愿意画一张“安全地图”。 一边是：低风险、高频、重复、可逆。 另一边是：高风险、低频、重大、不可逆。 越靠前，AI 权限越大。 越靠后，人越应该站在最后一道门前。 比如： 资料识别、历史 Case 检索、Rate 整理、版本比较、Status 汇总，可以大胆一点。 Solution Draft、Quote Draft、Supplier 推荐、异常提醒，可以让 AI 做大量准备，但人确认。 最终 Selling Rate、重大赔付、Credit、高风险 Compliance、关键客户承诺，至少现阶段我不会轻易把最终权限交给 AI。 这可能会让我推进得没有别人 Demo 那么快。 没关系。 我做的不是 Demo。 我要把它放进一家真的有客户、真的会赔钱、真的会丢单的公司里跑。 能跑，比看起来先进重要。 13｜所以这次组织重构，我大概率会反复打自己的脸 今天我可能写：航线部和海外部应该打通。 半年以后发现某些国家的 Destination 专业度太高，又重新拆出来。 今天我认为单证大量工作可以自动化。 真正跑起来以后发现某类特殊货、某几个国家、某种 BL 必须强制人工复核，那就重新把人放回去。 今天觉得一个 Agent 可以做某件事情。 跑 100 次以后发现准确率不够，那就降级成 Assistant。 这对我来说都不算失败。 反而是我现在最想得到的数据。 因为企业组织不是靠一篇文章设计出来的。 到底哪个岗位可以变薄，哪个部门可以融合，哪个 Agent 可以放权，最后都要靠真实业务告诉我。 所以接下来我可能会： 拆掉。 跑一段。 发现问题。 再组合。 再跑。 直到找到一个相对稳定的状态。 这可能比直接宣布“未来货代公司只需要四个部门”慢很多。 但我相信这个答案更值钱。 最后总结 过去我们按照人的能力边界设计公司。 一个人记不住，所以成立专业部门；一个人做不完，所以继续拆岗位；信息传不过去，所以增加 Coordinator；客户太复杂，再成立 Key Account Team。 公司越大，部门越多。 部门越多，Handoff 越多。 Handoff 越多，又需要更多人协调。 这套组织在过去非常合理，因为当时没有更好的办法。 但今天如果让我重新画一次组织架构，我不会先问： 销售部多少人？ 海外部多少人？ 航线部多少人？ 单证部多少人？ 我会先把一票业务摊在桌上，从客户第一次发 Inquiry，一直画到 Shipment 和 Revenue。 然后一段一段问： 这里需要的是知识，还是人？这里需要的是判断，还是传话？这里需要的是关系，还是数据搬运？这里是正常流程，还是异常处理？这里的错误可以改回来，还是错一次就可能丢客户？这里必须有人承担责任，还是过去只是因为系统不知道发生了什么，所以安排了一个人盯着？ 问完以后，再回头看组织。 有些部门还会在。 有些部门可能会合在一起。 有些岗位名字没变，里面做的事情已经完全不同。 也会有一些工作直接消失。 不是因为 AI 非要抢走谁的工作。 而是那些工作原本就在替低效的信息流动买单。 所以如果让我今天重新设计一家货代公司，我不会从“部门”开始。 我会从一票货开始。 客户要什么？ 这票业务需要哪些能力？ 哪些事实系统已经知道？ 哪些动作可以安全交给 AI？ 哪些只能让 AI 做 Draft？ 哪些必须由人确认？ 出了错，代价是什么？ 一段一段拆。 一段一段试。 然后再把人、AI、Workflow、Knowledge 重新组合起来。 过去是先有部门，再让业务在部门之间流转。 这一次，我想反过来：先让一票业务完整地流动，再把人放到真正需要人的地方。 我现在也不知道最后会组合成什么样。 也许一年以后，我自己都会推翻今天文章里的一部分判断。 但这恰恰是我接下来最想验证的事情： AI 时代，一家货代公司到底应该怎么重新长一遍？ 如果你也是做货代的，我也很想听听你的答案。 销售、航线、海外、客服、操作、单证、大客户服务—— 如果今天让你把这些部门全部打散，再重新组合一次，你会怎么组？ 哪些工作你已经敢交给 AI？ 哪些事情你到今天依然不敢？ 也许真正适合 AI 时代的货代组织，不会是我一个人想出来的。 我先拿自己的业务试。 你们也可以告诉我，什么样的组合才是最合适的。
01
02
03
04
05
06
07
08
09
10
11
12
13
14