进行中货运 · PO 2026-0418
查看货运详情 →200K 医用手套 · CIF Hamburg
集装箱已订舱7 月 02 日 · MSC
运输中第 3 批次装载中 · Klang
已离港— 计划 7 月 09 日
抵达 Hamburg— 预计到港 7 月 21 日
生产 · 已完成 78%来源 · 生产进行中 · 已隐藏
✓原材料
◐生产
QC
包装
发运
网络 · 客户门户
您的客户在您的门户中工作。审批、付款、提出索赔。顶部显示您的品牌标识。
您的客户每年向 15 家供应商下单。大多数供应商发送 PDF 发票，并等待被催问状态。审批通过电子邮件进行，一旦有人忘记回复便陷入停滞。”我的订单在哪里？”每周 50 次涌入您客服团队的收件箱。索赔与争议困在三天的邮件往来中，最终消失在共享文件夹里。客户离开时认为您的企业靠 PDF 运转。
TradeOS 客户门户正是这样一个门户——完全采用您运营商的品牌。9 个真实功能模块：订单、生产、货运、发票、索赔、样品、审批、消息、账户。3 个状态机（索赔 · 样品 · 审批）。Stripe Connect 支付通道。服务层信息屏蔽——供应商与利润率永不越过边界。
门户模块
9 · 订单、货运、财务、索赔及另外 4 项
状态机
索赔、样品、审批
多运营商身份
单次登录，覆盖所有运营商，统一视图
客户成本
$0 · 席位不限
M布雷文医疗 EU客户工作区 · 安娜 Kohl · VP 采购
切换运营商 ▾
首页订单 · 4生产货运发票 · 3文档任务 · 2消息分析设置
周三下午
下午好，安娜。2 件事项需要您今日处理 · 1 份修正案待审批，1 份发票将于周五到期。
1 项待审批 · 已分配给您
订单修正 · PO 2026-0418 · +50K units
操作方建议将第 4 批次数量从 150K 调增至 200K 件。规格不变，发货日期不变。净变动：+$140,000 · 未超出您的 director-tier 上限 $200K。11 分钟前提交。
近期动态
- 14:08样品 SMP-2026-088 · 附条件审批通过
- 11:22索赔 CLM-2026-014 · 已提出解决方案 · 信用额度 $4,200
- 09:45PO 2026-0418 · 生产进度达 78%
- 昨天文档 · 原产地证书 · 可下载
- 昨天付款已确认 · INV-2026-011 · $420,000
真实的首页仪表板— 运营商品牌化界面、9 区段导航、主状态栏、待审批操作提示、含活跃货运与发票中心的双列网格、近期动态信息流。单次后端调用（GET /api/portal/client/dashboard）返回全部数据。仪表板随客户首次会话的推进，在 4 个ClientDashboardMode状态间自适应切换（全新 → 生产中 → 运输中 → 活跃）。
永远清空不了的收件箱
「卓越客户服务」在今天究竟意味着什么。
工作是真实存在的：客户想知道订单在哪里，想要快速审批，想感受到自己在与一家专业企业打交道。而默认工具——PDF + 邮件 + 共享文件夹——每周要耗掉您 CS 团队好几天时间，对续约率的损耗则更大。
01 · 「我的订单在哪里？」活在每周 50 封邮件里
您的 CS 团队沦为邮件状态播报员。
客户想知道 RD-2026-018 是否已发货。他发邮件给 采购，采购 发给运营，运营打开四个界面，把答案手动回复过去。邮件到达时，该批次已经推进了两个阶段。乘以 20 个客户，每周就有两天的 CS 时间消耗在系统早已记录的状态更新上。
客户邮件→手动录入状态
本周已询问 3 次·同一订单
02 · 审批卡在 PDF 链条里
「我需要跟 CFO 确认」意味着四天毫无进展的邮件串。
您发出报价、订单、反提案。客户说需要上报。三天后您跟进，对方已经忘记。又过两天，审批邮件来了——但您在此期间更新的条款并未反映在其中。交易推进的速度取决于最慢的那个收件箱。
报价 PDF→CFO 邮件 · ?
4 天停滞·半数交易
03 · 您看起来像一台 PDF 打印机
有正规门户的竞争对手显得更专业。您没有。
您的客户每年向 15 家供应商采购。那家拥有品牌门户的供应商——订单、货运、索赔、审批全在一个界面——让人感觉是另一个量级的企业。它被续约。您被重新纳入 RFP 候选名单。
PDF 打印机→RFP 候选名单
门户 · 15 家之一·已续约
9 个模块 · 一个门户
客户使用的每个界面，集中于一套导航之中。
来自CLIENT_NAV.flatLinks的实时client/src/lib/navConfig.ts。移动端底部导航使用四项：首页 · 订单 · 付款（/invoices路由已重命名，因为客户的思维是「我在付款」）· 消息。
主页
1710 行自适应仪表板。Hero 状态 + 操作提示 + 2 列网格（含活跃货运 D3 地图及发票中心）。四种ClientDashboardMode状态，分别用于首次会话与持续业务关系的呈现。
订单
PO 接受、变更、行项目、批次、货运关联。608 行列表 + 964 行详情。通过任务引擎进行审批路由。
生产
实时跟踪货物生产过程——生产阶段、工厂进度、批次追踪。货源身份始终匿名化（在服务层脱敏处理）。
货运
D3 + topojson 地图，实时里程碑（已预订 → 装载中 → 已离港 → 已到港），文件附件功能。与主页使用相同的渲染器。
发票
发票列表 + 764 行详情。通过 Stripe Connect 付款（4 种支付通道）。在移动端，底部导航栏中此模块重命名为付款。
文档
基于可见性标签的访问控制。CO、BL、装箱单、CI、COA、保险、植物检疫证书、QC。异步导出（订单/发票/文档/消息/审计）。
待办事项
限定于客户范围的任务。由操作方客户门户操作通过auto-tasks.service.ts自动生成。审批流程同样在此处理（task_category='approval'）。
消息
与操作方的线程化消息沟通。按实体关联（订单、发票、货运、索赔、样品）。5 类通知偏好设置。
分析
关系层级分析。在 Business+ 及以上级别跨操作方聚合（真正的cross_operator_analytics功能）。
索赔与样品 · 商业工作流程
索赔与样品申请不再积压在您的客服收件箱中。
每段 B2B 业务关系都会产生既非订单也非发票的商业事件——质量问题、短装货、样品申请、金样确认。大多数运营软件将这些事件作为系统外的邮件往来处理。TradeOS 将其视为具有强制状态机的一等实体。
索赔 · 迁移 165 · 6 个状态
质量、交货、短装——在门户中记录并结案。
真实的 client_claims 数据表。六种索赔类型，涵盖”货物存在问题”的全部场景——有别于发票争议（涉及发票内容，在 迁移 166 中单独处理）。
short_shipmentdamagewrong_productquality_defectlate_deliveryother
open→under_investigation→resolution_proposed→resolved
分支机构：escalated · cancelled。六种解决方式（replacement_shipment · credit · refund · price_concession · no_action · dispute）。照片及证据存储于 JSONB。三个严重级别（minor / major / critical）。客户发起并接受方案，运营方调查并提出解决方案——在不同服务中采用独立的写入路径。
样品 · 迁移 163 · 8 个状态
产前样、金样、色样、安全样——全部在门户中跟踪。
真实的 sample_requests 数据表。五种样品类型，覆盖从”工厂首批发货”到”双方留存参考标准”的完整验证周期。
pre_production_sampleproduction_samplegold_sampleshade_color_samplesafety_functional_sample
requested→in_production→shipped→delivered→approved
决策分支：approved_with_conditions · rejected · cancelled。双方均可上传照片与标注。金样设有 retain_until 日期（通常为 2 年）。门户承载完整工作流——申请、照片上传、标注、决策、留存——无需退回至邮件处理。
随您的客户规模扩展
中小企业一键操作。中端市场按金额路由。Enterprise 自定义构建器。
同一门户同时服务街角零售买家与财富 500 强的 采购 部门。5 个真实的 client.*_approvals 层级 功能（迁移 161）随运营方 层级 的提升逐步解锁更丰富的路由能力。客户的 采购 流程将被 尊重，而非强制。
TIER · STARTER（中小企业默认）
单一用户。一键操作。
1 位审批人 · 无路由
1
负责人 / 买家
完全授权 · 不限金额
批准
真实功能键
client.single_approver_workflow
示例客户
独立连锁药店 · 4 家门店 · 月支出 $80K
级别 · SOLO+ / TEAM+
按金额路由，顺序审批。
3 位审批人 · 按金额逐级上报
1
团队负责人
采购团队
< $50K
按金额路由
2
总监
总监 · 采购
$50K — $200K
3
VP · 供应链
VP · 供应链
> $200K
真实功能键
client.amount_based_approvals(Solo+) ·client.sequential_multi_step(Business+)
示例客户
区域医疗经销商 · 14 个站点 · 月采购额 $4M
级别 · BUSINESS+ / ENTERPRISE
并行、条件式、授权委托。自定义审批构建器。
可配置 · n-of-m · 委托授权策略 · 审计日志
1
申请人
现场负责人
提交
↓ 顺序审批
2
成本中心负责人
财务审批
任一
↓ 并行审批— 两者均须批准
3
质量 / 合规
受监管 · 医疗
QA
4
安全 / 供应商风险
SAML · 企业版
风险
↓ 顺序审批 · 按金额路由
5
VP · 供应链
职能负责人 · 可授权委托
< $5M
6
CFO 签批
EXEC · 含授权委托
> $5M
真实功能键
client.parallel_approvals · client.delegation_policies · client.category_based_approvals(Business+) ·client.custom_approval_builder(Enterprise)
示例客户
Fortune 500 医院集团 · 200 个站点 · 月支出 $40M
PO 编号PO 2026-0418可见
订单明细200K 医用手套 · 8mil 丁腈可见
装运条款CIF 汉堡 · 预计7月21日可见
生产状态78% · 第 3 批，共 4 批 · 生产中可见
发票总额$560,000 · 商业报价价格可见
供应商名称▪▪▪▪▪▪▪▪▪▪▪▪已屏蔽
制造商所在国▪▪▪▪▪▪▪▪已屏蔽
运营商成本基准▪▪▪▪▪▪已屏蔽
运营商利润率▪▪▪▪▪已屏蔽
产能数据▪▪▪▪▪▪▪▪▪已屏蔽
其他客户▪▪▪▪▪▪▪▪已屏蔽
11个字段中有6个已隐藏→ 在 API 中强制执行 · 文档元数据已清理
数据隔离 · 架构层面
客户看不到的内容，才是生存法则。
一个泄露您供应商信息或利润率的客户门户，是您根本不会上线的门户。状态完全透明；来源完全不透明。每个可见字段均经过刻意开放；其余所有内容在数据行离开数据库之前已不可见。
×
仅限自己的订单与自己的数据
客户在平台上永远看不到您的其他客户。隔离范围在服务层按连接划定；跨运营商统一视图（Starter+）仅聚合该客户在其所连接运营商中的自有数据。
×
永不暴露您的供应商或制造商
「生产中」——不含 工厂 名称、不含国家、不含批次位置。真实的 redactFor() 在 server/src/modules/portal-shell/redaction.ts 中，数据行在离开服务层之前即被重写。
×
永不暴露您的成本、利润率或定价结构
客户只能看到其商业价格，永远无法看到您向工厂支付的价格、您的运费成本基础，也无法看到同一 SKU 下其他客户被收取的价格。
×
服务层的文档脱敏处理
即使文档的元数据中包含供应商引用——PDF 的 XMP 块、Excel 标题、水印——在传输前均会被重写。不存在因意外共享文件而导致泄露的路径。
×
没有可供错误配置的设置开关
不存在任何管理界面可让运营商误操作而暴露成本数据。该边界已编码固化；绕过它的唯一途径是经部署门控的代码审查。
OPERATOR-BRANDED · 客户看到的是您，而非 TradeOS
白标不是一个勾选项，它就是产品本身。
您的客户选择供应商，依据的不是您所用的后台软件，而是供应商的自我呈现方式。客户门户是运营商完成这一呈现的核心界面。每一个可见字节均以您的品牌对外输出。
LAYER 01 · 您的 LOGO，您的色彩
开放层级 · Solo TIER 起您的品牌出现在每一份文档、发票、合同与页面上。
上传 Logo，选定主品牌色，客户接触到的每一个输出物均自动继承—— 门户界面、PDF 发票、已签合同、邮件通知、可下载舱单。TradeOS 字标仅限于门户页脚处的小号展示；在文档上，则完全不出现。
层 02 · 自定义域名
适用层级 · ENTERPRISE TIER 起门户托管于 portal.yourcompany.com，使用您自己的 SSL 证书。
您的客户在浏览器中无需输入「edma」或「tradeos」。这是 Enterprise 层级 的核心client.custom_domain功能，依据迁移 161 实现完整白标部署。门户通过您自己的 DNS 提供服务，证书直接签发至您的域名。地址栏是您品牌的一部分——从登录到付款发票，始终保持干净一致。
运营商邮件发送功能（从您的域名发出 DKIM 签名邮件）已列入路线图——详见下方 §13，如实说明。
一个客户 · 多个运营商 · 统一视图
单次登录，所有运营商，统一读取视图。
在 TradeOS 上与多个运营商关联的客户法律实体，可通过真实的 client.cross_operator_account 功能密钥（Starter+ 级别，迁移 161）以及 /cross-operator/dashboard 中的 portal-client/services/cross-operator.service.ts 端点获得统一读取视图。
一个用户，一次登录，在同一屏幕中查看所有运营商——同时保留每个连接的隔离。每个运营商的数据仅限于各自的连接范围；聚合仅在安全的摘要层面进行（计数、合计，运营商之间无 PII 泄露）。跨运营商分析功能需 Business+ 及以上级别。
这是对许多客户门户 SaaS 产品常见 FAQ 的刻意偏离——「客户身份限定于运营商范围，不提供跨运营商视图。」TradeOS 之所以提供统一视图，是因为客户确实有此需求，而聚合层中的按连接隔离机制是架构层面的安全保障，而非功能的缺失。
布雷文医疗 EU
彭德鲁能源 · EU
AcmeCorp 贸易
所有运营商 · 统一视图
各自隔离 · 运营商之间数据互不可见
支付 · STRIPE CONNECT
四条支付通道。明确区分已接入与已就绪。
真实的 client.direct_payment_rails feature key（Starter+，迁移 161）。四条 Stripe Connect 通道—— 卡 · ACH · 9月A · BACS。读取端支付历史在发布时上线；INITIATE 端随 Stripe webhook 接收器一同发布，目前处于 v1.1 里程碑之后。两个界面均在下方标注，以便您准确了解哪些已接入、哪些已在界面层就绪。
卡
2.9% + 30¢
通过 Stripe 支持 Visa、MC、Amex。即时结算。适合注重速度的中小企业客户；不适用于手续费影响显著的大额发票。
ACH
0.8%
美国行际转账。2 天结算。大额发票的默认方式。每笔转账手续费最低。
9月A
0.5%
欧盟行际转账。在整个 9月A 区域内 2 天结算。欧洲客户向欧洲运营商付款的默认方式。
BACS
0.4%
英国行际转账。3 天结算。英国客户的默认方式。在一次性付款流程中替代直接借记。
状态
READ 界面已上线 · INITIATE 界面随 Stripe webhook 接收器发布（v1.1）
Business+ 及以上层级支持定期与循环付款（client.scheduled_payments）
AI · 贯穿客户端事件
客户侧同样具备 AI 能力——起草回复、路由审批、匹配付款。
客户在门户中的每次交互都是 AI 堆栈可介入的事件。相同的数据隔离规则同样适用——Atlas 仅在该客户自身的数据范围内进行推理，绝不跨越您其他客户的数据。
AATLAS · 起草客户回复
将客户邮件转发给 Atlas，它会结合运营上下文起草回复。
客户询问：「能否提前 3 天？」 Atlas 调取当前生产进度、运输方案、价格影响，并以您的语气起草回复。您点击发送，记录自动更新。
▶ FWD ATLAS · A. Kohl @ Brevin"Can we accelerate PO 0418 by 3d?"▶ ATLAS · draft reply"Yes — air-freight lot 3 for +$14K (currently 78% production, ETA Jul 18 instead of Jul 21). Confirm by EOD Tuesday and we'll book."→ context · production · freight · margin (private)
B机器人工作室 · 处理客户审批
客户批准变更后，机器人自动级联推送更新。
您只需配置一次机器人。它持续监听客户审批事件：自动更新供应商生产计划，起草货代通知，重新计算发票计划，仅在变更超出阈值时才上报人工处理。
▶ BOT client-approval-cascade · v2.4→event ·approve · +50K units→supplier plan ·lot 4 updated→forwarder ·capacity check requested→invoice schedule ·+$140K · INV-019→human ·none required
$会计 AI · 处理客户付款
Stripe Connect 付款自动与发票完成对账。
客户通过 ACH 支付 $560K。会计 AI 将支付渠道与发票匹配，过账至您的账本，标记任何短付情况，并依据已知的扣款政策进行核查，仅将需要人工审核的情形推送至前台。
▶ ACCOUNTING AI rail match · v1.8→ ACH · $560,000 · ref MERIDIAN-018→matched ·INV-2026-018 · 100%→ledger ·posted · AR cleared→next ·INV-019 holdback 2.3% · review
对比
客户已经在使用的五类工具，没有一个是为运营商而建的。
电子邮件加 PDF 是现有主流方案——凭借熟悉度取胜，其他方面全面落败。Customer Communities 与 Ariba 在企业级 采购 上占优，却在运营商品牌塑造和利润保护上失分。内部自建门户赢在灵活性，六个月后便得不偿失。
| 功能 | TradeOS 客户门户 | 邮件 + PDF | Salesforce Customer Communities | Ariba Buyer（强加于您） | 内部自建门户 |
|---|---|---|---|---|---|
| 运营商品牌门户（您的域名、您的配色） | ✓ portal.yours.com · 企业版 | ✓ 您的签名 | 您的配色，Salesforce URL | — SAP 品牌 | ✓ |
| 实时状态可见性 · 同一条记录 | ✓ 单次后端调用 | — 手动 | 通过集成实现 | 异步同步 | 自助式 |
| 内联审批 · 一键直达自定义构建器 | ✓ 5 个层级管控级别 | — PDF + 邮件 | ✓ 工作流构建器 | ✓ 仅 Enterprise | 自助式 |
| Stripe Connect 支付通道（银行卡 · ACH · 9月A · BACS） | ✓ 全部 4 种 · 费用透明 | — 仅支持电汇 | 通过第三方 | ACH · 电汇 | — 极少支持 |
| 跨运营商统一视图（单次登录，管理全部运营商） | ✓ Starter+ 功能 | — 不适用 | — 各组织独立隔离 | — 各组织独立隔离 | — 自行搭建 |
| 跨租户数据隔离由架构强制保障 | ✓ API 中的 redactFor() | — 存在意外数据泄露风险 | 组织级别 | 租户级别 | — 自行搭建 |
| 索赔与样品工作流（状态机） | ✓ 6 + 8 个状态 · 实时 | — 临时邮件处理 | cases 模块 | — 带外处理 | — 自行搭建 |
| Enterprise 层级 SAML SSO | ✓ client.saml_sso | — | ✓ SF Identity | ✓ | 自助式 |
| 客户免费席位（运营商支付 TradeOS 费用） | ✓ 对应层级内不限数量 | ✓ 邮件免费 | — 按社区用户计费 | — 按席位计费 | ✓ 内部自建 |
| 原生 AI 集成（Atlas · Bots · 会计） | ✓ 按客户独立配置 | — 需自行集成 | Einstein 附加组件 | Joule 附加组件 | — |
电子邮件才是真正的在位者——它凭借熟悉感赢得信任，这有其道理。客户对 PDF 驾轻就熟。客户门户不是要以更炫的方式取代电子邮件，而是要以比电子邮件更简单的方式取代它——在那些电子邮件力不从心的场景：状态可见性、审批路由、付款、索赔、样品、将文档附加到正确的 PO，以及避免让操作方看起来像一个靠 Excel 运转的供应商。
权限分级 · 19 个功能项
对客户免费。操作员的 层级 决定显示哪些功能。
真实的 tier_features 注册表（迁移 161）定义了 19 个客户端门户功能门控。客户端始终不会看到付费墙；所连接操作员的 层级 决定该操作员在您的工作区中可用的内容。路线图 标记表示 tier_feature key 已注册、但 UI/引擎实现在上线后完成的功能。
功能
入门版
单人版
商业版
企业版
基础门户（订单 · 货运 · 发票 · 文档 · 消息）
✓
✓
✓
✓
Stripe Connect 直接支付通道（银行卡 · ACH · 9月A · BACS）
✓
✓
✓
✓
样品申请流程（5 种类型 · 8 种状态 · 照片 + 批注）
✓
✓
✓
✓
索赔流程（6 种类型 · 6 种状态 · 证据 + 处理结果）
✓
✓
✓
✓
单一审批人流程（中小企业默认设置）
✓
✓
✓
✓
跨运营商客户账户（单一登录，多个运营商）
✓
✓
✓
✓
基于金额的审批路由
—
✓
✓
✓
顺序式多级审批链
—
—
✓
✓
跨运营商聚合分析
—
—
✓
✓
客户自主下单（self-service）
—
—
✓
✓
计划性及周期性付款执行
—
—
✓
✓
并行与条件审批流程
—
—
—
✓
审批委托策略（按时间/范围/金额限定）
—
—
—
✓
基于类别的审批路由
—
—
—
✓
已保存订单模板 路线图 UI
—
—
—
✓
客户用户 SAML SSO
—
—
—
✓
自定义可视化审批流程构建器
—
—
—
✓
自定义域名 / 完整 white-label
—
—
—
✓
订单/货运/发票流程 EDI 集成
—
—
—
✓
产品路线图
客户门户即将推出的功能。
v1 包含九个模块、三个状态机、四条 Stripe Connect 支付通道（READ 端已上线）、多租户身份体系及跨运营商统一视图、服务层数据脱敏、PWA 安装、引导覆层 + 分级感知清单、自动任务、数据导出，以及覆盖十九个功能键的分级管控。以下功能已如实标注——其 tier_feature 键已存在，但 UI、引擎及接入将在上线后完成。
01
Stripe webhook 接收器 · 支付 INITIATE
READ 界面（支付历史）已上线。INITIATE 端——POST /invoices/:id/pay——处于 stub 状态，待写入支付记录的 Stripe webhook 接收器就绪后生效。根据 payments.service.ts：「与 createSetupIntent 完全相同的 stub 方式，抛出 ValidationError 并附有已记录的后续步骤。」
02
运营商邮件发送（从您的域名发出 DKIM 签名邮件）
订单确认、审批请求、货运提醒、发票通知——均从 [email protected] 发出，而非经由 TradeOS 基础设施。SPF、DKIM、D3月C 在您的 DNS 上配置。尚未实现；构建完成后作为 Enterprise 级功能提供。
03
OIDC + SCIM 自动配置
SAML SSO 已在 Enterprise 级上线（client.saml_sso）。OIDC 和 SCIM 自动配置随后推出——同样限于 Enterprise 级。当客户的 HR 系统注销用户时，SCIM 将自动撤销配置，确保门户访问权限与客户数据源保持一致。
04
已保存订单模板 UI
真实功能键 client.order_templates，适用于 Business+（迁移 161，标注为「UI 上线后完成」）。Schema 已就绪；已保存模板选择器及一键复购流程将在上线后推出。
05
自定义审批工作流构建器 UI
client.custom_approval_builder，适用于 Enterprise 级。运行时引擎已就位（并行、串行、n-of-m、委托、类别路由均可运行）；面向非技术运营商的可视化构建器 UI 将在上线后推出。Enterprise 级运营商在此期间可向我们申请手工搭建的工作流。
06
EDI 集成
client.edi_integration，适用于 Enterprise 级（迁移 161）。对于使用 EDI 的企业客户，订单/货运/发票流程直接通过 X12 / EDIFACT 传输，而非经由门户 UI。Schema 已预留；集成适配器将在 Enterprise 合同签署后按客户逐一交付。
07
Wire + Letter of Credit 通道
四条 Stripe Connect 通道（卡 / ACH / 9月A / BACS）已覆盖数字通道全集。Wire 和 LC 属于带外通道，运营商目前仍可在发票上手动记录。针对电汇确认和 LC 提示跟踪的原生门户流程，将随使用场景的集中而陆续推出。
08
原生 iOS / Android 客户端应用
PWA 是 v1 客户端移动界面（manifest + service worker + InstallNudge——已上线）。具备生物特征认证、原生相机 API 和推送通知的原生应用将在上线后推出。
常见问题
每位运营商第一次看到此门户时都会提出的问题。
针对分销商、进口商和贸易公司负责人在演示通话中向我们提出的问题，给出诚实的解答。
是的——但它会以您的系统形象呈现。客户看到的是您的 logo、您的品牌色，在 Enterprise 层级还可使用自定义域名（portal.yourcompany.com，配备您自己的 SSL 证书）。大多数客户更愿意使用门户，而非追踪邮件中的 PDF；已完成切换的运营商反映，采购团队会主动要求使用门户，而不是相反。
将门户交给您最挑剔的客户，看他们是否比邮件更倾向于使用它。
预约 30 分钟演示。我们将为您搭建一个沙箱客户门户，使用您的 logo、品牌色、自定义域名（部署在 staging 子域名上），配备一个虚拟订单和一位虚拟采购副总裁。您在真实桌面和真实手机上完整体验一遍。如果客户不会比 PDF 链更喜欢它，我们不会要求您购买。