Как мы подошли к базе знаний из заявок для ИИ-поддержки в Битрикс24

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

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

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

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

С какой задачей к нам пришли

Запрос сначала звучал как задача обучения: сотрудники должны реже обращаться к специалистам 1С. Клиент уже распространял инструкции через задачи и внутренние материалы Битрикс24, предоставлял обучающие видео. Тем не менее помощь инженеров продолжала требоваться.

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

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

Что мы реально сделали и что получили на проверке

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

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

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

Что выяснили: готовых ответов недостаточно

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

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

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

Это изменило фокус нашей работы. Первоначально мы обсуждали ИИ-помощника, который использует корпоративные знания. После проверки стало понятно, что сначала нужен управляемый способ эти знания получать и подтверждать.

Что предложили изменить в плане проекта

Мы рассматривали два пути.

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

Второй - сначала организовать единый учёт обращений в Битрикс24. Сотрудник подаёт заявку через понятную форму; инженер проводит диагностику и фиксирует причину, действия и результат; затем ответственное лицо решает, можно ли добавить алгоритм в базу знаний.

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

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

Карточка решения: что фиксировать в каждой заявке

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

Состав карточки:

1. Исходное обращение. Внутренняя ссылка, дата и канал, чтобы специалист мог вернуться к контексту. Закрытые идентификаторы не переносятся в общую инструкцию.

2. Симптом. Что сотрудник пытался сделать и что увидел. Здесь фиксируется наблюдение, а не догадка о причине.

3. Контекст. Операция, необходимые права, состояние документа, особенности настройки - только то, что действительно влияет на решение.

4. Диагностика. Какие вопросы задали, что проверили и какие ответы получили. Не нужно копировать весь чат; нужны проверки, от которых зависел дальнейший шаг.

5. Причина. Установлена, предполагается или неизвестна. Для вопроса по утверждённой инструкции допустимо указать, что диагностика не требовалась.

6. Действия. Отдельно записываются рекомендации специалиста и фактически выполненные операции.

7. Результат. Как проверили, что вопрос закрыт. Если подтверждения нет, это тоже нужно прямо записать.

8. Границы применения. Когда решение подходит, при каких признаках его нельзя повторять и когда нужен человек.

9. Источник и права доступа. Связанная инструкция и допустимая аудитория. Закрытые документы или данные конкретного сотрудника не должны становиться общедоступными.

10. Проверка знания. Кто согласовал повторное использование, когда и что делать при изменении процесса.

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

Почему мы сделали акцент на ходе диагностики

При разработке карточки мы намеренно разделили 3 разных вещи:

1. что сотрудник увидел,
2. что инженер установил
3. что подтвердилось после его действий.
   Это снижает риск превратить частную рекомендацию в универсальную инструкцию.

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

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

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

Что публиковать в базе знаний, а что оставлять в истории обращения

После закрытия заявки требуется ещё одно решение: пригоден ли её результат для повторного использования? Мы предлагаем 3 статуса.

1. Публиковать или обновить инструкцию.
Причина и результат подтверждены там, где они нужны, условия применения описаны, права доступа понятны, ответственный проверил материал. Если инструкция уже есть, сначала стоит дополнить её, а не создавать конкурирующую версию.

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

3. Оставить в заявке.
Решение разовое, слишком привязано к конкретным данным или не образует повторяемого безопасного алгоритма. История полезна для работы поддержки, но это не повод добавлять её в общую базу знаний.

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

Как собрать этот процесс в Битрикс24

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

Рабочий маршрут может выглядеть так:
Обращение сотрудника -> уточнение и решение специалистом -> фиксация результата -> проверка пригодности знания -> публикация или обновление инструкции.

В Битрикс24 это можно проектировать через задачи, отдельный смарт-процесс или другую подходящую сущность - выбор зависит от объёма обращений, маршрутизации, прав и уже действующих процессов. Универсального обязательного объекта для любой компании здесь нет.

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

Для утверждённых инструкций можно использовать Базу знаний 2.0, где отдельно настраивается доступ к материалам.

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

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

Минимально нужны 3 роли:

1. владелец процесса обращений,
2. специалист, принимающий техническое решение,
3. ответственный за качество опубликованного знания.
   Один человек может совмещать роли, но важно, чтобы было ясно, кто принимает последнее решение.

Перед настройкой стоит проверить 4 практических вопроса:

1. какие поля сотрудник должен заполнить сразу,
2. как распределять обращения,
3. кому доступны исходные файлы
4. кто обновляет утверждённые материалы после изменения правил или настроек 1С.

О том, как связать базу знаний, ИИ и передачу вопроса человеку, мы уже писали в статье «База знаний в Битрикс24 с AI: как отвечать сотрудникам и передавать вопросы человеку». Здесь речь о предыдущем шаге: откуда берутся знания, которым можно доверять.

Какие риски мы учли и когда подключать ИИ

После первого разбора стало понятно, что у проекта есть не только технические, но и организационные риски.

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

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

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

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

Наше предложение поэтапное.

1. Сначала ИИ ищет ответы для инженера по проверенным материалам.
2. Инженер принимает, дополняет или отвергает рекомендацию и фиксирует результат.
3. После повторных проверок можно разрешать прямые ответы сотрудникам по отдельным типовым вопросам.
4. Сложные и неоднозначные случаи остаются у специалистов.

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

С чего начать на практике

Необязательно сначала переносить в базу знаний все старые чаты. Лучше проверить небольшой цикл на реальных вопросах.

1. Выберите обращения разного типа.
   Пусть в выборке будут и простые вопросы, и случаи, в которых специалисту приходилось уточнять обстоятельства.

2. Разделите их по способу помощи.
   Где достаточно инструкции, где нужны дополнительные условия, а где обязательна диагностика?

3. Согласуйте карточку решения.
   Не перегружайте форму сотрудника. Основные уточнения и итог может записывать инженер по ходу работы.

4. Назначьте проверяющего.
   Он должен знать, что именно считается подтверждением решения, кто публикует инструкцию и когда её нужно пересмотреть.

5. Примените 3 статуса к реальным карточкам.
   Сразу станет видно, каких данных не хватает и какие вопросы повторяются только по формулировке.

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

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

К какому выводу мы пришли

Мы начинали с задачи разгрузить поддержку 1С с помощью знаний и ИИ. Реально изучили часть обращений и существующих материалов, подготовили и вручную доработали пробную базу ответов, получили первую оценку специалистов. Именно здесь обнаружился ключевой пробел: готовый ответ без истории диагностики ещё не является проверенным знанием для следующего обращения.

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

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

Если вы хотите организовать такой процесс в своей компании, напишите нам в Лабораторию автоматизации «LOG [IN] OFF». Поможем разобраться в обращениях, спроектировать учёт и проверку знаний в Битрикс24 и определить безопасный порядок подключения ИИ.