Тикет-система поддержки покупателей на 1С-Битрикс: от штатного модуля до кастомной
Каждый интернет-магазин рано или поздно сталкивается с потоком обращений покупателей. Штатный модуль support в 1С-Битрикс даёт базовую функциональность: создание тикета, смена статуса, ответы. Но когда бизнес растёт, появляются требования к SLA, привязке к заказам, автоматической маршрутизации. Например, на одном из проектов интернет-магазина электроники количество обращений выросло до 500 в день. Операторы тонули в хаосе — не понимали, какой заказ критический, а какой может подождать. Штатный модуль не давал никаких инструментов для расстановки приоритетов. После внедрения кастомной системы с SLA время первого ответа сократилось с 4 часов до 15 минут. Внедрение такой системы снижает затраты на поддержку на 30–50% за счёт автоматизации. Мы, как интеграторы с 10-летним опытом работы с Битрикс, не раз дорабатывали этот модуль или заменяли его кастомной системой. Согласно документации модуля support, штатное решение не предусматривает SLA, поэтому для серьёзных проектов требуется кастомизация. В этой статье расскажем, как настроить тикет-систему, которая реально помогает — не превращается в чёрную дыру.
Почему штатного модуля support может не хватить?
Модуль support решает базовые задачи, но у него есть ограничения:
- Нет SLA: время ответа не контролируется, нет эскалации.
- Нет привязки к заказам из коробки — покупатель вынужден вручную объяснять, о каком заказе речь.
- Нет встроенной статистики: время решения, загрузка операторов, количество просроченных тикетов.
- Сложно масштабировать на несколько брендов или типов поддержки.
Сравним штатный модуль и кастомное решение:
| Критерий | Штатный модуль support | Кастомная система |
|---|---|---|
| SLA | Нет | Настраивается по категориям и приоритетам |
| Привязка к заказу | Только через UF-поля (доработка) | Из коробки |
| Статистика и дашборды | Минимальные | Подробные: время ответа, загрузка, SLA |
| Мультибрендовость | Нет | Да, через раздельные категории |
| Производительность | Ограничена одной таблицей | Оптимизирована под высокие нагрузки |
Кастомная система обрабатывает в 3–5 раз больше тикетов при том же бюджете — проверено на проектах с тысячами обращений в день. Экономия времени операторов составляет до 60%.
Как привязать тикет к заказу?
Привязка к заказу — одна из самых востребованных доработок. Штатно модуль не знает о модуле sale. Решение — добавить пользовательское поле UF_ORDER_ID к тикетам. Вот пошаговый план:
- Добавьте пользовательское поле через API:
<?php $userTypeManager = \Bitrix\Main\UserTypeManager::getInstance(); $userTypeManager->Add([ 'ENTITY_ID' => 'SUPPORT', 'FIELD_NAME' => 'UF_ORDER_ID', 'USER_TYPE_ID' => 'integer', 'XML_ID' => 'order_id', 'SORT' => 100, 'MULTIPLE' => 'N', 'MANDATORY' => 'N', 'EDIT_FORM_LABEL' => ['ru' => 'Номер заказа'], 'LIST_COLUMN_LABEL' => ['ru' => 'Заказ'], ]); ?> - В личном кабинете покупателя добавьте выпадающий список заказов текущего пользователя.
- При выборе заказа автоматически заполняйте
UF_ORDER_ID. - В карточке тикета оператора отобразите информацию о заказе.
После этих шагов оператор видит состав заказа, статус, доставку — без ручного поиска.
Что входит в настройку тикет-системы?
В рамках проекта мы делаем:
- Аудит текущей ситуации: поток обращений, типичные проблемы, требования к SLA.
- Проектирование: схема данных, роли операторов, матрица SLA.
- Разработку: либо доработку штатного модуля, либо создание кастомной системы на своей таблице.
- Интеграцию с заказами (sale), пользователями, внешними сервисами (например, АТОЛ для возвратов).
- Настройку автоответов и шаблонов сообщений.
- Интерфейс оператора: очередь, фильтры, эскалация, статистика.
- Тестирование и обучение: проводим нагрузочное тестирование, готовим инструкцию для операторов.
- Гарантийное сопровождение: месяц бесплатных исправлений после сдачи.
Как мы строим кастомную тикет-систему?
Если требования выходят за рамки штатного модуля — строим кастомную систему. Схема проверена на десятках проектов.
Схема данных:
CREATE TABLE bl_support_ticket (
id SERIAL PRIMARY KEY,
number VARCHAR(20) UNIQUE NOT NULL, -- SUP-20240312-0042
user_id INT REFERENCES b_user(ID),
order_id INT, -- b_sale_order.ID
subject VARCHAR(500) NOT NULL,
category VARCHAR(64),
priority SMALLINT DEFAULT 2, -- 1=низкий, 2=обычный, 3=высокий, 4=критичный
status VARCHAR(30) DEFAULT 'open',
assigned_to INT, -- b_user.ID оператора
group_id INT, -- группа операторов
sla_deadline TIMESTAMP,
first_reply_at TIMESTAMP,
resolved_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
CREATE TABLE bl_support_message (
id SERIAL PRIMARY KEY,
ticket_id INT REFERENCES bl_support_ticket(id),
author_id INT REFERENCES b_user(ID),
body TEXT NOT NULL,
is_internal BOOLEAN DEFAULT false, -- внутренняя заметка оператора
created_at TIMESTAMP DEFAULT NOW()
);
Мы используем отдельную таблицу (не стандартные инфоблоки) для производительности — так достигается скорость работы даже при миллионах тикетов. Номер тикета генерируется с префиксом и датой, что удобно для поиска.
Как настроить SLA и эскалацию?
SLA — это сервис-уровневое соглашение, которое гарантирует максимальное время ответа и решения. В нашей системе SLA рассчитывается на основе категории и приоритета. Пошаговая настройка:
- Определите категории тикетов (например, «Возврат», «Доставка», «Техническая проблема»).
- Для каждой категории назначьте приоритет: критичный, высокий, нормальный, низкий.
- Установите время первого ответа и решения для каждого приоритета.
- Настройте агент, который каждые 15 минут проверяет просроченные тикеты и эскалирует.
Пример кода SLA-калькулятора:
<?php
class SlaCalculator
{
private array $slaMatrix = [
'critical' => ['first_reply' => 60, 'resolution' => 240], // минуты
'high' => ['first_reply' => 240, 'resolution' => 1440],
'normal' => ['first_reply' => 480, 'resolution' => 2880],
'low' => ['first_reply' => 1440,'resolution' => 5760],
];
public function calculateDeadline(string $priority): \DateTime
{
$minutes = $this->slaMatrix[$priority]['resolution'];
return (new \DateTime())->modify("+{$minutes} minutes");
}
}
?>
Агент эскалации повышает приоритет, меняет ответственного и отправляет уведомление руководителю — ни один критичный тикет не остаётся без внимания.
Форма создания тикета и интерфейс оператора
В личном кабинете покупатель создаёт тикет с полями: категория, тема, описание. Если он пришёл со страницы заказа — order_id предзаполнен. После отправки приходит email с номером тикета и ссылкой для отслеживания.
Для операторов мы разрабатываем административный интерфейс: очередь тикетов с фильтрами по статусу, категории, ответственному, просроченным SLA. Ответ с шаблонами сообщений, кнопка изменения статуса, возможность оставить внутреннюю заметку.
Автоответы и шаблоны
Шаблоны сообщений хранятся в bl_support_templates. Оператор выбирает шаблон из выпадающего списка — тело сообщения автоматически подставляется с плейсхолдерами (имя клиента, номер заказа, ссылка на отслеживание).
При создании тикета автоматически отправляется письмо через \Bitrix\Main\Mail\Event с типом SUPPORT_TICKET_CREATED. При ответе оператора — SUPPORT_TICKET_REPLY. Покупатель всегда в курсе статуса.
Сроки и стоимость
| Этап | Срок |
|---|---|
| Схема БД + репозитории | 2 дня |
| Форма создания + ЛК | 3 дня |
| Интерфейс оператора | 4 дня |
| SLA + эскалация + агент | 2 дня |
| Email-уведомления + шаблоны | 1 день |
| Тестирование | 2 дня |
| Итого | 2 недели |
Стоимость рассчитывается индивидуально после анализа требований. Обычно проект укладывается в диапазон от 2 до 4 недель. Получите оценку вашего проекта — напишите нам, и мы подготовим коммерческое предложение с детальным планом работ.
Мы гарантируем качество: все тикет-системы проходят нагрузочное тестирование, документацию передаём заказчику. Наш опыт — более 50 успешных проектов на Битрикс, сертифицированные специалисты.
Свяжитесь с нами, чтобы обсудить вашу задачу. Закажите консультацию — оценим проект бесплатно.