Новый сотрудник в первый день пишет в тот же чат Битрикса, что и все остальные: "как получить доступ к почте", "куда идти за пропуском", "как подключить принтер". Отвечает ему тот же бот, что закрывает заявки в техподдержку. Отдельного приложения для адаптации нет - онбординг стал ещё одним сценарием внутри уже работающей связки. У клиента, крупной инженерной компании, это часть боевого контура: техподдержка, ввод новичков и протоколы созвонов живут в одном боте.
Обычно адаптацию новичка вешают либо на живого наставника, либо на отдельный HR-инструмент. Оба варианта дают разрыв: инструкции лежат в одном месте, доступы заводятся в другом, а спросить "а как у нас тут" не у кого, пока сосед по кабинету занят. Мы пошли иначе: расширили сценарии бота, который уже отвечает всей компании, вместо второго сервиса.
Почему онбординг живёт в том же боте
Бот в этом проекте устроен как приёмная всех рабочих обращений. Сотрудник пишет обычными словами, бот понимает намерение: поздоровался человек, задал вопрос или сообщил о проблеме. Сначала ищет ответ в базе знаний, и только если решения нет - предлагает завести заявку. Вопрос новичка "как настроить корпоративную почту на телефоне" ничем не отличается от вопроса ветерана "почему не печатает сетевой принтер". Оба - запрос в базу знаний, и отвечает на них бот одной механикой.
40% всех обращений в этой компании бот закрывает прямо из базы знаний, без заявки. Для новичка эта доля выше: почти все его вопросы первых недель - типовые, они давно описаны во внутренних статьях. Боту не нужно отдельное "меню адаптации": он находит нужный документ в корпоративной базе и отдаёт пошаговую инструкцию по доступам, оргтехнике и базовым сервисам.
Второй бот означал бы второй контур: своя база, свои права доступа, своё сопровождение, своя точка отказа. Вместо этого новый сценарий получает всё, что уже построено: смысловой поиск по базе знаний, учёт прав доступа, локальную модель в контуре, приём заявок с 10 шаблонами. Расширять каталог сценариев дешевле, чем содержать два инструмента.
Что именно бот делает с новичком
Первый рабочий день человека - пачка мелких, но блокирующих вопросов. Где взять учётную запись. Как подключиться к внутренним системам. Куда писать, если не выдали технику. Раньше на них отвечали наставник и коллеги в перерывах между своей работой - тот же механизм, из-за которого в техподдержке первый ответ мог ждать до 10 часов, пока инженер занят основной задачей.
Теперь новичок задаёт вопрос боту и получает ответ мгновенно. По типовым темам - доступы, ввод по оргтехнике, базовые сервисы - бот отдаёт готовую инструкцию из базы знаний. Если инструкции нет или вопрос требует человека (например, физически выдать оборудование), бот собирает заявку: подбирает подходящий шаблон, вытаскивает из текста параметры вроде номера кабинета, доспрашивает недостающее по одному вопросу и создаёт задачу с исполнителем и сроком, отдавая ссылку.
Права доступа тут работают как страховка. Бот учитывает, что можно показывать конкретному сотруднику: новичок без допуска не вытащит через бота чувствительные данные - зарплаты, маржу сделок. Онбординг не открывает лишнего, потому что наследует ту же модель прав, что и вся база знаний.
Как понять, какой сценарий добавлять следующим
Онбординг появился из данных. Бот кормит рабочие таблицы, поверх которых в BI-конструкторе Битрикса собраны панели: графики по тематикам обращений, распределение нагрузки, среднее время выполнения, рейтинг узких мест. Отдельный срез - анализ набора закрытых заявок и поиск кандидатов на автоматизацию.
Логика простая: смотрим, какие типы обращений повторяются чаще всего и решаются одинаково. Если сотни заявок в месяц - вариации одного "как мне получить доступ к X", такой сценарий отдаём боту целиком. Вопросы новичков как раз собрались в заметную, повторяющуюся группу - их и автоматизировали следующими. Каталог сценариев растёт постепенно: накопленная статистика показывает следующее узкое место.
- 01Собрать набор закрытых заявок за период и сгруппировать по смыслу, а не по формальному шаблону.
- 02Найти повторяющиеся однотипные обращения с одинаковым решением - кандидаты на автоматизацию.
- 03Оформить решение как статью базы знаний или новый шаблон заявки, который клиент заводит сам.
- 04Проверить на живом потоке и вернуться к панели за следующим кандидатом.
Так одна связка постепенно закрывает всё больше рутины. Начинали с техподдержки, добавили онбординг, рядом встали протоколы созвонов и расшифровка звонков. Каждый раз - расширение сценариев уже работающего бота, не новый проект с нуля.
Что это даёт компании
Новичок перестаёт зависеть от того, свободен ли наставник. Ответ на типовой вопрос приходит сразу, а не через несколько часов. Заявки на выдачу техники и доступов не теряются - раньше при потоке через почту, звонки и устные просьбы терялось около 10% обращений, теперь каждое доходит до исполнителя в единой очереди.
Наставники и ИТ-служба разгружаются от повторяющихся вопросов и занимаются тем, где нужен человек. А компания не платит за второй инструмент и не поддерживает второй контур: онбординг живёт внутри бота, который и так закрывает всю техподдержку со средней оценкой 4,5 из 5. Весь проект от старта до боевого использования занял 3 месяца.
Если у вас уже есть чат-бот или система заявок, обычно вопрос не в том, строить ли ещё один сервис под адаптацию. Вопрос - какие повторяющиеся сценарии стоит отдать одной связке. Мы разбираем это на диагностике: смотрим ваш поток обращений, считаем, что автоматизировать первым, и показываем, как расширять каталог сценариев по данным, а не наугад.
