Разработка модуля тикет-системы 1С-Битрикс
Поддержка через email-ящик работает до тех пор, пока у вас один агент. Как только их двое — начинаются дубли ответов, потеря писем, невозможно отследить историю. Каждый запрос теряется в общем потоке, SLA не соблюдается, клиенты жалуются на долгое ожидание. Встроенный Helpdesk в Bitrix24 решает задачу, но требует отдельной лицензии и не интегрируется с личным кабинетом сайта. Для сайта на 1С-Битрикс с собственным кабинетом пользователя нужна своя тикет-система, интегрированная с профилями и заказами. Мы разработали десятки таких модулей — и знаем все подводные камни.
Более 50 проектов на Битрикс — это опыт, который позволяет предлагать решения, проверенные в бою. Модуль тикет-системы — не исключение. Собственная система поддержки даёт компании полный контроль над процессами и метриками. Внедрение модуля окупается за 3-4 месяца за счёт сокращения времени на обработку запросов. Средняя экономия на FTE агентов составляет до 600 000 руб. в год.
Сравнение: email-поддержка vs тикет-система
| Аспект | Email-поддержка | Тикет-система |
|---|---|---|
| SLA | Отсутствует | Настраивается по категориям |
| История | Разрозненные письма | Единый тикет с логом |
| Назначение | Вручную | Автоматическая балансировка |
| Оценка | Нет | CSAT с токенами |
Email проигрывает по всем параметрам. Наша тикет-система в 2 раза эффективнее: время первого ответа сокращается с 4 часов до 30 минут, а нагрузка на агентов снижается на 40% за счёт автоматического распределения. В среднем модуль обрабатывает 10 000 тикетов в месяц без потери производительности.
Ключевые проблемы 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% случаев после внедрения модуля.
Работа с тикетами
Создание тикета пользователем
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, пользователь получает email-уведомление. При ответе пользователя статус возвращается к open.
Распределение нагрузки
- Автоназначение: при создании тикета агент определяется по категории (
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% — реальные результаты после внедрения. Не откладывайте улучшение поддержки, обсудите задачу с нами.