פיתוח מודול מערכת כרטוס ל-1C-Bitrix עם SLA ו-CSAT

פיתוח מודול מערכת פניות (Ticket System) ל-1C-Bitrix

תמיכה בדוא"ל עובדת עד שיש לך נציג אחד. ברגע שיש שניים, תשובות כפולות, הודעות שאבדו והיסטוריה שלא ניתן לעקוב אחריה הופכים לנורמה. כל בקשה הולכת לאיבוד בזרם הכללי, SLA לא נאכף, ולקוחות מתלוננים על זמני המתנה ארוכים. ה-Helpdesk המובנה של Bitrix24 פותר את הבעיה אך דורש רישיון נפרד ואינו משתלב עם החשבון האישי של האתר. עבור אתר על 1C-Bitrix עם אזור משתמש משלו, יש צורך במערכת פניות מותאמת אישית המשולבת עם פרופילים והזמנות. פיתחנו עשרות מודולים כאלה—ואנחנו מכירים את כל המלכודות.

ניסיון של מעל 50 פרויקטי Bitrix מעניק לנו את היכולת להציע פתרונות מוכחים בשטח. מערכת פניות מותאמת אישית נותנת לחברה שליטה מלאה על תהליכים ומדדים. ההטמעה מחזירה את עצמה תוך 3-4 חודשים על ידי צמצום זמן הטיפול בבקשות.

תמיכה בדוא"ל לעומת מערכת פניות: השוואה

הדוא"ל מפסיד בכל החזיתות. מערכת הפניות שלנו יעילה פי שניים: זמן התגובה הראשונה יורד מ-4 שעות ל-30 דקות, ועומס הנציגים יורד ב-40% באמצעות חלוקה אוטומטית. בממוצע, המודול מטפל ב-10,000 פניות בחודש ללא ירידה בביצועים.

בעיות עיקריות בתמיכה בדוא"ל

תמיכה בדוא"ל מפסיקה לעבוד תחת עומס. אין SLA, אין תור אחיד, אין היסטוריית הזמנות. לקוח עלול לכתוב פעמיים בשרשורים שונים, ונציגים עונים לשניהם. התוצאה: כאוס ופניות שאבדו. מערכת פניות מותאמת אישית פותרת את הבעיות האלה: כל בקשה הופכת לפנייה עם מספר ייחודי, סטטוס וקישור להזמנה.

ארכיטקטורת המודול

המודול vendor.tickets כולל טבלאות:

• b_vendor_ticket — פניות: id, מספר (קריא לאדם, T-0001), user_id, נושא, סטטוס (פתוח/ממתין/טופל/סגור), עדיפות (נמוכה/רגילה/גבוהה/דחופה), category_id, assigned_to, order_id, first_response_at, resolved_at, created_at, updated_at
• b_vendor_ticket_message — הודעות: id, ticket_id, author_id, author_type (משתמש/נציג/מערכת), גוף ההודעה, is_internal, created_at
• b_vendor_ticket_attachment — קבצים: id, message_id, file_id
• b_vendor_ticket_category — קטגוריות: id, שם, sort, default_assigned_to, sla_hours
• b_vendor_ticket_sla_breach — הפרות SLA: id, ticket_id, breach_type, breached_at

מבנה זה מכסה 95% מתרחישי התמיכה וניתן להרחבה בקלות. עבור אינטגרציה עם 1C, פשוט הוסף את השדה order_id המקשר את הפנייה להזמנה מקטלוג המוצרים.

כיצד בקרת SLA עוזרת לעמוד בהתחייבויות?

SLA מוגדר ברמת הקטגוריה (sla_hours). הסוכן בודק כל 15 דקות:

public static function checkSlaBreaches(): void {
    $breachTime = (new DateTime())->modify("-{ $category['SLA_HOURS']} hours");
    $overdue = TicketTable::getList([
        'filter' => [
            'STATUS' => 'open',
            '<=CREATED_AT' => $breachTime,
            'FIRST_RESPONSE_AT' => false,
        ],
    ])->fetchAll();
    foreach ($overdue as $ticket) {
        SlaBreachTable::add([
            'TICKET_ID' => $ticket['ID'],
            'BREACH_TYPE' => 'first_response',
            'BREACHED_AT' => new DateTime(),
        ]);
        $this->notifySlaManager($ticket);
    }
}

במקרה של הפרת SLA, המנהל מקבל התראה—זה מבטיח תגובה בזמן ומשפר את ה-CSAT. עם בקרה כזו, שביעות רצון הלקוחות נשארת מעל 4.5 מתוך 5. הפרות SLA מתרחשות בפחות מ-5% מהמקרים לאחר הטמעת המודול.

עבודה עם פניות

משתמש יוצר פנייה

class TicketService {
    public function create(int $userId, array $data): CreateResult {
        $number = $this->generateNumber(); // T-0001, атомарный счётчик
        $category = CategoryTable::getById($data['category_id'])->fetch();
        $ticketId = TicketTable::add([
            'NUMBER' => $number,
            'USER_ID' => $userId,
            'SUBJECT' => $data['subject'],
            'STATUS' => 'open',
            'PRIORITY' => $data['priority'] ?? 'normal',
            'CATEGORY_ID' => $data['category_id'],
            'ASSIGNED_TO' => $category['DEFAULT_ASSIGNED_TO'],
            'ORDER_ID' => $data['order_id'] ?? null,
        ])->getId();
        MessageTable::add([
            'TICKET_ID' => $ticketId,
            'AUTHOR_ID' => $userId,
            'AUTHOR_TYPE' => 'user',
            'BODY' => $data['message'],
        ]);
        $this->notifyAgent($ticketId);
        return CreateResult::success($ticketId);
    }
}

