Как составить эффективный тикет в поддержку TrekMail

Хорошо составленный тикет дает команде достаточно сведений для расследования без догадок. Он не гарантирует срок ответа или результат, но делает следующий шаг понятнее. В этом руководстве перечислены нужные данные и приведены шаблоны для распространенных категорий.

О том, как подать тикет, где нажать и какие поля заполнить, читайте в статье Работа с центром поддержки. Здесь речь идет о содержании.

Основная структура хорошего тикета

Каждый полезный тикет отвечает на четыре вопроса:

1. Что я пытался сделать: ваша цель, а не только описание сбоя.
2. Что произошло: точная ошибка, статус или наблюдаемое поведение.
3. Что я уже попробовал: это помогает не повторять базовую проверку.
4. Идентифицирующие сведения: домен, почтовый ящик, номер счета или временные отметки, относящиеся к случаю.

Чем больше такого контекста вы дадите, тем проще проверить нужную часть продукта. Никогда не указывайте пароль, код 2FA или токен API.

Что указывать для каждой категории

Тикеты по оплате

• Номер счета или платежная ссылка из Billing или платежной квитанции.
• Ожидаемая сумма и фактическая сумма, если они различаются.
• Относится ли вопрос к продлению, активации add-on, запросу возврата и так далее.
• Последние 4 цифры карты для вопроса о конкретной карте, но никогда не полный PAN или CVV.
• Валюта и сумма спора.

Пример:

Вчера с меня списали $52, хотя я ожидал $39. Ниже указан номер счета со страницы Billing. Последние 4 цифры карты: 4242. Объясните, относится ли разница к другому товару или налогу. Я приложил снимок панели управления со списанием.

Технические вопросы и отправка

• Адрес отправляющего почтового ящика.
• Адрес получателя или шаблон, например "все получатели @gmail.com".
• Точное сообщение об ошибке, полный текст с кодами вроде 550, 421.
• Когда началось: по возможности дата, время и часовой пояс.
• Может ли тот же ящик отправлять на другие адреса: это показывает, ограничена ли проблема одним получателем или провайдером.
• Может ли webmail отправить то же письмо: так можно отличить ошибку настройки почтового приложения от проблемы аккаунта или доставки.

Пример:

Mailbox 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 показывает ту же ошибку. Началось около 09:00 UTC 2026-05-15. Другие ящики этого домена также не могут доставить почту на gmail.com.

Тикеты DNS

• Имя домена.
• Статус домена в TrekMail и точная запись, которая не подтверждена.
• Результат DNS-запроса, если он есть, например вывод dig для MX или SPF TXT.
• Ваш DNS-провайдер, например Cloudflare или GoDaddy.
• Конкретная запись, которая не подтверждается.
• Меняли ли вы DNS недавно и примерное время изменения.

Пример:

Домен: mycompany.com. Запись DKIM по-прежнему красная на странице Domains. Вчера я добавил запись в 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, но не сам токен.
• Вызываемый endpoint.
• Тело запроса со скрытыми конфиденциальными данными.
• Ответ, код статуса и тело.
• Ожидаемое поведение и наблюдаемое поведение.

Пример:

При вызове POST /api/v1/verify/bulk с очищенным массивом emails и mode: quick я получаю HTTP 422. Тело ответа приложено ниже, адреса почты удалены. Я ожидал создания задания проверки. Имя токена: "production-verify-token". Проблема появилась сегодня около 13:00 UTC, а вчера тот же запрос работал.

Тикеты аккаунта и входа

• Адрес аккаунта, используемый для входа.
• Что происходит: невозможно войти, не приходит сброс пароля, не работает 2FA и так далее.
• Браузер и ОС.
• Используете ли вы для входа социального провайдера, например Google или Microsoft.
• Примерная дата последнего успешного входа.

Для восстановления 2FA опишите проблему с доступом и предоставляйте только сведения об аккаунте, запрошенные официальным процессом поддержки. Никогда не отправляйте действующий пароль, код 2FA, код восстановления или документ, удостоверяющий личность, в обычном сообщении тикета, если только проверенный процесс TrekMail прямо этого не требует.

Что НЕ следует указывать

Не передавайте:

• Пароли открытым текстом. Никогда. Ни пароль панели, ни пароли почтовых ящиков, ни пароли сторонних сервисов.
• Полные номера банковских карт, CVV или полные реквизиты банковского счета. Для идентификации достаточно последних 4 цифр.
• Токены API открытым текстом, их можно определить по имени.
• Адреса или данные других клиентов во вложениях. Обезличьте или скройте их.
• Конфиденциальные персональные данные получателей, если они не необходимы для расследования.

Если вы случайно передали секрет, по возможности отзовите или замените его и быстро сообщите поддержке, чтобы команда подсказала дальнейшие действия.

Рекомендации по вложениям

• Снимки экрана: только изображения JPEG, PNG, GIF или WebP, максимум 5 MB. Покажите нужную страницу и ошибку, но обрежьте или скройте 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>

Связанные статьи

• Работа с центром поддержки и тикетами
• Частые ошибки отправки и их исправление
• Проблемы с оплатой картой или криптовалютой
• Исправление неудачных платежей
• Слишком высокая доля отказов
• Письма попадают в спам
• Не удается подключить почтовый клиент