Управление знаниями
Хелпдеск
Поддержка
Тарифы
Бизнесу
Управление знаниями
Конструктор отчетов
Управление персоналом
Корпоративный поиск
AI
Хелпдеск
Поддержка
Тарифы
Бизнесу
Управление знаниями
Конструктор отчетов
Управление персоналом
Корпоративный поиск
AI
Хелпдеск
Гибкие автоматизации
Интеграции и API
Конструктор отчётов
ИИ Ассистент
Ключевые преимущества
Хелпдеск
Настройки cookie
Технические — всегда включены
Аналитические (Яндекс.Метрика)
Маркетинговые (VK Pixel)
Инструкция для сборки статьи SWARMICA Статья собирается из готовых блоков в библиотеке Tilda. Добавить блок можно так: «+» → «Мои блоки» → выбрать нужный блок из набора «Статья». Блоки можно копировать, переставлять, редактировать и удалять. Главное - не смешивать зоны статьи между собой и не менять технические настройки блоков, если они уже заданы. Общая структура страницы Страница статьи состоит из 5 зон: Верх статьи Лид-абзац Основная часть статьи Финальное завершение статьи CTA в конце статьи 1. Верх статьи В верхней зоне должны быть только блоки, которые относятся к началу статьи: ME605 Статья: хлебные крошки Навигация над статьёй. Ставится самым первым блоком. TL01 Статья: заголовок H1 и прочее Главный заголовок статьи. В этом блоке должен быть только H1. Описание / подзаголовок теперь выносится отдельно в лид-абзац. TX01 Статья: дата публикации Дата статьи. Ставится под H1. TX01 Статья: время чтения Время чтения. Ставится рядом с датой публикации. IM01 Статья: обложка Главная обложка статьи. Правильный порядок верхней зоны: ME605 Статья: хлебные крошки TL01 Статья: заголовок H1 и прочее TX01 Статья: дата публикации TX01 Статья: время чтения IM01 Статья: обложка Важно: в верхнюю зону не добавляем обычные текстовые блоки, H2, кнопки, выделения и CTA. 2. Лид-абзац TX01 Статья: лид-абзац Короткое вступление после hero-блока. Это первый смысловой абзац статьи. Лид-абзац не должен быть внутри H1-блока. Он стоит отдельно перед основной частью статьи. 3. Основная часть статьи В этой зоне собирается сам материал. Эти блоки можно копировать, переставлять и использовать несколько раз. TL01 Статья: заголовок 2-уровня H2 Заголовок раздела. TX01 Статья: текстовый блок Обычный текст статьи. TX01 Статья: фраза с выделением Важная мысль, вывод, предупреждение или смысловая врезка. TX01 Статья: подпись к изображению Подпись под изображением. Ставится сразу после изображения. CR47 Статья: кнопка для прочего Одиночная кнопка внутри статьи. Используется для перелинковки, перехода к кейсу, демо, чек-листу или другому материалу. Если в статье есть изображение внутри текста, используйте соответствующий блок изображения из библиотеки и сразу после него ставьте подпись. Пример структуры основной части: TX01 Статья: лид-абзац TL01 Статья: заголовок 2-уровня H2 TX01 Статья: текстовый блок TX01 Статья: фраза с выделением TX01 Статья: текстовый блок CR47 Статья: кнопка для прочего TX01 Статья: текстовый блок 4. Финальное завершение статьи Каждую статью важно замыкать финальными блоками. Они отделяют вывод от основной части и помогают шаблону корректно завершить материал. TL01 Статья: финальный заголовок H2 Финальный заголовок. Например: «Что в итоге», «Вывод», «Что делать дальше». TX01 Статья: финальный текстовый блок Заключительный текст статьи. После финального заголовка и финального текста не стоит добавлять новые обычные H2-разделы. Если статью нужно продолжить, лучше перенести финальные блоки ниже. 5. CTA в конце статьи После финальных блоков ставится призыв к действию: CR47 Статья: призыв к действию в конце Это отдельный финальный CTA. Его не нужно путать с блоком «CR47 Статья: кнопка для прочего». Разница: CR47 Статья: кнопка для прочего - обычная кнопка внутри статьи. CR47 Статья: призыв к действию в конце - большой финальный CTA после статьи. Короткая правильная схема статьи ME605 Статья: хлебные крошки TL01 Статья: заголовок H1 и прочее TX01 Статья: дата публикации TX01 Статья: время чтения IM01 Статья: обложка TX01 Статья: лид-абзац TL01 Статья: заголовок 2-уровня H2 TX01 Статья: текстовый блок Дополнительные блоки основной части при необходимости TL01 Статья: финальный заголовок H2 TX01 Статья: финальный текстовый блок CR47 Статья: призыв к действию в конце Что можно делать Можно копировать блоки основной части статьи. Можно менять порядок блоков внутри основной части. Можно добавлять несколько H2, текстовых блоков, подписей, выделений и кнопок. Можно редактировать текст, ссылки, изображения, подписи и кнопки. Что важно не делать Не смешивать блоки верхней зоны с блоками основной части. Не ставить обычные H2 и текстовые блоки выше хлебных крошек. Не писать лид-абзац внутри H1-блока. Не использовать финальный CTA как обычную кнопку внутри статьи. Не использовать обычную кнопку внутри статьи как финальный CTA. Не оставлять статью без финального заголовка и финального текстового блока. Не менять CSS name блоков, если он уже задан. Не использовать длинные CSS name: Tilda может их обрезать.

