Настройки 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 может их обрезать.

Как понять, что пора менять хелпдеск

Вопрос «менять или не менять хелпдеск» обычно откладывают: система вроде бы работает, тикеты вроде бы закрываются, клиенты вроде бы довольны. Ограничения текущей системы техподдержки редко проявляются, как сбой, и обычно незаметны без глубинного анализа. Чаще всего - это выработанный набор обходных решений, встроившихся в процессы: выгрузки в Excel, ручные сверки, костыльная автоматизация, собранная в обход ограничений системы. Все работает до первой нестандартной ситуации: аудита, требований ИБ или крупного клиента с собственными условиями по SLA.
24 августа 2026
Время на чтение 6 минут
Чаще ограничения проявляются незаметно: метрики потихоньку перестают расти. И объяснение этому почти всегда ищут в команде: ужесточают KPI по времени ответа, вводят нормы по количеству тикетов на агента, усиливают контроль. Какое-то время это работает: показатели действительно улучшаются. Затем начинается текучка кадров, а вместе с новыми людьми возвращаются прежние цифры — только теперь к ним добавляются расходы на подбор персонала и онбординг.

Причина в том, что предел производительности может быть не связан с командой. Иногда дело в инструментах, которые тормозят процессы: интерфейс, в котором каждое действие требует лишних кликов, три системы вместо одной с необходимостью переключения между ними, кастомные отчеты для топ-менеджмента, которых нет. Прежде чем поднимать планку людям, стоит оценить инструменты.

Как понять, что пора менять хелпдеск

За последние годы функционал хелпдесков почти сравнялся: автоматизация, SLA-политики, ИИ-агенты есть практически у всех.
Сравнение функционала популярных хелпдесков.
Поэтому если посмотреть на таблицы сравнения, хелпдески на первый взгляд мало чем отличаются друг от друга. И это усложняет выбор. Как и всегда есть нюансы. Посмотреть детальное сравнение коробочных хелпдесков.

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

Пять признаков, что ваш хелпдеск ограничивает техподдержку

  1. Поддержка управляется вручную, а не системой
Признаки:
  • заявки распределяются руками;
  • руководитель сам проверяет, кто чем занят;
  • SLA контролируется в голове, таблицах или постфактум;
  • обращения перекидываются между людьми без прозрачности;
  • часть задач теряется в почте, чатах, Jira, Telegram, Битриксе.
Процессы держатся не на системе, а на людях. Пока команда маленькая и поток обращений небольшой — это работает. Но с ростом объёма ручное управление становится узким местом: нагрузка распределяется неравномерно, сроки срываются незаметно, а часть обращений просто не доходит до исполнителя. Руководитель вместо развития поддержки занимается распределением обращений, а качество сервиса зависит от того, кто сегодня на смене и насколько он внимателен.
2. Агенты работают одновременно в нескольких системах

Признаки:
  • интеграции с Jira/YouTrack/Yandex Tracker/CRM/биллингом сделаны костылями;
  • API недостаточно гибкий;
  • Telegram, почта, портал, веб-чат и внутренние системы существуют разрозненно.

Тикеты в одной системе, база знаний в другой, данные клиента в CRM. Согласно статистике, на переключение между инструментами уходит до 40% рабочего времени сотрудника поддержки. Это вопрос архитектуры рабочего места, а не мотивации агентов. Умножьте эти проценты на ФОТ поддержки — получится первая статья в расчете стоимости бездействия.
3. Нужного отчета нет и собрать его негде. Руководитель не видит реальную картину событий.

Признаки:
  • отчеты собираются вручную в Excel;
  • непонятно, сколько обращений в работе;
  • сложно понять нагрузку по агентам;
  • нет нормальной картины по SLA;
  • нельзя быстро увидеть проблемные продукты, клиентов, каналы;
  • руководитель узнает о проблемах только после эскалаций.

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

Признаки:
  • база знаний в Notion, Confluence, Google Docs или вообще в головах сотрудников;
  • агенты редко используют статьи при ответе;
  • новые знания не создаются из обращений;
  • повторяющиеся вопросы решаются заново;
  • статьи устаревают, но никто не понимает какие;
  • нет связи “обращение → статья → повторное использование”.

Самый недооцененный признак и самый дорогой, если вы планируете внедрять ИИ. Языковая модель отвечает клиентам на основе информации, которую в нее загрузили: базы знаний, тикетов, переписок. Если база знаний пустая устаревшая, ИИ будет выдавать неправильные ответы. Это в свою очередь увеличит количество эскалаций и, как следствие, затраты. И логичную потерю лояльности клиентов.
5. Поддержка не встроена в CJM

Признаки:
  • нужен личный кабинет, но helpdesk живет отдельно;
  • клиентам приходится переходить в другой интерфейс;
  • невозможно нормально связать тикет с продуктом, клиентом, задачей разработки;

Пользователь уходит из продукта, чтобы задать вопрос, и по дороге теряется. Формально API есть почти у любого хелпдеска, но собрать на нём нативный опыт внутри приложения могут единицы — для этого система должна быть API-first, а не порталом с интеграциями поверх.

