Обработка исключений в AI: почему ломаются планы чисто AI-команд

Почему чисто AI-команды рано начинают буксовать

Большинство планов для чисто AI-команд выглядят надежно примерно неделю.

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

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

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

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

Одна пропущенная исключительная ситуация может еще и сломать обещание, которое компания уже дала. Если в продукте написано «настройка в тот же день» или «поддержка в течение 24 часов», один необычный случай может сделать это обещание ложным для клиента, которому было нужно больше всего внимания. Клиенту неважно, что внутри компании случай выглядел мелким. Ему важно, что обещание не сработало.

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

Oleg Sotnikov выстраивал AI-first-операции в масштабе, и урок здесь довольно прямой: автоматизировать обычный сценарий легко. Сложнее решить, кто подхватывает странные случаи, как быстро он отвечает и какие правила использует, когда сценарий больше не совпадает с реальностью.

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

Как на самом деле выглядит исключение

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

Один частый пример — форма с неполными или противоречивыми данными. Клиент вводит одно название компании в первом поле, другое в счете и оставляет налоговый номер пустым. Модель может догадаться, что имелось в виду, но догадка все равно риск. Если процесс пойдет дальше, плохие данные могут оказаться в договоре, отгрузке или карточке клиента.

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

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

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

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

Почему в цикл снова попадает основатель

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

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

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

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

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

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

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

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

Как выстроить медленную ветку

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

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

Постройте путь проверки

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

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

Для каждой группы задайте время ответа. Используйте простые ориентиры: 15 минут, 4 часа или следующий рабочий день. Избегайте расплывчатых правил вроде «скоро» или «по необходимости». Людям нужны временные рамки так же, как и AI.

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

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

Установите правила, которые защищают обещание

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

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

Проверяющим тоже нужны короткие правила. Большинство команд здесь ошибается. Они отправляют крайние случаи человеку без рамки, и каждый проверяющий отвечает по-своему. Короткий набор правил делает медленную ветку единообразной: одобрять только если запрос соответствует письменной политике, отклонять если AI что-то угадал или пропустил проверку, задавать один уточняющий вопрос, если недостающее факт может закрыть кейс, и эскалировать только тогда, когда решение меняет стоимость, риск или обещание клиенту.

Клиент не должен ощущать передачу как тишину. Напишите сообщение о задержке до запуска. Сделайте его коротким и конкретным. «Нам нужна ручная проверка этого запроса. Мы ответим до 15:00 завтра» работает лучше, чем расплывчатое извинение, потому что дает и причину, и срок.

Каждая проверка должна оставлять след. Фиксируйте решение, причину и сигнал, который вызвал передачу. После десяти или двадцати случаев паттерны появляются быстро. Может выясниться, что половина исключений идет из одного пустого поля в форме или из одной строки политики, которую AI читает неправильно.

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

Простой пример стартапа

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

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

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

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

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

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

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

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

Ошибки, которые создают лавину исключений

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

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

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

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

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

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

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

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

Oleg Sotnikov часто говорит об AI-first-операциях в практических терминах, и здесь это мышление действительно помогает. Скорость появляется из ясных правил, отдельных путей для рискованной работы и заметок, которые живут дольше одного разговора. Если вашей команде нужно меньше отвлечений, начните с этого. Медленная ветка с записанными решениями лучше быстрой ветки, построенной на догадках.

Быстрые проверки перед запуском

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

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

Хорошо работает короткий предзапусковой чек-лист:

• Проверьте грязные случаи, а не чистые демонстрации, и посмотрите на точный момент, когда AI просит проверку.
• Дайте каждой группе исключений одного понятного владельца вместо того, чтобы отправлять каждый странный случай основателю.
• Передайте шаги проверки новичку в команде. Если он застрял, значит процесс живет в голове у одного человека.
• С первого дня отслеживайте две цифры: сколько исключений ждут рассмотрения и сколько времени занимает проверка.

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

Цифры по очереди важнее, чем думает большинство основателей. Очередь из 12 ожидающих проверок со временем ответа 20 минут выглядит управляемой. Очередь из 80 с задержкой в 9 часов значит, что медленный путь уже не работает, даже если автоматический путь на бумаге все еще выглядит нормально.

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

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

Что делать дальше

Начните с одного обещания, которого клиент ждет каждый раз. Сделайте его ясным и измеримым. Например: «Мы отвечаем каждому квалифицированному лиду в течение 30 минут» или «Каждый счет проверяется перед отправкой».

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

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

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

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

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

Вот здесь дизайн AI-first-команды и становится реальным. Вопрос уже не в том, «Можем ли мы это автоматизировать?», а в том, «Что ломается, кто это ловит и как быстро мы восстанавливаемся?»

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