INITE Protocol: 6 этапов на разобранном примере, с артефактами

О чём этот пост

INITE Protocol - методология из 6 этапов, по которой INITE ведёт каждый проект в B2B SME: Break, Hold, Track, Cut, Cast, Form. Названия служат ярлыками, и смысл большинства читатель угадает по слову. Передать сложнее другое, и это же опускает любой консалтинговый обзор методологий: что команда делает на каждом этапе, какие артефакты получаются и какие решения принимаются.

Об этом и пост. Он проходит по одному разобранному примеру - внедрению в фирме профессиональных услуг на 60 человек, из которых двенадцать консультантов приносят выручку. Фирма не названа, и опубликованного кейса INITE с её данными нет, поэтому цифры ниже - пример расчёта, который стоит повторить на своих числах, а не доказательство того, сколько даёт внедрение. Два рабочих воркфлоу запущены за 19 календарных дней от начала Cast, сборка стоила $24K. Первый год примерно выходит в ноль, отдача приходит во втором. Так обычно и выглядит первая автоматизация, и именно это большинство разборов показывать не хочет.

Все числа ниже относятся к этому примеру, и каждое выводится из другого числа на этой же странице: объёмы взяты из систем, часы - из объёмов, деньги - из часов по названной полной ставке. Где выгоду так посчитать нельзя, мы её называем и оставляем за пределами отдачи, вместо того чтобы вписать оценку. Среднего по клиентам INITE не публикует, потому что такого измеренного среднего нет. Сам протокол описан в lib/brand-canonical.ts (whatShipped), locales/<lang>/common/protocol.json и HowTo JSON-LD в components/StructuredData.tsx.

Этап 1 - Break (неделя 1-2): диагноз и перезагрузка

Break отвечает на один вопрос: есть ли здесь процесс, автоматизацию которого оправдывает арифметика? Если есть, идём дальше. Если нет, проект заканчивается на диагностике и ничего не строится.

Начинаем с интервью: CEO, COO и 1-2 сотрудника, которые делают работу руками. В этом проекте это были партнёр, ведущий практику, офис-менеджер и двое старших консультантов. Потом 4-8 часов ходим за людьми и смотрим, как целевой воркфлоу выполняется на самом деле. Выгружаем 90 дней операционных данных из систем фирмы (CRM, трекер проектов, биллинг, учёт времени) и расставляем по текущему процессу замеры: время шагов, пропускную способность, число ошибок. На выходе три артефакта.

1. Карта процесса с отмеченными узкими местами. Swimlane-диаграмма всех шагов целевого воркфлоу, где у каждой передачи указаны пропускная способность, доля ошибок и время цикла. В этом проекте мы расписали трёх кандидатов. (a) Квалификация входящих лидов: 34 лида в неделю, на каждый уходит 22 минуты операционного координатора (разобрать, внести в CRM, направить), всего 12,5 часа в неделю, и ещё 6 часов в неделю консультанты переделывают работу по неверно направленным лидам. Медианное время до первого ответа 38 часов, 24% лидов не получили ответа за пять рабочих дней. (b) Обновления статуса проектов: 26 активных проектов, по заметке в неделю, на заметку уходит 40 минут консультанта, всего 17,3 часа в неделю. (c) Сверка инвойсов с учётом времени: 8 часов в неделю офис-менеджера при доле ошибок 22%.

2. Отчёт о стоимости хаоса. Те же часы по полной стоимости: $95 в час за консультанта, $45 за операционного координатора и офис-менеджера. Это то, во что час обходится фирме, а не сумма из расчётного листка. Квалификация лидов стоит $1 133 в неделю, обновления статуса $1 647, сверка $360. Итого $3 140 в неделю, а в год $151K. Год мы считаем по 48 рабочим неделям, а не по 52, потому что отпуска и провальные недели автоматизация не убирает. С этим числом сверяется всё, что мы утверждаем дальше.

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

3. Матрица приоритетов. Каждый воркфлоу оценён по автоматизируемости (техника, 0-100) и по отдаче (бизнес, 0-100). Верх матрицы строится в Cast, низ откладывается, и это записано.

По отдаче квалификация лидов получила больше баллов, чем оправдывают её часы: в деньгах это меньшая из двух строк, $1 133 в неделю против $1 647. Матрица - единственное место, где мы позволили учесть неоценённый отвал лидов. Она ранжирует, а не суммирует, и в ранжировании допустимо суждение. В денежных расчётах оно недопустимо, поэтому дальше в посте отвал не входит ни в одну цифру. Матрица отличается от догадки тем, что прямо говорит, где в ней суждение, а где счёт.

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

