关于 EDMA

EDMA Group的生产环境中构建。两年实际运行。随后对外开放。

EDMA Group 是一家实体贸易企业—— 9 个制造国,多个分销市场,每年约 2000 万箱。TradeOS 负责运营管理。在两年自用运行验证了哪些环节真正重要、哪些无关紧要之后,我们才将其作为产品推出。本页讲述的正是这段历程,以及由此形成的系统架构。

阅读故事查看架构

GMV

$80M年度 · 实物贸易 · EDMA Group

运营记录

2 年持续内部实测 · 生产环境同一代码

制造业务

9个国家 · 真实工厂 · 真实批次

体量

~20M箱/年 · 覆盖多个市场

当前租户

1目前仅我们自己 · 直到您加入

我们如何走到今天

大多数贸易软件由从未亲身做过贸易的人开发。我们恰恰相反。

EDMA Group 最初是一家实体贸易企业。随着时间推移,我们扩展至 9 个制造国和多个分销市场——软件栈也随之增长到 14 个工具,靠电子邮件和电子表格勉强维系。NetSuite 负责账簿,SAP 负责供应商端,Salesforce 负责买方端,DocuSign 负责合同,Slack 负责运营,其余一切靠电子邮件。

在这些工具之间传递信息的综合成本,吞噬了我们贸易运营团队约三分之一的人力。员工并非在做贸易——他们在彼此不通的系统之间反复录入数据。

于是我们开发了 TradeOS。最初是为自己所用,后来是为那些我们知道正在承受同样代价的运营商而建。产品中的每一个模块,都是因为当天某笔交易真实需要它而建立的,而不是因为它在路线图上好看。

我们对自己设立的检验标准

您在 edma.trade 上看到的版本,是 EDMA Group 内部运行的同一平台的公开发布版。没有分叉版本,没有单独的「演示」构建,没有独立的 Enterprise 版本。某项功能若周二交付给我们,周三即交付给运营商。若某项功能在真实交易中出现故障,便在真实交易中完成修复。

运营方优先决策 · 验证点

只有操作者才会放进产品里的设计决策。

TradeOS 中的六项设计决策——如果我们不是每天都在平台上处理真实交易,我们不会做出这些决策,甚至可能根本不会注意到这些问题。

01

风险面板有 6 个信号,不是 12 个。

早期设计中我们测试过更多信号。财务审核人员从来不会看完超过六个。六个信号无需滚动即可在屏幕上完整显示,也是承保人能够同时在脑中保留的数量上限。我们删除了其余部分。六个现已成为固定规范。

→ 买方信贷 · 转让状态 · 保险单据 · 文件完整性 · 生产与发货 · 客户索赔

02

披露分两步完成,而非一步。

在某个 列表 上表达兴趣的融资方,在操作者批准该融资方所属机构之前,看不到操作者的名称。操作者与融资方在同一时刻、经双方同意后相互披露身份。大多数 交易市场 产品的默认机制是一步完成(您报价,对方即可看到您)。我们接受了操作层面的代价(匹配速度较慢),换取协议层面的收益(在做出承诺前保护身份信息)。

→ listing.disclosure_state = 'pending' | 'disclosed'

03

交易市场费用由融资方承担,而非操作者。

平台费用向融资方收取。操作者支付平台订阅费以访问 TradeOS,不需要在此之外额外支付 列表 费或撮合费。向操作者收取交易费,恰恰会重新引入我们建设交易市场时致力于消除的摩擦。

→ 融资方侧:每次还款事件收取平台费 · 操作者侧:仅订阅费

04

结算瀑布 自动计算。

无需电子表格。买方按 转让通知书 付款,融资方扣除本金 + 费用 + 平台费,操作者的剩余款项在 T+2 自动划付。我们在第一次于自己平台上对真实应收账款进行保理时编写了瀑布逻辑——因为我们意识到自己即将像所有人一样在 Excel 里手工计算。

→ 7 行确定性逻辑 · 合同派生 · 零对账

05

文档设有可见性标签,而非「已共享 / 未共享」。

提单与客户共享。工厂发票则不共享。供货协议与融资方共享,但不与客户共享。五种可见性状态跨越六类交易对手——文档链上共有 30 种不同的暴露排列组合。现成的协作工具只有两种状态。我们自己构建,是因为别无选择。

