AI-операторы в бизнес-процессах: что по-прежнему остаётся за людьми

Почему накапливаются промежуточные уровни

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

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

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

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

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

Мелкие согласования создают самые медленные петли. Запрос ждёт менеджера, потом финансистов, потом юристов, потом ещё кого-то, кто «просто быстро посмотрит». Каждое согласование по отдельности выглядит незначительно. Вместе они превращают простую задачу в два дня ожидания.

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

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

Что AI может снять с плеч людей

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

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

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

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

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

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

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

Что всё ещё должно оставаться за назначенным человеком

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

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

То же правило действует, когда цели конфликтуют. Процесс может дойти до точки, где скорость спорит с точностью, продажи — с маржой, а удовлетворённость клиента — с политикой компании. AI может показать этот компромисс, но человек должен решить, какая цель важнее именно сейчас, и принять последствия.

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

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

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

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

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

Как нарисовать путь исключений

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

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

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

Рабочая схема простая. Определите триггер, который ломает обычный поток. Назначьте одного человека, который отвечает за этот триггер. Задайте время реакции, например 15 минут или 4 рабочих часа. Дайте AI чёткое правило остановки и понятное сообщение для эскалации. Потом запишите финальное решение простым языком.

Правило остановки должно иметь реальные границы. Фраза «эскалировать, если не уверен» звучит нормально, но на практике не работает, потому что AI будет неуверен по-разному. Напишите, что именно значит остановка. Например: «Остановиться и эскалировать, если сумма договора выше 10 000 долларов, если условия оплаты отличаются от шаблона или если уверенность ниже 85%». Такое правило уже можно проверять.

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

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

Как двигать один процесс шаг за шагом

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

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

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

Хороший запуск должен быть узким. Выберите один повторяемый сценарий с понятным входом и понятным завершением. Нарисуйте реальный путь, включая ожидания, согласования и переделки. Уберите задачи, которые только создают статус, но не меняют результат. Потом дайте AI одну функцию — например, сортировку, follow-up или черновик — и назначьте одного человека, который подключится, когда правила скажут остановиться.

Узкий фокус очень важен. Не просите AI «вести онбординг» или «управлять поддержкой». Попросите его сортировать входящие запросы, собирать недостающие детали или готовить первый черновик для проверки. В human-in-the-loop workflows маленькие победы лучше больших обещаний, потому что команда видит, где инструмент помогает, а где ошибается.

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

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

Простой пример для небольшой команды

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

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

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

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

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

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

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

Такой подход сохраняет скорость в быстрых частях. Он также делает human in the loop workflows понятными, потому что у каждого исключения есть один владелец, а не три человека, которые гадают в чат-переписке.

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

Ошибки, которые создают ещё больше работы

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

Именно поэтому автоматизация часто разочаровывает в начале. С моделью может быть всё в порядке. Ломается процесс вокруг неё.

Одна из самых частых ошибок — расплывчатые правила. Команды пишут промпты вроде «сначала обрабатывай срочные запросы» или «отмечай рискованные заказы» и предполагают, что AI сам поймёт то же самое, что имеет в виду каждый менеджер. Не поймёт. Дайте пороги, разрешённые действия и несколько простых примеров. Если возврат свыше 300 долларов требует проверки, так и скажите. Если отсутствие налоговых данных означает стоп, скажите и это тоже.

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

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

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

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

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

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

Быстрые проверки перед неделей запуска

Процесс должен ощущаться скучным, прежде чем вы покажете его клиентам, подрядчикам или деньгам. Если команда всё ещё говорит «разберёмся, если случится что-то странное», поток ещё не готов.

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

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

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

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

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

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

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

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

Одна эта привычка уже сильно помогает. Многие AI-проекты проваливаются по скучной причине: все предполагают, что кто-то другой поймает странные случаи.

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

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

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

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