按行业看
我们做过的事
每个案例都写清楚：原来怎么干、我们建了什么、接了哪些系统、哪些判断留给人、你会拿到什么、现在到哪一步。
报关与清关J.D. USA美国报关行
一天 300 多票，五个人，三十年的手工经验。
原来是怎么干的
客户把提单、发票、装箱单发到 Yahoo、Gmail、Hotmail 等多个邮箱。操作员逐封下载附件，人工识别品名和 HS Code，登录 NetCHB 一项项录入，再到本地版 QuickBooks 记账。NetCHB 没有官方 API，三套系统之间全靠人搬。人力已经满载，业务想长也长不动。
人工负责的部分
品名、HS Code 和申报要素的最终判断，始终由持证报关人确认后才提交。
我们建了什么
- 收件与附件处理 Agent：按货主和提单号把散落的附件归集成一票
- 单证解析与要素提取，连同这家报关行自己的判断规则写成业务手册
- NetCHB 操作工具：沿用人工的操作路径写入，没有 API 也能接
- 开发文档与部署运维文档，交接和排错不依赖某个人
涉及的系统
NetCHBQuickBooksEmail (Yahoo / Gmail / Hotmail)
交付物
- 报关 Agent 与业务规则手册
- NetCHB 系统操作工具
- 开发与部署运维文档
有完整的开发与部署文档；生产可用范围按环节逐项确认，不按整体宣称已全自动。
卡车与港口运输Nature Brother Trucking美西拖柜与派送
查柜不该是一天里最耗人的事。
- 跨多个码头与船司站点
- 调度与报价在同一套工具里
- 操作员本机执行，沿用已有登录态
原来是怎么干的
调度员在各个码头和船司网站之间逐柜点查，抄进表格，再用电话和微信通知司机。网站会改版、会要验证、会把人踢出登录，一柜一柜重来。报价规则在老员工脑子里，换人就得重教。
人工负责的部分
派车、改价和对客户的承诺由调度确认；Agent 负责取数、填单和留痕。
我们建了什么
- 查柜 Agent：跨码头与船司站点取状态，异常和验证统一处理
- 调度工作台：柜况、派车、报价在同一个界面上推进
- Windows 桌面连接器：在操作员自己的电脑上执行，复用已有登录态
- 行业规则沉淀成操作手册，新人照着就能上手
涉及的系统
Terminal portalsCarrier portalsOdooWeComLocal Chrome
交付物
- 查柜与调度 Agent
- 调度工作台（Web）
- Windows 桌面连接器与发版流程
- 操作手册与运维文档
工具在客户日常使用中；后续合同范围仍在确认，不把合同范围当成已交付范围。
海外仓与仓储Allways Express Logistics拆柜 · 一件代发 · 长期存储
跨系统核对，拆成可以一条条检查的步骤。
- 三条业务线：拆柜 / 一件代发 / 长期存储
- Property Broker，运力全靠外部承运商
- 服务跨境电商与 Amazon FBA
原来是怎么干的
POD、承运商回单、仓库系统和客户账单各自一套数据。对不上的时候，只能靠人翻单据、翻邮件、翻聊天记录，一笔一笔核。差异发现得晚，账也就跟着晚。
人工负责的部分
差异的定性和对客户的账务处理由仓储和财务决定，Agent 只负责找出差异并给出依据。
我们建了什么
- POD 核对 Agent：按单据对照仓储与承运商数据，差异单独列出
- 仓储运营中控看板：在库、出库、异常一屏可见
- 承运商与仓储系统适配器，核对脚本可重复跑
涉及的系统
WMSCarrier portalsPostgreSQLEmail
交付物
- POD 核对工作流与脚本
- 运营中控看板
- 承运商 / 仓储适配器
适配器、部分动作和核对脚本可用，整体部署尚未完成。不写完成百分比。
餐饮与到家履约LoveHibachi到家日式铁板烧服务
总部、站点和厨师，看同一份事实。
- 总部 / 站点 / 厨师三端协同
- Odoo 19 承载账务与销售税
- 工单与电子签在系统内闭环
原来是怎么干的
订单来自多个渠道，排班靠群聊，厨师入驻和合同靠来回发文件。出了问题要翻聊天记录找责任人，权限也说不清谁能改什么。
人工负责的部分
派单、客诉处理和合同条款由运营和管理层确认；系统负责把过程留痕。
我们建了什么
- 履约中控台：订单、排班、站点与厨师状态在一处推进
- Odoo 19 账务与美国销售税接口对接
- 内置工单系统：客户提单、我们回复、每条修复附可反复观看的演示
- 厨师入驻与合同电子签
- 角色权限与操作事件记录
涉及的系统
Odoo 19FirebaseStripeNext.js
交付物
- 履约中控台（Web）
- Odoo 19 账务与税务模块
- 工单系统与交付解说
- 部署与环境配对文档
核心履约与账务在生产使用；部分模块仍在开发环境迭代，按环境分别说明。
上门服务与现场作业WASHGO上门洗车与汽车养护
从客户点下预约，到技师签字完工。
- 客户端与技师端双端已部署
- 排程读班次、位置与通行时间
- 结算、分成与凭证落在 Odoo 19
原来是怎么干的
预约在网站和小程序，派单在微信，作业记录在技师手机相册，结算在表格。多城市复制的时候，每个区域都得重新教一遍人。
人工负责的部分
排程草稿由调度员确认后才派出；赔付与投诉处理由客服和管理层决定。
我们建了什么
- 客户预约端：下单、改约、评价与售后
- 技师作业端：导航、到场、洗前洗后拍照、客户签字
- 排程引擎：按时间窗、技能与产能排当日行程，调度员可改
- Odoo 19 Field Service 工单、Stripe 收款、技师分成结算
涉及的系统
Odoo 19 Field ServiceStripeWeChatNext.js
交付物
- 客户端与技师端应用
- 排程引擎与调度看板
- Odoo 19 现场服务与结算配置
- 部署记录
双端有部署记录、可实际点开演示；不等于客户已完成验收或已产生经营结果。
跨境电商与品牌站Lovia · Cabinique · ITSVA珠宝 / 家居建材 / 餐饮平台
商品、内容、支付和后台，不该是四个项目。
- 品牌站与商家门户均已上线
- 多环境：开发 / 测试 / 生产分开
- Odoo 承载商品、订单与售后
原来是怎么干的
商品资料散在供应商表格、图片目录和旧网站里。上新要重复录入，内容和库存两张皮，支付和后台对账靠人工。
人工负责的部分
定价、选品和对外文案由品牌方决定；我们负责让数据和流程接得上。
我们建了什么
- 品牌站与商家门户：商品、内容、下单与售后一条线
- Odoo 模块对接：订单、订阅、配送、售后
- 商品资料组织与上新流程
涉及的系统
OdooNext.jsStripeSupabase
交付物
- 品牌站 / 门户前端
- Odoo 业务模块与接口
- 多环境部署与发布流程
站点与门户已上线，模块验收按项目逐项确认；Cabinique 目前是研究与原型阶段。
面单、运费与支付PointVault · Yiba运费与面单 / 海外仓约车
报价、买单、结算，接成一条线。
- 运费查询与面单购买打通
- 支付与 ERP 对账
- 按目的仓聚合生成约车报告
原来是怎么干的
查运费、买面单、记账各用一套工具，金额和单号靠复制粘贴。约车计划要从几张表里手工汇总，口径还不统一。
人工负责的部分
承运商选择、费率谈判和付款审批由业务和财务决定。
我们建了什么
- 运费查询与面单购买流程，含支付与凭证
- 与 ERP 的订单、结算对接
- 海外仓计划同步，按目的仓聚合生成约车报告
涉及的系统
OdooCarrier APIsStripeSpreadsheets
交付物
- 运费与面单工作流
- ERP 对接与对账
- 约车报告生成工具
有工程实现与完成记录；生产部署范围按项目确认。
教育与专业服务Xinli留学与升学顾问
顾问的判断留给顾问，重复的材料工作交给系统。
原来是怎么干的
学生材料、沟通记录和申请进度分散在聊天和文档里，顾问把时间花在找材料和重复答疑上。
人工负责的部分
选校、文书和对学生家庭的建议由顾问负责，这一项不进入自动化范围。
我们建了什么
- 顾问 AI 工作流与平台方案（含范围、分期与验收口径）
目前只是方案草案，不作为已交付案例。放在这里是为了说明我们怎么开始一个项目。