Support (Tickets) / الدعم (التذاكر) — User Guide

Support is the service-management module for handling customer and internal requests through tickets. Instead of scattered email threads and chat messages, each request is tracked in one controlled record with routing, ownership, replies, attachments, status updates, escalation, and closure.

In Xfatora, the ticket is the main service record. Tickets can be created by staff, portal users, and inbound email (when email piping is enabled). A ticket can include:

• Subject and initial message
• Department, priority, service, and status
• Submitter and assignee
• Attachments, tags, and internal notes
• Full threaded reply history

The model also supports customer/contact linkage, project linkage, CC, merged tickets, reply attachments, and department-aware visibility.

Support governs the full service lifecycle:

• Tickets: Intake, reply history, attachments, ownership, and status progression.
• Departments: Queue routing and team ownership, with optional department-restricted visibility.
• Priorities: Governed urgency values (not free-text) that drive escalation.
• Statuses: Controlled workflow values with reference checks and default protections.
• Services: Optional classification by product area/service line.
• Predefined replies: Reusable reply snippets for speed and consistency.
• Public and email intake: CAPTCHA/public form and email piping with spam/loop/rate protections.
• Bulk and merge tools: Mass updates and duplicate consolidation.
• Notifications: Staff assignment alerts, customer reply notifications, and department-based routing.

• Support Admin
• Configures departments, priorities, statuses, services, predefined replies, spam controls, and permissions.
• Owns intake policy (staff-only, portal, public, email) and bulk-action governance.
• Support Agent
• Creates/replies to tickets, updates status, handles attachments, and escalates.
• May assign tickets depending on permissions.
• Team Lead / Queue Manager
• Reviews backlog, aging, routing quality, and priority usage.
• Decides reassignment, merge, and escalation.
• Read-only / Management Reviewer
• Reviews operational trends and queue health without editing records.
• Customer / Portal User (if enabled)
• Submits tickets, replies, and uploads files through allowed channels.
• Has no configuration access.

1. Configure departments first (routing, ownership, visibility, notification behavior depend on this).
2. Set priorities (start simple: Low / Medium / High).
3. Set statuses (recommended: New, Open, In progress, Waiting, Resolved, Closed).
4. Configure services if you need service-line/product categorization.
5. Build predefined replies (greetings, troubleshooting, payment steps, escalation notices).
6. Enable spam/abuse controls (CAPTCHA, filters, sender blocking, loop/rate controls for email).
7. Decide intake channels (staff, portal, public form, email piping, or a combination).
8. Decide notification model (assigned staff, department alerts, customer notifications).
9. Run workflow testing (staff ticket, customer ticket, attachments, assignment, replies, status moves, merge, notifications).

#### Workflow 1: Create a ticket

1. Open Support → Tickets.
2. Create ticket with subject, message, department, priority, and optional service.
3. Attach relevant files (screenshots, logs, documents).
4. Save and confirm ownership.

Ticket creation may also come from customer/contact context, project context, portal forms, or inbound email.

#### Workflow 2: Reply and move status

1. Open ticket thread.
2. Add a structured reply and request missing data if needed.
3. Move status on the agreed path (example: Open → In progress → Waiting → Resolved/Closed).
4. Keep replies clear; include attachments when needed.

#### Workflow 3: Assign and escalate

1. Assign ticket owner.
2. If routed wrong, move to correct department.
3. For escalation: raise priority, add internal note, and route to the right team.

#### Workflow 4: Close correctly

1. Confirm issue is resolved.
2. Add final summary (what was done and outcome).
3. Set to Resolved/Closed.
4. Optionally link related Knowledge Base content.

#### Workflow 5: Use predefined replies and services

• Use predefined replies for repeated questions.
• Use services to classify demand by line/product area.

#### Workflow 6: Handle public or email intake

• Public form: Enable CAPTCHA and default routing.
• Email intake: Verify mailbox mapping, piping rules, spam handling, and reply import behavior.

#### Workflow 7: Use bulk and merge carefully

• Use bulk actions for controlled queue cleanup.
• Merge only true duplicates into one primary ticket.

• Daily: Tickets by status and priority (backlog control).
• Weekly: Tickets by department and routing quality.
• Weekly/Monthly: Aging review and volume trends.
• Monthly: Top recurring issues and prevention actions (KB content, process fixes, product improvements).

7) Best practices

• Keep module naming simple: Support + Tickets.
• Keep statuses minimal early on.
• Require clear subject lines and sufficient first-message context.
• Keep predefined replies updated.
• Do not track real service work in email alone—keep it in tickets.
• Treat public/email channels as controlled intake with anti-spam protections.
• Restrict merge/bulk operations to trained roles.

Q: Tickets menu is missing. What should we check?