Итог Break выглядел так. Два воркфлоу, которые стоит строить, обходятся фирме в $2 780 в неделю из $3 140, то есть в $133K в год. Модель исходила из того, что автоматизация вернёт 60% этих часов, а не все, потому что исключения остаются людям: $70-85K в год. Сборку оценили в $24K, мониторинг и настройку после неё - в $750 в месяц. Воркфлоу заработают в конце третьего месяца, так что в первом году выгода копится девять месяцев: около $52K против $33K затрат, чистыми примерно +$19K, окупаемость около девятого месяца. Во втором году, когда платить остаётся только за поддержку, около +$61K. Решили переходить к Hold.

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

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

Этап 2 - Hold (неделя 2-3): стабилизация и починка

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

Для каждого воркфлоу, который будет строиться в Cast, мы находим источники данных выше по потоку, правила проверки и точки передачи, на надёжность которых опирается автоматизация. Сломанное чиним. Для шагов, которые останутся за людьми, пишем SOP (стандартные операционные процедуры): новый воркфлоу всё равно будет отдавать людям пограничные случаи, и ручная часть должна работать одинаково. На выходе три артефакта.

1. SOP для ключевых воркфлоу. В этом проекте впервые записали правила разбора писем для входящих лидов: какой лид считается квалифицированным, что эскалируется, что отбрасывается. Ещё появился шаблон обновления статуса, который команда до этого каждый раз придумывала заново, и требования к полям CRM: какие обязательны при приёме лида, а какие при конверсии.
2. Исправленные данные. В CRM у источника лида было три значения там, где нужно одно ("website", "web", "Website"), мы свели их в одно. В трекере проектов было 4 активных статуса, а команда пользовалась тремя, лишний убрали. В почте за 5 лет накопилось 14 правил входящих писем, половина не работала, оставили 6 действующих.
3. Быстрые ручные исправления, которые сразу экономят время. Два узких места в квалификации лидов удалось убрать без всякого AI. Одно было правилом пересылки, которое отправляло лиды на автоответчик сотрудника в отпуске. Другое - ошибкой с обязательным полем в CRM, из-за которой консультанты вводили одни и те же данные дважды. Оба исправили в Hold, до начала Cast. Один только Hold сэкономил команде около 6 часов в неделю ещё до появления какой-либо автоматизации. Эти часы входят в цифры 12-й недели ниже, а не добавляются к ним, потому что один час нельзя посчитать дважды.

Большинство методологий «AI-пилотов» этот этап пропускают, а именно от него зависит, будут ли у воркфлоу из Cast стабильные входные данные. Если LLM-воркфлоу получает разнобой в источниках лидов, двусмысленные статусы и письма, попавшие не в тот ящик, на выходе будет мусор, и команда обвинит в этом AI. Hold отвечает за то, чтобы основа была чистой.

Этап 3 - Track (неделя 3-4): измерение и анализ

Track выясняет, как процесс выглядит, когда его измеряют в работе, а не по карте, нарисованной в Break со слов людей.

Каждый шаг воркфлоу мы снабжаем журналом событий с отметками времени. Обычно это лёгкая прослойка, которая записывает события процесса (лид получен, квалифицирован, конвертирован, обновление статуса отправлено и так далее) со временем, исполнителем и результатом. За 2-3 недели собираем данные по процессу, уже приведённому в порядок в Hold, и ищем повторы, которых статичная карта не показала. На выходе три артефакта.

