Инструкция для сборки статьи 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 может их обрезать.

Как KCS влияет на производительность агентов поддержки

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

09 июля 2026

Представьте руководителя поддержки, у которого на дашборде все в норме: SLA выполняется, обращения закрываются вовремя, CSAT держится на хорошем уровне. Он предлагает команде новую практику: каждый раз, решив обращение, добавлять готовое решение в базу знаний, чтобы в следующий раз подобный вопрос не пришлось разбирать с нуля. Реакция предсказуема: «Вы хотите, чтобы к каждому тикету мы добавляли еще одно действие? Тогда AHT* вырастет, а SLA* окажется под угрозой», - скажет команда.

Возражение звучит убедительно и у него есть основания. Ниже - детальный разбор процесса с метриками: сколько на самом деле стоит сохранение знаний, что компания получает взамен и как KCS ускоряет работу поддержки.

KCS* (Knowledge-Centered Service) - методология, при которой знания создаются и обновляются прямо в процессе обработки обращений. Узнать больше.
AHT* (Average Handle Time) - среднее время обработки обращения.
SLA* (Service Level Agreement) - это соглашение об уровне сервиса, определяющее стандарты, скорость и качество работы.

Сказка о потерянном времени

AHT - это среднее время обработки одного обращения, один из ключевых показателей нагрузки на команду техподдержки и SLA. Добавляем к работе над тикетом ещё один шаг - создание или привязку статьи. Логично, что время на обработку тикета растет.

AHT - полезная метрика, но в одиночку она обманчива: ее легко «улучшить» во вред делу, закрывая обращения быстрее за счет качества и роста переоткрытий тикетов.

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

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

KCS - это инвестиция

Внедрение методологии KCS правильнее рассматривать с точки зрения инвестиций. «Актив» здесь - база знаний, «вложение» — небольшая часть AHT, которую агент тратит на добавление статьи при решении обращения. Прибыль превышает вложение в разы:

*Согласно данным Consortium for Service Innovation

Цена вопроса: сколько стоит создать статью

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

1.  Скопировать тему обращения в название статьи.
2.  Скопировать исходный вопрос клиента в блок «Симптомы».
3.  Скопировать собственный ответ в блок «Решение».

Создание черновика статьи с нуля без ИИ

4. Или можно сгенерировать ответ с помощью ИИ-агента в один клик за пару секунд.

Создание черновика статьи с нуля с помощью ИИ

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

Арифметика AHT: минута вложений против ускорения решения обращений на 50–60%

Одна минута - это много или мало? Все зависит от поддерживаемого продукта и вашего текущего AHT.

Например, AHT равен 10 минутам. Тогда дополнительная минута - это +10% к времени обработки в моменте. Для SLA и для агента это ощутимо, спорить не будем. Но это вложение, а не потеря. Теперь посмотрим на возврат.
Даже если считать выгоду только по одному показателю — по AHT, — снижение времени работы над тикетом при внедренном KCS достигает 50–60%.
Кейс: вложили +1 минуту (+10%), получили −50–60%. Итоговое снижение AHT с учетом инвестиции — порядка 40–50%. То есть тикет, который занимал 10 минут, со временем решается за 5–6.

А если AHT измеряется не минутами, а десятками минут, часами или даже днями (такие продукты тоже есть), то одна минута на черновик - это статистическая погрешность. В этом случае почти весь эффект уходит в чистую прибыль: расход незаметен, а результат тот же. Чем сложнее поддерживаемый продукт и дороже обращения, тем выгоднее для компании внедрение KCS.

Поясним на втором примере. Пусть продукт сложный и среднее обращение разбирается два часа. Минута на черновик - это меньше 1% AHT, на грани измеримости. А снижение на 50–60% означает, что в зрелом состоянии такое обращение решается за 50–70 минут вместо двух часов. Инвестиция почти невидима, а отдача — максимальна.

Эффект маховика: откуда берется рост производительности

Откуда берётся снижение времени решения обращений на 50–60%? Изменения происходят из-за того, что меняется сам процесс работы:

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

Когда база знаний встроена в рабочий процесс, агент опирается не на память коллег, а на накопленный опыт всей компании. Это дает сразу несколько точек роста производительности:

• меньше повторной работы - одинаковые вопросы не решаются по второму, третьему, десятому разу. Требуется лишь проверить наличие подобного обращения, скопировать ответ и отправить клиенту;
• быстрее поиск - чтобы найти статью не нужно покидать хелпдеск - релевантная статья под рукой. Экономия времени на переключение между инструментами также экономит время. По статистике, 1-5 часов в день агенты тратят на поиск информации и переключаются между экранами для поиска;
• меньше зависимости от «носителей знаний» — знания перестают жить в голове ключевого агента, экспертиза команды накапливается и доступна всем;
• быстрый онбординг - новичку есть на что опереться: агент с 2-недельным стажем обладает той же экспертизой, что и агент с 2-летним стажем;
• снижение нагрузки на команду - полезная база знаний позволяет клиентам самостоятельно решать простые вопросы, не обращаясь к агентам.

Производительность - это не только скорость

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

KCS разрывает его: знание остаются в базе знаний, а не в голове агентов, поэтому уход человека не повлияет на качество поддержки. Снижается текучка — растет уровень экспертизы в команде, и это тоже производительность, просто в более длинном горизонте.

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

Как не потерять инвестицию на старте

Инвестиция в KCS проваливается в одном предсказуемом сценарии — когда фиксация знаний оторвана от процессов. Несколько вещей держат расход маленьким, а отдачу — реальной:
•  Фиксировать знание в момент решения, а не «в конце дня».
Отложенная статья либо не пишется вовсе, либо пишется по памяти и теряет точность.
•  Не требовать «идеальных» статей.
Черновик из трех скопированных блоков полезнее гипотетической статьи, которая так и не была написана. Качество дорабатывается по мере переиспользования: востребованные статьи улучшаются, невостребованные отмирают.
•  Измерять переиспользование, а не количество статей.
Ценность создает не объем базы знаний, а то, как часто из нее берут готовые решения.
•  Встроить процесс в инструмент.
Если статья создается в одном окне с тикетом за несколько кликов — это ускоряет процесс и повышает мотивацию агентов.

Почему все решает инструмент: подход Swarmica

Вся эта арифметика работает при одном условии: фиксация знания должна стоить агенту секунды, а не минуты. Если для создания статьи нужно выйти из тикета, открыть отдельную систему и оформить материал «по правилам», инвестиция перестает быть маленькой — и сопротивление команды оправданно.

Поэтому внедрить KCS проще и быстрее, когда методология заложена в механику инструмента, а не существует обособленным модулем. Swarmica построена вокруг KCS: решая обращение, агент получает подсказку создать или дополнить статью прямо в окне работы — те самые несколько кликов. Одна база знаний из единого источника питает агентов, клиентский self-service и ИИ-ассистента.

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

Посчитайте эффект на своих цифрах
Оценим ваш текущий AHT и FCR и покажем, какой эффект даст использование KCS после первых 3 месяцев.

Получить консультацию эксперта

Часто задаваемые вопросы (FAQ)