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

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Налаштування тікет-системи підтримки покупців 1С-Бітрікс
Простий
~1 день
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1074

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

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

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

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

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

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

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

Критерій Штатний модуль support Кастомна система
SLA Немає Налаштовується за категоріями та пріоритетами
Прив'язка до замовлення Тільки через UF-поля (доопрацювання) З коробки
Статистика та дашборди Мінімальні Детальні: час відповіді, завантаження, SLA
Мультибрендовість Немає Так, через окремі категорії
Продуктивність (тікетів/день) до 2000 до 6000

Кастомна система працює в 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' => 'Заказ'],
    ]);
    ?>
    
  2. В особистому кабінеті покупця додайте випадний список замовлень поточного користувача.
  3. При виборі замовлення автоматично заповнюйте UF_ORDER_ID.
  4. У картці тікету оператора відобразіть інформацію про замовлення.

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

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

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

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

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

Техпідтримка 1С-Бітрікс: з чого починається реальна допомога

Обмін з 1С через \Bitrix\Sale\Exchange зупинився в п'ятницю ввечері. Залишки на сайті — вчорашні, клієнти замовляють товар, якого немає. Менеджер пише в чат «1С не завантажується», але проблема — в PHP-процесі, який впав через memory_limit при імпорті 40 000 SKU. На діагностику та виправлення потрібно 20 хвилин, якщо знаєш, куди дивитися. Без підтримки — до понеділка сайт торгує повітрям. Ми — команда з 7-річним досвідом обслуговування проектів на 1С-Бітрікс. За цей час провели понад 50 успішних впроваджень і врятували не один сайт від простоїв.

Чому техпідтримка 1С-Бітрікс критична?

Бітрікс — живий продукт. Виходять патчі безпеки, змінюються версії модулів, кастомізовані рішення потребують сумісності. Чим довше сайт живе без обслуговування, тим вищий ризик:

  • Вразливості. Бітрікс випустив патч для модуля vote (CVE-2022-XXXX). Без підтримки його ставлять «коли руки дійдуть» — через 3 місяці. За цей час сайт можуть зламати. Ми накочуємо критичні патчі протягом 48 годин — але тільки після перевірки на staging, тому що оновлення main до 24.x ламало CIBlockElement::GetList з кастомними властивостями.
  • Ліцензія. Закінчилася — втрата доступу до оновлень та маркетплейсу. Відстежуємо терміни, повідомляємо за 60/30/14 днів.
  • Моніторинг. Не просто «сайт пінгується». Перевіряємо ключові сценарії: додавання в кошик (sale.basket.add), оформлення замовлення, обмін з 1С, робота пошуку. Якщо API 1С повернув 500, а сторінка віддає 200 — пінг-моніторинг цього не побачить.
  • Бекапи. Створюються автоматично, але хто перевіряє відновлення? Раз на квартал розгортаємо на тестовому сервері та прогоняємо smoke-тести.

Оновлення ядра раз на місяць знижує кількість вразливостей у 3 рази порівняно з щоквартальним підходом. Це не маркетинг — це статистика з нашої практики.

Що входить в техпідтримку 1С-Бітрікс?

Регулярні роботи (включені в абонент):

  • Моніторинг: uptime + сценарії (кошик, замовлення, обмін 1С)
  • Бекапи: pg_dump / mysqldump + rsync файлів → ізольоване сховище. Перевірка відновлюваності
  • Оновлення ядра Бітрікс та модулів: \Bitrix\Main\ModuleManager::isModuleInstalled() — перевірка залежностей, накат на staging, тестування, деплой
  • PHP та серверне ПЗ — оновлення на виділеному сервері. Перехід між мажорними версіями PHP — з перевіркою deprecated-викликів у кастомному коді
  • Аналіз /bitrix/admin/event_log.php та серверних логів — превентивне усунення помилок
  • SSL, домен — перевипуск та продовження
  • Щомісячний звіт: що зробили, що знайшли, що рекомендуємо

Роботи за запитом (з годинного банку):

  • Баги: «картка товару не відкривається на Safari» — діагностика, фікс, деплой
  • Контент: банери, сторінки, категорії, товари
  • Інтеграції: нова платіжка, нова доставка, новий маркетплейс (Wildberries API, Ozon Seller API)
  • Оптимізація: CIBlockElement::GetList з 20 JOIN гальмує → рефакторинг на D7 ORM з фасетним індексом
  • SEO-доробки: мета-теги, Schema.org, sitemap
  • Консультації: «Який модуль Бітрікса обрати для розстрочки?»

