如何撰写有效的 TrekMail 支持工单

内容清楚的支持工单能让团队获得调查所需的信息，无需猜测。它不能保证回复时间或结果，但能让下一步更明确。本指南说明应包含哪些内容，并提供常见工单类别的模板。

有关如何提交工单，包括点击位置和字段，请参阅使用支持中心。本文讲解的是工单内容。

有效工单的核心结构

每个有用的工单都应回答四个问题：

1. 我想完成什么： 说明目标，而不只是哪里出错。
2. 实际发生了什么： 提供看到的确切错误、状态或行为。
3. 我已经尝试了什么： 避免重复进行基础检查。
4. 识别信息： 能确定案例的域名、邮箱、发票号或时间戳。

提供的上下文越多，就越容易检查产品中的正确区域。切勿提供密码、2FA 验证码或 API token。

各类别需要提供的信息

账单工单

• Billing 或付款收据中显示的发票号或付款参考号。
• 如果不同，请提供预期费用与实际费用。
• 问题是关于续订、add-on 激活、退款请求还是其他事项。
• 如果询问某张卡的问题，提供卡号后 4 位，但绝不能提供完整 PAN 或 CVV。
• 争议的币种和金额。

示例：

昨天向我收取了 $52，但我预期是 $39。下面附有 Billing 页面中的发票号。卡号后 4 位：4242。请说明差额是其他项目还是税费。我附上了显示该笔费用的控制面板截图。

技术或发信工单

• 发信邮箱地址。
• 收件人地址或模式，例如“所有 @gmail.com 收件人”。
• 确切错误消息，复制包含 550、421 等错误码的完整文本。
• 开始时间： 尽可能提供日期、时间和时区。
• 同一个邮箱能否向其他地址发信： 可判断问题是否仅限于某个收件人或服务商。
• webmail 能否发送同一封邮件： 可区分邮件应用设置问题与账户或投递问题。

示例：

邮箱 alice@mycompany.com 从今天早上开始无法向任何 gmail.com 地址发信。其他收件人 (yahoo.com、outlook.com) 正常。退信消息是 "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." Webmail 显示同一错误。问题大约从 2026-05-15 09:00 UTC 开始。同一域名下的其他邮箱也无法投递到 gmail.com。

DNS 工单

• 域名。
• TrekMail 显示的域名状态，以及未验证的确切记录。
• 如果有，请提供 DNS 查询结果，例如 MX 记录或 SPF TXT 记录的 dig 输出。
• DNS 服务商，例如 Cloudflare、GoDaddy。
• 无法验证的具体记录。
• 最近是否更改过 DNS，并提供大致时间。

示例：

域名：mycompany.com。Domains 页面上的 DKIM 记录仍为红色。我昨天在 Cloudflare 添加了该记录，并设置为 DNS-only 而非代理。dig +short TXT dkim._domainkey.mycompany.com 返回预期的 v=DKIM1; k=rsa; p=... 值，但 TrekMail 仍标记为缺失。我还使用另一个 DNS 查询服务检查了传播情况。

送达率或垃圾邮件工单

• 发信的域名和邮箱。
• Domain Email Stats 面板中的退信率。
• 发生退信或进入垃圾邮件文件夹的示例收件人，不要提供完整列表。
• 名单来源： 用户主动订阅表单、旧服务商或其他来源。
• 近期发信模式： 最近是否改变了数量或受众。

示例：

域名 mycompany.com 的退信率在过去七天从 0.5% 上升到 8%。我附上了 Email Stats 截图。我的主动订阅新闻邮件名单约有 2,000 名订阅者。退信包括 "user unknown" 和 "mailbox over quota." 两周前我删除了约 200 名不活跃订阅者，这是近期唯一的变化。再次发送前是否应验证剩余名单？

API 工单

• API token 名称，不要粘贴实际 token。
• 调用的 endpoint。
• 请求正文，遮盖所有敏感数据。
• 响应，包括状态码和正文。
• 预期行为与实际行为。