התכתבות בפנייה

כל הודעה חדשה היא רשומה ב-public static function checkSlaBreaches(): void { $breachTime = (new DateTime())->modify("-{ $category['SLA_HOURS']} hours"); $overdue = TicketTable::getList([ 'filter' => [ 'STATUS' => 'open', '<=CREATED_AT' => $breachTime, 'FIRST_RESPONSE_AT' => false, ], ])->fetchAll(); foreach ($overdue as $ticket) { SlaBreachTable::add([ 'TICKET_ID' => $ticket['ID'], 'BREACH_TYPE' => 'first_response', 'BREACHED_AT' => new DateTime(), ]); $this->notifySlaManager($ticket); } } . נציגים יכולים להשאיר הערות פנימיות (class TicketService { public function create(int $userId, array $data): CreateResult { $number = $this->generateNumber(); // T-0001, атомарный счётчик $category = CategoryTable::getById($data['category_id'])->fetch(); $ticketId = TicketTable::add([ 'NUMBER' => $number, 'USER_ID' => $userId, 'SUBJECT' => $data['subject'], 'STATUS' => 'open', 'PRIORITY' => $data['priority'] ?? 'normal', 'CATEGORY_ID' => $data['category_id'], 'ASSIGNED_TO' => $category['DEFAULT_ASSIGNED_TO'], 'ORDER_ID' => $data['order_id'] ?? null, ])->getId(); MessageTable::add([ 'TICKET_ID' => $ticketId, 'AUTHOR_ID' => $userId, 'AUTHOR_TYPE' => 'user', 'BODY' => $data['message'], ]); $this->notifyAgent($ticketId); return CreateResult::success($ticketId); } } ) שאינן גלויות למשתמש. כאשר נציג עונה, הסטטוס משתנה ל-b_vendor_ticket_message, is_internal = 1 נרשם, והמשתמש מקבל התראה בדוא"ל. כאשר המשתמש עונה, הסטטוס חוזר ל-pending.

חלוקת עומסים

• שיבוץ אוטומטי: בעת יצירת פנייה, הנציג נקבע לפי קטגוריה (first_response_at).
• איזון עומסים: אם יש מספר נציגים בקטגוריה, נבחר זה עם מספר הפניות הפתוחות הנמוך ביותר.
• העברה ידנית: נציג יכול להעביר פנייה לעמית עם סיבה.

לוגיקה זו מפחיתה את זמן התגובה בממוצע ב-30% בהשוואה לשיבוץ ידני.

CSAT ומדדים

לאחר שפנייה מוגדרת ל-open, המשתמש מקבל קישור לדירוג:

GET /support/rate/?ticket=T-0001&token=abc123&score=5 

הטוקן הוא חד-פעמי עם תוקף של 7 ימים. הדירוגים מסוכמים ל-CSAT לפי נציג וקטגוריה.

ממשקים

משתמש: רשימת פניות, סטטוסים, התכתבות, יצירת פנייה חדשה, צירוף קבצים.

נציג תמיכה: פניות נכנסות (תור אישי + לא משויכות), סינון לפי עדיפות/קטגוריה/סטטוס, תשובות מהירות (תבניות), הערות פנימיות.

מנהל: דשבורד — זמן תגובה ממוצע, CSAT לפי נציג, מספר הפרות SLA, עומס.

כיצד להגדיר בקרת SLA: שלב אחר שלב

1. צור קטגוריות תמיכה (למשל, "תמיכה טכנית", "חיוב").
2. הגדר זמן תגובה יעד (sla_hours) לכל קטגוריה.
3. שייך נציגים אחראיים (default_assigned_to).
4. הפעל את סוכן בדיקת ה-SLA (רץ כל 15 דקות).
5. הגדר התראות למנהל על הפרות SLA.

מה כלול

עם סיום העבודה תקבל:

• קוד מקור מלא של המודול עם הערות.
• תיעוד ארכיטקטורה ו-API.
• מדריך התקנה והגדרה.
• הדרכה לנציגים ולמנהל מערכת (מקוון, עד שעתיים).
• אחריות על המודול ל-6 חודשים.
• סיוע באינטגרציה והתאמה במידת הצורך.

לוחות זמנים ועלות

המרת דוא"ל לפנייה (יצירת פנייה מהודעת דוא"ל נכנסת) מוסיפה יומיים נוספים. העלות מחושבת באופן אישי לפי מורכבות האינטגרציה. בקש ייעוץ כדי לדון בפרטים. נכין הצעה תוך יום אחד. צור קשר כדי להעריך את הפרויקט שלך.

לפי ויקיפדיה, הסכם רמת שירות (SLA) הוא הסכם בין ספק שירות ללקוח המגדיר את רמת איכות השירות.

הפחתה של עד 25% בעלויות השירות ועלייה של 20% ב-CSAT הם תוצאות אמיתיות לאחר ההטמעה. אל תדחה את שיפור התמיכה שלך—דון במשימה איתנו.