В поддержке 1С есть особый тип обращений. Они не всегда сложные. Не всегда срочные. Не всегда требуют разработки.
Но они очень хорошо умеют съедать время.
“Как заполнить эти реквизиты?”
“Где посмотреть задачи по бизнес-процессу?”
“Почему документ не заполняется?”
“У меня не работает”.
Открываешь обращение, начинаешь разбираться, а потом выясняется: всё работает именно так, как должно. Просто пользователь забыл порядок действий, не видел инструкцию, не знает, где посмотреть задачу, или пытается сделать операцию не по тому сценарию.
Один раз объяснить — нормально.
Второй раз — тоже бывает.
Но если один и тот же вопрос задают третий раз, это уже не просто вопрос.
Если вопрос задают третий раз — это кандидат в базу знаний.
База знаний 1С-поддержки нужна не для красоты и не для галочки. Она нужна, чтобы команда не отвечала бесконечно на одни и те же вопросы, пользователи могли быстрее решать типовые ситуации, а знания не жили только в головах отдельных сотрудников и старых файлах.
В этой статье разберем, какая база знаний действительно помогает в 1С-сопровождении, где должны жить инструкции, кто отвечает за их актуальность и как понять, что она работает.
База знаний — это не папка с инструкциями
Я довольно осторожно отношусь к фразе “у нас есть база знаний”.
Иногда под этим подразумевается папка с файлами, куда когда-то сложили несколько инструкций. Часть документов устарела. Часть называется так, что пользователь никогда их не найдет. Часть лежит на ресурсе, к которому у пользователя нет доступа. А часть вообще существует только потому, что “надо было куда-то положить регламент”.
Формально база знаний есть.
Практически — пользователь всё равно пишет в поддержку.
Для меня рабочая база знаний — это не место хранения файлов. Это часть процесса поддержки.
Она должна отвечать на простые вопросы:
- где пользователь может быстро найти инструкцию;
- понятно ли по названию, о чем статья;
- можно ли решить вопрос без обращения в поддержку;
- есть ли инструкция рядом с тем местом, где возникает вопрос;
- актуальна ли инструкция после изменения процесса;
- кто отвечает за ее обновление;
- снижается ли количество повторных обращений.
Если база знаний не помогает пользователю действовать, она превращается в архив.
Архив может быть полезен. Но поток обращений он снижает плохо.
Какие вопросы чаще всего должны попадать в базу знаний
Не каждое обращение нужно превращать в инструкцию.
Если ситуация уникальная, редкая или требует анализа разработчика, достаточно закрыть ее в рамках заявки.
Но есть вопросы, которые почти сами просятся в базу знаний.
Например:
- как заполнить реквизиты документа;
- какие поля обязательны;
- где посмотреть задачи в бизнес-процессе;
- как согласовать документ;
- что делать, если документ не перешел на следующий этап;
- почему не отображается нужный документ;
- где поставить отбор;
- как выбрать период или организацию в отчете;
- что означает конкретный статус;
- какой порядок действий после изменения процесса;
- что делать при типовой ошибке пользователя;
- к кому обращаться, если инструкция не помогла.
Особенно хорошо база знаний работает там, где проблема повторяется, но не требует изменения кода.
Например, пользователь говорит:
“Не заполняется документ”.
Начинаешь проверять, и оказывается: по инструкции в этом статусе документ и не должен заполняться автоматически. Или сначала нужно выполнить другое действие. Или задача появляется не сразу, а после перехода бизнес-процесса на следующий этап.
В таких ситуациях поддержка не должна каждый раз объяснять процесс заново.
Должна быть понятная инструкция.
Повторное обращение — сигнал, а не просто раздражитель
Повторяющиеся вопросы раздражают.
Не потому что пользователи плохие. А потому что ты уже это объяснял.
Объяснял в чате. Потом в письме. Потом на созвоне. Потом еще одному пользователю. Потом новому сотруднику. Потом снова первому, потому что он забыл.
В какой-то момент ловишь себя на мысли:
“Я опять пишу одно и то же”.
Вот это хороший момент для базы знаний.
Повторный вопрос показывает не только проблему пользователя. Он показывает пробел в системе поддержки.
Возможные причины:
- инструкции нет;
- инструкция есть, но пользователь о ней не знает;
- инструкция лежит не там;
- инструкция устарела;
- инструкция написана слишком сложно;
- в инструкции нет ответа на типовую ошибку;
- ссылка на инструкцию не встроена в рабочий процесс;
- пользователь не привык сначала искать ответ самостоятельно.
Иногда проблема решается не новой доработкой, а нормальной инструкцией в правильном месте.
И это не менее ценно, чем написать код.
Где должны жить инструкции
Есть распространенная ошибка: сделать инструкции, но спрятать их так, что пользователь всё равно не сможет ими пользоваться.
Инструкция может лежать:
- в Word-файле;
- на внутреннем портале;
- в общей папке;
- в базе знаний service desk;
- в регламенте;
- в карточке процесса;
- в задаче проекта;
- в описании доработки;
- в самой 1С через гиперссылку или подсказку.
Сам по себе формат не так важен.
Важно, чтобы пользователь мог быстро дойти до инструкции в момент, когда она ему нужна.
Мне нравится подход, когда инструкции не просто лежат на отдельном внутреннем ресурсе, а связаны с рабочим процессом в 1С.
Например:
- в документах 1С встроены гиперссылки на инструкции;
- при открытии документа справа отображается инструкция;
- в карточке процесса есть ссылка на порядок действий;
- в сообщении об ошибке есть не только текст ошибки, но и ссылка “что делать”;
- в форме есть подсказка для спорных реквизитов;
- в разделе помощи собраны инструкции по типовым операциям.
Это сильно повышает шанс, что пользователь воспользуется инструкцией.
Если инструкция лежит “где-то в файлах”, пользователь должен сначала вспомнить, что она есть, потом найти ее, потом понять, актуальна ли она.
Чаще он просто напишет в поддержку.
Если ссылка на инструкцию находится прямо рядом с документом или процессом, барьер ниже.
Инструкция должна быть написана для пользователя, а не для автора
Плохая инструкция часто выглядит умно.
Там много текста, терминов, общих формулировок и ссылок на регламенты. Автору кажется, что всё описано подробно.
Пользователь открывает и закрывает.
Потому что ему нужно не изучить методологию, а понять, что нажать сейчас.
Хорошая инструкция для 1С-пользователя обычно проще:
- короткое название;
- когда использовать инструкцию;
- пошаговый порядок действий;
- скриншоты или понятные ориентиры в интерфейсе;
- что должно получиться в конце;
- что делать, если результат другой;
- к кому обратиться, если инструкция не помогла;
- дата актуальности;
- ответственный за содержание.
Я бы не пытался в одну инструкцию запихнуть всё.
Лучше несколько коротких статей:
- “Как заполнить реквизиты документа”;
- “Как посмотреть свои задачи по бизнес-процессу”;
- “Что делать, если документ не перешел на следующий этап”;
- “Почему отчет пустой: что проверить сначала”;
- “Как выбрать период и организацию в отчете”.
Пользователь ищет ответ на конкретный вопрос. Инструкция должна помогать ему быстро этот ответ найти.
FAQ, чек-лист и пошаговая инструкция — это разные форматы
База знаний не должна состоять только из длинных инструкций.
Разные вопросы требуют разных форматов.
| Формат | Когда подходит | Пример |
|---|---|---|
| Пошаговая инструкция | Пользователю нужно выполнить процесс от начала до конца | Как согласовать документ в 1С:Документооборот |
| FAQ | Есть набор частых коротких вопросов | Почему я не вижу задачу? Почему отчет пустой? |
| Чек-лист | Нужно проверить несколько условий | Что проверить перед обращением в поддержку |
| Инструкция по ошибке | Пользователь видит конкретную ошибку или ситуацию | Что делать, если документ не заполняется |
| Краткая памятка | Нужно напомнить порядок действий | 5 шагов для запуска бизнес-процесса |
| Статья для поддержки | Нужно описать диагностику для первой линии | Как проверить, почему пользователь не видит задачу |
Для пользователя лучше коротко и по делу.
Для поддержки можно подробнее: где проверить настройки, какие вопросы задать, что посмотреть в 1С, когда передавать разработчику.
Это разные аудитории. И смешивать их в одной статье не всегда удобно.
Кто должен отвечать за базу знаний
База знаний не живет сама.
Ее нужно организовать, поддерживать и обновлять.
На мой взгляд, отвечать за это должен тот, кто отвечает за систему или процесс: тимлид, руководитель проекта, владелец системы, руководитель поддержки или другой ответственный.
Разработчик может помочь технически:
- объяснить, как работает механизм;
- подсказать ограничения;
- описать логику доработки;
- проверить техническую корректность;
- добавить ссылку в форму или документ;
- подготовить текст ошибки или подсказки.
Но разработчик не всегда должен быть владельцем пользовательской инструкции.
Если инструкция описывает бизнес-процесс, за смысл должен отвечать владелец процесса или тот, кто управляет системой.
Иначе возникает странная ситуация: разработчик написал код, потом написал инструкцию, потом объясняет пользователям, потом обновляет инструкцию при изменении процесса, потом еще отвечает на вопросы, почему бизнес решил работать именно так.
Это не всегда правильно.
Хорошая схема выглядит так:
| Роль | Ответственность |
|---|---|
| Владелец системы / тимлид / РП | Организует базу знаний, определяет правила, следит за актуальностью |
| Владелец процесса | Отвечает за смысл инструкции и правильность бизнес-сценария |
| Аналитик / консультант | Описывает пользовательский сценарий понятным языком |
| Разработчик | Проверяет технические детали и помогает встроить ссылки/подсказки в 1С |
| Поддержка | Находит повторяющиеся вопросы и предлагает темы для статей |
| Пользователи | Дают обратную связь: понятно или нет, помогла инструкция или нет |
Если ответственного нет, база знаний быстро устаревает.
А устаревшая инструкция иногда хуже отсутствующей. Пользователь делает по ней, получает неправильный результат и перестает доверять базе знаний.
Что обязательно заносить в базу знаний
Я бы не пытался сразу описать всё.
Лучше начать с того, что реально снижает нагрузку.
1. Повторяющиеся вопросы
Если один и тот же вопрос задают несколько раз, значит ответ должен быть доступен без участия разработчика или поддержки.
Примеры:
- как заполнить реквизиты;
- как найти задачу;
- как посмотреть историю согласования;
- как понять статус документа;
- почему отчет ничего не показывает.
2. Ошибки пользователей
Если обращение часто возникает из-за неверного отбора, периода, организации, статуса или порядка действий, это хороший материал для FAQ или чек-листа.
Например:
“Перед обращением в поддержку проверьте: период, организацию, отборы, статус документа, наличие задачи в списке”.
3. Новые доработки
Если в 1С добавили новый функционал, инструкция должна появиться не через месяц после запуска, а вместе с ним.
Иначе пользователи начнут спрашивать:
- что изменилось;
- куда нажимать;
- почему теперь не так;
- какие поля заполнять;
- кто должен выполнять новый шаг.
4. Измененные процессы
Очень частая проблема: процесс поменяли, а инструкции остались старыми.
Пользователь открывает старую инструкцию, делает по ней, получает другой результат и пишет в поддержку.
Поэтому изменение процесса должно автоматически означать проверку инструкции.
5. Порядок действий после релиза
Если после релиза пользователям нужно сделать что-то иначе, это должно быть описано.
Не только в сообщении “мы обновили систему”, а в понятной форме:
- что изменилось;
- кого касается;
- что теперь делать по-другому;
- где инструкция;
- куда писать, если возникла проблема.
Как понять, что инструкция хорошая
Хорошая инструкция — это не та, которую красиво оформили.
Хорошая инструкция — это та, после которой пользователь смог решить вопрос.
Проверить качество можно простыми признаками:
- после публикации стало меньше повторных обращений;
- пользователи открывают инструкцию до обращения в поддержку;
- первая линия поддержки отправляет ссылку, и вопрос закрывается;
- по инструкции можно выполнить действие без устного пояснения;
- в инструкции есть типовые ошибки и что делать при них;
- понятно, для кого она написана;
- понятно, когда она обновлялась;
- есть ответственный за актуальность.
Если инструкция есть, но вопросы не уменьшаются, нужно смотреть причину.
Возможно:
- пользователи не знают о ней;
- ее сложно найти;
- она написана слишком общо;
- нет нужного ответа;
- процесс изменился;
- ссылка находится не там;
- пользователи привыкли сразу писать в поддержку.
В базе знаний важно не количество статей, а их применимость.
Метрики: без них база знаний быстро становится верой
Мне нравится идея измерять не только количество обращений, но и их качество.
Потому что база знаний нужна не просто для того, чтобы “было где посмотреть”.
Она должна снижать нагрузку.
Что можно отслеживать:
| Метрика | Что показывает |
|---|---|
| Количество повторных обращений по одной теме | Есть ли темы, которые нужно занести или переработать в базе знаний |
| Доля обращений, закрытых ссылкой на инструкцию | Работают ли инструкции как инструмент поддержки |
| Количество обращений после изменения процесса | Понятно ли пользователям, что изменилось |
| Количество вопросов по новым доработкам | Хватило ли обучения и инструкций при запуске |
| Время реакции поддержки на типовой вопрос | Сократилась ли нагрузка на первую линию |
| Количество обращений, переданных разработчику без необходимости | Сколько времени команды можно было сэкономить |
| Просмотры инструкций | Пользуются ли базой знаний вообще |
| Оценка полезности инструкции | Помогла ли статья пользователю решить вопрос |
Не нужно превращать это в сложную аналитику с десятью отчетами.
Но хотя бы базово понимать динамику полезно.
Если после появления инструкции количество однотипных обращений снизилось — значит, база знаний работает.
Если не снизилось — нужно не ругать пользователей, а проверить, почему инструкция не закрывает вопрос.
Что должен понять руководитель
База знаний — это не “дополнительная бумажная работа”.
Это способ экономить время и ресурсы.
Каждый повторный вопрос стоит денег.
Даже если на него ответили за пять минут. Потому что это пять минут специалиста, переключение контекста, отвлечение от задачи, ожидание пользователя и накопление мелких прерываний.
Если один вопрос задают десятки раз, это уже не мелочь.
Это постоянная утечка времени.
Руководителю важно увидеть простую связь:
Повторяющийся вопрос → инструкция → ссылка в рабочем процессе → меньше обращений → меньше отвлечений → больше времени на важные задачи.
Но есть условие.
Пользователь должен знать, что перед тем как задать вопрос, он может где-то посмотреть, как должно работать.
Если такой культуры нет, база знаний будет простаивать.
Поэтому мало написать инструкции. Нужно встроить их в процесс:
- добавить ссылки в 1С;
- прикладывать ссылки в ответах поддержки;
- обновлять инструкции после изменений;
- показывать пользователям, где искать ответы;
- не отвечать каждый раз с нуля, если уже есть статья;
- собирать темы для новых инструкций из повторных обращений.
Минимальный процесс работы с базой знаний
Чтобы база знаний не умерла через месяц, ей нужен простой процесс.
Например такой:
- Пользователь задает вопрос или создает обращение.
- Поддержка решает вопрос.
- Если вопрос повторяется, его помечают как кандидата в базу знаний.
- Ответственный готовит короткую инструкцию, FAQ или чек-лист.
- Владелец процесса проверяет смысл.
- При необходимости разработчик проверяет технические детали.
- Инструкцию публикуют на внутреннем ресурсе.
- Ссылку добавляют в 1С, процесс, документ или ответ поддержки.
- Через некоторое время смотрят, уменьшились ли повторные обращения.
- При изменении процесса инструкцию обновляют.
Ничего сверхсложного.
Но именно такие простые циклы часто и дают эффект.
План запуска базы знаний за 30 дней
Если базы знаний нет или она существует только формально, можно начать с небольшого цикла.
Неделя 1. Собрать повторяющиеся вопросы
- Посмотреть обращения за последние недели.
- Выписать вопросы, которые повторялись несколько раз.
- Отдельно отметить обращения, которые закрывались простой инструкцией.
- Найти темы, где пользователи чаще всего забывают процесс.
- Выбрать 5–10 первых статей для базы знаний.
Неделя 2. Подготовить первые инструкции
- Написать короткие пошаговые инструкции.
- Сделать FAQ по самым частым вопросам.
- Добавить чек-листы “что проверить перед обращением”.
- Проверить инструкции на реальных пользователях или первой линии поддержки.
- Упростить формулировки, если инструкция получилась слишком технической.
Неделя 3. Встроить инструкции в рабочий процесс
- Разместить инструкции на доступном внутреннем ресурсе.
- Добавить ссылки в документы, формы, процессы или сообщения 1С.
- Настроить отображение инструкции рядом с документом, если такая возможность есть.
- Договориться, что поддержка отвечает ссылкой на инструкцию, если вопрос типовой.
Неделя 4. Начать измерять эффект
- Посмотреть, уменьшились ли повторные обращения.
- Отметить инструкции, которые реально помогают.
- Найти статьи, после которых вопросы всё равно остаются.
- Собрать обратную связь пользователей.
- Назначить ответственных за актуальность ключевых инструкций.
Главное — не пытаться за месяц описать всю систему.
Лучше закрыть первые 10 самых частых вопросов, чем создать огромную структуру, которую никто не будет наполнять.
Типовые ошибки базы знаний
Ошибка 1. Писать инструкции после того, как поток вопросов уже начался
Если запускается новая доработка или меняется процесс, инструкция должна готовиться вместе с изменением, а не через месяц после жалоб.
Ошибка 2. Хранить инструкции там, где пользователь их не найдет
Файл может быть отличным, но бесполезным, если пользователь не знает, где он лежит.
Ошибка 3. Не обновлять инструкции после изменений
Устаревшая инструкция снижает доверие. Пользователь один раз сделал по ней неправильно и в следующий раз снова пойдет в поддержку.
Ошибка 4. Писать слишком технически
Пользователю не всегда нужно знать внутреннюю логику 1С. Ему нужно понять, что делать.
Ошибка 5. Не измерять эффект
Если не смотреть на повторные обращения, сложно понять, работает база знаний или просто существует.
Главный вывод
База знаний 1С-поддержки — это не склад файлов и не формальность.
Это инструмент, который помогает снижать поток повторных обращений, экономить время специалистов и делать работу пользователей спокойнее.
Если пользователь каждый раз спрашивает, как заполнить реквизиты или где посмотреть задачу в бизнес-процессе, проблема не только в пользователе.
Возможно, у него нет понятной инструкции рядом с рабочим процессом.
Возможно, инструкция устарела.
Возможно, она лежит в месте, куда он не ходит.
Возможно, команда поддержки каждый раз отвечает вручную, вместо того чтобы один раз оформить нормальный ответ.
Я бы оставил главное правило таким:
Если вопрос задают третий раз — это уже не вопрос, а кандидат в базу знаний.
Не каждый вопрос нужно превращать в большую инструкцию. Иногда достаточно короткого FAQ, чек-листа или ссылки в форме 1С.
Но знания не должны жить только в головах сотрудников, личных сообщениях и случайных файлах.
Иначе команда будет снова и снова отвечать на одно и то же.
А это время можно было потратить на развитие системы, устранение причин проблем и действительно важные задачи.