1. Дашборд KPI с живыми метриками. KPI каждого воркфлоу в реальном времени, которые дальше отслеживаются на Cast и Form. В этом проекте это время цикла воркфлоу, пропускная способность на консультанта, доля вмешательств (как часто оператор отменяет автоматическое решение) и доля ошибок. Дашборд появляется в Track и работает на всех следующих этапах, команда смотрит в него каждый день.
2. Отчёт о найденных повторах. Неочевидное, что показали замеры. В этом проекте выделились три вещи. (a) 31% входящих лидов приходили с 18:00 до 8:00 по местному времени, когда в ручном процессе никто не дежурил, и такие лиды лежали без ответа 12-16 часов. Команда этого не знала, потому что в нерабочее время никто не смотрел. (b) Большую часть обновлений статуса отправляли одной пачкой в пятницу после обеда, поэтому клиентам отчётность казалась рваной, а внутри фирмы этого никто не замечал: изнутри получался ровный недельный ритм. (c) Два консультанта, писавшие самые длинные обновления, оказались теми же двумя, у чьих проектов самая высокая доля продлений. Два человека - не выборка, и ничего это не доказывает. Но этого хватило, чтобы не настраивать автоматизацию на краткость, а такое решение дашборд за вас не примет.
3. Оценки автоматизируемости по шагам. Для каждого шага каждого воркфлоу записано, стоит ли его автоматизировать (большой объём, чёткие входные данные, понятный критерий успеха) или оставить людям (малый объём, неоднозначные входные данные, нужны суждения). В этом проекте квалификация лидов получила 82/100 (хорошо автоматизируется), черновик обновления статуса - 76/100 (автоматизируется, если человек проверяет результат), а финальная отправка клиенту - 38/100 (остаётся за человеком даже после черновика от AI).

Track превращает догадку из Break («этот процесс, похоже, медленный и с ошибками») в спецификацию для Cast («у этого воркфлоу узкие места вот на этих шагах, и данные там вот такие»). Команда, которая пропускает Track, строит в Cast решение не той задачи.

Этап 4 - Cut (месяц 2): упрощение и устранение

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

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

1. Упрощённые процессы. Вычищенная версия каждого целевого воркфлоу, готовая к автоматизации. В этом проекте квалификация лидов сократилась с 11 шагов до 6. Убрали пять: повторный ввод данных (CRM обновляли дважды по историческим причинам, которые перестали действовать 18 месяцев назад), лишнее согласование у менеджера (его ввели после давнего инцидента с качеством, который давно разрешён), два письма со статусом, которые никто не читал (мы померили открываемость: 4% и 7%), и ручную выгрузку данных для отчёта, который больше никто не запускал.
2. Число и виды убранных шагов. По двум целевым воркфлоу убрано 9 шагов из 22, то есть 41%. Доля высокая, и у неё конкретная причина: фирма 4 года не пересматривала процессы, и лишнее накопилось. По видам: 4 повторных ввода данных, 2 лишних согласования, 2 мёртвых уведомления, 1 ручная выгрузка в мёртвый отчёт.
3. Спецификации для автоматизации. Для каждого оставшегося шага, который будет автоматизирован, написана спецификация: какие данные приходят на вход, что считать успехом, как обрабатывать ошибки, куда эскалировать, какие метрики отслеживать. По ней строится Cast, а проверка объёма одна: операционный руководитель должен прочитать её целиком за один присест, а не пролистать. Обе спецификации в этом проекте проверку прошли. Письменная спецификация защищает от самого частого провала Cast, когда разработчики строят не то, о чём операционная команда договорилась в Track.

Большинство инициатив вида «давайте добавим AI», которые запускает CTO, пропускают Cut, потому что никому не хочется спорить с командой из-за любимого шага. Мы спорим. Спор решают цифры: к каждому решению об удалении прикладывается объём шага из Track. Команда без Cut в итоге автоматизирует хаос и закрепляет его.

Этап 5 - Cast (месяц 2-3): сборка и запуск

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

Каждый воркфлоу мы строим по спецификации, замороженной в Cut, и запускаем в рабочей среде с живыми пользователями, а не на демо-стенде или в песочнице. Мониторинг подключаем до запуска. Воркфлоу встраиваются в инструменты, которыми команда уже пользуется (CRM, почта, трекер проектов), и ничего из них не заменяют.

