Почему большинство корпоративных чат-ботов разочаровывают — и что вместо этого стоит создавать

Чатбот отвечает; бизнес закрывается

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

Никакая работа не заключается в получении ответа. Кто-то должен выдать возврат средств, одобрить заказ, перенаправить установку, подтвердить претензию по гарантии или заключить контракт с юридическим отделом. Ответ — это просто середина этого процесса. Система, которая останавливается на ответе, возвращает работу тому, кто пытался ее передать.

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

Три пути к сбою

Большинство разочаровывающих развертываний имеют несколько общих черт:

• Отсутствие доступа к живым системам. Бот обучен на документах. Вопрос клиента касается его заказа, его счета или его аккаунта. Бот без доступа к системе заказов может говорить только общими фразами, а общие фразы уже есть на странице FAQ.
• Неспособность действовать. Даже зная ответ, он не может выполнить действие. Каждое общение заканчивается перенаправлением, поэтому бот добавляет шаг вместо того, чтобы его устранить.
• Отсутствие определения "завершения". Никто заранее не согласился, что хороший результат выглядит так, поэтому никто не может сказать, работает ли он. Показатели использования растут, объем контактов в центре поддержки не снижается, и проект тихо прекращает обсуждение.

Под всеми этими аспектами лежит одно решение: проект был масштабирован как канал — новый способ общения с компанией, а не как способность выполнять больше работы с теми же людьми.

Создайте завершитель задач вместо этого

Альтернатива не более сложна. Она узкая и глубокая.

Выберите одну высокопроизводительную задачу. Не тему, а задачу — "перенаправить доставку", а не "вопросы логистики". Это происходит сотни раз в месяц и следует известному пути.

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

Затем определите, что делать, когда он не может завершить задачу. Это часть, которую большинство проектов пропускают, и она делает больше для доверия, чем любое количество настройки модели. Определите условия, при которых он останавливается и передает человеку — низкая уверенность, необычное состояние аккаунта, все, что связано с деньгами выше определенного порога — и сделайте передачу контекста полной, чтобы клиент не повторял себя. Система, которая чисто завершает 60% случаев и передает остальное с подробным резюме, превосходит систему, которая пытается выполнить 100%, и получает половину из них неправильно.

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

Что это меняет в плане

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

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

Мы строим второй тип. Первый тип легче запустить, но гораздо сложнее поддерживать.