场景讲了发生什么，这份讲落在哪个系统、哪个界面、哪个人手上。企业端与银行端各三个界面，附对接清单与开通流程。
企业客户问的第一个问题永远是「我要不要换系统」。答案是不用。
这套东西不要求企业换掉任何现有系统。银行提供的是一个额度与授权的控制层，企业选择从哪里进入这个控制层。三种形态的差别只在于「界面长在谁家」，背后的授权逻辑完全一样。
| 形态 | 界面在哪 | 适合谁 | 企业 IT 要做的事 |
|---|---|---|---|
| A · 托管式 | 银行企业网银里新增一个「Agent 控制台」页签 | 20–200 人的中小企。没有自研系统，也不想接 API。首期主力形态。 | 零开发。开通后由财务经理在网银里配额度，业务同事用银行提供的助手界面。 |
| B · 嵌入式 | 企业自己的 ERP、差旅系统或内部工具里，通过组件嵌入授权与额度视图 | 已有 ERP 或采购系统、希望员工不跳出的中型企业 | 接入前端组件 + 单点登录。开发量约 2–4 周。 |
| C · API 直连 | 没有界面。企业自建 agent 直接调银行授权接口 | 技术能力强、自建 agent 平台的公司（如场景 02 的 SaaS 公司） | 对接授权、额度、取证三组 API。开发量约 6–10 周，需通过安全评估。 |
「你不用换系统，也不用开发。开通之后，你的财务经理在网银里多一个页签，把额度按部门切好，就可以了。」——这是形态 A，覆盖首期绝大多数目标客户。形态 B 和 C 只在客户主动问起时才提。
以下为形态 A（托管式）的界面示意。谁用、看到什么、能做什么。
这是财务经理每周会打开一到两次的页面。它回答三个问题：钱花到哪了、哪个 agent 在动、有没有需要我处理的。
| 云服务助手 本月支出达额度 80%，申请临时提额至 75,000 |
HKD 48,200 | 待审批 | 批准调整 |
| 采购助手 18 分钟内向同一商户 4 笔小额，形态异常，已自动暂停 |
HKD 900 | 已暂停 | 撤销该助手查看 |
| 部门 / 助手 | 本月额度 | 已用 | 使用率 | 状态 |
|---|---|---|---|---|
| 营运部 · 差旅助手 | 60,000 | 31,400 | 正常 | |
| 技术部 · 云服务助手 | 60,000 | 48,200 | 接近上限 | |
| 采购部 · 采购助手 | 40,000 | 12,600 | 已暂停 | |
| 行政部 · 办公用品助手 | 15,000 | 4,300 | 正常 | |
| 市场部 · 未启用 | 25,000 | 0 | 未配置 |
界面上没有出现「令牌」「mandate」「哈希」。财务经理看到的是额度、使用率、状态、和两个按钮。技术复杂度全部藏在右侧那一栏之外。
这是整套产品的差异化核心，也是财务经理在开通时唯一需要认真做一次的配置。做完之后基本不用再动。
| 允许类目 | 机票、火车票、酒店、地面交通 + 添加 |
| 禁止类目 | 转账 预付卡储值 加密资产 系统强制，不可解除 |
| 商户白名单 | 国泰航空、Klook、Trip.com、港铁 · 白名单外首次交易一律需人工确认 |
| 单笔上限 | HKD 5,000 超过则推送确认，不自动拒绝 |
| 授权有效期 | 每次授权 48 小时后自动失效 |
| 提额权限 | 助手不可自行提额 硬边界，任何情况下不可开启 |
注意界面上明确标出的两条「系统强制、不可解除」：禁止高变现类目、助手不可自行提额。这两条是防提示词注入的硬边界，产品上不提供关闭选项——把它显示出来本身就是一种信任信号。
陈太、李小姐这些实际发起采购的人，看到的不是控制台，是一张推送卡片。这是整个产品里被使用次数最多的界面，也是最需要克制的界面。
这一屏是场景 01 的「关键时刻」。设计要点：金额、额度余额、授权边界三件事必须同屏可见，用户按下确认时应当清楚自己授权了什么。那行绿字是用户唯一需要理解的「技术」内容，且用的是日常语言。
这是场景 03 的界面。财务经理点开任意一笔交易就能看到，不需要联络银行。
「导出举证包」是这一页的关键按钮。它输出的是一份标准格式文件，包含授权原文、时间戳、确认方式、风控评分与发票凭证——客户可以直接拿去跟老板解释、跟审计交代、或进入银行的争议流程。
银行内部实际要有人做事。这三个岗位是新增或需要改造的。
| 岗位 | 新增还是改造 | 日常做什么 | 大约需要多少人 |
|---|---|---|---|
| Agent 运营专员 | 新增岗位 | 监控助手状态、处理异常队列、协助客户配置授权矩阵 | 试点阶段 1–2 人，商业化后按客户数扩 |
| 争议处置专席 | 在现有客服 / 争议团队内新设 | 调取意图日志、判定争议、生成举证材料 | 试点阶段兼岗，C 端开放后需专岗 |
| Agent 风控分析员 | 在现有风控团队内新增职责 | 调整意图偏离阈值、分析误报、维护 agent 行为基线 | 1 人，与现有欺诈分析团队共用工具链 |
| 客户经理（RM） | 现有岗位加培训 | 客户开通、授权矩阵初次配置的陪同、续约 | 不新增编制，需 2 天培训 |
运营专员的主界面。它管的不是单笔交易，是助手的状态——哪些在跑、哪些异常、哪些客户的配置有问题。
| 时间 | 客户 / 助手 | 触发维度 | 系统动作 | 状态 | 处理 |
|---|---|---|---|---|---|
| 11:42 | 興發貿易 · 采购助手 | 频次形态 | 已自动冻结令牌 | 待联络客户 | 处理 |
| 10:17 | 南洋物流 · 差旅助手 | 意图偏离 | 已升级为人工确认 | 客户已确认 | 归档 |
| 09:55 | Kite Labs · 云服务助手 | 累计额度 | 达 80% 阈值，已通知 | 客户处理中 | 跟进 |
| 09:03 | 永基工程 · 办公助手 | 新商户 | 白名单外首次，已升级 | 已放行 | 归档 |
运营专员不能解冻令牌或修改客户额度——只能联络客户、记录处理、升级至风控。所有动作留审计轨迹。
权限设计上有一条硬规则：运营专员没有解冻和改额度的权限。解冻只能由客户自己在企业端操作，改额度只能由客户的授权人。这避免了内部操作风险，也让责任边界在争议时保持清晰。
当客户对一笔 agent 扣款提出异议，这是客服打开的界面。目标是把平均处理时间从数天压到十几分钟。
| 授权是否存在 | 是 有签名授权与生物识别确认记录 |
| 交易是否在授权范围内 | 是 类目、金额、商户、时效均相符 |
| 助手是否被篡改 | 无迹象 签名有效，行为符合基线 |
| 建议处理 | 向客户出具授权链路说明，建议其内部核实发起人。责任归属依届时适用的网络规则判定，本工作台不作赔付承诺。 |
裁决区最后一行是刻意写死的：责任归属依届时适用的网络规则判定，本工作台不作赔付承诺。在争议规则未公布前，专席人员的话术必须统一，不能因个案压力而口头承诺。这句话应同时写入客服话术手册与系统界面。
风控分析员的界面。它的核心用途不是抓单笔欺诈，是调阈值——升级验证率太高客户会烦，太低风险敞口会大。
| 维度 | 触发次数 | 其中真阳性 | 占比 | 当前阈值 | 建议 |
|---|---|---|---|---|---|
| 新商户首次 | 184 | 3 | 一律升级 | 建议加白名单学习 | |
| 累计额度阈值 | 62 | 5 | 80% | 维持 | |
| 意图偏离 | 41 | 17 | 35 分 | 表现良好 | |
| 频次形态 | 7 | 6 | 15 分钟 3 笔 | 表现良好 | |
| 单笔超限 | 96 | 1 | 按客户设定 | 属客户配置，非风控 |
阈值调整须经双人复核并留版本记录。任何调整不得使确定性规则（范围、额度、时效）失效——那一层不可调。
这张表暴露了一个真实的运营问题：「新商户首次」维度触发 184 次，真阳性只有 3 次。误报率过高会让客户对每次确认都变得麻木，反而降低了真正异常时的警觉性。这是产品上线后前三个月必然要处理的调参问题，值得在试点阶段就设为观察指标。
形态 A 是零开发。以下清单针对形态 B 和 C。
| 接口组 | 用途 | 形态 B | 形态 C | 备注 |
|---|---|---|---|---|
| 授权接口 | 创建、查询、撤销授权；接收确认回调 | 组件内置 | 必接 | 核心接口，含签名机制 |
| 额度接口 | 查询各层级剩余额度、触发阈值通知 | 组件内置 | 必接 | 只读，写入仍在银行侧 |
| 取证接口 | 按交易反查授权链路、导出举证包 | 组件内置 | 选接 | 不接则从网银下载 |
| 财务过账 | 推送已匹配的交易与发票至企业财务系统 | 选接 | 选接 | 首期支持主流云端财务系统 |
| 单点登录 | 企业员工免二次登录 | 必接 | 不适用 | 标准 SSO 协议 |
具体接口规格待技术方案阶段输出。本表用于 BD 在客户 IT 部门在场时给出量级判断，不作为开发依据。
给企业财务经理和银行运营人员各一条。这是最直观的部分。
一、单人可管理的客户数。决定商业化后的运营成本，直接影响 B2B 的单位经济。
二、授权矩阵配置耗时。如果每家客户都要 90 分钟人工陪同，规模化时会成为瓶颈，需要做配置模板。
三、升级验证的误报率。过高会让客户对确认动作麻木，反而削弱风控效果。