示例：

使用遮盖后的 emails 数组和 mode: quick 调用 POST /api/v1/verify/bulk。收到 HTTP 422，下面附有删除邮箱地址后的响应正文。我原本预期创建一个验证任务。Token 名称："production-verify-token"。问题从今天 13:00 UTC 左右开始，昨天同一请求仍正常。

账户或登录工单

• 账户邮箱，即登录地址。
• 出现的情况，例如无法登录、收不到密码重置邮件、2FA 不工作等。
• 浏览器和操作系统。
• 是否通过 Google、Microsoft 等社交服务商登录。
• 大致的上次成功登录日期。

对于 2FA 恢复请求，请描述访问问题，并且只提供正式支持流程要求的账户信息。除非经过验证的 TrekMail 流程明确要求，否则绝不要在普通工单消息中发送当前密码、2FA 验证码、恢复码或身份证明文件。

不应提供的内容

请勿分享：

• 明文密码。 任何时候都不要提供，包括控制面板密码、邮箱密码和第三方服务密码。
• 完整银行卡号、CVV 或完整银行账户信息。 后 4 位可用于识别。
• 明文 API token，我们可以通过名称识别。
• 附件中的其他客户地址或数据。请匿名化或遮盖。
• 收件人的敏感个人数据，除非调查确实需要。

如果意外分享了秘密，请尽可能撤销或轮换，并立即告知支持团队，以便获得下一步建议。

附件指南

• 截图： 仅限 JPEG、PNG、GIF、WebP 图片，最大 5 MB。显示相关页面和错误，但要裁剪或遮盖包含 token 的 URL、邮箱地址和其他私人信息。
• DNS 查询输出： 以文本形式粘贴，用反引号提高可读性，不要使用截图。
• 错误日志： 仅粘贴相关行，不要提供完整日志。
• 邮件退信文本： 提供完整退信报告，尤其是 Diagnostic-Code: 行。
• 浏览器截图： 避免显示其他标签页、通知、已保存密码或无关客户数据。

工单图片附件计划在工单关闭 30 天后删除。请在本地保留所有重要内容的副本。

每张工单只处理一个问题

如果有两个独立问题，请分别提交两张工单。这样每段对话都能专注于一个问题，也更容易跟踪历史记录。

如果两个问题彼此相关，例如“账单付款失败并且发信停止”，只要关系说明清楚，就可以放在同一张工单中。

更新工单

如果支持团队回复前问题自行解决，例如 DNS 完成传播或第三方服务恢复，请添加简短更新："Resolved: DNS finished propagating. Please close this ticket." 也可以在工单页面自行关闭有效工单。

如果部分变通方法可以使用，但并不是想要的修复，请说明："I worked around it by doing X, but I would still like to understand why the original way did not work."

可复制的模板

一般的故障工单：

Subject: <one-line summary of the issue>

What I was trying to do:
  <your goal>

What happened:
  <exact error or behaviour, including error messages>

Started:
  <timestamp or "always", "since yesterday", etc.>

What I tried:
  - <attempt 1>
  - <attempt 2>

Identifying info:
  - Domain: <domain.com>
  - Mailbox: <user@domain.com>
  - <Invoice number if billing, API token name if API, and similar identifiers>

功能请求：

Subject: Feature request: <one-line description>

What I'd like to do:
  <user story: "as a <type of user>, I'd like to <action> so that <benefit>">

Current workaround:
  <if any>

Why this would help:
  <use case, frequency, scale>

Similar in other tools:
  <if any reference example>

账单争议：

Subject: Billing dispute: <one-line summary>

Invoice number or payment reference: <from Billing or the payment receipt>
Charge amount: $X.XX
Expected amount: $Y.YY
Account email: alice@mycompany.com

What I was expecting:
  <explanation of what your subscription should have charged>

What was actually charged:
  <explanation of the actual invoice / charge>

Resolution requested:
  <refund / credit / explanation / something else>