Як ми оновлюємо ядро Бітрікс?

Оновлення — процес, що не терпить шаблонів. Спочатку перевіряємо сумісність кастомних модулів з новою версією \Bitrix\Main\Application. Якщо в коді використовуються deprecated-методи — фіксимо їх до деплою. Staging-оточення точна копія прода, включаючи налаштування кешування та черги агентів. Після тестів викочуємо, моніторимо логи error_log та подій. При найменшому відхиленні — відкат за 5 хвилин. — Інструкція з оновлення ядра на dev.1c-bitrix.ru

Які типові завдання вирішуємо в рамках техпідтримки?

Контент. Банери до «Чорної п'ятниці» — за день, тому що маркетолог згадав у четвер. Нова категорія з фільтрами через catalog.smart.filter. Лендінг під рекламну кампанію — з готових компонентів, без дизайнера, за 4-6 годин.

Функціонал. Поле «прикріпити файл» в form.result.new — 2 години. Форма запису на консультацію з інтеграцією в AmoCRM через webhook — 4-6 годин. Підключення JivoSite / Carrot Quest — 1-2 години.

Верстка. «Поїхав» блок на iPhone з Dynamic Island — Safari рендерить env(safe-area-inset-top) по-своєму. Оновили ядро Бітрікс — зламався CSS картки товару, тому що компонент catalog.element оновив HTML-структуру. Чинимо.

Інтеграції. Обмін з 1С: агент CAgent по catalog.import.1c впав по таймауту при 50 000 товарів — розбиваємо імпорт на пакети через STEP. API СДЕК оновився з v1.1 на v2 — переписуємо обробник sale.delivery.handler. Новий еквайринг — налаштовуємо sale.paysystem.handler.

Серверні. Перехід між мажорними версіями PHP: grep по deprecated (each(), create_function(), {$var} строковий доступ), фікс, тестування. SSL: certbot не продовжив — cron-задача не відпрацьовувала через зміну шляху до Python. DKIM/SPF/DMARC для поштового домену — щоб сповіщення про замовлення не потрапляли в спам.

Терміни та вартість

Параметр Старт Бізнес Профі
Годин / місяць до 5 до 15 до 40
Реакція 8 роб. годин 4 роб. години 1 година 24/7
Моніторинг Щотижневий Щоденний Real-time
Бекапи Щотижневі Щоденні Щоденні + інкрементальні
Оновлення ядра Щоквартально Щомісячно У міру виходу
Виділений менеджер Ні Так Так
Звіт Щомісячний Щомісячний Щомісячний + аналітика
Перенесення годин ні В межах кварталу В межах півріччя

Вартість розраховується індивідуально під обсяг завдань. Додаткові години за ставкою з договору. Можлива зміна пакету: підвищення — в будь-який момент, пониження — з початку наступного місяця. Нестандартні вимоги обговорюємо окремо. Зв'яжіться з нами — підберемо оптимальний варіант.

Екстрена підтримка — коли горить

Сайт ліг, оплата не проходить, виявлено злам.

  • Гаряча лінія — Telegram + телефон. Для преміум-клієнтів — виділений номер чергового інженера
  • Реакція від 15 хвилин на критичні інциденти
  • Поза чергою — критичні інциденти обробляються раніше поточних завдань, незалежно від залишку годин
  • Постмортем — після усунення фіксуємо, що зламалося, чому і як запобігти. Документуємо в базі знань проекту
Як передати проект від іншої команди? Беремо проекти будь-яких розробників. Починаємо з аудиту — «міни» є завжди. - Код: grep по `mysql_query` (так, і зараз зустрічається), несанкціоновані `eval()`, SQL без `ForSql()`, хардкод паролів в `init.php` - Інфраструктура: права на файли, конфігурація Nginx/Apache, налаштування PHP, схема деплою - Документація: збираємо архітектуру, нестандартні рішення, інтеграції - Доступи: сервер, хостинг, домен, DNS, платіжки, 1С — складаємо реєстр

Приймання — 3-5 робочих днів. Після нього — повноцінна підтримка.

Які бекапи і як часто? Залежно від тарифу: від щотижневих до щоденних + інкрементальні. Обов'язково перевіряємо відновлення на тестовому сервері раз на квартал.
Чи можна змінити тариф у процесі? Так. Підвищення — в будь-який момент, пониження — з початку наступного місяця.

Замовте техпідтримку зараз — отримайте первинний аудит в подарунок та гарантію безперебійної роботи вашого проекту на 1С-Бітрікс.