客户投诉：去哪里查？¶
客户投诉不是统一从同一个页面开始。先听清楚客户投诉什么，再进入能直接回答该问题的页面。
先选问题，再选入口¶
成交价异常
“为什么成交在这个价格？”
Orders → Decision → 必要时 Ticks订单被拒绝
“为什么订单没有成交？”
Orders → Decision → 必要时 Alarm log订单找不到
“我下单了，但系统里没有。”
Orders → Order → 确认时间与账户 → Logs / 实时订单流报价异常
“价格停了、跳了或点差突然很大。”
Ticks → Dashboard → Alarm log有 Ticket 时优先使用 Ticket。没有 Ticket 时，收集 Account、Symbol、Side、Order Type、客户看到的时间及其时区，再缩小查询范围。
示例：客户投诉成交价异常¶
客户说：“XAUUSD 为什么成交在 2341.80？当时看到的价格不是这样。”
这类投诉的第一入口是 Orders → Decision，不是普通 Order 列表，也不是 Clients。
第一步：打开 Orders 的 Decision¶
进入 Orders，选择顶部的 Decision 标签。用 Ticket 或 Dec ID 查询；没有这些 ID 时，再组合 Account、Symbol 和较窄的日期范围，然后点击 Search。
Decision 页面先回答：系统收到什么价格请求、实际按什么价格成交，以及最终给客户什么价格？
| 必看字段 | 新人应确认什么 |
|---|---|
| Time | Decision 的准确 Server Time；需要查 Ticks 时使用这个时间 |
| Dec ID / Ticket / Order ID / Position ID | 锁定同一张订单与同一次 Decision |
| Account / Client | 是否属于投诉客户与正确账户 |
| Symbol | 产品及后缀是否正确 |
| Side | BUY 还是 SELL |
| Action / Type | Open / Close；Market / Limit / Stop / SL / SO |
| Request price | 订单进入 Decision 时的请求价格 |
| Filled price | Decision 记录的实际成交价格 |
| Client fill price | 客户侧最终成交记录 |
| Rule / Route / Mode | 本次 Decision 使用的规则、路由与模式 |
| Spread / Slippage / Delay / Final | Decision 中记录的价格调整组成 |
| Cost | 页面记录的处理时间 |
| Status | FILLED、PARTIAL、PENDING 或 REJECTED |
示例订单：CLT-18421、账户 9022001、Decision DEC-89234、Ticket 47892013、XAUUSD BUY。Decision 显示 Server Time 15:48:56.527、Request price 2341.50、Filled price 2341.55、Client fill price 2341.80 (+25)、Rule Force STP — T5、Route STP、Final +5 pts、Cost 3ms、Status FILLED。
此时只能确认订单记录。不要仅凭价格不同就写“成交错误”或“滑点异常”。
第二步：需要核对报价背景时再查 Ticks¶
进入 Ticks，选择订单对应的 Taker 与准确的 Taker symbol，把时间范围缩小到订单 Server Time 前后，再点击 Search。
Decision 已经提供成交价调查的核心价格证据。只有需要核对当时的市场报价背景、Source 或报价连续性时，才进入 Ticks。
- 确认 Taker 与 Symbol 后缀和订单一致。
- 找订单 Server Time 前后最接近的 Tick。
- 记录当时 Bid、Ask 与 Spread。
- 记录 Bid 与 Ask 分别来自哪个 Source。
- 查看报价是否连续，是否突然扩大、跳动或改变来源。
方向必须对应：BUY 通常重点对照 Ask，SELL 通常重点对照 Bid；最终判断仍需结合 Order Type、系统规则和获批 SOP。附近 Tick 是证据背景，不自动等于每种订单的准确可成交价。
第三步：有异常迹象时才扩大调查¶
| 发现的迹象 | 下一站 | 目的 |
|---|---|---|
| 同一时间可能有 Quote、Taker、LP 或 Pool 异常 | Logs → Alarm log | 查相同窗口是否存在相关告警 |
| 报价停更、Stream 差异或 Source 状态可疑 | Dashboard | 查当前 Stream 与产品状态；仅作当前背景 |
| Ticket、Account 或客户关系不清楚 | Clients | 确认 UID、账户、Platform 与 Group |
| 其他订单似乎也受影响 | Orders | 用相同 Symbol / 时间窗口确认影响范围 |
| 怀疑报价配置或临时 override | 记录 Sym、Taker sym、Stream 与时间并升级 | 由授权人员查 Controls / Audit；历史生效需日志证明 |
| 怀疑新闻或 Session 影响 | Events / Calendar | 核对时区、窗口、Symbol 与消费者 |
| 需要判断是否为群体模式 | Insights / Markout report | 先记录样本量，再定位具体 Ticket |
| 怀疑有人改过设置 | 保存现象、时间与相关 ID 后升级 | 由授权人员查 Audit events |
查 Alarm log¶
在 Logs → Alarm log 使用相同时间窗口，查看 Rule、Severity、Scope 与 Status。
Firing 表示记录中的条件尚未清除；Recovered 表示系统检测到条件恢复。时间相近不等于告警导致订单结果。
查 Dashboard¶
Dashboard 可以查看当前报价是否新鲜、哪些 Stream 发布该产品，以及某条 Stream 是否与其他 Stream 不同。
Dashboard 是当前快照，不能单独证明较早的成交情况。历史成交价投诉仍以 Orders 与 Ticks 的时间线为主。
需要时才查 Clients¶
Account 与 Client 对应关系不清楚，或需要确认同一 UID 下有哪些账户时，再进入 Clients。
Tag、Score、P&L 和其他账户只是背景，不能证明该订单的成交价是否正确。
新人最终要交出的证据¶
- 客户 ID、准确 Account、Ticket / Position ID
- Server Time 与客户所述时间的时区换算
- Symbol、Side、Action、Type、Volume 与 Status
- Request price、Filled price、Client fill price、Rule、Route、Mode、Final 与 Cost
- 同一 Taker / Symbol 的相关 Tick 时间窗口
- Bid、Ask、Spread 与 Source
- 相关 Alarm；若未发现，写明已查询的时间窗口
- 当前确认范围、未知项和下一步
升级信息示例¶
15:48:56.527 Server Time，客户 CLT-18421、账户 9022001 投诉 XAUUSD Ticket 47892013 成交价异常。Orders → Decision 的 DEC-89234 显示 Request price 2341.50、Filled price 2341.55、Client fill price 2341.80 (+25)、Rule Force STP — T5、Route STP、Final +5 pts、Cost 3ms、Status FILLED。[如需报价背景：已查询相同 Taker / Symbol 的 Ticks，确认……]。目前确认范围为 [范围]；[未知项]仍待复核。