洞察
每一套系统，具体做什么
一条原则：先自用，再输出
下面这些系统有一个共同点：它们都是我们自己天天在用的那一套。
飞驼不是先做产品再找客户，而是先在自己的仓、自己的销售团队、自己的财务和自己的投放后台里被真实业务磨过，磨到自己愿意用，才谈对外。
这条原则听起来朴素，实际影响非常大。一套没有被真实单量磨过的系统，演示时有多好看，上线后就有多难用——因为它没有见过现场的一百种例外，而现场只由例外构成。
系统按四个域组织：履约、客户、经营、决策。前三个域解决「记录与执行」，第四个域解决「判断」。
履约域：把货按时按质送出去
支撑日均十万量级订单的主战场，也是所有系统里被磨得最狠的一组。
云仓 WMS
多仓统一管理，按仓切片的作业模型。 所有仓跑同一套系统，库存、作业、人效同一口径。
核心能力包括：库位与库区管理、入库上架、波次生成与拣选策略、库存盘点、人效统计。出库模式按当日的单据结构自动匹配——单品爆款单走批量流水，多品订单走摘果播种，策略提升的是人均每小时出库单量。
仓内对接 Geek+ 货到人 AGV 拣选，机器人把货架搬到拣货员面前，产能不随招工难易波动。
出库前的称重复核是整条链路上性价比最高的一道闸门：实际重量与理论重量比对，错发漏发在包裹离开仓库之前被拦下来。
OMS 订单中台
订单从各个平台进来的样子千差万别。OMS 的职责是把这些消化掉，让下游只看到规整的作业单：
多平台订单归集（店铺授权即接，ERP 走接口对接）、拆单与合单（跨仓跨温层要拆，同一收件人的多笔可合）、异常前置拦截（地址异常、缺货、超区在进仓前处理完）。
进仓前多拦一单，仓里就少一次返工。
TMS 运输管理
承运商路由是一张多维规则表：条件维度包括平台、店铺、商品标记、原始指定物流、订单金额区间、收货省市、重量区间和优先级；输出的是首选承运商加一串备选，首选不可用时自动降级。规则带生效起止日期，改规则不影响历史单据的可解释性。
时效跟踪每个包裹落一条完整路由记录，配合「发货省市到收货省市」的时长基准表，滞留、虚假签收、退回在路由层被识别出来，而不是等买家投诉。
计费核对这件事比看上去难：一个订单可能拆成多个包裹，每个包裹有自己的运单号和计费重量，账单按包裹算，业务侧按订单看。系统逐票比对「我们称的重、承运商计的重、承运商收的钱」——全量，不是抽查。这是仓配服务里最容易漏钱的地方。
关于与承运商约定的月度量级承诺：目前系统里已有的是冲量机制，为达成承诺主动改派订单时，记录「本应给谁、实际给了谁」并逐单核算这次改派的代价。而「月中就预测出承诺达不达得成」的风险预警，我们还在研究，尚未上线。
云端面单打印
十多个电商平台的打单组件，过去散在各台终端上：换机器要重装、组件升级要挨个更新、打印能力绑死在某个工位。
我们把这些组件集中到云端统一调度，终端按运单号取件出单。打印能力不再绑死在某一台电脑上，出单速度也不受终端环境影响。
报表系统
从仓内作业到履约时效的全链路报表。
关键不在「有报表」，在于口径统一维护：货主、仓库、管理层看到的是同一套数字。系统里对「签收」「出库」「异常」这些词只有一个定义。
智能工单：问题处理的协作中枢
这一套单独讲，因为它是履约体系里最容易被低估、但对客户体验影响最大的一块。
它要解决什么
仓配这门生意里最消耗信任的不是问题本身，是问题的处理过程：货主在群里发一句「这单怎么回事」，客服转给仓库，仓库查完回给客服，客服再转给货主。中间隔了三次转述、两个小时。三天后同类问题再来一次，没有人记得上次是怎么处理的。
问题被解决了，但经验没有沉淀，责任没有归属，时长没有记录。
分类体系决定一切
我们把履约链路上真实会发生的问题做成了两级分类，覆盖电商订单与 B 端出库单两条线：发起物流拦截、顾客拒收退件、物流停滞或退回、物流虚假签收、货品破损少件、货品错漏发件。
分类不是为了好看。工单类型直接决定后面的一切：能填什么内容、走哪条处理路径、可以有哪些处理结果、最后由谁承担赔付责任。
挂在单据上，不是挂在文字里
每张工单必须关联具体业务单据：订单号、运单号、入库单、B 端出库单、退货单。
挂了单据，工单才能自动带出这一单的全部上下文——发了什么、什么时候出库、走的哪家承运商、物流到哪了、称重记录是多少。处理人不用去别的系统里翻，货主也不用把订单号贴三遍。
每种工单类型还配有内容模板，把「请提供一下运单号」「麻烦拍张照片」这类第一轮往返，前置到提单那一刻。
完结的权力在提单方手上
状态流转是：待处理 → 受理中 → 已处理 → 已完结。
关键在最后一步：判断问题有没有被解决的权力在提单方手上，不在客服手上。 不满意可以打回「需继续处理」，工单重新排队；一直不表态的超时后自动完结，避免单子无限期挂着。
工单在受理前可以删除，受理后只能作废——因为从受理那一刻起就有人的时间投在上面了，这个记录不该消失。
每一次转手都留一条记录
工单可以在部门之间流转，流转后可指定处理人或由部门内的人认领。每一次处理和每一次流转都生成一条独立记录：谁处理的、哪个部门、什么时候开始、什么时候完成、做了什么。
系统还分别标记「有新的提问」和「有新的答复」，双方都不会漏掉对方的最新一条消息。
结论与赔付责任不靠拍脑袋
处理完要从一个受工单类型约束的结果列表里选结论——顾客已签收、已退回仓库、退回仓库有损、未退回仓库记丢件、退回仓库后丢失、补发、赔付客户、仓库无责——而不是自由发挥。
然后是最容易扯皮的一步：赔付责任由「工单类型 + 处理结果」自动推导，无须赔付、快递赔付还是仓库赔付，规则事先配置好，双方都认。工单上记录涉及金额，月底有账可查。
物流拦截类的工单还会生成对应的拦截指令进入承运商的拦截通道，并回写拦截成功还是失败——这件事有人在做、有记录、有结果，而不是一句「我帮您问问」。
需要说明的是，承运商不会登录我们的系统，但承运商相关的动作和结论都收敛在这张工单上：拦截指令从这里发起并回写结果，赔付责任的判定直接指向承运商，涉及金额有记录。仓库、货主、承运商三方的事最终落在同一张单据上——这才是「不用三方转述」的真正含义。
客户域：把客户侧的信息收进同一套结构
呼叫中心与 CRM
自建呼叫中心，浏览器即软电话。 坐席打开网页就能外呼和接听，不用装客户端也不用配话机；通话记录与录音自动沉淀到客户档案。
CRM 覆盖线索接收、分配、跟进、转化的完整闭环：
线索自动分配引擎采用「预模拟 + 人工可改 + 超时自动落实」的设计。引擎给出建议分配，主管和坐席可以在时限内修改或否决，超时无人干预才自动落实；总开关一关就完全回到人工认领。分配因子包括公平轮转、在线在岗状态、新人减量。这个设计是管理层敢开自动分配的前提——自动化不是一次惊险的切换，人始终能接管。
归属与业绩口径做成硬约束：成交归属在转化那一刻定死、改派不变；认人一律用工号不用姓名（重名和脏数据会让按姓名统计彻底失真）；建档不等于转化，真转化以签约为准。提成奖金只认「完成结款」的账单，只算真收到的钱。发钱这件事有可核查的口径，事后能回查当初算得对不对。
获客质量多维分析：按平台、渠道、账户、留咨方式、付费与自然流量、到具体的人，统计有效性、精准性和转化率。花钱的效果能拆到人和渠道，而不是只有一个总数。
配套的还有多标签工作台（多条线索并行处理不丢上下文）、员工数据中枢（人事数据单向进入，各模块订阅同一份员工事实，离职当天自动停号踢会话）、以及语音通知外呼（关键系统异常可以直接打到人的手机上，不会淹没在消息里）。
多平台消息接入
把多个渠道的客户消息接进统一的处理结构：一套业务代码对接多渠道，换渠道只换适配层，业务逻辑和坐席工作台零改动。
对客户的意义是：从哪个渠道来的不重要，接待流程、归属规则和数据沉淀是同一套；新增一个渠道不需要重做一遍客服系统。
广告投放管理
自建的多平台投放后台：建计划、建广告、调预算调出价、启停、管素材、盯盘，全部在自己的后台完成。
素材中心统一管理图文、视频、图片，组织内共享可见，改素材是「勾掉不要的、挑上想要的、看改前改后对比、确认」，改完系统自己读回核对一遍。
下单台支持在盯盘数据行上直接调预算、调出价、启停。
最值得说的是写操作安全闸。投放接口没有沙盒，调用即真花钱，所以这套系统的默认状态是「不发出去」：默认试运行、账户白名单、单次金额上限加单日累计上限加上调倍数限制、全量留痕、意图台账防止重试导致重复扣钱、新建广告一律落成暂停态需要人工开启。
还有一条被写进产品原则的要求：「确认的是什么，发出去的就是什么」。核对页显示 300 而实际发出 3000，我们当作严重缺陷处理。
效果归因链路把「花了多少钱 → 来了多少线索 → 成了几单」打通，单线索成本和单签约成本直接算得出来。
经营域：让经营结果和现场动作对得上账
应收应付与开票
应收、应付、预付账款管理加开票、采购报销一体化。它有两条不可协商的机制：
第一，财务单据永不删除。 只能冲销、调整、作废，所有写操作强制留痕（谁、何时、改了什么、改前改后值），审计不可关闭。任何一笔钱的来龙去脉都能回放。
第二，业务型账款不允许人工创建。 一律走统一的入账管道：上游业务系统增量拉取、其他系统推送、周期性合同自动生成、发票驱动建账、报销借款。每条账款强制带「来源系统、来源单号、来源版本」的幂等标识；上游重推同一单时，未核销的自动冲销重建，已部分核销的生成调整单。这一条杜绝了「人工补一条账」造成的对不上，也杜绝了重复推送产生重复账。
其他设计：金额一律用定点数、全系统禁用浮点；集团多主体是一等公民，银行账户、合同、收付款强制归属唯一法人主体，付款时只能选该主体名下的账户（多子公司集团最常见的错付串户，在机制上被堵死）；回款与账款多对多核销，未核销的付款余额即预付、回款余额即预收；会计期间关账，特批解锁走审批。
使用者是全公司，不只是财务：业务员看自己客户的账款与逾期，行政录费用，出纳执行付款，财务看全局，管理层看报表。
数据字典
把「这个字段到底是什么意思」从口口相传变成会自己更新的活文档。
仓储侧的数据字典分三层：官方设计说明书的快照、数据库的实况结构、以及人工沉淀的业务口径笔记。官方文档一有变更就自动触发同步，产出可比对的变更报告并提醒负责人——官方文档滞后于线上结构的部分一眼可见。
客户侧的数据字典由代码里的结构注释自动生成，每一列都写清楚：含义、谁写的、取值枚举，以及「坑」——这一列在什么情况下会骗你。
口径有出处，新人和 AI 都不用靠猜。这是所有结构化工作的地基：字段的含义没有唯一定义，上面盖什么都是危房。
招聘工作台
AI 辅助的简历初筛与业务方轻量评审，与现有招聘系统并存——招聘系统仍然是记录系统和外部集成方，工作台接管高频的内部工作。
它有几条硬规则值得一提，因为它们体现了我们对「AI 进入业务流程」的一贯态度：
- AI 推荐，人决策。 评分永远不直接触发候选人状态变更，必须有人确认。
- 评审必须写理由，在接口层和数据库层双重强制。走过场式的批量通过会在数据里显形。
- 意见与决策分表。 「评价」谁都可以有多条，不移动候选人；「评审」是决策，移动候选人并回写招聘系统。
- 评分表单版本化，分数只在同版本内可比；后来改权重不会悄悄改写已经下过的判断。
- 失败的回写必须可见。 一条没写回招聘系统的决策就是一个静默丢失的决定，系统专门有入口列出它们。
决策域：Flyto Agent 决策引擎
上面三个域解决「记录与执行」，这个域解决「判断」。
Flyto Agent 是飞驼自研的决策引擎，核心是场景中立的：它不知道什么是仓库，也不知道什么是报价单，业务知识全部住在「场景描述」里。换一个场景，换的是描述，不是重写一套系统。
它的全部工程设计围绕同一个问题展开——错了怎么办：
- AI 负责决策，业务系统的接口负责执行，AI 不直接写业务数据库。
- 三层防御：指令层约束方向，参数层限制能力边界，兜底层接住前两层漏掉的一切。
- 决策暂存与双层校验：每个决策先落成一条可审计的记录，通过技术层与业务层校验才进入执行。
- 决策留痕与反向论证：留得下依据，代价高的动作要先被反驳一遍。
- 影子运行、灰度、熔断回退：上线不是一次赌博，出问题能自动退回去。
首个落地场景是物流报价对账，跑在飞驼自己的物流业务上，用的是真实的账单和真实的钱。
这个域值得单独一整页来讲。
关于对外输出
这些系统先服务飞驼自己的业务，也对外输出。
我们不承诺「什么都能做」。能对外讲的，都是我们自己每天在用的；正在建的、只画在设计文档里的，我们不会说成已经有的。
无论你要的是完整的仓配履约服务，还是其中某一个单独的能力，都可以聊。能演示的，我们直接演示给你看。