효과적인 TrekMail 지원 티켓 작성 방법

잘 작성된 지원 티켓은 담당 팀이 추측하지 않고 조사하는 데 필요한 세부 정보를 제공합니다. 응답 시간이나 결과를 보장하지는 않지만, 다음 단계가 더 명확해집니다. 이 가이드에서는 일반적인 티켓 유형에 사용할 수 있는 템플릿과 함께 포함해야 할 내용을 설명합니다.

티켓을 제출하는 방법, 즉 클릭할 위치와 입력 필드는 지원 센터 사용 방법을 참조하세요. 이 문서는 티켓의 내용을 다룹니다.

좋은 티켓의 기본 구조

유용한 티켓은 다음 네 가지 질문에 답합니다.

1. 하려던 작업: 잘못된 결과뿐 아니라 목표도 적으세요.
2. 실제로 일어난 일: 확인한 정확한 오류, 상태 또는 동작을 적으세요.
3. 이미 시도한 작업: 기본 점검을 반복하지 않도록 해 줍니다.
4. 식별 정보: 사례를 식별할 도메인, 메일함, 청구서 번호 또는 타임스탬프입니다.

이러한 맥락을 자세히 제공할수록 제품의 올바른 영역을 더 쉽게 확인할 수 있습니다. 비밀번호, 2FA 코드 또는 API 토큰은 절대 포함하지 마세요.

유형별로 포함할 내용

결제 티켓

• Billing 또는 결제 영수증에 표시된 청구서 번호나 결제 참조 번호.
• 둘이 다른 경우 예상 청구액과 실제 청구액.
• 문제가 갱신, 부가 기능 활성화, 환불 요청 등에 관한 것인지 여부.
• 카드 관련 문제를 문의한다면 카드 끝 4자리. 단, 전체 PAN이나 CVV는 절대 보내지 마세요.
• 분쟁의 통화와 금액.

예시:

어제 $52가 청구되었지만 $39를 예상했습니다. Billing 페이지의 청구서 번호를 아래에 포함했습니다. 카드 끝 4자리: 4242. 차액이 다른 항목인지 세금인지 설명해 주세요. 청구액이 표시된 대시보드 스크린샷을 첨부했습니다.

기술 문제 및 발송 티켓

• 발송 메일함 주소.
• 수신자 주소 또는 패턴, 예: "모든 @gmail.com 수신자".
• 정확한 오류 메시지. 550, 421 같은 오류 코드를 포함한 전체 텍스트를 복사하세요.
• 시작 시점: 가능하면 날짜, 시간, 시간대를 포함하세요.
• 같은 메일함에서 다른 주소로 보낼 수 있는지 여부: 문제가 한 수신자나 제공업체에 국한되는지 보여 줍니다.
• 웹메일에서 같은 이메일을 보낼 수 있는지 여부: 메일 앱 설정 문제와 계정 또는 전송 문제를 구분하는 데 도움이 됩니다.

예시:

오늘 아침부터 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."입니다. 웹메일에도 같은 오류가 표시됩니다. 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 전용으로 설정했습니다. 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 토큰 이름. 실제 토큰은 붙여 넣지 마세요.
• 호출하는 엔드포인트.
• 요청 본문. 민감한 데이터는 가리세요.
• 응답. 상태 코드와 본문을 포함하세요.
• 예상 동작과 관찰된 동작.

예시:

가린 emails 배열과 mode: quick을 사용해 POST /api/v1/verify/bulk을 호출합니다. HTTP 422가 반환되며, 이메일 주소를 제거한 응답 본문을 아래에 첨부했습니다. 검증 작업이 생성될 것으로 예상했습니다. 토큰 이름: "production-verify-token". 오늘 13:00 UTC경부터 발생했으며, 같은 요청이 어제는 정상 작동했습니다.

계정 및 로그인 티켓

• 계정 이메일, 즉 로그인 주소.
• 발생하는 일. 로그인 불가, 비밀번호 재설정 메일 미수신, 2FA 미작동 등을 적으세요.
• 브라우저와 운영 체제.
• 소셜 제공업체(Google, Microsoft 및 유사 서비스)로 로그인하는지 여부.
• 대략적인 마지막 로그인 성공 날짜.

2FA 복구 요청에서는 접근 문제를 설명하고 공식 지원 절차에서 요청하는 계정 세부 정보만 제공하세요. 검증된 TrekMail 절차가 명시적으로 요청하지 않는 한 일반 티켓 메시지에 현재 비밀번호, 2FA 코드, 복구 코드 또는 신분증을 절대 보내지 마세요.

포함하면 안 되는 내용

다음 정보는 공유하지 마세요.

• 평문 비밀번호. 어떤 경우에도 안 됩니다. 대시보드 비밀번호, 메일함 비밀번호, 타사 서비스 비밀번호 모두 포함됩니다.
• 전체 신용카드 번호, 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>