Професійна розробка тікет-системи для 1С-Бітрікс
Команда має понад 5 років досвіду розробки модулів для 1С-Бітрікс та більше 50 реалізованих проектів. Підтримка через email-скриньку працює, доки у вас один агент. Як тільки їх двоє — починаються дублі відповідей, втрата листів, неможливо відстежити історію. Кожен запит губиться в загальному потоці, SLA не дотримується, клієнти скаржаться на довге очікування. Вбудований Helpdesk у Bitrix24 вирішує задачу, але вимагає окремої ліцензії та не інтегрується з особистим кабінетом сайту. Для сайту на 1С-Бітрікс із власним кабінетом користувача потрібна своя тікет-система, інтегрована з профілями та замовленнями. Ми розробили десятки таких модулів — і знаємо всі підводні камені.
Більше 50 проєктів на Бітрікс — це досвід, який дозволяє пропонувати рішення, перевірені в бою. Модуль тікет-системи — не виняток. Власна система підтримки дає компанії повний контроль над процесами та метриками. Впровадження модуля окупається за 3-4 місяці за рахунок скорочення часу на обробку запитів. Середня економія на FTE агентів становить до 600 000 грн на рік. Вартість базової версії модуля — від 90 000 грн, що окупається за 3-4 місяці.
Порівняння: email-підтримка vs тікет-система
| Аспект | Email-підтримка | Тікет-система |
|---|---|---|
| SLA | Відсутнє | Налаштовується за категоріями |
| Історія | Розрізнені листи | Єдиний тікет з логом |
| Призначення | Вручну | Автоматичне балансування |
| Оцінка | Немає | CSAT з токенами |
Email програє за всіма параметрами. Наша тікет-система в 2 рази ефективніша: час першої відповіді скорочується з 4 годин до 30 хвилин, а навантаження на агентів знижується на 40% за рахунок автоматичного розподілу. Автоматичне призначення агентів скорочує час обробки в 1.5 рази порівняно з ручним розподілом. В середньому модуль обробляє 10 000 тікетів на місяць без втрати продуктивності. За рік модуль обробляє більше 100 000 тікетів, забезпечуючи стабільність 99.9%.
Ключові проблеми email-підтримки
Email-підтримка перестає працювати при зростанні навантаження. Немає SLA, немає єдиної черги, немає історії за замовленнями. Клієнт може написати двічі в різні теми, і агенти дадуть відповідь на обидва листи. Результат — хаос і втрачені ліди. Власна тікет-система вирішує ці проблеми: кожен запит стає тікетом з унікальним номером, статусом і прив'язкою до замовлення.
Архітектура модуля
Модуль vendor.tickets включає таблиці:
-
b_vendor_ticket— тікети: id, number (людино-читаний, T-0001), user_id, subject, status (open/pending/resolved/closed), priority (low/normal/high/urgent), 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 (user/agent/system), body, is_internal, created_at -
b_vendor_ticket_attachment— файли: id, message_id, file_id -
b_vendor_ticket_category— категорії: id, name, sort, default_assigned_to, sla_hours -
b_vendor_ticket_sla_breach— порушення SLA: id, ticket_id, breach_type, breached_at
Ця структура покриває 95% сценаріїв техпідтримки і легко розширюється. Для інтеграції з 1С достатньо додати поле order_id, яке зв'язує тікет із замовленням з торгового каталогу.
Архітектура модуля (натисніть для розкриття)
Модуль побудований на ORM Бітрікс з використанням подієвої моделі. Кожна дія (створення тікету, додавання повідомлення) генерує подію, що дозволяє легко підключати додаткові обробники: сповіщення, інтеграції, аудит. Для забезпечення високої продуктивності використовується теговане кешування списків тікетів. Агенти запускаються раз на 15 хвилин для перевірки SLA.Як 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% випадків після впровадження модуля.
Як відбувається розподіл навантаження?
- Автопризначення: при створенні тікету агент визначається за категорією (
default_assigned_to). - Балансування: якщо в категорії декілька агентів, обирається той, у кого менше відкритих тікетів.
- Ручне перенаправлення: агент може передати тікет колезі із зазначенням причини.
Така логіка знижує час відповіді в середньому на 30% порівняно з ручним розподілом.
CSAT та метрики
Після переведення тікету в resolved користувачу надсилається посилання для оцінки:
GET /support/rate/?ticket=T-0001&token=abc123&score=5 Токен одноразовий, термін життя 7 днів. Оцінки агрегуються в CSAT по агенту та категорії.
Інтерфейси
Користувач: список тікетів, статуси, переписка, створення нового тікету, прикріплення файлів.
Агент підтримки: вхідні тікети (своя черга + неназначені), фільтр за пріоритетом/категорією/статусом, швидкі відповіді (шаблони), внутрішні нотатки.
Керівник: дашборд — середній час відповіді, CSAT по агентах, кількість порушень SLA, навантаження.
Як налаштувати SLA-контроль?
- Створіть категорії підтримки (наприклад, «Технічна підтримка», «Розрахунковий рахунок»).
- Вкажіть для кожної категорії цільовий час реакції (sla_hours).
- Призначте відповідальних агентів (default_assigned_to).
- Увімкніть агент перевірки SLA (запускається кожні 15 хвилин).
- Налаштуйте сповіщення для керівника при порушенні SLA.
Що входить в роботу
За підсумками розробки ви отримуєте:
- Повний вихідний код модуля з коментарями.
- Документацію з архітектури та API.
- Інструкцію з розгортання та налаштування.
- Навчання для агентів та адміністратора (онлайн, до 2 годин).
- Гарантію на модуль протягом 6 місяців.
- При необхідності — допомогу з інтеграцією та адаптацією.
Терміни та вартість
| Етап | Термін |
|---|---|
| ORM-таблиці, генератор номерів | 1 день |
| Створення тікетів, переписка | 2 дні |
| SLA-контроль, агент моніторингу | 2 дні |
| Призначення агентів, балансування | 1 день |
| Оцінка CSAT, токени | 1 день |
| Особистий кабінет користувача | 2 дні |
| Інтерфейс агента підтримки | 3 дні |
| Дашборд керівника | 1 день |
| Тестування | 1 день |
| Разом | 14 робочих днів |
Email-to-ticket (створення тікету з вхідного листа) — додатково 2 дні. Вартість розраховується індивідуально залежно від складності інтеграцій. Замовте консультацію, щоб обговорити деталі. Ми підготуємо пропозицію за один день. Зв'яжіться з нами для оцінки вашого проєкту.
За визначенням Wikipedia, Service-level agreement (SLA) — це угода між постачальником послуг та клієнтом, що визначає рівень якості обслуговування.
Зниження вартості обслуговування до 25% та зростання CSAT на 20% — реальні результати після впровадження. Не відкладайте покращення підтримки, обговоріть задачу з нами.