CSAT 97%: как UserGate превратила поддержку в управляемую систему

UserGate отказались от устаревшей системы технической поддержки Kayako в пользу SWARMICA — платформы, объединяющей продуктовую поддержку, базу знаний и ИИ в единой платформе. Результат: входящий поток обращений сократился на 21%, онбординг новых агентов ускорился в 4 раза, CSAT стабилизировался на уровне 97%.
29 июня 2026
«SWARMICA позволила нам перейти от хаотичной обработки тикетов к системному управлению знаниями. Теперь обучение новых инженеров занимает считанные недели, а база знаний реально работает на сокращение нагрузки.»

— Дмитрий Ошкуков, руководитель технической поддержки UserGate

О компании

UserGate — российский разработчик программного обеспечения в области информационной безопасности.

Контекст: поддержка перестала справляться с ростом

До перехода на Swarmica UserGate использовала хэлпдеск Kayako. Она решала базовую задачу: принимать тикеты и распределять их по агентам. Но по мере роста клиентской базы этого стало недостаточно: в системе не было инструментов для работы со знаниями, автоматизации и аналитики. Каждое обращение обрабатывалось вручную, а накопленный опыт инженеров никуда не сохранялся. Это проявилось в системных проблемах:
·   Онбординг нового инженера занимал до 12 месяцев до полной самостоятельности
·   Знания хранились в головах конкретных специалистов
·   База знаний создавалась техническими писателями отдельно от поддержки — быстро устаревала
·   Повторяющиеся обращения перегружали команду
·   Среднее время решения заявки составляло 7 дней 

Масштабирование команды приводило к росту затрат, а не эффективности.

Решение: единый контур поддержки на базе SWARMICA

  • KCS-подход к базе знаний
Знания создаются в процессе обработки обращений и переиспользуются. Статьи имеют два слоя: внешний — публикуется и индексируется в поисковых системах, внутренний — только для инженеров, с техническими деталями, не предназначенными для клиентов.
  • Интеллектуальная обработка обращений
Автоматическая классификация и маршрутизация сократили время первого ответа с 1 часа до 15 минут.
  • Единое рабочее пространство
Инженер видит полный контекст клиента сразу при открытии заявки.
  • Интеграции с инфраструктурой
CRM, SSO, лицензирование и внутренние системы объединены в один контекст.
  • On-premise
Соответствие всем требованиям требованиям информационной безопасности без компромиссов.
  • ИИ-ассистент
Ускоряет поиск нужных статей и сокращает время ответа клиентам при срочных обращениях.

Как проходило внедрение

Внедрение прошло в три этапа без остановки работы поддержки.

Этап 1 — Миграция и настройка
Перенесли существующую историю обращений из Kayako в SWARMICA, настроили интеграции с CRM, SSO и системой лицензирования. Параллельно развернули on-premise инфраструктуру согласно требованиям ИБ.

Этап 2 — Запуск KCS и формирование базы знаний 
Команду обучили KCS-методологии: инженеры начали создавать статьи прямо в процессе решения обращений, а не после. Первые статьи сформировали ядро базы знаний на реальных кейсах.

Этап 3 — Стабилизация и масштабирование
После накопления критической массы статей новые инженеры начали закрывать обращения, опираясь исключительно на базу знаний. Показательный пример: новый инженер закрыл обращение за 20 минут, не обращаясь к коллегам. Постепенно часть клиентов перешла на самообслуживание через публичный слой базы знаний.

Ключевой эффект для бизнеса

Поддержка перестала быть узким местом и стала управляемой функцией с измеримыми результатами:

Поддержка работает на удержание клиентов
Среднее время решения сократилось с 7 до 5 дней, время первого ответа — с часа до 15 минут. Это напрямую влияет на лояльность в сегменте B2B, где скорость реакции критична.

База знаний, как актив
Раньше экспертиза уходила вместе с людьми. Теперь каждое решенное обращение пополняет базу, которая работает на всю команду. Новый инженер выходит на самостоятельную работу за 3 месяца вместо 12 — без наставников и дополнительного обучения.

Масштабирование без роста затрат
21% входящих обращений закрывается через самообслуживание — клиенты находят ответы без обращения в поддержку. Рост клиентской базы больше не требует пропорционального найма команды.

Качество не зависит от конкретного инженера 
CSAT 97% — не результат работы лучших специалистов, а следствие того, что правильный ответ доступен каждому в команде при открытии любой заявки.

KCS (Knowledge-Centered Service) — методология, при которой знания создаются и обновляются прямо в процессе обработки обращений.
CSAT — показатель удовлетворенности пользователей после обращения.