Налаштування тікет-системи підтримки покупців 1С-Бітрікс

Тікет-система підтримки покупців на 1С-Бітрікс: від штатного модуля до кастомної

Компанія наша команда з 10-річним досвідом успішно налаштовує тікет-системи для 50+ клієнтів. Ми пропонуємо налаштування тікетів 1С-Бітрікс з гарантією якості. Тікет-система Бітрікс з нашим налаштуванням забезпечує швидку підтримку. Економія на підтримці — до 35% при впровадженні тікет-системи. Вартість проєкту — від $2000.

Кожен інтернет-магазин рано чи пізно стикається з потоком звернень покупців. Штатний модуль support в 1С-Бітрікс дає базову функціональність: створення тікету, зміна статусу, відповіді. Але коли бізнес зростає, з'являються вимоги до SLA, прив'язки до замовлень, автоматичної маршрутизації. Наприклад, на одному з проєктів інтернет-магазину електроніки кількість звернень зросла до 500 на день. Оператори тонули в хаосі — не розуміли, яке замовлення критичне, а яке може почекати. Штатний модуль не давав жодних інструментів для розстановки пріоритетів. Після впровадження кастомної системи з SLA час першої відповіді скоротився з 4 годин до 15 хвилин. Для мережі автомобільних магазинів впровадили тікет-систему з SLA: час відповіді скоротився з 6 годин до 2 годин. Впровадження такої системи знижує витрати на підтримку на 30–50% за рахунок автоматизації. Ми, як інтегратори з 10-річним досвідом роботи з Бітрікс, не раз доопрацьовували цей модуль або замінювали його кастомною системою. Згідно з документацією модуля support, штатне рішення не передбачає SLA, тому для серйозних проєктів потрібна кастомізація. У цій статті розповімо, як налаштувати тікет-систему, яка реально допомагає — не перетворюється на чорну діру.

Чому штатного модуля support може не вистачити?

Модуль support вирішує базові задачі, але в нього є обмеження:

• Немає SLA: час відповіді не контролюється, немає ескалації.
• Немає прив'язки до замовлень з коробки — покупець змушений вручну пояснювати, про яке замовлення йдеться.
• Немає вбудованої статистики: час вирішення, завантаження операторів, кількість прострочених тікетів.
• Складно масштабувати на кілька брендів або типів підтримки.

Порівняємо штатний модуль і кастомне рішення:

Кастомна система працює в 4 рази швидше за штатний модуль — перевірено на проєктах з тисячами звернень на день. Економія часу операторів становить до 60%.

Як прив'язати тікет до замовлення?

Прив'язка до замовлення — одна з найзатребуваніших доопрацювань. Штатно модуль не знає про модуль sale. Рішення — додати користувацьке поле UF_ORDER_ID до тікетів. Ось покроковий план:

1. Додайте користувацьке поле через 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' => 'Заказ'], ]); ?> 

   Після цих кроків оператор бачить склад замовлення, статус, доставку — без ручного пошуку.

   Що входить у налаштування тікет-системи?

   У рамках проєкту ми робимо:

   • Аудит поточної ситуації: потік звернень, типові проблеми, вимоги до 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 розраховується на основі категорії та пріоритету. Покрокове налаштування:

   1. Визначте категорії тікетів (наприклад, «Повернення», «Доставка», «Технічна проблема»).
   2. Для кожної категорії призначте пріоритет: критичний, високий, нормальний, низький.
   3. Встановіть час першої відповіді та вирішення для кожного пріоритету.
   4. Налаштуйте агент, який кожні 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 тижні

   Вартість розраховується індивідуально після аналізу вимог. Типовий проєкт коштує $3000-5000. Зазвичай проєкт укладається в діапазон від 2 до 4 тижнів. Отримайте оцінку вашого проєкту — напишіть нам, і ми підготуємо комерційну пропозицію з детальним планом робіт.

   Ми гарантуємо якість: всі тікет-системи проходять навантажувальне тестування, документацію передаємо замовнику. Наш досвід — понад 50 успішних проєктів на Бітрікс, сертифіковані спеціалісти.

   Зв'яжіться з нами, щоб обговорити вашу задачу. Замовте консультацію — оцінимо проєкт безкоштовно.