Как мы добавили ИИ-ассистента в SaaS-платформу — и ничего не сломали

Каждая SaaS-команда, с которой мы общаемся, рано или поздно произносит вслух одну и ту же фразу: «Нам стоит встроить сюда ИИ-ассистента». Иногда это давление совета директоров, иногда запуск конкурента, иногда искреннее желание. Интересна тут никогда не сама идея — она есть почти у всех. Интересен разрыв между этой фразой и функцией, на которую реальные пользователи действительно полагаются. Это история одной команды, которая этот разрыв преодолела, и неброских решений, которые их к этому привели.

Небольшая оговорка перед началом: клиента мы анонимизировали, а цифры округлили. Это небольшая прибыльная B2B SaaS-компания — меньше двадцати человек — которая продаёт инструмент для рабочих процессов операционным командам. Мы изменили достаточно деталей, чтобы вы их не узнали, но форма проекта ровно такая, какой была на самом деле. Цифры иллюстративные, а не проверенные аудитом; мы предпочитаем показать вам закономерность, а не приукрашивать график.

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

Ситуация: две проблемы в одном костюме

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

Их было не одна. Под этим единственным запросом скрывались две совершенно разные боли. Первая — нагрузка на поддержку: команда клиентского сервиса из двух человек тонула в повторяющихся обращениях — «как это экспортировать», «где настройка для того», «почему не сформировался мой отчёт». Примерно 60 % входящих обращений были вопросами, ответы на которые уже где-то были в их справке. Вторая боль была тише и дороже: активация. В их продукте была по-настоящему мощная функция, спрятанная на три клика вглубь, которую почти никто не находил сам. Пользователи, которые её находили, оставались годами. Те, кто не находил, уходили в первые два месяца.

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

Сужаем объём до того, что реально закончить

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

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

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

Первый прототип, который мы построили — и удалили

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

Модель была уверенно неправа. На вопрос о настройке, переименованной полгода назад, она бодро придумывала старый путь в меню. На вопрос о функции старшего тарифа объясняла, как ею пользоваться — клиенту, у которого к ней не было доступа. Каждый ответ звучал авторитетно, что делало ошибочные хуже, чем отсутствие ответа. Бот поддержки, который вежливо лжёт, не снижает число обращений; он порождает более злые.

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

Что мы построили на самом деле

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

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

Опора на источники важнее изобретательности

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

Изящная передача человеку

Когда ассистент не был уверен, он не гадал. Он говорил об этом и предлагал переход к человеку в один клик — унося с собой контекст разговора, чтобы пользователю не пришлось повторяться. Вопреки интуиции, это заставило людей больше доверять боту: ассистент, признающий свои границы, кажется честным, и на лёгкие 60 % они полагались на него именно потому, что на трудных 40 % он отступал.

Знает, кто спрашивает

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

1. 1
   Очистили и структурировали базу знаний

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

   Сначала поиск, потом ответ. Модель всегда видела только выверенный, актуальный контент — с указанием отказываться от всего, что нельзя опереть на источник.
3. 3
   Подключили контекст продукта

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

   Построили путь «я не уверен — вот человек» как полноценную функцию, с полным контекстом разговора, переданным команде поддержки.
5. 5
   Выкатили на 10 % пользователей за флагом

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

Результаты — и тот, что нас удивил

После того как ассистент проработал для всех около трёх месяцев, картина стала ясной. Дадим вам округлённые, иллюстративные цифры — направление важнее десятых долей.

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

Но результат, который на самом деле удивил основателя, был тем, под который мы вообще не оптимизировали. Поскольку ассистент целый день отвечал на вопросы «как сделать X», он естественным образом постоянно направлял пользователей к той спрятанной, удерживающей функции — той, что связана с удержанием. Ассистента активации мы ещё не построили. Бот поддержки тихо выполнял часть его работы как побочный эффект — просто будучи полезным и знающим продукт. Новые пользователи находили функцию на недели раньше, чем прежде.

Что мы сказали бы следующей команде

Если вы SaaS-команда, глядящая на ту же фразу «нам стоит добавить ИИ-ассистента», несколько выводов из этого проекта хорошо обобщаются и за его пределами.

• Разделите проблемы, прежде чем строить. «ИИ-чатбот» почти всегда скрывает две-три разные задачи, которым нужен разный дизайн.
• Начинайте со сценария, где неверный ответ обходится дешевле всего. Отклонение обращений в поддержку — почти идеальный первый ход; запасной вариант — статус-кво.
• Заложите большую часть усилий на контент, а не на модель. Опора на чистые, актуальные данные — то, что делает ассистента заслуживающим доверия.
• Сделайте «не знаю» функцией, а не провалом. Честная передача человеку строит доверие, из-за которого пользователи полагаются на то, что бот делает хорошо.
• Сначала выкатите за флагом на небольшую долю. Реальные разговоры научат вас тому, чего не покажет ни одна демонстрация.

Частые вопросы