• Confirm user permission to view tickets.
• Confirm support module/features are enabled.

Q: We get too much spam from the public form. What should we check?

• Enable CAPTCHA.
• Add spam-domain/keyword filters.
• Restrict public submission where needed.

Q: Agents reply, but customers say they did not receive emails. What should we check?

• Verify outbound email configuration.
• Check customer spam folder.
• Confirm the ticket uses the correct customer/contact email.

Q: Status usage is inconsistent. What should we do?

• Reduce status count.
• Train team on “Waiting” vs “In progress”.
• Publish a short internal SOP.

Q: Duplicate tickets are confusing the queue. What should we do?

• Use merge controls to consolidate duplicates.
• Train users to search before opening a new ticket.

Q: Department routing is wrong. What should we check?

• Review department ownership and default routing.
• Review support-email-to-department mapping in email piping.

---

1) نظرة عامة

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

في Xfatora، التذكرة هي سجل الخدمة الرئيسي. ويمكن إنشاؤها من:

• الموظفين
• بوابة العميل
• البريد الإلكتروني الوارد (عند تفعيل Email Piping)

وقد تشمل التذكرة:

• الموضوع والرسالة الأساسية
• القسم والأولوية والخدمة والحالة
• مقدم الطلب والمسؤول المعيّن
• الوسوم والملاحظات الداخلية والمرفقات
• سجل ردود متسلسل كامل

كما يدعم النظام الربط مع العميل/جهة الاتصال والمشروع، وCC، ودمج التذاكر، ومرفقات الرد، والرؤية حسب القسم.

2) ما الذي تتحكم فيه الوحدة

تغطي وحدة الدعم دورة الخدمة كاملة:

• التذاكر: إنشاء الطلب، مسار المعالجة، سجل الردود، المرفقات، والإغلاق.
• الأقسام: التوجيه وملكية الطوابير، مع إمكانية تقييد الرؤية حسب القسم.
• الأولويات: قيم منضبطة تقود الاستجابة والتصعيد.
• الحالات: مسار عمل مضبوط مع حماية القيم الافتراضية والمرتبطة.
• الخدمات: تصنيف اختياري حسب خط الخدمة/مجال المنتج.
• الردود الجاهزة: نصوص موحدة لتسريع الرد وتقليل التباين.
• الاستقبال العام والبريد: نموذج عام مع CAPTCHA واستقبال بريدي مع حماية من الإزعاج والتكرار.
• الإجراءات الجماعية والدمج: تنظيف الطوابير ومعالجة التكرارات.
• الإشعارات: تنبيهات للموظفين والعملاء حسب التعيين والقسم.

3) الأدوار والصلاحيات

• مسؤول الدعم (Support Admin)
• يضبط الأقسام والأولويات والحالات والخدمات والردود الجاهزة ومرشحات الإزعاج والصلاحيات.
• يحدد سياسة قنوات الاستقبال وصلاحيات الدمج والإجراءات الجماعية.
• موظف الدعم (Support Agent)
• ينشئ التذاكر ويرد عليها ويغير الحالة ويدير المرفقات والتصعيد.
• قد يعيّن التذكرة حسب الصلاحيات.
• قائد الفريق / مدير الطابور
• يراجع التراكم وعمر التذاكر وجودة التوجيه واستخدام الأولويات.
• يقرر إعادة التوزيع أو الدمج أو التصعيد.
• مراجع إداري / إدارة
• يطّلع على المؤشرات والاتجاهات دون تعديل السجلات التشغيلية.
• العميل / مستخدم البوابة
• يفتح تذكرة ويرد ويرفع مرفقات ضمن القنوات المسموح بها.
• لا يملك صلاحيات الإعدادات الداخلية.

4) الإعداد قبل التشغيل الفعلي

1. إنشاء الأقسام أولًا لأن التوجيه والرؤية والإشعارات تعتمد عليها.
2. ضبط الأولويات بنموذج بسيط (منخفضة / متوسطة / عالية).
3. ضبط الحالات (مثل: جديد، مفتوح، قيد التنفيذ، بانتظار، محلول، مغلق).
4. تجهيز الخدمات إذا كان لديك أكثر من خط خدمة/منتج.
5. إنشاء مكتبة ردود جاهزة (تحية، خطوات متكررة، فوترة، تصعيد).
6. تفعيل الحماية من الإزعاج (CAPTCHA، فلاتر، حظر المرسل، منع الحلقات وحدود السرعة للبريد).
7. تحديد قنوات الاستقبال (موظفون، بوابة، نموذج عام، بريد، أو مزيج).
8. تحديد سياسة الإشعارات للموظفين والعملاء حسب الحاجة.
9. اختبار المسارات قبل الإطلاق من الإنشاء حتى الإغلاق والدمج والإشعارات.