Если проект строится на экосистеме Inite (см. отдельный пост про общую среду исполнения @inite/*), Cast использует готовое: @inite/assistant исполняет LLM, @inite/inbox служит каналом разговоров, @inite/api-kit - обёрткой запросов, @inite/incidents - путём эскалации к человеку, а @inite/security маскирует персональные данные в журнале аудита. С готовой инфраструктурой Cast сводится к тому, чтобы большую часть настроить и дописать логику предметной области, вместо того чтобы строить всё. В этом проекте квалификация лидов прошла от заморозки спецификации до живых лидов за 8 календарных дней. На выходе три артефакта.

1. 1-3 автоматизированных воркфлоу в рабочей среде. В этом проекте их два. (a) Квалификация лидов работает в CRM и почтовом ящике: все входящие лиды теперь проходят разбор через AI, и оператор может вмешаться на любом шаге. (b) Обновления статуса проекта работают в трекере проектов и почте: воркфлоу готовит черновики, консультант их проверяет и отправляет. Оба воркфлоу заработали в течение 19 календарных дней от начала Cast.
2. Встраивание в инструменты фирмы. Нового дашборда, который команде пришлось бы осваивать, нет. Воркфлоу лидов виден как правила автоматизации и комментарии от AI внутри привычной CRM. Воркфлоу обновлений статуса появляется черновиками в обычном окне написания письма. Ежедневные инструменты команды не изменились, AI работает внутри них незаметно, как водопровод. Пилоты чаще всего гибнут оттого, что ими не начинают пользоваться, и Cast обходит эту беду за счёт того, что ничего не меняет в привычных инструментах. Через реестр инструментов @inite/assistant воркфлоу доступны любому агенту, которому нужно их вызвать, включая MCP-совместимых агентов, которыми CTO фирмы пользуется для code review.
3. Обучение команды и передача. На каждый воркфлоу проводим 90-минутную живую сессию с командой, которая будет с ним работать, и оставляем письменный runbook на 3-5 страниц. В нём описано, как воркфлоу работает в обычном режиме, на какие метрики смотреть, что делать при срабатывании алерта, кто внутри фирмы за него отвечает и как связаться с нами. Runbook ведёт в Form.

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

Этап 6 - Form (месяц 3-6): настройка и масштабирование

Form проверяет, проработает ли запущенный воркфлоу 12 месяцев живого использования и остаётся ли у команды умение, а не разовый проект.

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

1. Дашборд мониторинга. Дашборд KPI из Track, теперь подключённый к рабочим воркфлоу. Внутренний владелец смотрит его каждый день. Замеры 12-й недели против бейзлайна, который оператор подписал в конце Track: медианное время до первого ответа на входящий лид сократилось с 38 часов до 1,4 часа, доля лидов без ответа за пять рабочих дней - с 24% до 9%, время операционного координатора на разбор лидов - с 12,5 до 3,5 часа в неделю, время консультантов на обновления статуса - с 17,3 до 5,2 часа в неделю, переделка консультантами по неверно направленным лидам - с 6 до 1,5 часа в неделю. Исключения по-прежнему уходят человеку, поэтому ни одна цифра не падает до нуля, а предложение, которое обещает ноль, стоит читать внимательно.
2. Настройка по реальному использованию. За первые 90 дней прошло четыре раунда настройки. На 3-й неделе классификатор слишком охотно записывал пограничные лиды в неквалифицированные. Порог сдвинули, и операционный координатор перестал каждое утро перепроверять отбракованное. На 6-й неделе черновики выходили слишком общими, и мы добавили подтягивание контекста по клиенту из трекера проектов. На 9-й неделе эскалаций стало так много, что их начали игнорировать, и перед ними поставили фильтр по уверенности модели. На 12-й неделе журнал переопределений показал три типа лидов, которые никогда не должны квалифицироваться автоматически, и для них появились жёсткие правила. Ничего из этого нельзя было сделать до запуска, потому что этих данных ещё не существовало.
3. План следующей волны автоматизации. Когда платформа работает, у команды освобождается время. Мы записали 4 кандидата на следующий цикл: сверку инвойсов с учётом времени, отложенную в Break (теперь она возможна, потому что Hold вычистил данные), автоматизацию приёма новых клиентов, помощника для написания коммерческих предложений и автоматизацию квартальных отчётов для клиентов. Каждый оценён по той же матрице автоматизируемости и ROI, что и в Break. Фирма выбрала два на Q3-2026, их границы мы определим отдельным проектом.

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

Сколько стоил проект и что он дал

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

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

Что такое протокол в одном предложении

INITE Protocol - методология, выстроенная от конца, от вопроса «проработал ли воркфлоу 12 месяцев живого использования?». Break, Hold и Track отвечают за то, чтобы арифметика была настоящей. Cut - за то, чтобы автоматизировать стоило то, что осталось. Cast выпускает рабочий софт под вычищенный процесс. Form закрепляет изменение. Деньги на AI-консалтинг пропадают, когда пропускают любой из шести этапов. Когда проходят все шесть, воркфлоу продолжает работать и в следующем квартале после нашего ухода.