提交
This commit is contained in:
@@ -1,4 +1,339 @@
|
||||
# client-logistics
|
||||
# 物流与货代 AI 智能体解决方案
|
||||
|
||||
本页面面向物流与货代客户，说明匠厂如何围绕真实业务流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 客户询价来自微信、邮件、表格、截图，格式不统一，业务员每天要花大量时间整理要素、反复确认起运港、目的港、箱型箱量和时效要求
|
||||
- 查舱位、查船期、查轨迹、查费用分散在多个网站、船司系统和内部表格里，机械查询占用一线大量时间
|
||||
- 客户催问「货到哪里了」「为什么还没放行」，异常往往在客户投诉前才被发现，被动响应多、主动预警少
|
||||
- 托书、发票、装箱单、提单、报关单之间信息不一致，改单、退单、查验时才发现错漏，处理成本高
|
||||
- 对账依赖人工逐行核对船司账单、拖车账单、客户 SOA，差异定位慢，月结期间财务和操作压力集中
|
||||
- 新人要熟悉各航线、各船司、各客户特殊要求，培训周期长，经验多在老员工脑子里，交接容易断档
|
||||
- 管理层想看航线利润、客户贡献、异常率，数据要从多个系统导出再手工汇总，报表往往滞后
|
||||
- 合规筛查、归类、禁限品判断依赖人工查清单、问同事，高峰期容易漏检或反复确认
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### 询价与报价
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 从邮件、微信、附件中自动提取询价要素，减少手工抄录和漏项
|
||||
- 结合费率表、协议价和附加费规则，快速生成可对比的报价草稿
|
||||
- 报价后跟进提醒、成交率分析，帮助销售把精力放在客户沟通上
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 询价邮件整理智能体
|
||||
- 综合报价草稿智能体
|
||||
- 协议价与附加费核算智能体
|
||||
- 报价跟进提醒智能体
|
||||
- 投标应标文件辅助智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 结构化询价单（起运港、目的港、品名、箱型箱量、贸易条款、时效要求）
|
||||
- 多方案对比报价单（海运费、本地费、目的港费、杂费明细）
|
||||
- 待跟进客户清单与建议话术
|
||||
- 应标文件初稿与历史投标复用建议
|
||||
|
||||
### 轨迹查询与异常提醒
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 海运、空运、陆运、快递轨迹统一查询，减少多网站切换
|
||||
- 船期变更、中转延误、滞箱滞港、温控异常等主动提醒，而不是等客户来问
|
||||
- 订舱确认、VGM 截止、报关放行等关键节点进入待办列表
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 全程运单追踪智能体
|
||||
- 集装箱动态监控智能体
|
||||
- 运输异常预警智能体
|
||||
- 船期变更提醒智能体
|
||||
- 报关进度追踪智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 单票货物最新节点与时间线摘要
|
||||
- 异常待处理清单（延误、甩柜、查验、超期费等）
|
||||
- 关键截止时间提醒（截关、截 VGM、截补料等）
|
||||
- 客户可发送的状态说明草稿
|
||||
|
||||
### 单证与资料核对
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 从托书、PDF、Excel 中提取收发货人、唛头、品名、数量等要素，减少重复录入
|
||||
- 商业发票、装箱单、提单、报关单之间自动比对，提前发现不一致
|
||||
- 报关制单、产地证、保险单等单证草稿生成，操作员专注审核而非从零填写
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 托书解析与建档智能体
|
||||
- 跨单证一致性核对智能体
|
||||
- 提单与发票校验智能体
|
||||
- 报关制单辅助智能体
|
||||
- 合规与禁限品预检智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 结构化托书/订单信息
|
||||
- 单证差异对照表（字段、原值、建议修正）
|
||||
- 报关单及随附单证草稿
|
||||
- 合规风险提示清单（归类、品牌、危险品、制裁筛查等）
|
||||
|
||||
### 对账与财务
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 客户 SOA、船司账单、拖车账单自动匹配，差异行高亮，减少逐行核对
|
||||
- 共用费用分摊、多币种换算、凭证草稿生成，缩短月结整理时间
|
||||
- 应收账龄、逾期预警、催款话术分级生成，财务跟进更有节奏
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 对账单智能核销智能体
|
||||
- 承运人账单审核智能体
|
||||
- 共用费用分摊智能体
|
||||
- 对客开票草稿智能体
|
||||
- 应收逾期提醒智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 已对平/待确认差异清单
|
||||
- 重复计费、金额异常、科目错配提示
|
||||
- 分摊结果表与开票明细草稿
|
||||
- 分级催款话术与账龄摘要
|
||||
|
||||
### 客户服务与通知
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 常见问题、轨迹查询、业务咨询自动应答，减轻前台重复回复压力
|
||||
- 到港、放行、签收、异常等节点按客户偏好自动通知
|
||||
- 投诉分级升级、道歉函与补偿方案草稿，服务响应更规范
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 货代智能客服智能体
|
||||
- 客户节点通知智能体
|
||||
- 投诉升级路由智能体
|
||||
- 内部知识库问答智能体
|
||||
- 客户自助门户辅助智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 客户咨询答复草稿（含轨迹摘要与下一步建议）
|
||||
- 按模板生成的状态通知（邮件/消息草稿）
|
||||
- 投诉处理单与责任人分派建议
|
||||
- SOP、客户特殊要求、历史工单检索答案
|
||||
|
||||
### 经营分析
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 订单利润、航线贡献、客户价值分层自动汇总，管理层不必等手工报表
|
||||
- 销售漏斗、成交率、供应商绩效等分析定期输出，支持经营决策
|
||||
- 箱量预测、运价走势、现金流滚动预测辅助锁仓、谈价和资金安排
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 订单利润分析智能体
|
||||
- 航线与客户经营看板智能体
|
||||
- 销售漏斗诊断智能体
|
||||
- 供应商绩效报告智能体
|
||||
- 经营周报月报智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 多维度利润排名与异常波动提示
|
||||
- 航线/客户/业务员贡献度摘要
|
||||
- 询价到成单转化率与胜负原因分析
|
||||
- 可钻取的 KPI 看板与定期经营报告
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 试点一：询价邮件整理 + 报价草稿
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 每天发生频次高，业务员感受直接，价值容易量化
|
||||
- 规则相对明确（港口、箱型、费率表、附加费），智能体输出便于人工复核
|
||||
- 不直接对外发送，风险可控
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 典型询价邮件/微信/表格样例（脱敏即可）
|
||||
- 常用航线费率表、协议价、附加费规则
|
||||
- 现有报价单模板与审批习惯
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 结构化询价单
|
||||
- 含多方案对比的报价草稿
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 询价要素是否提取完整、准确
|
||||
- 报价金额、贸易条款、有效期是否可对外发送
|
||||
|
||||
### 试点二：运单轨迹查询 + 异常提醒
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 查询动作重复、耗时，客户催问压力大
|
||||
- 接入轨迹数据源后，智能体可汇总状态并主动推送异常
|
||||
- 可先对内使用，验证节点准确性后再对客户开放摘要
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 常用承运人/船司/航司及现有查询方式
|
||||
- 内部异常定义（如延误天数、甩柜、查验、滞箱费阈值）
|
||||
- 客户通知模板与通知渠道偏好
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 单票轨迹时间线摘要
|
||||
- 异常待办清单与通知草稿
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 节点时间与状态是否与客户/承运人信息一致
|
||||
- 对外通知内容是否准确、语气是否合适
|
||||
|
||||
### 试点三：跨单证一致性核对
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 错单改单成本高，提前发现不一致能直接减少损失
|
||||
- 比对规则清晰（品名、数量、金额、唛头、收发货人等）
|
||||
- 适合在制单完成后、提交前作为固定复核环节
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 商业发票、装箱单、提单、报关单等典型样例（含历史改单案例更佳）
|
||||
- 各客户、各航线的字段要求与常见错漏点
|
||||
- 现有审核流程与责任人分工
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 字段级差异对照表
|
||||
- 建议修正项与风险说明
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 差异是否属实、是否必须改单
|
||||
- 涉及金额、品名、贸易条款的修正需操作主管确认
|
||||
|
||||
### 试点四：SOA 对账差异标记
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 月结对账痛点集中，差异定位慢
|
||||
- 匹配规则可逐步完善（柜号、提单号、费用科目、金额容差）
|
||||
- 智能体只做「标记差异」，核销与入账仍由财务把关
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 客户 SOA、内部台账、船司/拖车账单样例
|
||||
- 费用科目映射关系与常见差异类型
|
||||
- 现有对账流程与月结时间表
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 已匹配/待确认/无法匹配明细
|
||||
- 差异原因分类与跟进建议
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 差异是否可接受、是否需要追收或调整
|
||||
- 确认后的核销结果方可入账或对外回复
|
||||
|
||||
### 试点五：内部知识库问答（SOP / 客户特殊要求）
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 投入相对小，新人与跨岗同事立即可用
|
||||
- 不直接改动对外单证或财务数据，风险低
|
||||
- 可快速沉淀老员工经验，减少「问人」和重复培训
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 操作手册、SOP、航线指引、客户特殊要求文档
|
||||
- 历史工单或常见问题汇总（脱敏）
|
||||
- 希望覆盖的岗位场景（操作、销售、客服、报关等）
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 带来源引用的问答答复
|
||||
- 未覆盖问题清单，供后续补充知识库
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 涉及合规、放货、改单等关键操作时，仍须人工按制度执行
|
||||
- 新知识入库前由业务负责人审核准确性
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 案例一：某国际货代企业 — 询价整理与报价辅助
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 以海运出口为主的国际货代，销售与操作分岗，日询价量较大 |
|
||||
| **原业务流程** | 销售从邮件、微信收集询价，手工填入 Excel 或 OMS，再查费率表做报价，忙时易漏项、报价比价慢 |
|
||||
| **主要问题** | 询价要素整理耗时长；同一客户多次询价重复录入；报价版本多、难追溯；新人报价一致性差 |
|
||||
| **匠厂交付内容** | 询价邮件整理智能体、综合报价草稿智能体、报价跟进提醒；对接现有费率表与报价模板；执行日志与人工确认界面 |
|
||||
| **人工确认节点** | 结构化询价单发送前由销售确认；报价对外发送前必须人工审核金额与条款 |
|
||||
| **上线后变化** | 销售从「整理信息」转向「谈条款与成单」；报价草稿可追溯；漏项类差错在复核环节前置发现 |
|
||||
| **适用边界** | 非标特种货、需现场勘验或复杂合规论证的询价，仍须专家介入；智能体不替代最终报价审批权 |
|
||||
|
||||
### 案例二：某货代企业 — 轨迹汇总与异常待办
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 海空联运货代，客服需频繁回复客户在途状态，操作需跟踪甩柜、查验、滞箱等异常 |
|
||||
| **原业务流程** | 客服、操作分别在船司网站、承运人平台、内部表格查询，再手工回复客户或登记异常 |
|
||||
| **主要问题** | 查询分散、重复劳动多；异常发现偏晚；客户通知口径不统一；交接班信息易遗漏 |
|
||||
| **匠厂交付内容** | 全程运单追踪智能体、运输异常预警智能体、客户节点通知草稿；异常待办推送到现有协作工具；关键节点执行记录 |
|
||||
| **人工确认节点** | 对外通知发送前由客服或操作确认；涉及索赔、改配、费用承担的判断由主管确认 |
|
||||
| **上线后变化** | 客户在途咨询响应更快；异常进入待办而非散落在个人记事；班次交接有统一状态摘要 |
|
||||
| **适用边界** | 依赖承运人数据质量与更新频率；极端天气、港口罢工等需结合人工判断与客户沟通策略 |
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂按真实业务流程分步落地，不追求一步「全自动化」：
|
||||
|
||||
1. **需求访谈** — 了解岗位分工、系统现状、痛点优先级与合规要求
|
||||
2. **流程拆解** — 把高频环节拆成「理解 → 执行 → 人工确认 → 记录」可验收步骤
|
||||
3. **样例数据确认** — 用脱敏邮件、单证、对账单等样例校准规则与输出格式
|
||||
4. **智能体开发** — 按场景开发对应智能体，对接 ERP/TMS/邮件/表格等已有工具
|
||||
5. **小范围试运行** — 先选一条航线、一个客户群或一个岗位试点，收集反馈
|
||||
6. **培训上线** — 操作手册、现场培训、确认节点与异常处理约定一并交付
|
||||
7. **持续优化** — 根据日志与业务变化迭代规则、模板和知识库
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 询价整理、轨迹查询、单证核对、对账标记等**高频、规则相对明确、可复核**的工作
|
||||
- 已有费率表、SOP、单证模板、对账习惯，愿意提供样例数据的企业
|
||||
- 希望在**人工确认前提下**减少重复录入、重复查询、重复汇总
|
||||
- 多系统并存（OMS/TMS/财务/邮件/Excel），需要有人把环节串起来
|
||||
- 希望把老员工经验沉淀为**可查询、可追溯**的智能体能力
|
||||
|
||||
### 不适合
|
||||
|
||||
- 期望「完全不经过人」就对外报价、放货、入账、报关申报
|
||||
- 没有任何样例流程或数据，且不愿意配合梳理业务规则
|
||||
- 核心系统接口、数据权限无法配合，智能体无法读取必要信息
|
||||
- 特种货、重大合规争议、索赔谈判等**必须专家判断**的场景，不宜强行全自动
|
||||
- 仅想要通用聊天机器人，而不愿定义具体业务任务与验收标准
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂物流与货代技能组，当前包含 **123** 个技能仓库。
|
||||
|
||||
@@ -303,3 +638,16 @@
|
||||
- **draft-internal-handover** — 班次与岗位交接文档自动生成
|
||||
- **log-operation-audit** — 操作轨迹与审计日志
|
||||
- **audit-compliance-log** — 合规操作日志审计
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
www.jc2009.com
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
Reference in New Issue
Block a user