→ 运营商 · 供应商 · 客户 · 物流 · 融资方 · 平台

06

客户门户在移动端将「Invoices」重命名为「Payments」。

客户的思维是「我在付款」,而不是「我在处理发票」。我们在自己的客户找不到账单后,将移动端导航路由重新命名。数据相同,标签不同。用词即产品。

→ 相同路由 · 两个标签 · UX wins

团队介绍

团队精简,经验深厚,以交付为导向。

该平台由一支亲身参与实物贸易运营的团队构建。创始人 尼克 设计了这套系统,并每天将其用于 EDMA Group 在九个制造国的真实交易中。工程团队规模精小,与 trade-ops 团队保持紧密协作循环——正是这些人,在正确的货物按时发出时,周一的工作才会变得更轻松。

没有顾问,没有外包工程师,没有白标代码。TradeOS 的每一行代码,都出自曾亲自交易实物产品、或近距离观察身边同事完成交易的人之手。

负向定义 · 有必要明确说明

TradeOS 不是什么。

大多数产品页面告诉您它是什么。更快传达我们正在构建什么的方式,是说明我们主动决定不做什么。

× NOT

以交易市场为核心的产品。

交易市场只是 TradeOS 的一个标签页。平台的价值在于运营记录,而非撮合。即便我们从未促成过任何一笔运营方与资金方之间的交易,订单 / 生产 / 货运 / 文档 / 任务 / 财务 / 仪表板这些模块本身依然构成一套完整的运营系统。

× NOT

伪装成横向平台的垂直 SaaS。

我们起步于实物贸易。数据模型的每个字段都以真实货物在真实交易方之间跨越真实边境为前提。我们无意成为下一个 ServiceTitan、Procore 或 Toast。横向扩张——如果有朝一日发生——方向是网络,而非其他行业。

× NOT

金融科技公司。

交易市场是附带融资层的运营基础设施。我们收取平台费,而非利差。在 v1 版本中,我们不持有资金——资金方直接向供应商付款;客户直接向资金方付款。我们不是银行,不是做市商,也不是资产托管平台。

× NOT

由风险投资主导。

EDMA Group 依靠贸易利润自我造血,而非依赖 条款清单。平台由需要它的实物贸易业务出资建设。外部资本一旦引入,规模将用于扩展运营记录和开发节奏——而不是追逐品牌客户或踏上不计代价的增长曲线。

× NOT

「AI 优先。」

产品中确实包含 AI——Atlas 文档智能 解析文件链,会计 AI 将付款与发票进行核对,智能体工作室让运营人员用自然语言构建智能代理。这一切的存在,是因为我们某天在某笔交易中实际需要它。我们是一套在有用的地方使用 AI 的运营记录系统。我们不是一个寻找工作流的聊天机器人。

当前进展

两个界面已投入生产。本页面不含任何未兑现的承诺。

我们明确说明已交付的内容,也明确说明尚未交付的内容。以下列表涵盖平台中已在 EDMA Group 正式运行、或正在积极构建以供公开 v1 发布的部分。

  1. 01

    TradeOS

    核心运营记录系统。19 个模块,4 个门户。覆盖实物贸易的完整生命周期——订单、生产、货运、文档、任务、财务、仪表板、沟通——服务于运营方及其交易对手方。

    已发布运行于 EDMA Group · 公开 v1 预计 2026 年 6 月
  2. 02

    交易市场

    经过预审的融资方对运营方发布的项目进行竞价。平台服务费由融资方按每次还款事件支付。两步式信息披露机制在双方达成一致前保护各方身份。

    运营方侧已发布融资方门户开发中

在这两个界面之外,我们已就结算通道及资本市场相关领域规划了较长期的架构工作——但在正式交付之前,这些内容不会对外推介。我们的原则是:本页面仅呈现您今天可以实际用于完成交易的功能,或将在 v1 中具备该能力的功能。

下一步该做什么

从这里出发,前往何处。

根据您的身份进行引导。我们在一个工作日内回复。关于上线前的咨询,创始人会亲自阅读每一封邮件。

阅读构建日志每一个已交付的里程碑、每一项架构决策以及每一次失败,均发布于 /newsroom。

关于我们— 由贸易从业者打造,为贸易从业者服务 | TradeOS