Большинство компаний, впервые пробующих использовать ИИ-агентов, сразу переходят к выбору инструмента. Обычно это ошибка. Компании, которые получают реальную выгоду, как правило, начинают с чего-то менее захватывающего: с выяснения того, какую именно проблему они решают, прежде чем кто-либо начнет работать с платформой.
В этом плане подробно описаны четыре этапа, отличающие работающего ИИ-агента от дорогостоящего эксперимента, начиная с определения сценария использования и заканчивая тем, что происходит после запуска.
Читайте дальше, чтобы узнать, как каждый этап основывается на предыдущем.
Определение оптимального сценария использования вашего первого ИИ-агента
Выбор правильной отправной точки имеет большее значение, чем большинство команд ожидают, поскольку от него зависит, будет ли агент чувствовать себя полезным или его тихо бросят. Возникает соблазн ставить перед собой масштабные цели, но для первого развертывания лучше работают небольшие и конкретные задачи.
Вот несколько факторов, которые необходимо учитывать при разработке убедительного первоначального варианта использования:
Повторяемость задачи
Удачный первый сценарий использования возникает достаточно часто, чтобы получить значимые данные в течение нескольких недель, а не месяцев. Оператор, обрабатывающий пять вопросов клиентов в день, мало что скажет о своих сильных и слабых сторонах. Запросы на сброс пароля или проверку статуса заказа, которые могут поступать десятки раз в день, обеспечивают команде достаточный объем работы для быстрой оценки производительности.
Четкие критерии успеха
Прежде чем что-либо создавать, команде необходимо понять, работает ли агент. Логистическая компания может отслеживать, сколько вопросов, связанных с доставкой, решается без участия человека. Это число становится отправной точкой для принятия решения о том, получит ли агент более значимую роль в будущем.
Воздействие локализованного отказа
Начинающие сотрудники будут совершать ошибки, поэтому сценарий использования должен ограничивать ущерб, который может нанести ошибка. Сотрудник, который составляет резюме внутренних совещаний, несет меньший риск, чем тот, кто автоматически оформляет возврат средств. Начало работы с задач меньшей важности дает команде возможность исправлять проблемы до того, как они дойдут до клиента.
Выбор правильной инфраструктуры и инструментов
Решения по инфраструктуре, как правило, принимаются в спешке после определения сценария использования, но они определяют объем работы, необходимой для остальной части проекта. Некоторые команды разрабатывают все внутри компании, в то время как другие полагаются на внешних партнеров для технической подготовки.
Ниже перечислены некоторые факторы, которые обычно влияют на принятие этого решения:
Внутреннее строительство против строительства под управлением компании
Создание агента с нуля означает ответственность за все интеграции, обновления и исправления ошибок в будущем. Поставщик управляемых услуг часто предоставляет существующую инфраструктуру, которая уже была протестирована в других развертываниях.
Это особенно актуально для агентов по продажам, использующих ИИ , где поставщики предлагают готовые интеграции с CRM-системами и системами маршрутизации лидов. В противном случае их разработка внутри компании заняла бы месяцы. Команда, рассматривающая оба варианта, должна учитывать не только время разработки, но и последующее обслуживание.
Сложность интеграции
Некоторым агентам необходимо подключаться к одной системе, например, к платформе службы поддержки, в то время как другие взаимодействуют с несколькими инструментами одновременно. Команде продаж может потребоваться агент, который одновременно работает с CRM, почтовой системой и инструментом планирования. Чем больше точек интеграции, тем больше мест, где могут возникнуть сбои.
Критерии оценки поставщиков
Не все провайдеры предлагают одинаковый уровень поддержки после запуска агента. Команде следует поинтересоваться, как поставщик обрабатывает простои, какие возможности настройки доступны и как ценообразование зависит от использования. Ответы на эти вопросы часто важнее, чем первоначальная демонстрация, поскольку от них зависит, насколько долго продлятся отношения.
Создание и тестирование агента перед запуском.
Качество обучающих данных определяет все последующие этапы, поскольку эффективность агента зависит от того, на чем он учится. Команда поддержки, использующая устаревшую документацию, в итоге получит агента, дающего устаревшие ответы. Проверка исходных материалов до начала обучения позволяет выявить это на ранней стадии, а не после того, как это заметят клиенты.
Помимо самих данных, установление четких границ предотвращает превышение агентом своих полномочий. Агент без четко определенных ограничений может предложить скидку, которую он не имеет права утверждать, просто потому что ничто не запрещало ему это делать. Определение того, что агент может решить самостоятельно, а что требует одобрения человека, предотвращает подобные ситуации еще до их возникновения.
После того, как установлены правила и границы дозволенного, тестирование на реальных, не совсем корректных данных имеет большее значение, чем тестирование в идеальных условиях. Розничная компания, управляющая службой поддержки клиентов через оператора, может обнаружить, что она хорошо справляется с вежливыми, четко сформулированными вопросами, но испытывает трудности с раздраженными сообщениями, полными опечаток. Проведение короткого внутреннего пилотного проекта перед полномасштабным запуском, как правило, выявляет эти пробелы, пока их еще легко исправить.
Мониторинг, итеративный анализ и масштабирование после развертывания.
Первые несколько недель после запуска позволяют получить больше информации о реальном поведении агента, чем любое предзапусковое тестирование. Логистическая компания может обнаружить, что клиенты спрашивают о задержках доставки способами, которые не были предусмотрены обучающими данными. Тщательный мониторинг в этот период позволяет выявить эти пробелы до того, как они повлияют на большое количество взаимодействий.
Отслеживание производительности по ранее установленным показателям превращает мониторинг в действенный инструмент. Снижение коэффициента решения проблем может указывать на определенный тип вопросов, которые агент постоянно неправильно понимает. Еженедельный анализ этой закономерности, а не ожидание ежеквартальной проверки, упрощает корректировку работы агента до того, как мелкие проблемы усугубятся.
Как только производительность стабилизируется со временем, масштабирование становится разумным следующим шагом, а не гаданием. Компания может расширить штат агента поддержки для обработки вопросов, связанных с выставлением счетов, после нескольких месяцев стабильной работы с запросами по доставке. Каждое новое дополнение работает лучше всего, когда оно следует той же основе, заложенной на предыдущих этапах, от определения сценария использования до надлежащего тестирования.
Заключение
Успешное внедрение ИИ-агента сводится к последовательности действий. Пропуск этапа или спешка при переходе к следующему, как правило, приводят к проблемам на более поздних стадиях, когда их сложнее исправить. Компании, которые целенаправленно проходят каждый этап, в итоге получают агентов, которые действительно хорошо работают в реальных условиях.