5) سير العمل الأساسي

#### المسار 1: إنشاء تذكرة

1. افتح الدعم → التذاكر.
2. أدخل الموضوع، الرسالة، القسم، الأولوية والخدمة إن وجدت.
3. أرفق الملفات اللازمة (صور، مستندات، سجلات).
4. احفظ التذكرة وتأكد من الملكية.

#### المسار 2: الرد وتحريك الحالة

1. افتح سجل التذكرة.
2. أضف ردًا واضحًا واطلب البيانات الناقصة عند الحاجة.
3. حرّك الحالة ضمن مسار متفق عليه (مثال: مفتوح → قيد التنفيذ → بانتظار → محلول/مغلق).
4. أرفق ما يلزم من ملفات داعمة.

#### المسار 3: التعيين والتصعيد

1. عيّن مالك التذكرة.
2. انقلها إلى القسم الصحيح إذا كانت في طابور خاطئ.
3. عند التصعيد: ارفع الأولوية، أضف ملاحظة داخلية، وحوّلها للفريق المناسب.

#### المسار 4: الإغلاق الصحيح

1. تحقق من الحل الفعلي.
2. أضف ملخصًا نهائيًا لما تم.
3. غيّر الحالة إلى محلول/مغلق.
4. اختياريًا: اربطها بمقالة من قاعدة المعرفة.

#### المسار 5: استخدام الردود الجاهزة والخدمات

• استخدم الردود الجاهزة للحالات المتكررة.
• استخدم الخدمات لتحسين التصنيف والتقارير.

#### المسار 6: استقبال عام أو عبر البريد

• النموذج العام: فعّل CAPTCHA واضبط القيم الافتراضية للتوجيه.
• البريد الإلكتروني: تحقق من خرائط عناوين الأقسام وسياسة الاستيراد وفلاتر الرسائل.

#### المسار 7: الدمج والإجراءات الجماعية بحذر

• استخدم الإجراءات الجماعية لتنظيف طوابير متعددة بشكل منضبط.
• ادمج فقط الحالات المكررة فعليًا تحت تذكرة رئيسية واحدة.

6) التقارير وإيقاع المراجعة

• يوميًا: مراجعة التذاكر حسب الحالة والأولوية.
• أسبوعيًا: مراجعة التذاكر حسب القسم وجودة التوجيه.
• أسبوعيًا/شهريًا: مراجعة عمر التذكرة واتجاهات الحجم.
• شهريًا: مراجعة الأسباب المتكررة وإجراءات الوقاية (قاعدة معرفة/تحسين إجراء/تحسين منتج).

7) أفضل الممارسات

• اجعل التسمية بسيطة: الدعم كوحدة والتذكرة كسجل رئيسي.
• ابدأ بعدد حالات قليل.
• ألزم موضوعًا واضحًا وسياقًا كافيًا في الرسالة الأولى.
• راجع الردود الجاهزة دوريًا.
• لا تعتمد على البريد فقط في تتبع الخدمة.
• اضبط قنوات الاستقبال العامة والبريد بسياسات مكافحة الإزعاج.
• قصر الدمج والإجراءات الجماعية على أدوار مدرّبة.

8) الأسئلة الشائعة / معالجة المشكلات

س: قائمة التذاكر غير ظاهرة، ماذا نراجع؟

• تحقق من صلاحيات المستخدم.
• تحقق من تفعيل موديول/خصائص الدعم.

س: تصلنا رسائل مزعجة كثيرة من النموذج العام، ماذا نراجع؟

• فعّل CAPTCHA.
• أضف فلاتر نطاقات/كلمات.
• قلل الاستقبال العام عند الحاجة.

س: الموظف يرد لكن العميل لا يستلم البريد، ماذا نراجع؟

• راجع إعدادات الإرسال.
• راجع مجلد الرسائل غير المرغوبة لدى العميل.
• تأكد من صحة بريد العميل/جهة الاتصال على التذكرة.

س: استخدام الحالات غير متسق، ماذا نفعل؟

• قلّل عدد الحالات.
• درّب الفريق على الفرق بين بانتظار وقيد التنفيذ.
• انشر SOP داخليًا مختصرًا.

س: التذاكر المكررة تربك الطابور، ماذا نفعل؟

• استخدم الدمج لتجميع الحالات المتكررة.
• درّب الفريق على البحث قبل فتح تذكرة جديدة.

س: التوجيه بين الأقسام غير صحيح، ماذا نراجع؟

• راجع ملكية الأقسام والقيم الافتراضية للتوجيه.
• راجع ربط عناوين بريد الدعم بالأقسام في مسار Email Piping.