كيفية كتابة تذكرة دعم TrekMail فعالة

توفر التذكرة المكتوبة جيدا للفريق التفاصيل اللازمة للتحقيق دون تخمين. لا تضمن وقت استجابة أو نتيجة، لكنها توضح الخطوة التالية. يوضح هذا الدليل ما يجب تضمينه ويقدم قوالب للفئات الشائعة.

لمعرفة كيفية تقديم تذكرة، مثل موضع النقر والحقول، راجع استخدام مركز الدعم. تتناول هذه المقالة المحتوى.

البنية الأساسية لتذكرة جيدة

تجيب كل تذكرة مفيدة عن أربعة أسئلة:

1. ما كنت أحاول فعله: هدفك، وليس فقط ما حدث.
2. ما حدث فعليا: الخطأ أو الحالة أو السلوك الدقيق.
3. ما جربته: يمنع تكرار فحص أساسي.
4. معلومات التعريف: النطاق أو صندوق البريد أو رقم الفاتورة أو الطوابع الزمنية.

كلما زاد السياق، سهل فحص الجزء الصحيح. لا تضمن أبدا كلمة مرور أو رمز 2FA أو token لـ API.

ما يجب تضمينه حسب الفئة

تذاكر الفوترة

• رقم الفاتورة أو مرجع الدفع الظاهر في Billing أو إيصال الدفع.
• الرسم المتوقع مقابل الرسم الفعلي إذا اختلفا.
• هل تخص تجديدا أو تفعيل إضافة أو طلب استرداد أو غيره.
• آخر 4 أرقام من البطاقة لمشكلة تخص البطاقة، وليس PAN الكامل أو CVV.
• العملة والمبلغ في النزاع.

مثال:

خصم مني $52 أمس، لكنني توقعت $39. رقم الفاتورة من صفحة Billing مدرج أدناه. آخر 4 أرقام: 4242. يرجى توضيح هل الفرق بند آخر أو ضريبة. أرفقت لقطة من dashboard تظهر الرسم.

تذاكر التقنية أو الإرسال

• عنوان صندوق الإرسال.
• عنوان المستلم أو النمط، مثل "كل مستلمي @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 الخطأ نفسه. بدأ حوالي ~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 بلا proxy. يعيد dig +short TXT dkim._domainkey.mycompany.com القيمة المتوقعة v=DKIM1; k=rsa; p=.... ما زال TrekMail يعتبره مفقودا. وتحققت من الانتشار بخدمة DNS أخرى.

تذاكر التسليم أو spam

• النطاق وصندوق البريد المرسل.
• معدل الارتداد من لوحة Domain Email Stats.
• عينة مستلمين ترتد رسائلهم أو تذهب إلى spam، دون القائمة كلها.
• مصدر قائمتك: نموذج opt-in أو مزود قديم أو غيره.
• نمط الإرسال الحديث: هل تغير الحجم أو الجمهور.

مثال:

ارتفع معدل ارتداد mycompany.com من 0.5% إلى 8% خلال آخر سبعة أيام. أرفقت لقطة Email Stats. أرسل إلى قائمة opt-in من نحو 2,000 مشترك. تشمل الارتدادات "user unknown" و"mailbox over quota". حذفت نحو 200 غير نشطين قبل أسبوعين، وهو التغيير الوحيد. هل أتحقق من بقية القائمة قبل الإرسال؟

تذاكر API

• اسم token لـ API دون لصق token نفسه.
• endpoint الذي تستدعيه.
• محتوى الطلب بعد حجب البيانات الحساسة.
• الاستجابة مع رمز الحالة والمحتوى.
• السلوك المتوقع مقابل السلوك الملحوظ.

مثال:

أستدعي POST /api/v1/verify/bulk بمصفوفة emails محجوبة وmode: quick. أتلقى HTTP 422، ومحتوى الاستجابة مرفق بعد حذف العناوين. توقعت إنشاء مهمة تحقق. اسم token: "production-verify-token". بدأ حوالي 13:00 UTC اليوم، ونجح الطلب نفسه أمس.

تذاكر الحساب أو تسجيل الدخول

• بريد الحساب المستخدم للدخول.
• ما يحدث مثل تعذر الدخول أو عدم وصول إعادة كلمة المرور أو تعطل 2FA.
• المتصفح ونظام التشغيل.
• هل تدخل بواسطة مزود اجتماعي مثل Google أو Microsoft.
• التاريخ التقريبي لآخر دخول ناجح.

لاسترداد 2FA، صف مشكلة الوصول وقدم فقط تفاصيل الحساب المطلوبة عبر مسار الدعم الرسمي. لا ترسل كلمة مرور حالية أو رمز 2FA أو رمز استرداد أو وثيقة هوية في تذكرة عادية، إلا إذا طلبتها صراحة عملية TrekMail متحققة.

ما يجب عدم تضمينه

لا تشارك:

• كلمات المرور بنص صريح. أبدا، سواء لوحة التحكم أو صناديق البريد أو خدمات أخرى.
• أرقام بطاقات الائتمان الكاملة أو CVV أو البيانات البنكية الكاملة. تكفي آخر 4 أرقام للتعريف.
• tokens لـ API بنص صريح، فيمكن تعريفها بالاسم.
• عناوين أو بيانات عملاء آخرين في المرفقات. أخف الهوية أو احجبها.
• البيانات الشخصية الحساسة للمستلمين ما لم تكن ضرورية للتحقيق.

إذا شاركت سرا بالخطأ، فألغه أو دوره عند الإمكان، ثم أخبر الدعم فورا.

إرشادات المرفقات

• لقطات الشاشة: صور JPEG أو PNG أو GIF أو WebP فقط، بحد أقصى 5 MB. أظهر الصفحة والخطأ، واقصص أو احجب URLs التي تحوي token أو عنوان صندوق أو معلومات خاصة.
• ناتج استعلام DNS: الصقه كنص منسق بـ backticks، لا كصورة.
• سجلات الأخطاء: الصق السطور ذات الصلة لا السجل كله.
• نص ارتداد البريد: ضمن التقرير كاملا، وخصوصا سطر Diagnostic-Code:.
• لقطات المتصفح: تجنب إظهار تبويبات أخرى أو إشعارات أو كلمات مرور محفوظة أو بيانات عملاء غير ذات صلة.

من المقرر إزالة مرفقات صور التذاكر بعد 30 يوما من إغلاق التذكرة. احتفظ بنسخة محلية من كل شيء مهم.

مشكلة واحدة لكل تذكرة

إذا كانت لديك مشكلتان منفصلتان، فقدم تذكرتين منفصلتين. يبقي ذلك كل محادثة مركزة ويسهل تتبع السجل.

إذا كانت المشكلتان مرتبطتين، مثل "فشلت الفوترة وتوقف الإرسال"، يمكن وضعهما في تذكرة واحدة ما دامت الصلة واضحة.

تحديث التذكرة

إذا حلت المشكلة نفسها قبل رد الدعم، كاكتمال انتشار DNS أو عودة خدمة خارجية، فأضف تحديثا قصيرا مثل: "تم الحل: اكتمل انتشار DNS. يرجى إغلاق التذكرة." ويمكنك إغلاق التذكرة النشطة بنفسك من صفحتها.

إذا كان الحل المؤقت الجزئي مقبولا لكنه ليس الإصلاح المطلوب، فقل: "التففت حوله بفعل X، لكنني ما زلت أريد فهم سبب عدم نجاح الطريقة الأصلية."

قوالب يمكنك نسخها

لتذكرة عامة عن عطل:

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>