Самописные хелпдески: когда экономия заканчивается

Аргумент «свое решение дешевле готового» верен до тех пор, пока не подсчитаны доработки и поддержка на 5 лет вперед.

Три вопроса, на которые стоит ответить:
  • как часто вы дорабатываете систему;
  • сколько эти доработки стоят в человеко-часах;
  • сколько времени вы ждете новой интеграции или фичи.

Прямо сейчас ваша самописная система идеально удовлетворяет потребности бизнес. Но что будет с ней через пару лет? Рынок не стоит на месте: мессенджеры меняют API, появляются новые каналы обращений, партнеры требуют интеграций, которых год назад не существовало. К этому добавляются требования регуляторов и новые законы о защите информации. Каждое такое изменение для коробочного продукта — обновление, которое выкатывает вендор. Для самописной системы — задача в вашем бэклоге, которая конкурирует за ресурс с продуктовой разработкой. И проигрывает ей почти всегда, потому что поддержка — это не то, на чем компания зарабатывает.

В итоге система не ломается — она просто отстает. Сначала на одну интеграцию, потом на автоматизацию, которую конкуренты уже внедрили, потом на ИИ-фичи. Разрыв копится незаметно и догонять всегда стоит дороже. Посмотреть сравнение стоимости самописных хелпдесков и коробочных решений.

Опенсорсные хелпдески: иллюзия кастомизации

Аргумент «open source бесплатный» верен ровно до строчки «лицензия». Дальше начинается бюджет. В среднем, “бесплатный” open source оплачивается зарплатами пяти специалистов: администратор БД, фронтенд, бэкенд, тестироващик, devops.
Опенсорс дает свободу — свой сервер, открытый код, любые доработки. Но вместе со свободой он отдаёт вам и всю ответственность.

У вендора есть SLA, дорожная карта и обязательства; у сообщества есть только добрая воля. Обновление, которое коробочный продукт выкатывает вам сам, здесь превращается в задачу: проверить совместимость, не сломать свои доработки, обновить форк. И чем глубже вы допилили систему под себя, тем дороже обойдется каждое обновление. В какой-то момент проще остаться на старой версии, чем обновляться.

Но выбор не сводится к «все или ничего». Зрелые вендоры давно поняли, почему люди уходят в опенсорс, и отдали кастомизацию наружу — только не на уровне исходников, а на уровне прикладной логики. Ядро — маршрутизация, права, база знаний, интеграционный слой — развивает и обновляет вендор, вы его не трогаете.

А все, что специфично именно для вашей компании, настраивается средствами самого хелпдеска: триггеры, правила, плагины, скрипты.
Например, в Swarmica это Python-скрипты: свои проверки при переводе тикета, обращения во внешнюю систему, автоматическое заполнение полей из вашей учетной записи, нестандартный расчет SLA — то, ради чего в опенсорсе пришлось бы лезть в код и потом тащить эти правки через каждое обновление. Свобода та же, счет за нее — другой.

Как выбрать хелпдеск

Если решение о смене хелпдеска принято, порядок действий до выбора вендора выглядит так:

Получите от команды ИБ список требований и отправьте вендору: где хранятся данные, куда передаются, какие варианты установки доступны, что использует ИИ, работают ли ИИ-функции внутри вашего контура или обращаются во внешний API. Отдельно уточните, что из этого входит в базовую лицензию.

Попросите провести демо на своих данных. Демо-стенд вендора обычно идеален: клиенты задают четкие вопросы, у поддержки готов ответ. В реальности у вас тысячи обращений с вложениями, где клиент описывает проблему одним образом, а причина в другом. Сценарий должен отрабатывать на ваших данных, а не на подготовленных.

Попросите показать сценарий миграции. Что произойдет с историей обращений, вложениями и ссылками, которые уже отправлены клиентам. Что переедет, а что нет — это нужно понимать до выбора, а не после. Как проходит миграция с одного хелпдеска на другой.

Дайте вендору список из нужных изменений, которые вы планируете внедрить в ближайший квартал. И спросите: какие из них команда сможет настроить сама в интерфейсе, какие потребуют участия вендора и сколько это будет стоить. Ответ покажет реальную стоимость владения точнее, а не прайс-лист на сайте.

Спросите SLA собственной поддержки вендора. Вы покупаете систему для поддержки, поэтому логично узнать, как устроена поддержка у того, кто ее продает. Это один из показателей зрелости вендора.

Сохраните привычный клиенту CJM. Если новая система не поддерживает канал, через который клиенты приходят к вам за поддержкой. Хорошая миграция — та, которую конечный ваш клиент не заметил.

Как понять, что пора меня хелпдеск: вывод

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

Если стоимость бездействия ниже стоимости миграции, разумно остаться и точечно закрывать узкие места. Если выше — смена системы окупается, и разговор с руководством строится не вокруг функций, а вокруг экономии рабочих часов и управляемых метрик.

Превратите техподдержку в драйвер роста бизнеса и повышения лояльности клиентов.
Получить консультацию эксперта
Часто задаваемые вопросы (FAQ)