У многих компаний уже есть практически всё, чтобы внедрить полноценное обучение сотрудников после приема на работу (онбординг) или освоения нового продукта: база знаний с рабочими статьями на внутренней платформе для совместной работы и АИС по клиентам. Они могут быть интегрированы между собой или существовать отдельно — на конечный результат это влияет мало. Для полного счастья остается только сделать семейство обучающих курсов — а до этого руки доходят хорошо если через один год.
Причина банальна: большинство курсов в корпоративных базах знаний либо надо делать отдельно от всего, либо там же, но создавая контент заново. Есть ли альтернатива такому подходу? Ну разумеется, и подобный подход реализует не одна российская платформа для совместной работы и управления знаниями.
В этой статье разберёмся, как превратить уже существующую базу знаний в полноценный курс — без методиста, копирайтера и полугодового согласования. Пойдём по шагам: от понимания, зачем вообще нужен курс, до настройки тестов, дедлайнов и статусов прохождения.
Всем привет. На связи вновь Вячеслав Зыкин, экс-начальник службы поддержки в системном интеграторе с двадцатипятилетним опытом. Скажу честно: у нас тоже не дошли руки до обучающих курсов. Но в планах есть, и даже понятно, как это сделать. Соображения по этому поводу — в статье.
Почему классическое обучение для поддержки не работает
Классический подход к обучению поддержки выглядит так:
пишем «учебник по продукту»;
читаем вводные лекции;
даём универсальный курс где-то на внешней системе обучения;
выпускаем новичка в боевую смену.
У этого сценария сразу несколько проблем.
Курсы учат идеальным сценариям. В учебных материалах всё работает по инструкции, а реальность поддержки — это целый букет: «падает» личный кабинет, клиент не может объяснить проблему, в продукте появился новый тариф, а схему подключения не обновили и приходится менять его клиентам в ручном режиме. Курсы почти не покрывают такие комплексные случаи.
Учебник устаревает быстрее, чем дописывается. Продукт живой: выходят релизы, меняются цены, добавляются интеграции, новый специалист по сценариям использования (UX-дизайнер) переделывает привычный уже интерфейс. Любой статичный учебник превращается в архив уже через пару месяцев, а обновлять его сложнее, чем саму базу знаний.
Возникает разрыв между теорией и практикой. Новичок отлично знает, где какая кнопка на тестовом контуре, который последний раз обновляли год назад, но не может найти её на боевом контуре с последними обновлениями. Он помнит теорию, но не знает, какие именно статьи открыть, чтобы быстро найти решение.
Если в компании уже есть база знаний, то учебник у вас уже написан. Это та самая «инструкция к продукту», которая постоянно живёт и обновляется. Логичный вопрос: зачем писать отдельный учебник, если можно научить человека работать именно с базой знаний и реальными сценариями?
В этой парадигме рассуждала команда Teamly, когда внедряла в платформу для совместной работы и управления знаниями механизм создания и прохождения курсов.
Задача обучающего курса на Teamly — не продублировать техническую документацию, а провести новичка по ключевым блокам знаний и продукте, научить ориентироваться в статьях и закрепить это через практику и тесты.
Что у нас уже есть: база знаний и корпоративная платформа
У типичного отдела поддержки есть:
внутренняя база знаний с инструкциями, схемами и ответами на повторяющиеся вопросы;
корпоративная платформа: почта, мессенджер, система обработки обращений, АИС по клиентам, она же CRM и т.п. — и это всё может быть в разных программах безо всякой интеграции (гордое слово «платформа» при этом означает стандартный набор приложений на компьютерах и рабочих мобильных устройствах);
опыт действующих сотрудников — реальные случаи, переписка с клиентами при решении обращений, «советы бывалых» — лучшие практики.
Этого вполне достаточно, чтобы собрать работающий курс. В компании не нужна отдельная «учебная вселенная» — можно просто наложить структуру обучения на имеющуюся в БЗ информацию:
выбрать, какие статьи и разделы нужны новичку в первую очередь;
связать их в логическую цепочку;
добавить пояснения и короткие задания-тесты;
объединить в курс.
Какие материалы нужны новому сотруднику поддержки
Ситуация: стажер проходит аттестацию и получает первую должность — оператор службы поддержки. Что он должен знать, впервые выходя на линию консультаций?
Его предполагаемые знания обычно делят на несколько тематических блоков.
О компании и продукте.
чем занимается компания;
кто её клиенты;
каковы основные сценарии использования продукта.
Базовая ориентация в продукте.
разделы интерфейса;
основные сущности: проекты, заказы, пользователи и т.п.
Инструменты поддержки.
какие каналы обращения: почта, чат, телефон, системы регистрации обращений (хелпдеск, сервисдеск);
где можно вести переписку с клиентами, а где — с коллегами;
как фиксировать результат обращения в корпоративной системе;
как пользоваться скриптами;
Типовые вопросы клиентов.
регистрация и вход;
оплата и возвраты;
ошибки и сбои;
вопросы по тарифам.
Работа с программными ошибками и нестандартными ситуациями.
как отличить ошибку продукта от ошибочного ожидания клиента;
что говорить клиенту, пока проблема решается.
Тон общения и правила.
пример фирменного стиля общения;
что можно и нельзя обещать.
Процессы и метрики.
как считается нагрузка;
какие цели по времени ответа и качеству;
что влияет на оценку работы.
Обычно каждый из этих блоков уже полностью или частично описан в базе знаний: есть статьи по продукту, инструкции по работе в системах, регламенты, примерные ответы, скрипты поддержки и т.д.
Задача — не переписать их, а упорядочить и выдать новичку порциями, добавив пояснения и проверку понимания через тесты на платформе Teamly.
Структурирование курса по ��тапам
Курсы для новичков проще всего разбить на несколько этапов, которые соответствуют первой неделе работы. Спойлер: на этом курсы не закончатся.
Этап 1. Вводный день
Цель: дать общее представление о компании, продукте и подходе к поддержке.
Краткий блок о компании и продукте.
Обзор каналов поддержки.
Правила общения и принятый в компании тон коммуникаций.
Этап 2. Продукт и база знаний
Цель: научить человека пользоваться базой знаний, а не держать всё в голове.
Ссылки на ключевые разделы базы.
Упражнения: «найди статью, которая отвечает на такой-то вопрос».
Разбор пары типовых сценариев обращения к БЗ вместе с наставником.
Использование ИИ-ассистента, область поиска.
Этап 3. Типовые обращения
Цель: познакомить с самыми частыми запросами и научить быстро находить ответы.
Блоки по темам: регистрация, оплата, доступ, ошибки.
Мини‑кейсы: «Клиент пишет… Что ты сделаешь? Как будешь искать ответы и решения в БЗ?».
Этап 4. Программные ошибки и сложные клиенты
Цель: показать, как действовать, когда «по инструкции» не получается.
Примеры реальных программных ошибок и пути их обработки.
Шаги эскалации разработчикам.
Сценарии общения с недовольным клиентом.
Этап 5. Закрепление и проверка
Цель: убедиться, что человек не только прочитал статьи, но и умеет ими пользоваться.
Итоговый тест в Teamly по блокам.
Проверка умения искать ответ в базе знаний.
Назначение следующих курсов или модулей для углубления.
Такую структуру легко перенести в курс: каждый этап = раздел курса, внутри — уроки и материалы.
Проектирование курса в Teamly
Рассмотрим, как собрать один курс — например, «Личный кабинет сотрудника».
Курсы в Teamly устроены таким образом:
на верхнем уровне модули;
в модули включены уроки и тесты.
Тест — элемент необязательный, но желательный. Типичная структура курса: один или несколько модулей по нескольку уроков и одному тесту в каждом. Так проще следить за прохождением курса.
Ниже — пошаговый план создания курса.
Шаг 1. Намечаем структуру курса
Для этого совсем не обязательно брать в руки карандаш и бумагу или рисовать на магнитно-маркерной доске.
Шаг 2. Создаём пустой курс
В управлении курсами добавляем новый курс. Оформляем:
название и назначение;
обложка.
В настройках задаётся предположительная продолжительность курса в днях. Учитывать ли при этом загруженность сотрудников или нет — дело каждой компании и каждого курса. В описании можно указать, например, «1 час в день, 3 дня»
Шаг 3. Создаём модуль
Модуль — это «контейнер», часть курса. В сущности, это такая же статья БЗ, как и все другие, которую назначили быть родительской для статей — уроков. У модуля нет текста, только название.
Шаг 4. Создаём уроки внутри модуля
Урок — это тоже статья базы знаний. Она может содержать текст, статьи базы знаний, списки и даже файлы.
Основное содержимое — всё же статьи, текст используется исключительно для связок и не может содержать информацию, подверженную изменениям.
Визуально статья БЗ вставляется в урок полностью. Но это только отображение — при изменении статьи в самой БЗ, в уроке тут же отобразится новая версия. Это называется термином «переиспользование статей».
Список на ознакомление — это тоже ссылка/ссылки, но на отдельную сущность БЗ. Такие списки создаёт администратор БЗ, включая в него любые сущности базы знаний.
Урок может состоять из нескольких статей, списков и связывающих их текстов в виде блоков, как в любой другой статье. Менять порядок материалов удобно, перетаскивая их за шесть точек в левом верхнем углу.
О тексте: в его оформлении можно применять практически весь арсенал обычного редактора Teamly — это недавнее нововведение.
Шаг 5. Создаём тесты
Логично завершать урок проверкой знаний, которые после него остались. На этапе создания тестов очень пригождается ИИ-ассистент Teamly, который умеет выделить из курсов главное и сформировать вопросы буквально за пару минут: Как искусственный интеллект меняет корпоративное обучение: тест за одну минуту.
Итог
Возвращаясь к запланированному:
Курс состоит из двух материалов.
Каждый материал содержит в себе несколько уроков, завершающихся тестами.
Как говорится, что ещё нужно для счастья? Только успешного прохождения.
Управление курсом: дедлайны, статусы и настройки
Когда курс собран, важно не только назначить его сотрудникам, но и управлять сроками и прохождением. Здесь Teamly помогает несколькими возможностями.
Назначение сотрудникам
Ролевая модель доступа Teamly даёт возможность назначать курсы сразу отделу, группе или отдельному человеку.
Срок прохождения автор обозначил в 3 дня, но администратор может назначить свои дедлайны.
Дедлайны и блок по срокам
При назначении курса можно указать количество дней на прохождение — оно не обязательно должно совпадать с указанным в курсе. Если администратор задаёт такой срок, в курсе появляется специальный блок с отображением дедлайна.
Сотрудник видит, сколько времени осталось, а руководитель — где риски срыва сроков.
Это дисциплинирует прохождение: курс перестаёт быть «когда‑нибудь потом» и превращается в понятную задачу с конкретной датой.
Порядок отображения курсов для сотрудника
Во вкладке «Мои курсы» порядок выстраивается автоматически по статусам:
в процессе;
не начат;
завершён;
просрочен.
Так сотрудник сразу видит, чем нужно заняться в первую очередь, а что уже закрыто. Для отдела поддержки, где параллельно могут идти несколько курсов (начальный, новый функционал, обновление регламентов), такой порядок экономит время и снижает «визуальный шум».
Быстрый доступ к настройкам курса
Работать с курсами удобнее, когда к управлению можно перейти напрямую из места, где вы сейчас находитесь. В Teamly добавлена кнопка перехода к настройкам во вкладках «Мои курсы» и «Библиотека курсов», а также на детальной странице курса.
Это значит, что администратору не нужно каждый раз переключаться на отдельную вкладку «Управление курсами», чтобы отредактировать содержимое, сменить дедлайн или переназначить курс — достаточно одного клика из того раздела, где он сейчас работает.
Итог: курс как «надстройка» над базой знаний, а не отдельная вселенная
Курс для отдела поддержки не должен превращаться в параллельный мир, живущий по своим правилам. Гораздо эффективнее сделать его надстройкой над тем, что уже работает: базой знаний и реальной практикой общения с клиентами.
Teamly помогает сделать это без лишней бюрократии: визуальный редактор, перемещение блоков «шестью точками», загрузка файлов — например, видео — и изображений, быстрый переход к исходным статьям, тесты с выбором типа вопросов, дедлайны, понятные статусы прохождения — всё это складывается в инструмент, который может применять не только методист (честно, у кого-то есть методисты в штате?), но и руководитель поддержки или опытный сотрудник.
