Как самому создать базу знаний поддержки. Даём инструкцию

Современная служба поддержки не может работать без нормальной базы знаний. Гугл-документы, записи в блокнотах и устное народное творчество «старичков» не в счёт. Как собрать разрозненные знания не просто в кучку, а в стройную структуру и не потратить на это 100 лет — в нашей статье.

Привет! Это команда TEAMLY — платформы для совместной работы и управления знаниями.

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

Эту историю рассказал нам Олег — исполнительный директор мультибрендового интернет-магазина туристического снаряжения и сопутствующих товаров «Турторг» (название изменено по просьбе владельцев). Ему слово.

Мы продаём снаряжение через свой интернет-магазин и маркетплейсы. У нас есть служба поддержки на удалёнке, которая помогает при затруднениях на портале, а также мониторит МП на предмет вопросов и отзывов, даёт обратную связь. Руководит ребятами из офиса «играющий тренер» — один из наиболее опытных сотрудников, который сам тоже работает — в основном разруливает нестандартные ситуации, но и берёт первичные обращения покупателей.

Чтобы ускорить ответы на типовые вопросы клиентов, мы сначала собирали алгоритмы — инструкции для покупателей — и скрипты — инструкции для поддержки — в одном гуглодоке с общим доступом. Но когда число статей перевалило всего лишь за 20 штук, поиск стал занимать слишком много времени. Вопрос о базе знаний встал в полный рост. И мы начали выбирать.

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

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

Это только базовый набор требований. Мы составили его, успокоились и перешли к выбору платформы реализации. Оказалось, что успокоились мы рано.

Руководитель поддержки и руководитель айтишников (CTO — chief technical officer) начали параллельный поиск. Читали профильные статьи, изучали сайты приложений и сервисов. С результатами исследований пришли на совещание с привлечением исполнительного директора в качестве арбитра.

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

Перечислим критерии, по которым выбирал он.

Программа или сервис?

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

Недостатки программы = достоинства сервиса. Работа в браузере не предполагает установки дополнительного софта, в том числе и на смартфон. Есть удобное приложение? Отлично. Нет? Никто не заплачет.

Таким образом отсеяли программы.

Собственный сервер или подписка?

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

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

Прикинули риски, посчитали деньги. Остановились на сервисе.

Визуальный редактор или непонятная разметка? Категории или атрибуты?

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

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

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

Визуальный редактор, в который можно вставлять картинки через буфер обмена, просто в разы удобнее. Привычный интерфейс форматирования текста, заголовки, автоматическая нумерация в списках — всё это давно работает в базах знаний, ориентированных на пользователя. И с категориями в большинстве решений работать гораздо проще. Особенно в простых БЗ — всё делается визуально, что очень облегчает создание статей.

На самом деле все три участника уже определились с сервисом к этому времени — и это был TEAMLY. Потому что просто повычёркивали остальные. Но сделали последний шаг.

Олдскульные адепты канбанов говорят о том, что доска должна быть не электронной, а материальной. Когда ты руками отклеиваешь стикер из одной колонки и приклеиваешь в другую, твоё физическое тело даёт сигнал мозгу о том, что пора переключиться на другую задачу, что помогает избежать инерции и прокрастинации. Может быть. Но в БЗ «все эти навороты» не очень востребованы.

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

Данные из умных таблиц можно визуализировать разными способами: работать с ними в Канбане, анализировать с помощью Диаграмм или просматривать в классическом варианте — Таблице.

Умные таблицы как очень удобные базы данных, для которых не нужно знать код. По кнопке можно изменить вид, легко отфильтровать или найти нужное по внутреннему поиску. Вжух, и готово!

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

Столбцы кастомные - есть основной набор свойств (текст, выбор, число и тп), но сами столбцы пользователи заводят самостоятельно исходя из своих нужд и задач. Свойства и атрибуты в данном случае - это одно и то же.

В ходе жизни статьи эти атрибуты могут меняться, но мы пока что остановились на статичной структуре — в БЗ содержатся только актуальные статьи. Если статья не нужна совсем, её удаляют. Если меняется информация в ней — меняют, о чём сообщают в рабочем чате СП.

Мы остановились на следующих свойствах наших статей:

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

Как показала практика, цветовое кодирование здорово помогает в поиске информации — попробуйте и поймёте, насколько.

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

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

В планах сделать онбординг для менеджеров поддержки в конструкторе курсов. Можно будет использовать наши статьи прямо из Базы Знаний - удобно.

Набросать первую структуру умной таблицы после беседы с нашим CTO заняло у нас с начальником СП примерно полчаса. За это время мы придумали четыре атрибута и их значения. Атрибут Краткий ответ появился в БЗ после тестирования на живых людях. Он позволил закрыть последнее требование заинтересованных лиц — время на поиск не более 10 секунд.

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

Мы сформулировали некие советы для тех, кто соберётся создать базу знаний. Делимся.

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

Читайте здесь, как TEAMLY может помочь службе поддержки.