Почему традиционный онбординг перестал работать
Ссылка на источник в задании ведёт на несуществующую страницу, поэтому конкретных фактов, цифр и цитат для этой секции у меня нет. Ниже — только общая постановка проблемы, без выдуманных данных.
Классический тур устроен предсказуемо: фиксированный маршрут, одинаковый набор точек для всех, один и тот же темп. Инструкция рядом — линейный список шагов, рассчитанный на «среднего» читателя. Пока аудитория однородна, а среда стабильна, такая связка работает: её легко собрать, легко повторять, легко контролировать.
Ограничения начинают проявляться, как только однородность исчезает.
- Единый маршрут не учитывает разный вход. Новичку нужен контекст и объяснение терминов; опытному — сразу переход к делу. Один и тот же тур даёт первому слишком много, второму — слишком мало. Инструкция это не лечит: она либо разжёвывает, либо молчит.
- Фиксированный порядок конфликтует с реальными задачами. Человек приходит за одним конкретным ответом, а вынужден проходить пять экранов или пять абзацев, прежде чем до него добраться.
- Точность инструкций падает по мере роста системы. Чем больше возможностей, тем длиннее список шагов и тем выше шанс, что часть из них устарела. Поддерживать такой документ в актуальном состоянии дорого, а расхождение с реальностью подрывает доверие к нему целиком.
- Обратная связь запаздывает. Туры и инструкции обычно обновляют по итогам разбора, а не в момент, когда пользователь застрял. К следующей правке проблема уже повторилась у десятков людей.
Здесь и возникает запрос на другой подход. Нужен не один маршрут, а адаптация под конкретную ситуацию: подсказка появляется там и тогда, где человек действительно остановился, а не там, где её заранее прописали. Инструкция перестаёт быть монологом и становится реакцией на поведение. Именно эту нишу и пытаются занять новые решения — но об этом уже в следующих секциях.
Экранные подсказки как интерфейс для AI-агента
Что именно видит агент, когда пользователь открывает интерфейс? Не список кнопок и полей, а состояние задачи: где человек находится, какие данные уже введены, какой элемент в фокусе, что он пытался сделать последним. Из этих сигналов складывается рабочая гипотеза о цели — и уже под неё строится следующий шаг.
Механика простая: агент собирает наблюдаемый контекст, сопоставляет его с типовыми сценариями и выдаёт действие, релевантное текущему состоянию, а не заранее записанной последовательности. Если открыта форма с пустым обязательным полем — подсказка касается этого поля. Если данные заполнены и курсор у кнопки подтверждения — логичнее предложить проверку перед отправкой. Источник: обсуждение на Hacker News.
Сценарии, где такой онбординг даёт максимальный эффект
Сложный B2B-интерфейс — первый кандидат. В системах закупок, ERP или банковских кредитных конвейерах оператор проходит по 8–12 экранам, и каждый следующий зависит от того, что заполнено раньше. Если агент видит, что пользователь третий раз возвращается к одному и тому же полю «Код контрагента», он может предложить подставить значение из справочника или открыть подсказку по формату — без того, чтобы человек искал инструкцию в Confluence. Контекст экрана здесь работает как навигационная карта: агент не угадывает профессию пользователя, а читает его текущий маршрут.
Мобильные приложения — второй сценарий. Экран маленький, места для тултипов нет, а ввод с клавиатуры дорог. Подсказка, привязанная к состоянию формы (что уже введено, где курсор, какое поле подсвечено ошибкой), выигрывает у постоянно висящих подсказок: она появляется в момент, когда пользователь застрял, и исчезает, когда он двинулся дальше. В условиях, где каждая лишняя секунда ввода снижает конверсию, это разница между завершённой заявкой и брошенной корзиной.
Третий кейс — обучение новых сотрудников. Стажёр в первый день не знает ни логики процессов, ни названий полей. Агент, реагирующий на состояние экрана, по сути ведёт его за руку: на пустом обязательном поле — подсказка о том, что тут вводится; после заполнения — предложение проверить перед отправкой. Это не заменяет наставника, но снимает часть типовых вопросов и позволяет новичку пройти первый сценарий самостоятельно, а не звать коллегу на каждом шаге.
Общее у всех трёх случаев одно: цена ошибки или задержки высока, а сам сценарий достаточно предсказуем, чтобы агент мог опираться на наблюдаемое состояние, а не на догадки.
Технические и продуктовые вызовы
Первый и самый неприятный риск — задержка вывода. Агент, который анализирует контекст экрана, почти всегда работает поверх отдельной модели или сетевого вызова. Если ответ приходит через две-три секунды, пользователь успевает переключиться на другую задачу или вручную закрыть форму — и подсказка появляется «в никуда». Пользователь воспринимает это не как помощь, а как шум, который нужно отключить. Ориентир простой: если подсказка не успевает появиться в момент, когда поле ещё в фокусе, — она уже неактуальна, даже если технически верна.
Второй риск — ложные срабатывания. Агент видит поле с ошибкой и предполагает, что пользователь не знает формат. Но иногда ошибка введена специально: тестовые данные, отрицательное значение, край edge case. Если система каждый раз предлагает «исправить» такое поле, она мешает работе. Здесь помогает не «умность» модели, а контекст: насколько часто это поле вообще вызывает ошибки у данного пользователя, повторяется ли ввод. Единичный случай — не повод показывать карточку.
Третий риск — приватность. Скриншот экрана может содержать номера карт, персональные данные, внутренние суммы сделок. Отправлять такое на обработку без явного согласия — уже нарушение. Даже если данные не покидают периметр, их хранение в истории сессии увеличивает поверхность атаки. Практичный минимум: маскировать чувствительные поля до анализа, не сохранять сырые скриншоты дольше одной сессии и давать пользователю возможность отключить подсказки для конкретного экрана.
Метрики успеха: как измерить эффект от агентного онбординга
Начнём с вопроса, который стоит задать до релиза: как вы поймёте, что встроенный агент приносит пользу, а не создаёт новую работу? Ответ — заранее договориться о числах и о том, откуда они берутся.
Time-to-value. Это время от запуска задачи до момента, когда пользователь впервые получает от агента результат, который он принимает. Собирать его проще всего на событийной модели: фиксируйте момент открытия формы или старта сценария и момент, когда подсказка была принята (нажата кнопка «применить», вставлен предложенный текст). Метрика полезна в разрезе: медиана по сценарию, а не среднее по всем — иначе редкие тяжёлые случаи перекроют типичный опыт.
Retention принятия. Считайте не факт показа, а долю сессий, где предложение было принято. Формула: принятия / показы, с разбивкой по типу задачи. Если по одному сценарию доля стабильно растёт, а по другому падает, — это сигнал, где именно стоит дорабатывать логику, а не всю систему целиком.
Снижение обращений в поддержку. Здесь важно не сравнивать «до и после» целиком, а изолировать эффект: возьмите тикеты по конкретной теме (например, «не проходит валидация поля»), присвойте им тег и отслеживайте динамику по неделям. Простой сдвиг в общем объёме обращений ни о чём не говорит — на него влияют релизы, сезонность и маркетинг.
Явная обратная связь. Дайте пользователю одну кнопку «это помогло / не помогло» прямо в точке предложения и храните её рядом с контекстом срабатывания. Это дешёвый источник качественных данных, который объясняет, почему цифры растут или падают.
Практический приём: заводите дашборд с этими метриками до того, как агент попадёт к реальным пользователям. Если метрику нельзя посчитать на исторических данных — значит, событие не логируется, и это первое, что нужно починить.
Будущее: от подсказок к проактивному ассистенту
Если свести обсуждение к трём пунктам, получится так. Во-первых, вопрос «нужен ли агент» уже не стоит — спорят о другом: где именно он работает и под чьим контролем. Во-вторых, ставка на степень автономии даёт меньше, чем ставка на предсказуемость: инженеры ценят агента за повторяемость результата, а не за размах инициативы. В-третьих, узкий домен выигрывает у универсального — агент, заточенный под один сценарий, вызывает доверие, тогда как «делаю всё» быстро превращается в источник скрытой ручной работы.
Практический совет: зафиксируйте границу ответственности агента письменно — какие действия он выполняет сам, какие только предлагает, а что эскалирует вам. Первые две-три недели собирайте долю эскалаций: если она систематически выше ожиданий, дело не в модели, а в слишком широком домене, и его стоит сузить.
