Как говорить об ограничениях ИИ на продажных созвонах и в отчетах совету директоров

Почему основатели звучат оборонительно, когда говорят об ИИ

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

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

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

Совет директоров реагирует похожим образом, но по другой причине. Если одно обновление звучит как хайп, а следующее — как извинение, члены совета слышат риск. Они начинают думать, понимает ли команда вообще свой продукт, рынок или операционную модель. Проблема часто не в самом ИИ. Проблема — в нервном сообщении вокруг него.

Такой тон быстро расходится внутри компании. Продажи повторяют его на звонках. Продукт повторяет его на демо. Customer success использует тот же осторожный язык с клиентами. Вскоре у компании появляются три версии истории: смелая, осторожная и паническая, которая всплывает, когда кто-то задает трудный вопрос.

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

Что люди на самом деле хотят услышать

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

Начинайте с полезной части, а не с предупреждения. Скажите простыми словами, какую задачу ИИ уже хорошо решает сейчас. "Он готовит ответы в поддержку менее чем за 30 секунд" звучит лучше, чем "Мы используем продвинутые модели, чтобы улучшить сервисные процессы".

Потом назовите этап, где человеку все еще нужно проверить результат. Сузьте рамки. Люди больше доверяют фразе "Человек утверждает решения по возвратам и изменениям в договорах", чем "Человек остается в процессе". Вторая фраза звучит расплывчато, потому что она и есть расплывчатая.

После этого объясните, как вы ловите ошибки или рискованные ответы. Говорите обычным языком. Можно сказать, что система помечает ответы с низкой уверенностью, сверяет их с одобренными данными или отправляет отдельные случаи человеку до отправки. Большинству не нужен глубокий разбор модели. Им нужно понять, что у вас есть тормоз.

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

Короткий пример делает это понятнее. Представьте стартап, который использует ИИ для подготовки коммерческих предложений. Сильная версия звучит так: "ИИ пишет первый вариант и хорошо вытаскивает стандартные данные по пакетам. Человек все еще проверяет индивидуальные цены и обещания перед отправкой. Мы ловим рискованные черновики через правила и шаги утверждения". Это звучит честно и под контролем.

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

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

Формула, которую стоит использовать каждый раз

Большинство основателей попадают в неприятности, когда начинают с модели. Начинайте с задачи. Четкие границы звучат сильнее, чем расплывчатая уверенность.

Почти в любой комнате работает короткая цепочка: что ИИ делает сегодня, где ему еще нужна осторожность, что ловит ошибку и какого результата люди могут ожидать сейчас. Вот и вся формула.

Используйте простой язык. Избегайте терминов вроде "agentic workflow", если в комнате так уже не говорят. "Он готовит первые ответы на типичные обращения в поддержку" звучит лучше, чем экскурсия по вашему стеку.

Затем назовите один реальный крайний случай. Выберите самый важный, а не длинный список всего, что может пойти не так. Когда вы спокойно говорите об ограничении, вы звучите как человек, который управляет процессом, а не прячется от него.

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

Заканчивайте бизнес-результатом, который уже есть. Используйте цифру, если она у вас есть. Люди лучше запоминают результаты, чем архитектуру.

Версия на одну минуту

"Наш ИИ делает первый вариант ответов на входящие вопросы в поддержку по оплате и изменениям в аккаунте. Ему все еще нужна проверка человека, если в деле есть возвраты, необычные исключения из правил или раздраженный клиент. Такие случаи мы отправляем в очередь на проверку до отправки. Сейчас это сокращает время ответа на типовые запросы примерно с 6 часов до менее чем 30 минут без потери качества."

Этот ответ работает, потому что он не извиняется за ограничение. Он воспринимает ограничение как часть рабочего плана.

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

Такой спокойный, практичный язык — это еще и то, как многие опытные советники подходят к внедрению ИИ. В работе со стартапами Oleg Sotnikov часто возвращает разговор к тому, что уже работает, где человек все еще нужен и какой компромисс получается по цене, скорости или риску.

Как говорить об этом на продажных созвонах

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

Простой вариант звучит так: "Наш ИИ читает входящие счета и отмечает расхождения". Затем: "Необычные случаи он отправляет человеку вместо того, чтобы угадывать". Эта вторая фраза не ослабляет предложение. Она делает сделку безопаснее.

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

Шаблон легко повторить. Назовите дорогую проблему, скажите, что умеет продукт, обозначьте ограничение и объясните, почему эта граница защищает время, деньги или доверие.

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

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

Такой тон делает основателей спокойными, а не оборонительными. Вы не извиняетесь за ограничение. Вы показываете, что у продукта есть понятные границы и что вы умеете работать с ним в реальном мире.

Как говорить об этом на демо

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

Этот порядок важен. Большинство людей не ждут идеальной системы. Им нужно понять, что происходит в обычный день, как часто это работает и что вы делаете, когда не работает.

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

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

Хороший сценарий демо покрывает четыре пункта: что пользователь просит ИИ сделать, что система делает сама, что запускает человеческую проверку и что происходит после нее.

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

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

Как говорить об этом в отчетах совету директоров

Членам совета директоров не нужен тур по каждому промпту, модели или эксперименту. Им нужна ясная картина: что уже работает, где люди все еще нужны и какое решение вы от них хотите.

Начинайте с того, что уже изменило бизнес. Скажите, где ИИ сегодня экономит время, сокращает расходы или убирает рутинную работу. Будьте конкретны: поддержка готовит первые ответы за 40 секунд вместо 6 минут, или команда выпускает релиз-ноты вдвое быстрее. Если экономия пока небольшая, так и скажите.

Держите отчет в четырех частях: что уже работает в продакшене, что еще в тесте, какие риски в цифрах и какое одно решение вам нужно от совета.

Простые цифры успокаивают зал. "Помощник обработал 3 200 обращений, в 78% случаев не потребовалась правка человека, а 6% были ошибочными настолько, что потребовали полной переработки" звучит намного сильнее, чем "качество выглядит многообещающим". Члены совета могут оценить компромисс, когда вы даете им реальные числа и проценты.

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

Заканчивайте одним решением. Может быть, вам нужно одобрение, чтобы расширить пилот на еще одну команду. Может быть, вы хотите закрыть слабый эксперимент и перевести бюджет в процесс, который уже экономит деньги. Один четкий запрос дает лучшие ответы, чем расплывчатая просьба просто продолжать поддерживать ИИ-направление.

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

Простой пример из одного стартапа

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

На продажном созвоне покупатель из среднего интернет-магазина задает вопрос, которого многие основатели стараются избежать:

"Что происходит, когда ИИ ошибается и отправляет клиенту плохой ответ?"

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

Сильный ответ звучит просто и спокойно:

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

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

Он также дает покупателю конкретную картинку. Человек видит, где ИИ работает сам, где человек проверяет результат и как ловятся ошибки. Так продукт выглядит управляемым, а не безрассудным.

Бизнес-результат обычно лучше, чем расплывчатое обещание. В одном типичном сценарии покупатель соглашается на пилот, потому что риск выглядит ограниченным. Вместо спора о том, идеален ли ИИ, разговор переходит к рабочему процессу: какие типы обращений безопасно автоматизировать первыми, кто проверяет крайние случаи и как измеряется успех.

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

Ошибки, которые ослабляют сообщение

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

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

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

Три привычки вызывают большую часть проблем. Первая — обещать будущую правку вместо ответа на текущий вопрос. Если вас спрашивают: "Что происходит, когда ИИ ошибается?", а вы отвечаете: "Мы улучшим это в следующем релизе", доверие падает. Сначала дайте ответ на сегодня. Даже скромный ответ лучше, чем расплывчатое обещание.

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

Третья — говорить общими предупреждениями вместо одного конкретного примера. Один конкретный случай понять проще, чем облако общих оговорок.

Если хотите звучать уверенно, будьте конкретны, спокойны и честны там, где продукт берет на себя нагрузку.

Короткая проверка перед любой встречей

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

Начните с одной задачи. Назовите работу, с которой ИИ справляется хорошо, простыми словами, а не языком продукта. "Он готовит первые ответы на обращения в поддержку" — понятно. "Он использует продвинутую автоматизацию для улучшения сервисных процессов" — расплывчато и скользко.

Потом так же прямо назовите одно ограничение. Выберите то, что важнее всего для этой встречи. "Он может ошибаться на пограничных случаях с политиками" звучит лучше, чем "Как и любой ИИ, он несовершенен".

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

Добавьте одну цифру или один короткий пример. Цифры делают сообщение реальным. Например: "Он обрабатывает около 70% первых черновиков без правок" или "На прошлой неделе он экономил команде примерно 15 минут на каждом типовом обращении".

Быстрая командная проверка может выглядеть так:

• Что ИИ уже делает хорошо сегодня?
• Где он все еще не дотягивает?
• Что не дает плохому результату дойти до пользователя?
• Какое доказательство мы можем дать одной фразой?
• Ответят ли все в команде одинаково?

Последний вопрос важнее, чем многие думают. Если продажи говорят одно, продукт — другое, а CEO добавляет третью версию, зал перестает слушать детали. Люди начинают думать, что неясно и остальное.

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

Что делать дальше с командой

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

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

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

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

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

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

Если вашей команде нужна внешняя помощь, чтобы сделать сообщение точнее, Oleg Sotnikov на oleg.is работает со стартапами над архитектурой продукта, практическим внедрением ИИ и поддержкой Fractional CTO. Такая внешняя проверка особенно полезна, когда компания постоянно мечется между хайпом, осторожностью и путаницей.

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