# INITE — Full Content Dump > Turn chaos into profit with AI automation INITE builds shared infrastructure for intelligent operations and applies it through INITE Solutions and vertical products. We deploy 1-3 workflows in production in 2-4 weeks and hand them to the client's own team; if diagnostics cannot show a payback, we do not build. Source URL: https://inite.ai Locale: ru Generated: 2026-09-11T03:51:53.160Z --- # Небольшая студия автоматизации или крупный консалтинг URL: https://inite.ai/ru/blog/ai-automation-agency-vs-big-consulting Date: 2026-09-10 Author: Anton Fenix Category: Comparison Tags: Comparison, Procurement, Operations, AI Automation ## Direct Answer Выбор обычно ставят как цену против надёжности, и в таком виде он прячет то, что действительно различается. Крупный консалтинг продаёт метод и имя, которое можно назвать совету директоров; писавшие предложение редко оказываются теми, кто пишет код, а минимальный размер работы задан их структурой затрат, а не вашим процессом. Небольшая студия продаёт самих сборщиков: меньше процесса, меньше запаса на случай ухода человека и куда более короткий путь от вопроса к ответу. Решать стоит по четырём вещам: кто несёт решение о границах, кто будет в комнате, какой самый маленький осмысленный объём работы и что останется у вас в день окончания. ## Key Facts - Автор предложения и человек, пишущий код, в крупной фирме обычно разные люди, а в маленькой один и тот же. - Минимальный размер работы в крупном консалтинге задан его структурой затрат, а не размером вашего процесса. - Один неавтоматизированный процесс часто оказывается ниже порога, при котором крупная фирма может взяться с прибылью. - Непрерывность - настоящее преимущество размера, и за неё стоит платить, когда работа идёт годами, а не неделями. ## Как этот выбор обычно подают Маленького против крупного обычно подают как дешёвое против надёжного. Описывать выбор так удобно, и объясняет это почти ничего, потому что различаются варианты в том, на чём ценника нет. ## Кто несёт решение о границах Это главное, и спрашивают об этом реже всего. В крупной фирме те, кто собирает вашу операционную деталь, те, кто оценивает работу, и те, кто её строит, - часто три разные группы. На каждой передаче деталь теряется, и выживает та версия границ, которая укладывается в коммерческую форму контракта. В небольшой студии это обычно один человек: потерь нет, риск сосредоточен. В любом случае решение о том, что стоит строить, должно оставаться у вас, а не у стороны, чей доход растёт вместе с ним, - тот же структурный довод, что и в тексте [агентство или фрилансер](/ru/blog/ai-automation-agency-vs-freelancer), только в большем размере. ## Кто будет в комнате Спросите прямо, будут ли выступающие теми же, кто станет делать, и попросите имена. Скандала не будет ни в одном из ответов, это просто сведения. Фирма, у которой есть команда предложения и команда поставки, может так и сказать и объяснить, как деталь переносится между ними. Та, что ответить не может, уже рассказала, что будет после подписи. ## Как выглядит самый маленький кусок Порог есть у всех. У крупной фирмы он задан структурой затрат и обычно заметно выше стоимости автоматизации одного процесса. Придите туда с одним процессом - и границы вырастут до порога. Не из нечестности, а из арифметики. Это практическая причина, по которой [покупателю с одним процессом лучше у того, кто берёт один процесс](/ru/answers/alternative-to-big-consulting-for-ai). И это же причина, по которой [с чего начинать автоматизацию](/ru/blog/what-to-automate-first-in-a-small-company) - вопрос с настоящим ответом для небольшой студии и неудобный для большой программы. ## Что остаётся у вас потом Код, доступы, документация, написанная для владельца, и названный человек с вашей стороны, у которого есть мнение о конструкции. Именно здесь сосредоточенность знаний в небольшой студии либо становится риском, либо перестаёт им быть, и разница целиком в том, отнеслись ли к передаче как к этапу или как к последнему дню. ## В каком порядке решать Границы, потом люди, потом порог, потом собственность. Цена пятой, и только когда оба итога включают двенадцать месяцев эксплуатации рядом со сборкой, - это арифметика из текста [как читать предложение на автоматизацию](/ru/blog/how-to-read-an-automation-quote). Всё, что решено раньше ответа на эти четыре, решено по бренду, а бренд ваш процесс собирать не будет. ## FAQ ### Крупный консалтинг надёжнее? Он непрерывнее, а это другое свойство. Уйдёт человек - есть скамейка, идёт работа годами - есть фирма, которая через эти годы всё ещё будет существовать. На длинных программах за это стоит платить. Чего это не покупает, так это лучшего решения о том, какой из ваших процессов автоматизировать первым, потому что решение зависит от операционной детали, а собиравшие эту деталь часто не те, кто оценивал работу, и не те, кто будет её делать. ### Где небольшая студия проигрывает по-настоящему? В непрерывности и в широте. Один-два человека, глубоко понимающие ваш процесс, - это риск, сосредоточенный в одном-двух людях, и честный ответ на него - передача: документация, написанная для владельца, названный человек с вашей стороны и код, который держите вы. Небольшая студия к тому же не поставит пять параллельных потоков сразу, поэтому программа, которой это действительно нужно, - не её задача, и сказать об этом входит в работу хорошей студии. ### Как размер работы влияет на выбор? У крупной фирмы есть порог, ниже которого она не может взяться с прибылью, и порог этот обычно заметно выше стоимости автоматизации одного процесса. Когда покупатель с одним процессом приходит туда, где минимальная осмысленная работа - это программа, границы растут к порогу, а не к задаче. Это не нечестность, это арифметика. И это же причина, по которой первый вопрос к любой из сторон - как выглядит самый маленький кусок работы, который они возьмут. ### По чему решение должно приниматься на самом деле? По четырём вещам в таком порядке: кто несёт решение о границах, будут ли оценивавшие работу теми же, кто её сделает, каков самый маленький осмысленный объём и что останется у вас в день окончания отношений. Цена идёт пятой, и только после того, как итоги сделали сравнимыми, поставив рядом сборку и двенадцать месяцев эксплуатации. Всё, что решено до ответа на эти четыре, решено по бренду. --- # Как выбрать между двумя подрядчиками, которые оба сказали «да» URL: https://inite.ai/ru/blog/choosing-between-two-automation-vendors Date: 2026-09-08 Author: Anton Fenix Category: Operations Tags: Operations, Procurement, Comparison, ROI ## Direct Answer Когда обе сметы читаются одинаково убедительно, цена - худший способ решить: меньшее число обычно описывает меньше работы, а не ту же работу дешевле. Развести их можно пятью вопросами. Какую базу вы измерили и как. Сколько выходит сборка плюс двенадцать месяцев эксплуатации. Что вы отказались бы для нас строить. Кому принадлежит код и ключи от аккаунтов в день, когда мы расстанемся. И что произойдёт, когда система, с которой вы интегрируетесь, сменит форму. У каждого есть правильный ответ, который чего-то стоит отвечающему, и потому все пять говорят больше, чем цена. ## Key Facts - Более дешёвое предложение обычно описывает меньше работы, а не ту же работу по меньшей цене. - Цена сборки плюс двенадцать месяцев эксплуатации - единственный итог, по которому два предложения сравнимы. - Подрядчик, не способный назвать, что он строить откажется, ещё не смотрел на ваш процесс. - Принадлежность кода и доступов решается в день передачи или в день ссоры. ## Проблема двух разумных чисел Два подрядчика, два предложения, оба убедительны, одно дешевле. Первый порыв - считать разницу эффективностью. А она ею почти никогда не бывает. Границы в итоговой сумме не видны. Одно предложение заложило маршрут исключений, сверку и месяц донастройки после запуска. Второе заложило маршрут, где всё идёт правильно, а остальное встретит запросами на изменение. Ни то, ни другое не враньё. Они описывают разную работу, и итоги скрывают, какую именно. ## Пять вопросов, ни один не про цену **Какую базу вы измерили и как?** Подрядчик, не способный сказать, откуда взялось текущее число, потом будет свободен придумать сравнение, когда проекту понадобится результат. Число «до» обязано существовать раньше, чем «после», - в этом весь довод текста [что обязан произвести аудит процессов](/ru/blog/process-audit-before-automation). **Сколько выходит сборка плюс двенадцать месяцев эксплуатации?** Расход на вашем настоящем объёме, хостинг, мониторинг и часы человека на то, что процесс возвращает обратно. Последний пункт в большинстве смет отсутствует и часто оказывается крупнейшим. Одна сумма - и большинство таких решений разрешается само, на той же арифметике, на которой держится [чтение предложения](/ru/blog/how-to-read-an-automation-quote). **Что вы откажетесь для нас строить?** Полезный ответ конкретен: решение, которое должно остаться за человеком, источник данных, слишком ненадёжный для основания, шаг, объём которого не окупает работу. Тот, кто построит всё, смотрел на бюджет, а не на процесс. **Кому принадлежит код и ключи?** Где он лежит, кто его читает, на чьих аккаунтах доступы и что у вас останется в понедельник после того, как вы перестанете платить. Договориться сейчас дёшево, обнаружить потом - неприятно. **Что произойдёт, когда интеграция сменит форму?** Любой процесс зависит от чужого расписания релизов. Хороший ответ называет, как поймают тихое изменение, и спрашивать об этом стоит [до сборки](/ru/blog/when-the-integration-changes-underneath-you), а не после первого плохого месяца. ## Что на самом деле меряют эти ответы Все пять чего-то стоят отвечающему честно. В этом и смысл. Цену назвать бесплатно и ошибиться в ней бесплатно, а отказ, пункт о собственности и письменная цифра эксплуатации - это обязательства. [Обязательства сортируют подрядчиков](/ru/answers/how-to-choose-ai-automation-agency) так, как итоговым суммам не под силу. ## Когда оба отвечают хорошо Тогда у вас настоящий выбор, а не ловушка, и оставшиеся различия - порядок работ, кто будет в комнате, как считаются изменения - те, судить о которых вы вправе. Берите того, с чьим списком отказов вы согласны. Этот список - самое близкое к предпросмотру того, как подрядчик поведёт себя, когда что-то пойдёт не так. А оно пойдёт. ## FAQ ### Почему более дешёвое предложение обычно не более дешёвая работа? Потому что границы в итоговой сумме не видны. Один подрядчик заложил маршрут исключений, сверку и месяц донастройки после запуска, второй заложил маршрут, где всё идёт правильно, а остальное встретит как запросы на изменение. Оба числа - честные описания того, что их автор намерен делать, и разница между ними не в эффективности, а в охвате. Увидеть её можно, сравнив оба предложения с брифом, который вы написали сами: тогда отсутствующее в одном из них читается как пробел, а не как экономия. ### Что на самом деле входит в стоимость эксплуатации? Расход модели или платформы на вашем настоящем объёме, а не на демонстрационном, хостинг, мониторинг и часы, которые кто-то тратит каждый месяц на исключения, возвращаемые процессом. Последний пункт выпадает из большинства смет и часто оказывается самым большим. Попросите месячную цифру письменно, умножьте на двенадцать и прибавьте к цене сборки. Эта одна сумма делает большинство решений о подрядчике очевидными в ту или иную сторону, а стоит она недорого. ### Зачем спрашивать, что подрядчик откажется строить? Затем, что ответ - свидетельство, смотрел ли он на ваш процесс или только на ваш бюджет. Тот, кто делал это раньше, назовёт конкретное: решение, которое должно остаться за человеком, источник данных, слишком ненадёжный, чтобы на нём строить, шаг, объём которого не окупает работу, - и объяснит почему. Тот, кто берётся за всё, описывает свою переговорную позицию, а не вашу операцию, и части, от которых стоило отказаться, всплывут во время приёмки, когда они дороги. ### Какие вопросы о собственности важны в первый день? Где лежит код и кто может его читать, на чьих аккаунтах ключи к интеграциям, кто может отозвать доступ и что вы получаете, если отношения закончатся в следующем квартале. Договориться об этом до контракта дёшево, а обнаружить после - неприятно, потому что ответом окажется то, что у подрядчика по умолчанию. Проверка простая: спросите, что у вас будет в понедельник после того, как вы перестанете платить, и ждите конкретного ответа, а не успокоительного. --- # Что показывает карта на этапе Break и что она решает URL: https://inite.ai/ru/blog/protocol-break-what-the-map-shows Date: 2026-09-03 Author: Mikhail Savchenko Category: Methodology Tags: INITE Protocol, Process Audit, Methodology, ROI ## Direct Answer Этап Break отдаёт клиенту три вещи: карту того, как работа движется на самом деле, стоимость хаоса по выбранным процессам и матрицу, где каждый кандидат оценён по выполнимости и по отдаче. Карта - это вход. Решение - две другие. Без них процесс для автоматизации выбирают по тому, кто громче жаловался, а число «до» восстанавливают по памяти уже после запуска, и оно всегда выходит льстивым. Break идёт на первой и второй неделе и имеет право закончить работу. ## Key Facts - Break занимает первую и вторую недели и имеет право закончить работу: депозит за диагностику возвращается, причины описываются письменно. - Стоимость хаоса считается по полной стоимости часа и по объёмам из систем, а не по окладам и не по разговору. - Каждый процесс-кандидат оценивается дважды - по выполнимости и по отдаче, и вторая оценка задаёт порядок сборки. - Карта, бейзлайн и матрица остаются у клиента вне зависимости от того, будет ли написана хоть одна строка кода. ## Что обычно ждут получить Спросите оператора, что даёт аудит автоматизации, и он опишет схему. Прямоугольники, стрелки, дорожки по отделам, презентация вокруг всего этого. Это вход, а не выход. Карта говорит, каков процесс. Она не говорит, что делать, и разрыв между этими двумя вещами - место, где принимаются все плохие решения об автоматизации. ## Два числа превращают карту в решение Первое - стоимость хаоса: сколько именно эти процессы теряют в неделю на переделках, ожидании и сорванных передачах. Полная стоимость часа, объёмы из систем, окно, достаточно длинное, чтобы поймать плохой месяц. Второе - оценка каждого кандидата по двум осям. Насколько это выполнимо надёжно и какую часть недельной стоимости оно вернёт при консервативных допущениях. Ни то, ни другое не сложно. И в большинстве коммерческих предложений этого нет - причём не по недосмотру. Предложение без измеренной базы нельзя проверить постфактум, что удобно той стороне, которая его пишет. ## Что ломается, когда этап пропускают Три вещи в предсказуемом порядке. **Автоматизируют не тот процесс.** Без оценки отдачи выбор сваливается на того, кто пожаловался последним, или на тот процесс, который проще описать на встрече. С затратами это связано слабо. **Число «до» придумывают потом.** Это дорогая часть. Старое время цикла никто не мерил, и когда новое отчитывается как четыре часа, старое становится «ну примерно день» - цифра, произведённая теми же людьми, которым нужно, чтобы проект сработал. [Аудит процессов до автоматизации](/ru/blog/process-audit-before-automation) существует ровно затем, чтобы такое восстановление не понадобилось. **Работа не может закончиться отказом.** У диагностики без арифметики нет механизма прийти к выводу, что строить не стоит, и потому она к нему не приходит. Любой аудит отвечает «да», и это «да» ничего не значит. ## Карта всё равно должна быть честной Измерение работает, только если под ним лежит карта настоящего маршрута, вместе с обходными путями. Общая таблица, которой официально никто не пользуется, несёт нагрузку, и обычно именно в ней прячутся противоречия, ломающие автоматизацию. Как эта карта рисуется - отдельный сюжет, он в тексте [почему большинство карт процессов бесполезны](/ru/blog/protocol-break-mapping-the-process). ## Что остаётся у клиента Карта, бейзлайн и матрица, письменно, независимо от того, что будет дальше. Так и задумано: этап должен окупать себя даже тогда, когда он убивает проект, иначе желание тихо найти проект возвращается. Break - один из [шести этапов](/ru/protocol), и всё, что идёт после, опирается на то, что этот результат настоящий. Вся последовательность на примере одного внедрения - в тексте [протокол от начала до конца](/ru/blog/inite-protocol-6-stages-applied). ## FAQ ### Почему карта - это не результат? Потому что карта отвечает не на тот вопрос. Она говорит, каков процесс, а на столе лежит вопрос, что с ним делать, и для него нужны ещё два артефакта. Первый - число: сколько этот процесс теряет в неделю на переделках, ожидании и потерянных передачах, посчитанное по выбранным процессам, а не по компании целиком. Второй - ранжирование: какой кандидат даёт больше при меньшем риске сборки. Подрядчик, который приносит красивую схему и коммерческое предложение, пропустил шаг, где схема превращается в аргумент, и вас просят согласовать сборку по эстетике. Карта - это доказательство. Стоимость и матрица - это вывод. ### Почему стоимости хаоса можно верить? Из-за того, как она собрана, и из-за того, что она записана до того, как стало ясно, что именно она обоснует. Она считается по полной стоимости часа, а не по окладу, потому что час, потраченный на переделку, стоит бизнесу столько, сколько стоит его обеспечить, а не столько, сколько написано в расчётном листке. Объёмы берутся из операционных систем за период, достаточно длинный, чтобы в него попал плохой месяц, а не из оценки, названной на встрече. И считается она только по выбранным процессам, что держит её маленькой и конкретной и не даёт ей уплыть в общекорпоративную неэффективность, которую не с чем сверить. Проверка простая: это база, с которой будет сравниваться любое последующее утверждение об отдаче, значит, вам должно быть не стыдно, что вас по ней спросят. ### Что именно оценивает матрица приоритетов? Две оси, намеренно грубые. Выполнимость спрашивает, достаточно ли структурированы входы, достижимы ли системы и устойчивы ли правила, чтобы софт делал это надёжно, а не почти всегда. Отдача спрашивает, какую часть измеренной недельной стоимости этот кандидат реально вернёт при консервативных допущениях, а не при оптимистичных. Считать надо обе, потому что кандидат с наибольшей отдачей сплошь и рядом оказывается наименее выполнимым, и план, который это игнорирует, выпускает проект, интересный три недели и брошенный на четвёртой. На выходе - очередь, и смысл очереди в том, что первый пункт можно защитить перед тем, кого не было в комнате. ### Как часто Break заканчивает работу отказом? Достаточно часто, чтобы ворота были настоящими, а это единственное свойство, которое имеет значение. Если арифметика при консервативных вводных не выходит в плюс, депозит за диагностику возвращается, причины описываются письменно, и работа на этом заканчивается. Звучит как маркетинговая строчка, а на деле её противоположность: фильтр, который никогда никого не отсеивает, это не фильтр, а формальность, и любой консалтинг, у которого он ни разу не сработал, делает второе, описывая первое. У клиента при этом остаются карта, бейзлайн и матрица, которые ценны сами по себе и делают следующую попытку автоматизации, кто бы её ни вёл, заметно дешевле. --- # Бриф на автоматизацию, который оператор пишет первым URL: https://inite.ai/ru/blog/automation-brief-template-for-operators Date: 2026-09-01 Author: Mikhail Savchenko Category: Operations Tags: Operations, Procurement, Process Audit, Automation ## Direct Answer Бриф пишется до разговора с кем бы то ни было. Семь пунктов: процесс одним предложением, объём за неделю из системы, а не по памяти, кто его касается и сколько минут тратит, что означает «готово», что нельзя автоматизировать никогда, сколько это стоит сейчас и какое доказательство результата вы примете. Вечер работы, и меняется то, что приходит обратно. Подрядчики, получившие бриф, считают одно и то же и потому сравнимы. Те, кому достался только разговор, оценивают разную работу, и выигрывает предложение, где описано меньше всего. Бриф вдобавок остаётся единственным артефактом, если решено не строить. ## Key Facts - Три предложения, написанные по трём разным разговорам, несравнимы: они считают разную работу. - Объём, взятый из системы, а не из памяти, - пункт, сильнее всего меняющий цену предложения. - Строку о том, что нельзя автоматизировать никогда, подрядчики опускают чаще всего, а клиенты имеют в виду чаще всего. - Бриф сохраняет ценность при решении не строить, чего о большинстве документов discovery сказать нельзя. ## Почему бриф идёт первым Попросите трёх подрядчиков оценить автоматизацию приёма заказов, и вы получите три цены за три разные работы. Не потому, что кто-то нечестен, а потому что каждый услышал свои полчаса описания и достроил пробелы тем, что обычно делает. Бриф закрывает пробелы на вашей стороне стола. Он стоит одного вечера и [превращает набор несравнимых предложений в набор сравнимых](/ru/answers/how-to-choose-ai-automation-agency). ## Семь строк **Первая. Процесс одним предложением.** От какого события до какого результата. «Заявка на аренду приходит по телефону, в мессенджер или через форму, и заканчивается, когда техника в машине с подписанным договором». Если нужно три предложения, у вас два процесса. **Вторая. Объём за неделю, из системы.** Не типичный день, а счёт за период, в который попадает плохая неделя. Эта строка сильнее всего двигает цену и чаще всего подаётся по памяти. Текст [с чего начинать автоматизацию в небольшой компании](/ru/blog/what-to-automate-first-in-a-small-company) держится на этом числе больше, чем на чём угодно ещё. **Третья. Кто участвует и сколько тратит.** Роли, а не имена, и минуты на объект, а не доля дня. Двое по двадцать минут - другая задача, чем шестеро по четыре. **Четвёртая. Что означает «готово».** Состояние, в котором процесс завершён, описанное так, чтобы проверить мог посторонний. Это условие приёмки, и записанное сейчас оно снимает версию, в которой «готово» означает то, что делает сданная система. **Пятая. Что нельзя автоматизировать никогда.** Возврат выше порога, всё клиническое, всё, что уходит регулятору, всё, что клиент воспримет как машину, решившую его вопрос. Эту строку подрядчики опускают, а клиенты, как выясняется, имели в виду с самого начала. **Шестая. Сколько это стоит сейчас.** Часы в неделю по полной стоимости часа плюс переделки, которые вы можете назвать. Не по компании целиком - по этому процессу. Арифметика, дающая число, которое выдержит чужую проверку, разобрана в тексте [четыре вопроса, ломающие большинство расчётов отдачи](/ru/blog/roi-math-for-automation-projects). **Седьмая. Какое доказательство вы примете.** Измерение, которое закроет вопрос через девяносто дней, и место, откуда возьмётся число. Согласованное сейчас, оно снимает сравнение постфактум с базой, восстановленной по памяти. ## Что меняется на той стороне Подрядчик, получивший этот документ, считает ту же работу, что и все остальные, кто его получил. В этом весь смысл. Там, где предложения всё-таки расходятся - подход, порядок, от чего отказываются, - расхождения настоящие, и [чтение самого предложения](/ru/blog/how-to-read-an-automation-quote) становится куда более коротким занятием. Бриф ещё и говорит кое-что о подрядчике. Опытный дополнит пятую строку и поспорит со второй. Тот, кто воспримет бриф как отнятые границы, показывает, где у него живёт маржа. ## Версия, в которой вы не строите Иногда шестая строка выходит маленькой. Это результат, а не потраченный вечер: он приходит до стройки, а не после, и та же страница остаётся написанным описанием одного процесса, его объёма и его настоящей стоимости. Следующая попытка начинается с неё, кто бы её ни вёл и когда бы она ни случилась. ## FAQ ### Почему бриф пишется до разговора с подрядчиками, а не после? Потому что предложение, написанное по разговору, описывает понимание подрядчика, а трое услышали три разные вещи. Несравнимыми предложения становятся незаметно: все разумные, все уверенные, и каждое считает слегка другую работу. Бриф фиксирует границы на вашей стороне стола, и различия между предложениями остаются там, где им и место, - в подходе и цене, а не в том, что именно строят. Заодно он уводит решение о границах от той стороны, чей доход растёт вместе с ними. ### Насколько точным должен быть объём? Достаточно точным, чтобы прийти из системы, а не из памяти, и за окно, в которое попадает плохая неделя. Оператор, которого спросили, сколько заказов он обрабатывает, назовёт типичный день, а это почти всегда то число, которое ему хотелось бы считать типичным. Выгрузка из системы, где это и так пишется, занимает двадцать минут и регулярно двигает ответ на треть в ту или иную сторону. Именно этот пункт сильнее всего меняет цену, потому что от объёма зависит, хватит ли правил или на вход нужна модель. ### Что писать в строке о том, что нельзя автоматизировать? Решения, ошибка в которых дорога и не отменяется тихо: возврат выше порога, клиническое или юридическое суждение, всё, что уходит регулятору, всё, что клиент воспримет как машину, решившую его вопрос. Записанные до сборки, они превращаются в спецификацию, а не в спор во время приёмки. Это ещё и самый быстрый способ понять, делал ли подрядчик это раньше: опытный дополнит ваш список, неопытный воспримет его как отнятые границы. ### Что если бриф покажет, что автоматизировать не стоит? Значит, бриф сработал. Измеренная недельная стоимость - то самое число, с которым потом сверяется любое утверждение об отдаче, и когда оно маленькое, честный вывод доступен сразу, а не после стройки. Документ при этом ценности не теряет: это написанное описание одного процесса, его объёма и его настоящей стоимости, и оно делает следующую попытку - чью угодно и в каком угодно году - заметно дешевле первой. --- # Когда интеграция меняется под тобой URL: https://inite.ai/ru/blog/when-the-integration-changes-underneath-you Date: 2026-08-28 Author: Mikhail Savchenko Category: Operations Tags: Operations, Automation, Workflow, Process Audit ## Direct Answer Автоматизации, которым перестали доверять, обычно всё это время работали. Наверху сменилась форма - поле переименовали, в ответе завёлся лишний уровень вложенности, в списке статусов появилось значение, о котором никто не предупредил, - и процесс продолжил считать по-старому. Результат выглядит убедительно и при этом неверен. Громкая поломка дешёвая: всё встало, кто-то заметил в тот же час, к вечеру починили. Дорогая работает шесть недель, пока человек не сверит два числа руками. Против дорогой есть три дешёвых приёма: каждое утро прогонять одну запись по всему маршруту, смотреть, в какой форме пришёл ответ, и следить за распределением результатов, не дожидаясь исключений. ## Key Facts - Деньги теряет та поломка, которая не поднимает ошибку, потому что о ней никто не узнаёт. - Одна проверочная запись, раз в день проходящая весь маршрут, - самый дешёвый детектор тихого изменения. - Сверка формы входящего ответа ловит переименования и новую вложенность, а код ответа не ловит ничего. - Предупреждение по распределению исходов замечает сместившийся процесс, а предупреждение по исключениям не заметит никогда. ## Поломка, которая о себе не сообщает Остановившаяся автоматизация - маленькая беда. Она встала, в течение часа кто-то заметил, причина очевидна, потому что сломалось то, что меняли последним. Дорогая поломка - та, что продолжает работать. Наверху переименовали поле, читающий его код получает пустоту, а пустота в большинстве процессов легальна: незаполненный комментарий, невыставленный флаг, отсутствующая вторая строка адреса. Ошибки не возникает. Процесс выдаёт записи, неотличимые от прошлонедельных, и делает это ровно столько, сколько нужно человеку, чтобы сверить руками два числа. ## Что меняется на самом деле Почти всё сводится к четырём формам. Поле переименовали или перенесли - обычно при уборке, которую никто не считал внешней. В ответе появился лишний уровень вложенности, когда поставщик добавил обёртку для постраничности или метаданных. В перечислении завелось новое значение, новый статус заказа или новый тип документа, и ветка, разбирающая известные значения, молча роняет неизвестное. Версия API ушла на покой, а запасным вариантом оказалась старая форма вместо ошибки. Ни одно из этого не авария. Каждое - вторник во второй половине дня в чужих примечаниях к релизу. ## Три защиты, все дешёвые **Одна запись, весь маршрут, каждое утро.** Искусственный объект, проходящий путь целиком и проверяемый на выходе против известного ответа. Он нагружает стыки между системами, а дрейф живёт на стыках. Четыре по отдельности здоровых сервиса вполне могут передавать друг другу то, что изменилось. **Проверять форму, а не статус.** Двести с разбираемым телом не доказывает, что тело означает то же, что месяц назад. Проверяйте, что читаемые поля на месте и нужного типа, и падайте громко, когда это не так. Это десять строк, и они превращают тихий неверный ответ в видимую остановку. **Предупреждать по распределению, а не по исключениям.** Если в прошлом месяце в ручной маршрут уходил один объект из двадцати, а сегодня уходит один из шести, - вот сигнал, и ни одно исключение при этом не поднялось. Работает это только тогда, когда обычные числа записали заранее, а довод в пользу этого приведён в тексте про [измеренную базу](/ru/blog/roi-math-for-automation-projects). ## Почему это вопрос границ, а не сопровождения Любая интеграция - это зависимость от чужого расписания релизов. Плохой идеей её это не делает: доставка в аренде из текста [куда уходят четыре часа](/ru/blog/order-processing-equipment-rental) читает наличие из системы, которой мы не управляем, и всё равно окупается. Это делает зависимость тем, что надо оценить. Практическая версия: когда границы процесса согласуются, перечислите, что он читает извне себя, и для каждого пункта скажите, что произойдёт при смене формы. Про большинство ответ будет «встанет, и пусть встанет». Те, где ответ звучит как «поедет дальше, и мы не узнаем», требуют проверочной записи до запуска, а не после первого плохого месяца. ## То, что называть не хочется [Процесс, за который не отвечает ни один человек](/ru/pricing), проверяет тот, кто случайно посмотрел, а на практике - клиент своей жалобой. Имя попадает в документ передачи вместе со всем остальным, и принадлежит оно тому, у кого есть мнение о конструкции, а не тому, кто был свободен на той неделе. Довод в пользу того, чтобы считать это этапом, а не последним днём, лежит в тексте [что обязан произвести аудит процессов](/ru/blog/process-audit-before-automation), а дописать это потом нельзя: человек, забывший, что было непонятно, уже не может это записать. ## FAQ ### Почему изменение интеграции ломает всё тихо? Потому что интеграции обычно проверяют на успех, а не на форму. Вызов вернул двести, тело разобралось, процесс поехал дальше. Если поле переименовали, читающий его код получает пустоту и обращается с ней как с обычным пустым значением: комментарий не заполнен, вторая строка адреса отсутствует, приоритет не выставлен. Каждое из этого где-то в процессе легально, поэтому ошибки не возникает. Процесс продолжает выдавать записи, неотличимые от прошлонедельных, и единственный сигнал - что исходы уехали, а за этим никто не следит. ### Что такое проверочная запись и почему она работает? Один искусственный объект, каждое утро проходящий весь маршрут целиком: создан, направлен, преобразован, доставлен, - и проверенный на выходе против заранее известного результата. Работает он потому, что нагружает стыки между системами, а не отдельную систему, и живёт дрейф именно на стыках. Мониторинг, пингующий каждый сервис по отдельности, доложит о четырёх здоровых сервисах, пока то, что они передают друг другу, изменилось. Стоит это одну запись в день и отвечает на вопрос, который поштучные проверки задать не умеют. ### Как отличить дрейф от обычного разброса? Тем, что обычное записали до запуска. Ровно для этого существует этап замера: объёмы за неделю, доля объектов, уходящих в исключения, разброс времени обработки. Дрейф проявляется как изменение формы этих чисел, а не их уровня: среднее держится, а хвост уезжает, или доля исключений за ночь переходит с одного из двадцати на один из шести. Без базы те же числа нечитаемы, потому что никто не может сказать, необычная эта неделя или нет. ### Чья это работа - заметить? Того, кого назвали по имени до запуска. Процесс без владельца проверяет тот, кто случайно посмотрел, а на практике это означает - после жалобы клиента. Имя стоит в документе передачи рядом с тем, что процесс делает, чего он не должен делать никогда и какое предупреждение о чём говорит. Поэтому передача - этап, а не последний день сборки: система, за которую никого не сделали ответственным, работает на допущении, что ничего не изменится, а что-нибудь меняется всегда. --- # Как читать смету на автоматизацию до того, как её подписать URL: https://inite.ai/ru/blog/how-to-read-an-automation-quote Date: 2026-08-24 Author: Anton Fenix Category: Operations Tags: Operations, Procurement, Automation, Strategy ## Direct Answer Смотрите на структуру раньше, чем на сумму. Смета, которую стоит подписывать, называет процесс, а не технологию, указывает предполагаемый объём, разбивает интеграции по системам, несёт месячную стоимость эксплуатации рядом с ценой стройки, говорит, что остаётся человеку, и называет владельца результата после передачи. Информативно именно отсутствующее: одна итоговая строка прячет, какие допущения могут поехать, а смета без месячной цифры недосчитывает двенадцати платежей первого года. Чаще всего забывают четыре статьи: расходы на модель, человека, разбирающего исключения, обслуживание при изменении соседних систем и время владельца процесса. ## Key Facts - Смета без месячной стоимости эксплуатации недосчитывает 12 платежей, которые вы внесёте за первый год. - Чаще всего пропускают 4 статьи: расходы на модель, человека в контуре, обслуживание и время владельца. - Мы выводим 1-3 процесса за 2-4 недели, поэтому смета на один процесс сроком в месяцы описывает другую работу. - Окупаемость обычно наступает через 3-6 месяцев, и без месячной стоимости проверить это невозможно вообще. ## Сначала форма, потом сумма Разбор сметы обычно начинают с итога и идут назад, а это неверный порядок. Итог это вывод. Структура это доказательства. Смета это описание объёма работ, надевшее цену, и первое, что стоит проверить, задан ли объём автоматизируемым процессом или списком результатов, под который подойдёт почти что угодно. «Интеграция ИИ, обследование, внедрение, тестирование, развёртывание» описывает любой проект, который когда-либо оценивали. «Приём броней из четырёх каналов, доступность считается по состоянию единицы техники, договор формируется из вашего утверждённого шаблона, отгрузка планируется» описывает один. ## Что должно быть на странице | Строка | Почему важна | | --- | --- | | Замер или обследование отдельной ценой | Без него смета это догадка о непосчитанном процессе | | Стройка, привязанная к названному процессу | А не к технологии, под которую подойдёт что угодно | | Интеграции по каждой системе | Здесь ошибаются оценки, а общая цифра прячет рискованную систему | | Месячная стоимость эксплуатации | Чаще всего отсутствующая строка, и она решает окупаемость | | Передача и состав документации | Определяет, владеете вы результатом или арендуете его | | Условия поддержки со сроком реакции | Иначе всё обязательство это «мы будем на связи» | Отсутствие любой из них это вопрос, а не приговор. Наличие всех шести означает, что смету можно сравнить с другой сметой из шести строк, а это [единственный способ придать сравнению цен смысл](/ru/answers/ai-automation-cost). ## Что прячет одна итоговая строка То, какие допущения могут поехать. Стоимость автоматизации определяется объёмом и площадью интеграций, и на момент сметы это оценки. В разбитом виде можно спросить, что будет при половине предполагаемого объёма или во что превратится цена, если четвёртая система потребует другого подхода. Ответы покажут, где сидит риск. Свёрнутое в одно число, любое последующее изменение становится пересогласованием из позиции, где не видно, какая часть сдвинулась. Однострочные сметы чаще ленивые, чем нечестные. Для вас эффект одинаков, а просьба разбить стоит ноль и отклоняется удивительно часто. ## Четыре пропадающие статьи Расходы на модель и инфраструктуру на каждое решение, при настоящем объёме это месячная статья, а не погрешность округления. Время того, кто разбирает эскалированные исключения. Это заложенная статья, а не дефект, и ей нужна честная оценка доли эскалаций, а не предположение, что она около нуля. Обслуживание, когда движется окружающий мир. Поставщик меняет форму, канал меняет интерфейс, кто-то должен заметить и починить. Продолжающееся время владельца процесса после передачи, потому что автоматизация без владельца деградирует тихо, пока дашборды выглядят нормально. Просите все четыре одной месячной цифрой, прибавляйте двенадцать таких к цене стройки и сравнивайте эти суммы. Тогда у [четырёх вопросов, ломающих большинство расчётов окупаемости](/ru/blog/roi-math-for-automation-projects), появляется материал, потому что окупаемость за три-шесть месяцев без месячной стоимости проверить нельзя вообще. ## Две структурные вещи, которые стоит проверить График платежей. Если каждая веха это дата, а не работающая вещь, вы финансируете прошедшее время. Хотя бы один платёж должен быть привязан к чему-то работающему в проде, на что можно посмотреть. Срок против объёма. Мы выводим один-три процесса в прод за две-четыре недели, поэтому смета на один процесс сроком в месяцы описывает другую работу: возможно, проект замены системы, возможно, обследование с пристроенной стройкой. Ни то ни другое не ошибка, но знать, что именно вы покупаете, стоит. ## Лучший вопрос Чего я за это не получаю. Хороший подрядчик отвечает сразу и конкретно, потому что уже решил, что вне объёма: краевые случаи, остающиеся ручными, система, не интегрируемая на этом этапе, отчёт, который не входит. Наш должен сказать вам, какие части остаются человеку по замыслу, потому что эта граница намеренная, а не вынужденная. Подрядчик, который ответить не может, либо не думал об объёме, либо откладывает разговор до превращения его в запрос на изменение. Оба варианта дают один и тот же спор на третьем месяце. ## До того как всё это придёт Смету легче читать, когда ответы у вас уже есть. Посчитайте свой объём по своим системам, назовите владельца и знайте, какая из ваших систем главная по каждому спорному полю. Это та же подготовка, что описана в посте [что делает карту процесса стоящей](/ru/blog/protocol-break-mapping-the-process), и она превращает разбор сметы из упражнения в доверии в упражнение в арифметике. Если числа в смете расходятся с вашими, у вас появляется конкретный разговор вместо общего беспокойства. А если не выполнены условия готовности из поста [когда автоматизироваться ещё рано](/ru/blog/what-size-company-should-not-automate-yet), то и лучшая на свете смета остаётся сметой на неправильный проект. ## FAQ ### Что должно быть разбито по строкам как минимум? Шесть вещей, и отсутствие любой из них это вопрос, а не приговор. Замер или обследование, оценённые отдельно, потому что смета, составленная без него, это догадка о процессе, который никто не посчитал. Сама стройка, привязанная к названному процессу, а не к технологии. Интеграции по системам, перечисленные поштучно, потому что именно на интеграциях оценки ошибаются, а общая цифра прячет, какая из систем несёт риск. Месячная стоимость эксплуатации, и это чаще всего отсутствующая строка. Передача, включая то, какая документация остаётся в конце и кто её получает. И условия поддержки после запуска, со сроком реакции. Смету с шестью строками можно сравнить с другой сметой с шестью строками, а это единственный способ придать сравнению цен хоть какой-то смысл. ### Что именно прячет одна итоговая строка? То, какие допущения могут поехать, а это и есть самое нужное. Стоимость автоматизации определяется объёмом и площадью интеграций, и на момент сметы оба это оценки, а не факты. Когда они разбиты, вы можете спросить, что будет при половине предполагаемого объёма, или во что превратится цена, если четвёртая система потребует другого подхода, и ответы покажут, где сидит риск. Когда всё свёрнуто в одно число, любое последующее изменение становится пересогласованием из позиции, в которой вы не знаете, какая часть сдвинулась. Подрядчик не обязательно что-то прячет: однострочные сметы чаще ленивые, чем нечестные. Но эффект для вас одинаков, а просьба разбить стоит ноль и отклоняется удивительно часто. ### Какие эксплуатационные статьи забывают чаще всего? Четыре, по нашему опыту, и вместе они составляют разницу между окупаемостью за четыре месяца и за одиннадцать. Расходы на модель и инфраструктуру на каждое решение, которые при настоящем объёме превращаются в месячную статью, а не в погрешность округления. Время того, кто разбирает эскалированные исключения, и это заложенная в конструкцию статья, а не дефект, требующая честной оценки доли эскалаций вместо предположения, что она около нуля. Обслуживание при движении окружающего мира, потому что поставщик меняет форму, канал меняет интерфейс, и кто-то должен это заметить и починить. И продолжающееся время владельца процесса после передачи, потому что автоматизация без владельца деградирует тихо, пока отчётность продолжает выглядеть нормально. Просите эти четыре одной месячной цифрой и прибавляйте двенадцать таких к цене стройки, прежде чем что-либо сравнивать. ### Какой один вопрос по смете самый лучший? Чего я за это не получаю. Хороший подрядчик отвечает сразу и конкретно, потому что он уже решил, что находится вне объёма и почему: краевые случаи, остающиеся ручными, система, которая на этом этапе не интегрируется, отчёт, который не входит. Подрядчик, который ответить не может, либо не думал об объёме, либо откладывает этот разговор до момента, когда тот превратится в запрос на изменение, и оба варианта дают один и тот же спор на третьем месяце. Второй по полезности вопрос звучит так: что произойдёт, если допущения окажутся неверными, и это вопрос о том, как оценивается изменение, а не о том, случится ли оно. Оно случается всегда. Сметы различаются тем, признают ли они это заранее. --- # Видимость в ИИ для операторов, измеренная на нашем же сайте URL: https://inite.ai/ru/blog/aeo-for-operators-what-it-buys-you Date: 2026-08-23 Author: Михаил Савченко Category: AEO Tags: AEO, AI Visibility, Operations, Strategy ## Direct Answer Быть читаемым для ИИ-движков и быть рекомендованным ими это разные достижения, и техническая задача только первое. Наш собственный сайт получает 90 из 100 за готовность к ИИ и 25 из 100 за видимость: краулеры разбирают всё, а движки нас почти не упоминают. Узнаваемость бренда достигает 2 движков из 6, а рекомендации в категории 0 из 6, и значимо именно второе число, потому что покупатель, спрашивающий ассистента о подрядчике, задаёт категориальный вопрос. Этот разрыв закрывается доказательствами и упоминаниями, а не дополнительной разметкой. ## Key Facts - Наш собственный сайт получает 90 из 100 за готовность к ИИ и 25 из 100 за видимость. - Узнаваемость бренда достигает 2 движков из 6, рекомендации в категории 0 из 6. - Search Console зафиксировала 30 кликов и 3262 показа за месяц при нуле показов по любому коммерческому запросу. - llms.txt найден на 10,13% доменов без измеримого прироста цитирований в исследовании SE Ranking от ноября 2025 года. - Google AI Mode работает примерно на 93% без кликов. ## Наши собственные цифры, потому что они объясняют лучше Аудит видимости в ИИ по inite.ai даёт 90 из 100 за готовность и 25 из 100 за видимость. Это значит, что краулеры разбирают всё, что мы публикуем, а движки нас почти не упоминают. Два движка из шести узнают бренд, когда им дали название. Ноль из шести рекомендуют нас в категории, а это и есть вопрос, который задаёт покупатель. Search Console рассказывает то же самое с другой стороны: 30 кликов и 3262 показа за месяц при нуле показов по любому коммерческому запросу. Не низкие позиции. Отсутствие. Мы это публикуем, потому что альтернатива это писать о видимости в ИИ из-за цифры, которую мы не заработали, и потому что сам разрыв и есть то полезное, что стоит понять. ## Готовность дёшева. Видимость нет. | | Готовность к ИИ | Видимость в ИИ | | --- | --- | --- | | Что меряет | Может ли движок вас прочитать | Решает ли он вас упомянуть | | Кто чинит | Разработчик, за две недели | Доказательства, копящиеся месяцами | | Растёт | Сразу | Медленно, если вообще | | Цена | Низкая и разовая | Постоянная | | Сколько стоит сама по себе | Ноль | Всё | Продают их по одной цене. Подрядчик, продавший видимость и поставивший готовность, поставил нечто настоящее и гораздо более дешёвое, чем вы думали, и вы не заметите этого квартал, потому что оценка готовности сдвигается сразу. ## Число, за которым стоит следить Рекомендация в категории, а не узнаваемость бренда. Узнаваемость проверяет, знает ли движок о вашем существовании, когда ему подсказали название. Улучшить её легко, а стоит она немного, потому что человек, который уже знает ваше имя, имеет и другие способы до вас дойти. Рекомендация в категории смотрит, появляетесь ли вы, когда кто-то описывает задачу и хочет знать, кто её решает. Это и есть то, что набирает покупатель. Наш разрыв между 2 из 6 и 0 из 6 это разница между «нас можно найти» и «нас рекомендуют», и выручка привязана только ко второму. Спросите любого подрядчика, какое из двух чисел описывает его главная метрика. Ответ показателен. ## Что, судя по всему, действительно сдвигает видимость Ничего экзотического и ничего, что заканчивается за две недели. Ответить на конкретный вопрос полностью, на странице, которая посвящена этому вопросу, в той форме, в какой вопрос задают. Разметить так, чтобы ответ извлекался, а не тонул в повествовании. И получить подтверждение где-то за пределами своего домена, потому что движок, взвешивающий, рекомендовать ли подрядчика, ищет что-то помимо утверждений подрядчика о самом себе. Не сдвигает, судя по данным, ровно то, что чаще всего продают. llms.txt найден на 10,13% доменов, и исследование SE Ranking от ноября 2025 года на 300 000 доменов не обнаружило приписываемого ему прироста цитирований. Мы всё равно его публикуем, потому что поддержка недорога. Это гораздо более слабое утверждение, чем обычное, и [полный разбор здесь](/ru/blog/is-llms-txt-dead-2026). ## Зачем это нужно, если 93% в AI Mode без кликов Потому что трафик не актив. В ответе без клика ассистент формулирует вывод и называет источники. Попадание в число названных ставит вас в короткий список, который покупатель несёт в следующий разговор, включая тот, где он в итоге наберёт ваше имя напрямую. Отношение к этому как к каналу трафика даёт неверное измерение и затем неверный вывод, почти всегда тот, что ничего не сработало. Считайте, называют ли вас в ответах на вопросы ваших покупателей, и смотрите на брендовый поиск в следующие месяцы. Если отчётность считает только сессии, успешная программа и провалившаяся выглядят одинаково. ## Что с этим делать оператору Три вещи по порядку, и ни одна из них не покупка инструмента. [Выясните, что ассистент сейчас отвечает](/ru/analyze) на вопрос, кто делает то, что делаете вы, в вашем городе или отрасли. Это занимает полдня и это единственная база, которая имеет значение. Закройте готовность один раз, потому что это дёшево и потому что нечитаемость обесценивает всё последующее. Пускать ли краулеров вообще, это решение бизнеса, а не техники, и компромисс разобран в [посте про список допущенных краулеров](/ru/blog/ai-crawler-allowlist-2026). Дальше тратьте постоянные усилия на доказательства, а не на разметку: кейсы с числами, ответы на настоящие вопросы и подтверждения на доменах, которыми вы не владеете. Это медленно, и именно это разводит две оценки. Механика, вместе с той разметкой, которая важна, и той, которая нет, лежит в [руководстве по AEO](/ru/blog/aeo-complete-guide-2026). ## Честный итог Мы хороши в дешёвой половине и плохи в дорогой, и обе стороны можем показать числами. Всякий, кто продаёт вам дешёвую половину по цене дорогой, покажет оценку, которая вырастет на второй неделе. Спросите, что именно она измерила. ## FAQ ### Чем готовность к ИИ отличается от видимости в ИИ? Готовность отвечает на вопрос, может ли движок вас прочитать. Видимость на другой: решает ли он вас упомянуть. Первое это технический чеклист, который грамотный разработчик закрывает за две недели: чистая разметка, структурированные данные, быстрые страницы, вменяемая политика для роботов, тексты, отвечающие на вопросы в той форме, в какой вопросы задают. Второе это репутационный результат, зависящий от того, подтверждает ли хоть что-то вне вашего домена то, что вы о себе говорите. Коммерчески это важно, потому что продают их по одной цене. Подрядчик, продавший видимость и поставивший готовность, поставил нечто настоящее и гораздо более дешёвое, чем вы думали, что купили, и разницу вы не заметите квартал, потому что оценка готовности растёт сразу, а оценка видимости нет. ### За каким числом малому бизнесу следить на самом деле? За рекомендациями в категории, а не за узнаваемостью бренда. Узнаваемость проверяет, знает ли движок о вашем существовании, когда ему дали ваше название; улучшить её легко, а стоит она немного, потому что клиент, уже знающий ваше имя, имеет и другие способы до вас добраться. Рекомендация в категории смотрит, попадаете ли вы в число ответов, когда человек описывает свою задачу и хочет знать, кто её решает, а это и есть вопрос настоящего покупателя. На нашем сайте разрыв резкий: 2 движка из 6 узнают бренд, 0 из 6 рекомендуют его в категории. Коммерчески значим именно второй ноль, и только его стоит показывать тому, кто платит. Спросите любого подрядчика, какое из двух чисел описывает его отчёт. ### Помогает ли llms.txt? Измеренных доказательств этому нет, и мы всё равно его публикуем по более узкой причине. Исследование SE Ranking от ноября 2025 года на 300 000 доменов нашло его на 10,13% и не смогло обнаружить приписываемого ему прироста цитирований. Это не доказательство бесполезности, но продавать файл как готовое средство видимости нельзя. Контент по-прежнему должен полностью отвечать на вопрос и получать подтверждение за пределами собственного сайта. Мы держим llms.txt потому, что его поддержка недорога, и это гораздо более слабое утверждение, чем то, которое обычно за него выдают. ### Зачем вообще появляться, если 93% в AI Mode проходят без кликов? Потому что оставшийся трафик не цель. В ответе без клика ассистент формулирует вывод и называет источники, и попадание в число названных это другой актив, а не визит: оно ставит вас в короткий список, который покупатель несёт в следующий разговор, включая тот, где он в итоге наберёт ваше имя напрямую. Отношение к этому как к каналу трафика даёт неверные измерения и затем неверный вывод, обычно тот, что ничего не сработало. Мерьте, называют ли вас в ответах на вопросы ваших покупателей, и смотрите на брендовый поиск в следующие месяцы, потому что эффект проявляется там. Если ваша отчётность считает только сессии, успешная программа видимости неотличима от провалившейся. --- # Почему провалился ваш прошлый чат-бот, и дело не в модели URL: https://inite.ai/ru/blog/why-your-last-chatbot-failed Date: 2026-08-22 Author: Olga Fedotova Category: Comparison Tags: Comparison, Operations, Customer Support, Automation ## Direct Answer Большинство провалившихся чат-ботов провалились не по вине модели. Их ставили отвечать на всё вместо заданного набора вопросов, не давали доступа к системам, где лежат настоящие ответы, и мерили долей обращений, закрытых без человека, а эта метрика платит боту за отказ звать оператора. Последнее и есть корень того опыта, который ваши клиенты возненавидели: метрика поощряла ровно то поведение, которое бесит. Автоматизация поддержки, которую стоит внедрять, отвечает на то, что может проверить, немедленно отдаёт остальное вместе со всей перепиской и мерится решением вопроса и скоростью передачи. ## Key Facts - Доля закрытых без человека обращений стоит на большинстве дашбордов и поощряет ровно 1 поведение: не передавать диалог. - Во внедрении у агентства недвижимости, где автоматика отвечала только на проверяемое, время ответа сократилось с 6 часов до 8 минут. - Мы выводим 1-3 процесса в продакшен за 2-4 недели, и поддержку часто рекомендуем не первой. - Точка входа - бесплатная диагностика на 15 минут, до любого разговора о цене и объёме. ## Метрика и создала этот опыт Большинство дашбордов по чат-ботам начинается с доли обращений, закрытых без человека. Перечитайте это определение со стороны клиента. Каждая передача оператору идёт в минус. Каждый отказ передать идёт в плюс. Клиент, который сдался и закрыл окно, набирает столько же очков, сколько клиент, которому помогли. Система, оптимизированная под это число, учится водить людей по кругу из переформулированных вопросов и предложенных статей. Это не тонкое расхождение целей. Это в точности тот механизм, который описывают, когда говорят, что ненавидят чат-ботов, и он был заложен намеренно тем, кто выбрал метрику. ## Ещё три вещи, которые скорее всего были правдой | Что сломалось | Как это выглядело для клиента | Чем чинится | | --- | --- | --- | | Поставлен отвечать на всё | Уверенные неверные ответы в краевых случаях | Определением того, на что ему можно отвечать | | Нет доступа к вашим системам | Пересказ раздела вопросов и ответов | Чтением из заказов, склада, биллинга, календаря | | Переписки никто не читал | Один и тот же отказ каждую неделю целый год | Один человек, один час, раз в неделю | Вторая строка тихо определяет всё остальное. [Автоматика, не подключённая ни к чему](/ru/automation/customer-support), способна только пересказывать опубликованное, поэтому конкурирует с вашим же поиском по сайту и проигрывает: клиент прочитал эту страницу до того, как открыл чат. Вопросы, которые порождают обращения, конкретны и личны. Где мой заказ. Это ещё доступно. За что с меня списали эту сумму. Можно ли перенести запись. Ответ на любой требует чтения из настоящей системы, и построение этого пути и есть основная часть работы. Предложение, которое её опускает, продаёт обёртку вокруг базы знаний. Демонстрация будет выглядеть отлично, потому что на демонстрациях задают общие вопросы. ## Что рабочая версия делает иначе Она отвечает только на то, что может проверить, и говорит, откуда взяла ответ. Во внедрении у агентства недвижимости автоматика отвечала на то, на что могло ответить само объявление: этаж, площадь, цена, что входит, доступен ли объект. Всё остальное уходило названному агенту вместе с перепиской. Время ответа ушло с 6 часов до 8 минут, и сработало это потому, что автоматика никогда не догадывалась. Всё обязывающее уходит человеку по замыслу. Цена вне опубликованной, условия, обещания. Эта граница разобрана в [наших правилах о человеке в контуре](/ru/blog/safe-ai-framework-human-in-loop), и мы за неё не извиняемся: автоматика, соглашающаяся на что-то от вашего имени в два часа ночи, это риск, а не возможность. ## Передача оператору и есть весь продукт Здесь ломается три вещи, и все три чинятся дёшево. Аварийный выход спрятан, поэтому клиент угадывает волшебную фразу, чтобы добраться до человека. Скажите в первом сообщении, что человек доступен. Передача выглядит голым уведомлением, поэтому оператор начинает с вопроса, который клиент уже дважды объяснил. Переносите переписку, иначе автоматика потратила время вместо экономии. Очередь за передачей не укомплектована под то, что бот эскалирует, поэтому быстрый отказ превращается в долгое молчание. Это решение о ресурсах, и принимать его надо до запуска, а не обнаруживать на второй неделе. Передавайте при первом признаке раздражения, а не при третьем. Цена лишней передачи это несколько минут времени оператора. Цена отказанной это клиент. ## Когда мы говорим не строить В этой категории чаще, чем в любой другой, и обычно по одной из трёх причин. Обращения в основном о том, что бот проверить не может. Объём слишком мал, чтобы кто-то это поддерживал. Или настоящая проблема в том, что медленно отвечают люди, а автоматика станет украшением поверх этого. Третий случай стоит назвать, потому что он частый. Если обращения ждут четыре часа, потому что в семь вечера отвечать некому, бот, приветливо и бесполезно отвечающий в семь вечера, ожидание не починил, а автоматизировал. Деньги лучше потратить на маршрутизацию, на покрытие часов или на устранение причины, по которой к вам обращаются. Это та же проверка, что и [пятое условие готовности](/ru/blog/what-size-company-should-not-automate-yet): если узкое место не здесь, ускорение этой части не даст ничего, что можно положить в кассу. ## Что спросить у следующего подрядчика Из каких систем он будет читать и что сделает, когда чтение не удастся. Чем его меряют, и если ответ «долей закрытых без человека», то что происходит с этим числом, когда бот правильно передаёт диалог. Как клиент добирается до человека, за сколько сообщений и кто ждёт его на той стороне. И попросите показать переписку из настоящего внедрения в плохой день. Как выглядит ответ на первый вопрос, который не стыдно дать, показано в посте про [разделение правил и модели в обработке заказов](/ru/blog/order-processing-equipment-rental): детерминированные вопросы за правилами, неструктурированный вход за моделью, и местами они не меняются. ## FAQ ### Что не так с метрикой доли обращений без человека? Она платит системе за то, что клиенты ненавидят. Метрика считает диалоги, закончившиеся без оператора, поэтому каждая передача засчитывается как провал, а каждый отказ передать как победа, независимо от того, получил ли клиент то, за чем пришёл. Бот, оптимизированный под это число, учится удерживать людей в кругу переформулированных вопросов и предложенных статей, потому что клиент, который сдался и закрыл окно, считается точно так же, как клиент, которому помогли. Это не тонкое расхождение целей, это в точности тот механизм, который люди описывают, когда говорят, что ненавидят чат-ботов. Мерьте решением вопроса и временем до передачи оператору, и та же самая технология даст совсем другой опыт, потому что стимул начнёт указывать туда же, куда смотрит клиент. ### Наш бот умел только пересказывать раздел вопросов и ответов. Почему? Потому что у него не было доступа к системам, где лежат ответы, а это решение об объёме работ и интеграциях, а не ограничение модели. Автоматика поддержки, не подключённая ни к чему, способна только пересказывать опубликованное, поэтому она конкурирует с вашим же поиском по сайту и проигрывает: клиент обычно прочитал эту страницу до того, как открыл чат. Вопросы, которые действительно порождают обращения, конкретны и личны: где мой заказ, это ещё доступно, за что с меня списали эту сумму, можно ли перенести запись. Ответ на любой из них требует чтения из системы заказов, склада, биллинга или календаря, и построение этого пути и есть основная часть настоящей работы. Предложение, которое её опускает, продаёт обёртку вокруг базы знаний, а демонстрация будет выглядеть отлично, потому что на демонстрациях задают общие вопросы. ### Как должна работать передача оператору? Немедленно, заметно и вместе со всей перепиской, а не отдельным новым обращением. На практике ломается три вещи, и все три чинятся. Аварийный выход спрятан, поэтому клиенту приходится угадывать волшебную фразу, чтобы добраться до человека, и лёгкое раздражение превращается в злость. Передача выглядит голым уведомлением, поэтому оператор начинает с вопроса, на который клиент уже дважды ответил, и автоматика потратила время вместо того, чтобы его сэкономить. И очередь за передачей не укомплектована под тот объём, который бот эскалирует, поэтому быстрый отказ превращается в долгое молчание. Скажите в первом же сообщении, что человек доступен, передавайте при первом признаке раздражения, а не при третьем, и переносите переписку целиком. ### Когда честный ответ состоит в том, что бота внедрять не надо? Когда обращения в основном о том, что бот проверить не может; когда объём слишком мал, чтобы кто-то это поддерживал; или когда настоящая проблема в том, что медленно отвечают люди, а автоматика поддержки станет украшением поверх этого. Последний случай встречается часто и его стоит назвать: если обращения ждут четыре часа, потому что в семь вечера за них никто не берётся, бот, который в семь вечера скажет что-то приветливое и бесполезное, ничего не починил, он просто автоматизировал ожидание. В такой ситуации деньги лучше потратить на маршрутизацию, на покрытие часов или на устранение причины, по которой к вам вообще обращаются. Мы отказываем в автоматизации поддержки по этим основаниям чаще, чем в любой другой категории проектов. --- # Ваш разработчик это построит. Вопрос не в этом URL: https://inite.ai/ru/blog/in-house-developer-vs-agency-for-automation Date: 2026-08-21 Author: Anton Fenix Category: Comparison Tags: Comparison, Operations, Procurement, Automation ## Direct Answer Ваш разработчик почти наверняка соберёт этот процесс. Вопрос в том, что вместо него не появится и заканчивается ли вообще проект без срока. Внутренняя разработка конкурирует с продуктовой дорожной картой, а не с датой поставки, и поэтому она регулярно растягивается, пока внешняя приземляется за недели. Свои выигрывают на знании ваших собственных странных систем и на владении вдолгую; агентство выигрывает на том, что уже видело, как эта работа проваливается. Схема, которая обычно бьёт обе, это внешняя стройка с внутренним владельцем с первого дня. ## Key Facts - Мы выводим 1-3 процесса в продакшен за 2-4 недели под дату поставки, которой у внутреннего проекта обычно нет. - Окупаемость наступает через 3-6 месяцев, и этот отсчёт начинается только когда стройка действительно закончена. - Внутренняя разработка силами одного человека имеет глубину в 1 человека, а очередь исключений переживает большинство сроков работы в компании. - Первая поставка - 1-3 процесса в продакшене за 2-4 недели, переданные команде клиента с документацией и мониторингом. ## Вопрос о способности самый простой Ваш разработчик это построит. В большинстве случаев так и есть, и к любому сравнению, которое начинается с сомнений на этот счёт, стоит отнестись настороженно. Интересные вопросы другие. Что вместо этого не появится и заканчивается ли вообще проект без срока. ## Невидимая цена Внутренняя разработка стоит того, что стояло следующим в дорожной карте. Эта цена никогда не появляется отдельной строкой, поэтому она редко появляется и в решении. Если вместо неё ваш разработчик выпускал бы продукт, за который платят клиенты, автоматизация дорога так, как счёт никогда не покажет. Если команда действительно недозагружена, арифметика переворачивается и строить внутри прямо правильно. Полезный ход в том, чтобы сделать её явной. Назовите функцию или исправление, которое поедет. Поставьте на него дату. Покажите эту дату владельцу дорожной карты и посмотрите, выглядит ли обмен по-прежнему очевидным. ## Почему внутренние проекты растягиваются Они конкурируют с дорожной картой, а не со сроком, а у проекта без даты поставки нет механизма закончиться. Схема повторяется достаточно устойчиво, чтобы её планировать. Стройка начинается быстро и хорошо. Потом приходит срочная проблема клиента, потом релиз, потом кто-то увольняется, и автоматизация становится тем, за что берутся между другими делами. Шесть недель работы, размазанные по восьми месяцам, это не шесть недель работы. Операционная проблема остаётся нерешённой все эти восемь месяцев, а требования под наполовину построенной системой уезжают. Внешняя поставка быстрее не потому, что люди лучше. Она быстрее, потому что у работы есть дата, зафиксированный объём и ничто другое не претендует на те же часы. Если строите внутри, лечение в том, чтобы дать проекту эти три вещи, а не надеяться. ## Что каждая сторона выигрывает на самом деле | | Свои | Агентство | | --- | --- | --- | | Знает недокументированные системы | Да | Изучает, ценой нескольких дней | | Имеет дату поставки | Редко | По договору | | Видело, как это проваливается | Иногда | Это и есть то, что вы покупаете | | На месте на четвёртый месяц | Да | Только если так договорились | | Зависит от того, останется ли один человек | Обычно да | Нет | | Цена по счёту | Нет | Настоящая | | Цена для дорожной карты | Настоящая | Нет | Две последние строки и есть всё сравнение, и указывают они в противоположные стороны. Остальное детали. ## Схема, которая обычно бьёт обе Не выбор. Разделение. Внешняя поставка под дату, внутреннее владение с первой недели. Человек, который будет владеть процессом, сидит в стройке, а не получает документ о передаче в конце, и знание переходит через участие, а не через бумагу. По этой модели мы и работаем, и поэтому [условие про названного владельца](/ru/blog/what-size-company-should-not-automate-yet) стоит в предложении, а не в последней неделе. Она же даёт то, что внутренняя разработка производит естественно, а внешняя часто нет: человека, который действительно понимает, почему система поступает так. ## О найме под это Только если у вас достаточно такой работы, чтобы человеку было интересно, а планка выше, чем кажется. Один инженер по автоматизации это единая точка отказа [так, как агентство ею не бывает](/ru/compare). У работы есть и проблема удержания, о которой не предупреждают: строить первые три процесса интересно, а поддерживать их, пока окружающие системы едут, нет. Компании, которые нанимают под это и потом остаются без новых задач, обычно теряют человека за год и получают систему, которую понимал только он. Если поток настоящий, по процессу в квартал бесконечно, наём выигрывает по экономике с большим отрывом. Если это два проекта и дальше поддержка, покупайте стройку и оставляйте себе владение. ## До того и до другого Ни один путь не поможет, если процесс не готов, и ни подрядчик, ни сотрудник не должны называть цену до того, как кто-то посчитал. [Неделя замеров](/ru/blog/rental-case-the-week-before) одинаково относится и к внутренней разработке, а внутренняя команда скорее пропустит замер, потому что уже уверена, что знает процесс. Обычно она знает свою часть. Это другое, и разрыв между этими двумя вещами разобран в посте [почему большинство карт процессов бесполезны](/ru/blog/protocol-break-mapping-the-process). ## FAQ ### Дешевле ли строить автоматизацию своими силами? По счёту почти всегда да. По полной стоимости всё зависит от того, что большинство сравнений опускает целиком, а именно от того, что ваш разработчик перестанет делать. У внутренней разработки есть настоящая цена, равная тому, что стояло следующим в дорожной карте, и эта цена невидима, потому что никогда не появляется отдельной строкой. Если вместо автоматизации он бы выпускал продукт, за который платят клиенты, автоматизация обходится куда дороже, чем выглядит, хотя деньги никуда не уходят. Если разработчики действительно недозагружены, расчёт переворачивается и строить внутри становится прямо правильным ответом. Полезный ход в том, чтобы сделать альтернативную стоимость явной до решения: назовите функцию или исправление, которое поедет, поставьте на него дату и покажите её тому, кто владеет этой дорожной картой. ### Почему внутренние проекты по автоматизации тянутся так долго? Потому что они конкурируют с дорожной картой, а не со сроком, а у проекта без даты поставки нет механизма закончиться. Схема повторяется достаточно устойчиво, чтобы её планировать: стройка начинается быстро и хорошо, потом приходит срочная проблема клиента, потом релиз, потом кто-то увольняется, и автоматизация становится тем, за что берутся между другими делами. Шесть недель работы, размазанные по восьми месяцам, это не то же самое, что шесть недель работы, потому что операционная проблема остаётся нерешённой эти восемь месяцев, а требования под наполовину построенной системой уезжают. Внешняя поставка быстрее не потому, что люди лучше, а потому, что у работы есть дата, зафиксированный объём и ничто другое не претендует на те же часы. Если строите внутри, лечение состоит в том, чтобы дать проекту те же три вещи, а не надеяться. ### Что свой разработчик действительно делает лучше? Две вещи, и обе стоят настоящих денег. Он знает ваши системы, включая недокументированные, поле, которое значит не то, что написано в его названии, и интеграцию, которую кто-то написал четыре года назад и с тех пор не трогал. Внешняя команда тратит первые дни ровно на это открытие, а в необычном хозяйстве эти дни составляют заметную долю проекта. Второе преимущество это постоянство: он всё ещё здесь на четвёртый месяц, когда поставщик сменил форму, и его знание процесса накапливается, а не уходит вместе с договором. Поэтому самая сильная схема обычно не выбор между двумя, а разделение: внешняя поставка под дату, внутреннее владение с первой недели, чтобы человек, который получит систему, всё это время сидел в комнате, а не принимал документ о передаче. ### Стоит ли нанимать человека именно под автоматизацию? Только если у вас достаточно такой работы, чтобы ему было интересно, а эта планка выше, чем кажется сначала. Один инженер по автоматизации это единая точка отказа так, как агентство ею не бывает, и у работы есть проблема удержания, о которой никто не предупреждает: строить первые три процесса действительно интересно, а поддерживать их, пока окружающие системы едут, нет. Компании, которые нанимают под это и потом не находят, что строить дальше, обычно теряют человека в течение года и получают систему, которую понимал только он. Если поток настоящий, по процессу в квартал бесконечно, наём выигрывает по экономике с большим отрывом. Если это один-два проекта и дальше поддержка, покупайте стройку и оставляйте себе владение: это стоит доли зарплаты и не зависит от того, останется ли один конкретный человек. --- # Почему большинство карт процессов бесполезны и что это лечит URL: https://inite.ai/ru/blog/protocol-break-mapping-the-process Date: 2026-08-20 Author: Михаил Савченко Category: Methodology Tags: Methodology, Operations, Process Audit, INITE Protocol ## Direct Answer Большинство карт процессов рисуют по интервью, а значит они описывают процесс таким, каким его задумали, а не таким, как он идёт, и разрыв между этими двумя картинами и есть место, где живут потери. Карта, которую стоит иметь, несёт число на каждой передаче, включает обходные пути, которыми люди действительно пользуются, и строится частично по системным данным, а не целиком по чужим словам. На одной стадии Break мы так описали 3 процесса-кандидата и оценили потерянные ими часы в 3 140 долларов в неделю, и именно с этой цифрой потом сверяется любое утверждение об окупаемости. ## Key Facts - На одной стадии Break мы описали 3 процесса-кандидата и оценили потерянные ими часы в 3 140 долларов в неделю, то есть 151 тысячу долларов в год по 48 рабочим неделям. - У одного из них медианное время до первого ответа составляло 38 часов, а 24% лидов не получали ответа за пять рабочих дней. - Сверка счетов и учёта времени в том же проекте занимала 8 часов в неделю при доле ошибок 22%. - Мы наблюдаем живую работу по 4-8 часов на каждый целевой процесс и забираем 90 дней операционных данных. - Стадия Break занимает 1-2 неделю работ и может их прекратить, с возвратом депозита за диагностику. ## Карта, которая у компании уже есть Почти в любой операционке где-то лежит схема процесса. Прямоугольники, стрелки, по дорожке на отдел, нарисованные когда-то тем, кто опросил всех. Обычно она верна и почти всегда бесполезна по одной причине: она описывает процесс таким, каким его задумали. Работают иначе, и разница и есть весь предмет разговора. ## Две вещи делают карту стоящей Первая это число на каждой передаче. Пропускная способность, доля ошибок, время цикла. Без них схема сообщает, что шаги существуют, и ничего о том, какой из них чего-то стоит, поэтому каждое решение о том, что чинить, принимается по впечатлению. С ними шаги сами разделяются на раздражающие и дорогие, а эти две группы пересекаются гораздо меньше, чем кто-либо ожидает. Вторая это настоящий маршрут вместе с обходными путями. Если три человека опираются на общую таблицу, которой нет в официальном процессе, эта таблица обязана быть на карте. [Она несущая, и обычно именно в ней прячутся противоречия, ломающие автоматизацию](/ru/protocol). ## Откуда берутся числа Интервью плюс системные данные, и отвечают они на разные вопросы. Люди точны в собственных шагах и ненадёжны в том, что касается ожидания, частоты и исключений. Человек, описывающий свою часть, даёт хороший отчёт о том, что делает он, и плохой о том, сколько работа лежит, пока не дойдёт до него: никто не переживает ту очередь, в которой не стоит. Поэтому мы наблюдаем живую работу по четыре-восемь часов на каждый целевой процесс и забираем девяносто дней операционных данных из тех систем, где они уже есть. Данные исправляют искажения: показывают распределение, а не впечатление, покрывают ночи и выходные, которых никто не помнит, и включают брошенные случаи, а их по определению никто не вспомнит. Интервью после этого нужны для другой работы: объяснить, почему данные выглядят так. ## Что получается на выходе | Артефакт | Что содержит | Для чего нужен | | --- | --- | --- | | Карта процесса | Каждый шаг с пропускной способностью, долей ошибок и временем цикла | Найти дорогие шаги, а не раздражающие | | Отчёт о стоимости хаоса | Деньги в неделю на переделках, потерях и ожидании | База, с которой сверяется любая заявка об отдаче | | Матрица приоритетов | Оценка каждого кандидата по выполнимости и отдаче | Решить, что строим, а что откладываем явно | В одном проекте описание трёх процессов-кандидатов оценило потерянные ими часы в 3 140 долларов в неделю. Самая крупная строчка - обновления статуса проектов: 26 активных проектов, по одной заметке в неделю, 40 минут времени консультанта на заметку, по 95 долларов в час полной стоимости. У другого процесса, сверки счетов и учёта времени, уходило 8 часов в неделю при доле ошибок 22%. Смысл именно в этих числах. Не потому, что они большие - они не большие, и фирма на шестьдесят человек может тащить потерю такого размера годами, ни разу не поморщившись, - а потому, что у будущего утверждения об улучшении появляется конкретная величина для сравнения, и никто не сможет тихо сопоставить число «после» с воображаемым «до». То, что в итог сознательно не вошло, важно не меньше. В том же проекте медианное время до первого ответа на входящий лид было 38 часов, и 24% таких лидов не получали ответа за пять рабочих дней. И то и другое почти наверняка дороже всех часов в итоге. Ни то ни другое в него не входит, потому что оценить их в деньгах значит предположить конверсию и размер сделки, а предположение, зашитое в базу, делает непроверяемым всё, что на ней потом построено. ## Находка это расхождение Самое полезное, что даёт карта, редко нарисовано на карте. Три человека описывают один процесс, и описания расходятся. Это не небрежность, это информация. Места, где рассказы расходятся, почти всегда там, где живут исключения, где обходной путь заменил официальный маршрут или где две системы расходятся в факте, а разные люди выбрали разных победителей. Последнее определяет размер будущего проекта сильнее любого технологического выбора, и подробно этот довод разобран в посте [решение, определившее трёхнедельное внедрение](/ru/blog/rental-case-the-decision-that-shaped-it). ## Что происходит, если числа говорят «нет» Стадия завершает работу, а депозит за диагностику возвращается. Такой исход обязан быть настоящим, иначе все замеры не значат ничего, и по той же причине [условия готовности](/ru/blog/what-size-company-should-not-automate-yet) стоит применять до коммерческого предложения, а не после него. Заказчик всё равно уходит с картой, базовыми замерами и матрицей. Все три полезны независимо от того, будет ли что-то построено, и они удешевляют любой будущий проект, потому что дорогая часть автоматизации состоит в выяснении, как работа движется на самом деле, а не в написании кода, который её двигает. Диагностика, не оставляющая ничего пригодного к переиспользованию, произвела коммерческое предложение, а не аудит. Это различие стоит применять к нам не меньше, чем к другим, а как оно выглядит на живой операционке, показано в посте [неделя замеров в прокатной компании](/ru/blog/rental-case-the-week-before). ## FAQ ### Что делает карту процесса стоящей потраченного времени? Числа на передачах и честность по поводу маршрутов, которыми люди действительно ходят. Схема из прямоугольников и стрелок без величин это картинка оргструктуры, притворяющаяся анализом: она говорит, что шаги существуют, и не говорит, какой из них чего-то стоит, поэтому все дальнейшие решения о выборе цели принимаются по впечатлению. Карта, которую стоит иметь, отмечает пропускную способность, долю ошибок и время цикла на каждой передаче, и это сразу разделяет шаги на раздражающие и дорогие, а пересекаются эти две группы гораздо меньше, чем принято думать. Второе требование в том, чтобы карта показывала настоящий маршрут вместе с обходными путями. Если три человека пользуются общей таблицей, которой нет в официальном процессе, эта таблица обязана быть на карте: она несущая, и обычно именно в ней прячутся противоречия, ломающие автоматизацию. ### Почему нельзя просто опросить тех, кто делает работу? Опрашивать нужно, но останавливаться на этом нельзя, потому что люди точны в собственных шагах и ненадёжны в том, что касается ожидания, частоты и исключений. Человек, описывающий свою часть процесса, даёт хороший отчёт о том, что делает он, и плохой о том, сколько работа лежит между его частью и следующей: никто не переживает ту очередь, в которой не стоит. Он же описывает процесс таким, каким тот должен идти, и это не обман, а естественный способ отвечать на вопрос о своей работе. Девяносто дней системных данных исправляют оба искажения: они показывают распределение, а не впечатление, покрывают ночи и выходные, которых никто не помнит, и включают случаи, которые бросили, а их по определению вспомнить нельзя. Интервью после этого становятся полезны для другой задачи, а именно для выяснения, почему данные выглядят именно так. ### Что такое стоимость хаоса и как она считается? Это деньги, теряемые за неделю на ручных переделках, потерянных передачах и ожидании, посчитанные по процессам-кандидатам, а не по компании целиком. В одном проекте эта цифра составила 3 140 долларов в неделю по трём процессам, и назначение у неё узкое, но важное: это база, с которой сверяется любое последующее утверждение об отдаче, чтобы никто не мог тихо сравнить число «после» с воображаемым «до». Она сознательно строится из полной стоимости часа, а не из окладов из объявления о вакансии, из слабого месяца, а не из хорошего, и из объёмов, взятых в системах, а не в разговоре. Стоимость хаоса, посчитанная иначе, льстит проекту, а польщённый проект всё равно проваливает ту же арифметику позже, только уже после того, как кому-то заплатили. ### Что остаётся у заказчика, когда работа заканчивается? Карта, базовые замеры и матрица приоритетов, и все три полезны независимо от того, будет ли что-то построено. Это важнее, чем звучит, потому что именно это позволяет стадии Break закончиться выводом, что проекта здесь нет. Если арифметика не выживает, работа на этом прекращается, депозит за диагностику возвращается, а заказчик всё равно уходит с посчитанной картиной собственной операционки, которой у него до этого не было. Это же удешевляет второй проект, потому что дорогая часть любой автоматизации состоит в выяснении, как работа движется на самом деле, а не в написании кода, который её двигает. Подрядчик, чья диагностика не оставляет ничего пригодного к переиспользованию, произвёл коммерческое предложение, а не аудит. --- # Решение, определившее трёхнедельное внедрение в прокате URL: https://inite.ai/ru/blog/rental-case-the-decision-that-shaped-it Date: 2026-08-19 Author: Михаил Савченко Category: Case Study Tags: Case Study, Operations, Equipment Rental, Methodology ## Direct Answer Замеры показали, что машины, физически стоящие на площадке, числятся недоступными, а это указывает на данные, а не на сотрудников. Оставалось три варианта: менять учётную систему, ставить языковую модель поверх существующих таблиц или сделать одну запись главной и дать единице техники больше одного возможного состояния. Выбрали третий, и поэтому внедрение заняло 3 недели, а не месяцы. У него была и цена, которую не пишут в коммерческих предложениях: кому-то пришлось отказаться от собственной таблицы. ## Key Facts - На столе лежали 3 варианта, и 2 из них измерялись месяцами, а не неделями. - Выбранное решение заменило 1 булево поле доступности на 7 состояний единицы техники. - Языковой модели осталась ровно 1 задача, чтение заявок свободным текстом, а не вопрос о доступности. - Внедрение заняло 3 недели и увело путь от брони до отгрузки с 4 часов до 3 минут. - Ёмкость пикового сезона выросла после этого в 2,5 раза без изменения численности. ## С чем нас оставили замеры Неделя подсчётов дала одну находку, изменившую проект: машины, физически стоящие на площадке, числились недоступными достаточно часто, чтобы объяснить и двойные брони, и часть отказов. Это утверждение про данные, а не про людей. Выйди счётчик около нуля, честным выводом было бы, что сотрудники перегружены, а лечение это люди или маршрутизация. Он не вышел около нуля, значит ответ лежал в том, как записывалась доступность. Дальше было три варианта. Два из них занимали месяцы. ## Три варианта | Вариант | Срок | Почему отвергнут или выбран | | --- | --- | --- | | Заменить учётную систему | Месяцы | Чинит одно поле миграцией всего, посреди сезона | | Поставить модель поверх таблиц | Недели | Отвечает по неверным данным быстрее и непрослеживаемо | | Одна главная запись, реальные состояния | 3 недели | Чинит именно то, что было сломано | Первый вариант предлагают чаще всего, когда виновата модель данных, и обычно это ответ неверного масштаба. Замена мигрирует историю, переобучает всех и держит две наполовину доверенные системы параллельно, и всё это ради одного поля. В сезонном бизнесе делать это в те месяцы, когда операционка и так напряжена, не деталь. Второй вариант было бы легче всего продать. Модель, читающая существующие таблицы и отвечающая на вопросы о доступности, хорошо смотрится на демонстрации и ломается ровно так, как замеры уже предсказали: данные говорят, что машина недоступна, пока она стоит на площадке, а модель повторяет это с большей уверенностью и меньшей прослеживаемостью, чем таблица. ## Почему модель эту работу не получила Под этим конкретным выбором лежит общее правило, и его стоит отделить от частностей. Проверка доступности обязана возвращать один и тот же ответ на один и тот же вопрос каждый раз и обязана объясняться потом, когда клиент спросит, почему ему отказали. Вероятностный ответ на детерминированный вопрос это дефект, и улучшение модели этого не меняет. Поэтому в готовой системе модель получила ровно одну работу: чтение заявок, приходящих свободным текстом в одиннадцать вечера, где машина названа словами клиента, а даты записаны в форме, которой не ждёт ни одно поле. Для правила это по-настоящему трудно, для модели по-настоящему легко. Полное разделение изложено в посте [куда уходят четыре часа](/ru/blog/order-processing-equipment-rental). ## Что изменило выбранное решение Две вещи, и вторая весила больше. Доступность перестала быть одним полем «да или нет» и стала семью явными состояниями, поэтому машина, вернувшаяся и ждущая осмотра, машина в пути и машина, забронированная без подтверждения, перестали показываться свободными. Затем одна запись стала главной по тому, что забронировано, а проверка переехала на момент подтверждения вместо момента заявки. Эта вторая правка и прекратила двойные брони, потому что конфликты жили в окне между «посмотрел в общую таблицу» и «пообещал машину». Ни одна из правок не экзотика. Ни одна не потребовала новых технологий. Обе потребовали решения, которое кто-то должен был принять и которого никто не принимал. ## Цена, которой нет ни в одном предложении Сделать одну запись главной значит, что кто-то должен перестать вести свою копию. В любой такой операционке есть один-два человека с личной таблицей, и они не вредничают. Они завели её потому, что когда-то официальная система ошиблась, а их таблица оказалась права, и с тех пор она тихо держала бизнес. Попросить их довериться системе, которая их подводила, и есть настоящая работа, и просьба ложится совершенно по-разному в зависимости от того, выслушали ли сначала их возражение. Именно эта часть ближе всего подошла к срыву проекта. Её нет ни в одном коммерческом предложении, включая наши ранние, и поэтому решение об источнике правды мы теперь проговариваем в начале, а не обнаруживаем на второй неделе. ## Что это дало Путь от брони до отгрузки ушёл с 4 часов до 3 минут. Двойные брони исчезли. Ёмкость пикового сезона выросла в 2,5 раза той же командой, а внедрение уложилось в 3 недели. Полный набор на [странице кейса](/ru/cases/equipment-rental-automation). Три недели это следствие решения, а не скорости. Два отвергнутых варианта не были медленными версиями того же проекта, это были другие проекты, и один из них закончился бы примерно к концу сезона. ## Переносимая часть До согласия на что-либо найдите факт, о котором две ваши системы расходятся, и решите, какая из них главнее. Это решение стоит ноль, занимает полдня и определяет размер каждого следующего проекта. Замер, который его вскрывает, описан в посте [неделя до](/ru/blog/rental-case-the-week-before), и по той же причине [противоречивые данные это единственный сорт бардака, вокруг которого не стоит автоматизировать](/ru/blog/what-size-company-should-not-automate-yet), пока у вопроса нет ответа. ## FAQ ### Почему не поменять учётную систему, раз проблема была в модели данных? Потому что модель данных была неверна в одном конкретном месте, а не повсюду, а замена системы ради одного поля это проект на месяцы, несущий риски, никак не связанные с исходной проблемой. Замена означает миграцию истории, переобучение всех и период параллельной работы двух систем, каждой из которых доверяют наполовину. Она же сажает всю операционку на новый инструмент ровно в те месяцы, когда операционка и так на пределе, а в сезонном бизнесе выбор момента это не деталь. Более узкое лечение состояло в том, чтобы оставить существующей системе то, что она держала верно, и сделать одну запись главной по единственному, в чём она ошибалась, то есть по броням на единицы техники. Это недели вместо месяцев, и это оставляет возможность заменить систему позже, а не тратит её сейчас. ### Чем плоха была языковая модель поверх существующих таблиц? Она отвечала бы на вопрос о доступности быстрее и ровно так же неверно, а это исход хуже, чем отвечать медленно. Замеры уже установили, что исходные данные показывают машины недоступными, пока те стоят на площадке, и модель, читающая эти данные, воспроизводит ошибку с большей уверенностью и меньшей прослеживаемостью. Есть и более тонкая проблема, которую стоит назвать, потому что она повторяется в большинстве проектов, где модель предлагают как короткий путь: проверка доступности обязана возвращать один и тот же ответ на один и тот же вопрос каждый раз и обязана поддаваться объяснению потом, когда клиент спросит, почему ему отказали. Вероятностный ответ на детерминированный вопрос это дефект независимо от качества модели. Место в готовой системе модель заработала, но у входной двери, на неструктурированных заявках, а это работа, которую правило действительно не выполнит. ### Что конкретно изменило выбранное решение? Две вещи, и вторая была важнее. Во-первых, доступность перестала быть единственным полем «да или нет» и стала явным набором состояний, поэтому машина, вернувшаяся и ждущая осмотра, машина в пути и машина, забронированная без подтверждения, перестали показываться свободными. Во-вторых, одна запись стала главной по тому, что забронировано, а проверка доступности переехала на момент подтверждения вместо момента заявки. Именно вторая правка убрала двойные брони, потому что конфликты жили в окне между тем, как человек посмотрел в общую таблицу, и тем, как он пообещал машину. Ни одна из правок не экзотика, ни одна не потребовала новых технологий. Обе потребовали решения, которое кто-то должен был принять и которого никто не принимал, и в этом обычная форма таких проектов. ### Чего это решение стоило? Кому-то пришлось перестать вести собственную копию, и это политическая цена, а не техническая. На практике в любой такой операционке есть один-два человека с личной таблицей, и обычно потому, что когда-то официальная система ошиблась, а их таблица оказалась права. Эти люди не вредничают: они держат тот самый обходной путь, на котором бизнес и работал. Сделать одну запись главной значит попросить их довериться системе, которая их уже подводила, и такая просьба ложится совершенно по-разному в зависимости от того, выслушали ли сначала их возражение. Это та часть проекта, которая ближе всего подошла к тому, чтобы его сорвать, она не встречается ни в одном коммерческом предложении, включая наши ранние, и поэтому решение об источнике правды мы теперь проговариваем в самом начале, а не обнаруживаем на второй неделе. --- # Шесть часов до восьми минут: заявки в агентстве недвижимости URL: https://inite.ai/ru/blog/lead-response-real-estate-agency Date: 2026-08-18 Author: Михаил Савченко Category: Automation Tags: Automation, Operations, Real Estate, Lead Response ## Direct Answer В агентстве недвижимости время ответа задаётся маршрутизацией, а не скоростью печати. Заявка приходит по конкретному объекту, и кто-то должен решить, какой агент её ведёт, обращался ли этот человек уже через другой портал и доступен ли объект вообще. На эти три решения и уходят часы, и все три это правила, а не суждение. Их автоматизация увела одно агентство с 6 часов ответа до 8 минут и сократила цикл сделки с 14 дней до 5, а внедрение заняло 4 недели. ## Key Facts - В одном агентстве время ответа на заявку сократилось с 6 часов до 8 минут, а цикл сделки с 14 дней до 5. - Подготовка документов там же ушла с 2 дней до 20 минут, а продуктивность агентов выросла на 60%. - Внедрение заняло 4 недели, что укладывается в обычные 2-4 недели на 1-3 процесса. - Покупатель, написавший через 3 портала об одной квартире, это 1 заявка, а счёт её за 3 и есть причина, по которой людям звонят дважды. - Первая поставка - 1-3 процесса в продакшене за 2-4 недели, переданные команде клиента с документацией и мониторингом. ## Заявка это не одна сущность Покупатель пишет про двухкомнатную квартиру. Это одно сообщение содержит три отдельных вопроса, и агентство отвечает на них по очереди, обычно с человеком, ожидающим между каждым. Кто этот человек и не говорили ли мы с ним уже? Он может лежать в воронке под другим номером с другого портала, потому что серьёзный покупатель пишет в несколько мест за один вечер. Что это за объект и доступен ли он ещё? Ушедший в задаток в пятницу это другой разговор, и агент, который этого не знает, сейчас потратит полдня. Какой агент его ведёт? Район, специализация, текущая загрузка и то, кто в эти выходные работает. Ни одно из трёх не суждение. Все три это правила, а часы между приходом заявки и уходом ответа почти целиком состоят из ожидания человека, который эти правила применит. ## Куда уходили шесть часов В агентстве, с которым мы работали, лиды жили в личных блокнотах агентов, а обновления по объектам рассылались письмами вручную. Воронку никто целиком не видел, поэтому застрявшая сделка оставалась незаметной, пока кто-нибудь не вспоминал спросить. | Шаг | Кто делал | Чего стоил | | --- | --- | --- | | Заметить заявку | Тот, кто заглянул в этот ящик | От минут до часов, смотря когда | | Проверить, новый ли покупатель | Агент, по памяти | Повторный контакт, когда память подводила | | Проверить доступность | Звонок или сообщение коллеге | Ожидание коллеги | | Решить, кто ведёт | Тот, кто был в офисе | Неровная загрузка, лучший агент завален | | Ответить | Агент | Минуты | Сам ответ всегда занимал минуты. Всё, что выше него, и было шестью часами. ## Дедупликация это невыигрышная половина Покупатель, написавший через три портала об одной квартире, это одна заявка. Считать её за три и есть способ позвонить одному человеку дважды за вечер и выглядеть неорганизованно ровно в тот момент, когда вас сравнивают с двумя конкурентами. Сопоставление только по номеру телефона не работает, потому что порталы номера маскируют. Только по имени тоже мимо, потому что имена повторяются. Срабатывает сочетание контакта, объявления и временного окна, и это правило, а не модель, и ни один продавец не применит его надёжно в девять вечера. Описывать эту часть проекта скучнее всего, а на практике она одна из самых ценных. ## Правило маршрутизации это управленческое решение Распространённых правил три, и они оптимизируют разное. | Правило | Оптимизирует | Тихо стоит | | --- | --- | --- | | Круговая раздача | Справедливость между агентами | Конверсию, когда агенты неодинаковы | | Специализация | Качество разговора | Неровную загрузку, единые точки отказа | | По загрузке | Занятость всех | Наказывает быстрых дополнительной работой | Большинству агентств нужна смесь. Самая полезная часть проекта часто тот разговор, который заставляет записать эту смесь, потому что непроговорённое правило и люди соблюдают непоследовательно. Мы реализуем то правило, которое выбрало агентство. Выбирать его не наше дело, и подрядчик, приходящий с мнением о том, кто из ваших агентов заслуживает больше заявок, неправильно понял задачу. ## Что отвечает в два часа ночи Достаточно, чтобы удержать разговор, и ничего обязывающего. Подтверждает, что объект ещё доступен. Отвечает на то, на что может ответить объявление: этаж, площадь, цена, что входит. Предлагает слоты из настоящего календаря назначенного агента. Фиксирует, что покупатель ищет, его словами. Торг, цена вне опубликованной и согласие на условия остаются за человеком. Это доходит до агента вместе со всей перепиской, и в этом разница между передачей и уведомлением. Граница та же, что описана в [наших правилах о человеке в контуре](/ru/blog/safe-ai-framework-human-in-loop), и это не недоработка, за которую мы извиняемся: автоматика, договаривающаяся о цене в два часа ночи, это риск, а не возможность. Большинство ночных обращений теряется потому, что никто не подтвердил существование квартиры, а не потому, что ночью никто не торговался. К утру у покупателя записаны два просмотра в другом месте. ## Откуда на самом деле взялся короткий цикл Время ответа ушло с 6 часов до 8 минут. Цикл сделки ушёл с 14 дней до 5. Эти числа цитируют рядом, и второе не вызвано первым. Цикл укоротила остальная часть той же работы: просмотры, записанные без трёх звонков, пакеты документов за 20 минут вместо 2 дней, и воронка, видимая всем, поэтому застрявшая сделка заметна, пока её ещё можно спасти. Продуктивность агентов выросла на 60% на том же основании. Проект, чинящий только первый ответ, даёт прекрасную первую метрику и почти не сдвинувшийся цикл. На этом различии стоит настаивать, когда вам называют эффектное число, и это та же дисциплина, что в [четырёх вопросах, ломающих большинство расчётов окупаемости](/ru/blog/roi-math-for-automation-projects). ## До того как на это соглашаться Посчитайте по своим системам две вещи: сколько заявок приходит вне рабочих часов и на сколько отвечают позже чем через час. Потом посчитайте, сколько покупателей встречается дважды. Эти три числа определяют весь проект, а метод описан в [неделе замеров](/ru/blog/rental-case-the-week-before). Полный кейс лежит на [странице агентства](/ru/cases/real-estate-deal-cycle), а что именно мы внедряем в этой отрасли, изложено на страницах [ИИ-автоматизация для недвижимости](/ru/industries/real-estate) и [обработка заявок](/ru/automation/lead-response). ## FAQ ### Почему заявку по объекту маршрутизировать труднее обычного лида? Потому что это не одна сущность, а три, а универсальный маршрутизатор лидов справляется только с первой. Есть человек, который может уже существовать в вашей воронке под другим номером с другого портала. Есть конкретное объявление, у которого есть ответственный, статус и, возможно, договорённость об эксклюзиве, определяющая, кому вообще разрешено его вести. И есть правило маршрутизации, которое в большинстве агентств представляет смесь района, специализации, текущей загрузки и того, кто в эти выходные работает. Ошибка по человеку означает второй звонок и вид неорганизованной конторы. Ошибка по объявлению отправляет агента показывать квартиру, ушедшую в задаток в пятницу. Ошибка по правилу заваливает лучшего продавца, пока коллега сидит без дела. Обычный приём лидов в CRM не решает ни одну из трёх задач, поэтому агентства с CRM всё равно отвечают часами. ### Что определяет, какому агенту достаётся заявка? Это управленческое решение, и честный ответ в том, что принимаем его не мы: мы реализуем то, которое агентство уже приняло, а часто просто никогда не записывало. Распространённых правил три, и они оптимизируют разное. Круговая раздача справедлива и проста и не замечает, что одни агенты закрывают заметно лучше других. Специализация по району или типу объекта даёт более качественные разговоры и распределяет нагрузку неровно. Раздача по загрузке держит всех занятыми и тихо наказывает тех, кто работает быстрее, подкидывая им ещё. Большинству агентств нужна смесь, и самая полезная часть проекта обычно тот разговор, который заставляет эту смесь проговорить вслух: незаписанное правило нельзя автоматизировать, а на практике его и люди соблюдают непоследовательно. ### Что именно отвечает система в два часа ночи? Достаточно, чтобы удержать разговор, и никогда ничего обязывающего. Она подтверждает, что объект ещё доступен, отвечает на вопросы, у которых есть фактический ответ из самого объявления: этаж, площадь, цена, что входит; предлагает слоты для просмотра из настоящего календаря назначенного агента и фиксирует, что покупатель на самом деле ищет. Чего она не делает: торг, цена вне опубликованной и согласие на условия остаются за человеком. Это уходит агенту вместе со всей перепиской, и в этом разница между передачей и уведомлением. Коммерческий смысл узкий: большинство ночных обращений теряется не потому, что ночью никто не торговался, а потому, что никто не подтвердил, что квартира ещё существует, и к утру покупатель записался на два просмотра в другом месте. ### Как быстрый ответ превращается в короткий цикл сделки? Через уменьшение числа пауз, и здесь стоит быть точным, потому что эти два числа цитируют рядом так, будто одно очевидно вызывает другое. Падение времени ответа с 6 часов до 8 минут само по себе не укорачивает сделку на девять дней. Цикл укоротила остальная часть той же работы: просмотр, записанный без трёх звонков, пакет документов, собранный за 20 минут вместо 2 дней, и воронка, которую все видят, поэтому застрявшая сделка заметна, пока её ещё можно спасти. Число про ответ привлекает внимание, потому что оно эффектное; двигают цикл числа про документы и воронку. Проект, который чинит только первый ответ, даст прекрасную первую метрику и почти не сдвинувшийся цикл. --- # Что автоматизировать первым и почему не самую ненавистную работу URL: https://inite.ai/ru/blog/what-to-automate-first-in-a-small-company Date: 2026-08-17 Author: Михаил Савченко Category: Operations Tags: Operations, Procurement, Automation, Methodology ## Direct Answer Первый процесс выбирают по радиусу поражения, а не по тому, насколько его не любят. Самая ненавистная работа обычно та, что касается договоров или денег, а именно там ранняя ошибка стоит клиента, а не минуты. Хороший первый процесс идёт достаточно часто, чтобы дать сигнал за недели, ломается так, что человек успевает откатить, и имеет владельца, который это заметит. На практике это чаще всего маршрутизация входящих обращений, поэтому из четырёх процессов, которые мы внедряем чаще всего, первым обычно идёт обработка заявок, и она же больше других говорит, стоит ли делать следующий. ## Key Facts - Мы выводим 1-3 процесса в продакшен за 2-4 недели, поэтому первый это выбор из 3, а не вопрос о том, делать ли вообще. - Из 4 процессов, которые мы внедряем чаще всего, первой обычно идёт обработка входящих заявок. - Во внедрении у агентства недвижимости время ответа сократилось с 6 часов до 8 минут, а цикл сделки с 14 дней до 5. - Окупаемость обычно наступает через 3-6 месяцев, а первый проект даёт пригодный сигнал куда быстрее, если идёт достаточно часто. ## Интуиция ошибается предсказуемым образом Спросите команду, [какой процесс автоматизировать первым](/ru/answers/is-my-process-worth-automating), и вам назовут тот, который ненавидят. Эта работа обычно муторная, ответственная и редкая. Подготовка договоров. Сверка в конце месяца. То, что обязано быть точным, занимает полдня и случается дважды в месяц. Как первый кандидат это почти худший выбор, причём по причинам, никак не связанным с тем, заслуживает ли она автоматизации когда-нибудь. ## Критерий это радиус поражения Список упорядочивает вопрос о том, что произойдёт, когда система ошибётся, потому что на первом проекте она ошибётся. | Процесс | Если сломается | Радиус поражения | | --- | --- | --- | | Маршрутизация заявок | Один ответ уйдёт не тому | 1 переписка, откат за минуты | | Проверка доступности | Откажут в брони, которую можно было взять | 1 бронь, откат в тот же день | | Сборка документов | Уйдёт договор с неверными условиями | Клиент и, возможно, юридическая проблема | | Цена или обязательство | Компания связана обязательством | Клиент, и обязательство остаётся в силе | Первые два это места, где учатся. Последние два места, где осторожничают, и именно оттуда почти всегда приходят жалобы. ## Частота превращает стройку в доказательство Второй критерий это частота, и он определяет, сколько вы будете ждать, чтобы узнать хоть что-то. Процесс, идущий сорок раз в неделю, даёт пригодный ответ за две недели. Та же стройка на процессе, который идёт дважды в месяц, молчит квартал, а к этому времени команда перестала следить, а подрядчик занялся другим. Отсюда же практическая причина уложить первый проект в две-четыре недели. Долгий первый проект это ставка, сделанная до прихода информации, связывающая вас с поставщиком и с решением тогда, когда вы знаете меньше всего. ## Каким он обычно оказывается Из четырёх процессов, которые мы внедряем чаще всего, первой обычно идёт обработка входящих обращений. Она идёт постоянно. Ошибка это один ответ не по адресу. Она задевает мало систем, поэтому интеграция не съедает график. И она быстро даёт число: во внедрении у агентства недвижимости время ответа ушло с 6 часов до 8 минут, а цикл сделки с 14 дней до 5. Второе число и финансирует следующий проект, и стоит заметить, откуда оно взялось. Быстрые ответы не сэкономили никому полдня измеримым образом. Они укоротили цикл, а короткие циклы лучше конвертируются, потому что меньше покупателей успевает остыть в паузе. ## Когда очевидный кандидат касается денег Разделите его, а не пропускайте, потому что часть, которая касается денег, редко оказывается той частью, где уходит время. В потоке заказов проверку доступности, сборку документов и планирование отгрузки можно автоматизировать, оставив человеку обязательство, цену и условия. Вы получаете частоту и экономию, не ставя трёхнедельную систему в положение, где она связывает компанию. Это не поблажка для начинающих. Это конструкция, которую готовая система имеет в любом случае, по причинам, изложенным в [наших правилах о человеке в контуре](/ru/blog/safe-ai-framework-human-in-loop), а [поток заказов в прокате](/ru/blog/order-processing-equipment-rental) разбирает именно такое разделение на живом примере. ## Для чего первый проект нужен на самом деле Это самая дешёвая возможность узнать три вещи, о которых не скажет ни одно предложение. Как ваша команда реагирует на систему, принимающую решения, а реагирует она редко так, как кто-либо предсказывал. Сколько исключений процесс порождает на самом деле, когда их кто-то считает, а это почти всегда больше оценки. И рассказывает ли подрядчик о проблемах раньше, чем вы их находите, а вот это и должно решать, будет ли второй проект. Эти ответы меняют форму того, что пойдёт следом. Выбрать первый проект, который не может их дать в течение месяца, и есть дорогая часть ошибки, и поэтому порядок важнее списка. ## До всего этого Ничего из перечисленного не поможет, если процесс не проходит проверку на готовность, и пять условий из поста [когда автоматизироваться ещё рано](/ru/blog/what-size-company-should-not-automate-yet) стоит прогнать до того, как выбирать порядок. Возьмите объём из своих систем. Назовите владельца. И берите первым частый и обратимый, даже если жалуются не на него. ## FAQ ### Почему не начать с процесса, на который больше всего жалуются? Потому что жалобы отслеживают неприятность, а неприятность не связана ни с ценностью, ни с безопасностью. Работа, которую все ненавидят, обычно муторная, ответственная и редкая, а это почти худшее возможное сочетание для первой автоматизации. Редкость означает, что вы месяцами ждёте достаточного числа прогонов, чтобы понять, работает ли оно. Высокая ответственность означает, что первая ошибка видна клиенту, а не коллеге. А муторность даёт процесс, набитый исключениями, и это ровно тот материал, из-за которого стройка длинная, а результат разочаровывает. Место у такого процесса есть, и оно второе или третье, после того как команда поняла, как система себя ведёт, и после того как кто-то несколько недель посмотрел очередь исключений. Начинать с него самый частый способ отвратить организацию от всей затеи. ### Что конкретно делает кандидата хорошим первым? Четыре свойства, и первые два весят гораздо больше остальных. Процесс должен идти часто, потому что частота превращает стройку в доказательство: то, что происходит сорок раз в неделю, скажет вам о своей работоспособности за две недели, а то, что происходит дважды в месяц, будет молчать квартал. Он должен ломаться обратимо, то есть человек должен успевать отменить ошибку до того, как её увидит клиент. У него должен быть названный владелец, который действительно будет смотреть. И он должен задевать достаточно мало систем, чтобы интеграционная работа не съела график. Маршрутизация входящих обращений удовлетворяет всем четырём в большинстве небольших компаний, поэтому так часто и идёт первой, а ещё она даёт то самое число, под которое легко финансировать второй проект. ### Первый проект это про автоматизацию или про обучение? И то и другое, и считать его только первым ошибка. Первый проект это самая дешёвая возможность выяснить три вещи, о которых не скажет ни одно коммерческое предложение: как ваша команда реагирует на систему, принимающую решения; сколько исключений ваш процесс на самом деле порождает, когда их кто-то считает; и рассказывает ли подрядчик о проблемах раньше, чем вы их находите. Эти ответы меняют то, каким должен быть второй проект, а иногда меняют и то, будет ли он вообще. По этой же причине мы держим первый достаточно маленьким, чтобы закончить за две-четыре недели. Полугодовой первый проект это ставка, сделанная до прихода любой информации, и она связывает вас с поставщиком и с проектным решением ровно в тот момент, когда вы знаете меньше всего. ### А если очевидный первый кандидат касается денег? Тогда его надо разделить, а не пропустить, потому что часть, которая касается денег, редко оказывается той частью, где уходит время. В потоке заказов проверку доступности, сборку документов и планирование отгрузки можно автоматизировать, оставив человеку само обязательство, цену и условия. Так вы получаете частоту и экономию времени, не ставя раннюю систему в положение, где она связывает компанию обязательством. Это то же правило, которое мы применяем постоянно, а не только на старте: всё обязывающее уходит человеку, исключения приходят с полным контекстом, каждое автоматическое решение логируется. Начать с необязывающей части это не уступка новичкам, а ровно та конструкция, которую готовая система имеет в любом случае. --- # Пять признаков того, что автоматизироваться вам ещё рано URL: https://inite.ai/ru/blog/what-size-company-should-not-automate-yet Date: 2026-08-16 Author: Михаил Савченко Category: Operations Tags: Operations, Procurement, Automation, Strategy ## Direct Answer Численность сотрудников это неверная проверка. Окупится ли автоматизация сейчас, решают пять условий: хватает ли объёма, чтобы фиксированная стоимость стройки на него разделилась; достаточно ли устойчив процесс, чтобы пережить окно окупаемости; есть ли внутри человек, который примет результат; настолько ли чисты данные, чтобы автоматизация не зацементировала бардак; и находится ли узкое место действительно здесь, а не в другом месте. Провал любого из пяти обычно повод подождать квартал, а не покупать. Компания из двенадцати человек проходит все пять, а компания из двухсот заваливает три, и поэтому размер предсказывает так мало. ## Key Facts - Мы выводим 1-3 процесса в продакшен за 2-4 недели, а окупаемость обычно наступает через 3-6 месяцев. - Процесс, который заметно меняется каждый месяц, будет перестроен от 3 до 6 раз внутри этого окна окупаемости. - Точка входа - бесплатная диагностика на 15 минут, до любого разговора о цене и объёме. - Готовность определяют 5 условий, и провала 1 из них обычно достаточно, чтобы подождать. ## Размер это неверный вопрос Вопрос приходит в стандартной форме: мы уже достаточно большие для этого? Полезного ответа у него нет, потому что [арифметика, которая всё решает, с численностью не связана](/ru/answers/is-my-process-worth-automating). Прокатная компания из двенадцати человек с четырьмя сотнями броней в месяц имеет больше автоматизируемого объёма, чем консалтинг из двухсот человек, где каждый проект уникален. Размер коррелирует с парой важных вещей и не предсказывает ни одну из них достаточно точно, чтобы этим пользоваться. Всё определяют пять условий. Провал одного обычно повод подождать квартал. ## Первое: объём должен разделить стоимость стройки Экономика автоматизации это фиксированные затраты, размазанные по пропускной способности. Одна эта фраза объясняет большинство разочаровавших проектов. Процесс, идущий четыреста раз в месяц и экономящий пятнадцать минут за раз, это понятный случай. Тот же процесс при восьмидесяти прогонах в месяц имеет ту же стоимость стройки, размазанную по пятой части выгоды, и честную арифметику обычно не проходит, хотя экономия за прогон одинаковая. Берите объём из своих систем, а не из опроса, считайте по слабому месяцу, а не по хорошему, и спросите, как выглядит окупаемость, если объём не вырастет никогда. Остальную арифметику разбирают [четыре вопроса, ломающие большинство расчётов окупаемости](/ru/blog/roi-math-for-automation-projects). ## Второе: процесс должен стоять на месте К концу окна окупаемости он должен оставаться узнаваемо тем же, а окно это три-шесть месяцев. Проверка конкретная. Опишите шаги такими, какими они были полгода назад, и такими, какие сейчас. Если разница в краевых случаях, всё в порядке, для них и существует очередь исключений. Если сама последовательность менялась дважды, вы автоматизируете чертёж, который ещё рисуют, а процесс с заметными ежемесячными изменениями будет перестроен от трёх до шести раз до наступления окупаемости. Дождаться, пока он устоится, гораздо дешевле, чем перестраивать, и с большим отрывом. ## Третье: кто-то внутри должен им владеть Один названный человек, у которого процесс записан в обязанности после ухода подрядчика, с полномочиями менять его без комиссии. Не тот, кто подписал договор. Обычно не самый старший в комнате. Работа владельца невыигрышная: смотреть очередь исключений, замечать смену формы нагрузки, решать, получает новый краевой случай правило или человека. Автоматизация без владельца деградирует тихо, и тихо здесь и есть проблема. Дашборды продолжают выглядеть нормально, пока исключения копятся, а сотрудники изобретают обходные пути мимо системы. Если вы не можете назвать этого человека до начала проекта, начните с этого. Стоит ноль, а предсказывает исход сильнее всего остального. ## Четвёртое: бардак в данных должен быть правильного сорта | Вид бардака | Автоматизировать сейчас? | Почему | | --- | --- | --- | | Пропущенные поля | Да | Процесс может спросить; дыры становятся видны когда важны | | Разнобой форматов | Да | Приведение к одному виду дёшево и механично | | Устаревшие записи | Обычно да | Автоматика вскрывает устаревание быстрее людей | | Две системы расходятся | Нет | Автоматизация противоречия исполняет его на скорости | Предусловие это не чистые данные. Это принятое решение о том, какой источник главный по каждому полю, от которого зависит процесс. Без такого решения автоматизация бардак не чистит, а цементирует, и расхождение исполняется быстрее, чем человек успел бы его поймать. ## Пятое: узкое место должно быть действительно здесь Самая дорогая версия этой ошибки это прекрасно автоматизированный бэк-офис, приделанный к компании, чьё настоящее ограничение в том, что к ней недостаточно обращаются. Операционная автоматизация ускоряет исполнение спроса. Если не хватает именно спроса, вы будете быстрее делать меньший объём, и прирост оказывается настоящим и коммерчески невидимым. Мы измеряем сорок-шестьдесят процентов от автоматизированной части, а не от компании, и если автоматизированная часть не ограничение, эффект на уровне компании близок к нулю. Проверяется вопросом: что случится, если процесс станет вдвое быстрее. Если ответ «сделаем больше работы, и у неё есть выручка», то проект правильный. Если ответ «все будут ждать с большим комфортом», то деньги лучше потратить на то, чего они ждут. ## Что делать с ответом «пока рано» Правильная реакция редко состоит в том, чтобы ничего не делать квартал. Измеряйте. Выгрузите отметки времени, посчитайте объём слабого месяца, назовите владельца и решите, какая система главная по каждому спорному полю. Эта работа полезна независимо от того, дойдёт ли дело до автоматизации, она укорачивает будущий проект, и это ровно тот аудит, который описан в посте [что обязан выдать аудит процессов](/ru/blog/process-audit-before-automation) и показан на живой операции в [неделе замеров](/ru/blog/rental-case-the-week-before). Мы отказываем проектам по этим основаниям, и стоит прямо сказать, что это в наших интересах не меньше, чем в ваших. Проект, не проходящий арифметику, всё равно не пройдёт её после того, как нам заплатили, а рекомендация стоит дороже гонорара. ## FAQ ### Есть ли численность, ниже которой автоматизация не имеет смысла никогда? Нет, и то, что этот порог продолжают искать, и есть причина, по которой на вопрос отвечают плохо. Арифметикой правит то, как часто идёт процесс и сколько занимает каждый прогон, а ни то ни другое надёжно с численностью не связано. Прокатная компания из двенадцати человек с четырьмя сотнями броней в месяц имеет больше автоматизируемого объёма, чем консалтинг из двухсот человек, где каждый проект свой. Численность предсказывает кое-что второго порядка, и это стоит знать: в маленьких компаниях чаще нет человека, способного принять результат после сдачи, а в больших чаще встречаются процессы, о которых три отдела не могут договориться. Оба препятствия настоящие, но они про владение и про согласие, а не про размер, и проверять их надо напрямую, а не выводить из числа сотрудников. ### Насколько устойчивым должен быть процесс? Настолько, чтобы к концу окна окупаемости он оставался узнаваемо тем же процессом, а окно у нас три-шесть месяцев. Планка ниже, чем звучит, потому что операционные процессы обычно куда устойчивее, чем считают те, кто их ведёт: еженедельно меняются как правило исключения, а не основной путь. Проверка конкретная: опишите шаги такими, какими они были полгода назад, и такими, какие они сейчас, и посмотрите, в чём разница, в последовательности или только в краевых случаях. Если сама последовательность менялась дважды, перед вами процесс, который всё ещё проектируется, а автоматизировать проект в процессе черчения значит платить за его перестройку от трёх до шести раз, пока он не устоится. Дождитесь этого. Ожидание дешевле перестройки, и с большим отрывом. ### Что на практике значит «есть владелец»? Один названный человек внутри вашей компании, у которого этот процесс записан в обязанности после ухода подрядчика и у которого хватает полномочий менять его без созыва комиссии. Это не тот, кто подписал договор, и обычно не самый старший из участников. Работа владельца невыигрышная и решающая: он смотрит очередь исключений, замечает, когда меняется форма нагрузки, решает, получает новый краевой случай правило или человека, и он же говорит, что что-то не так, раньше, чем это скажет отчётность. Автоматизация без владельца деградирует тихо, потому что дашборды продолжают выглядеть нормально, пока исключения копятся, а сотрудники изобретают обходные пути мимо системы. Если вы не можете назвать этого человека до начала проекта, чинить надо это, и стоит починка ноль. ### У нас бардак в данных. Сначала чистить или сначала автоматизировать? Зависит целиком от того, какой это бардак, и различить стоит за десять минут до принятия решения. Пропуски и разнобой в форматах обычно можно автоматизировать как есть, потому что процесс можно построить так, чтобы он запрашивал недостающее, и на практике автоматизация такой бардак скорее лечит, делая дыры видимыми ровно в тот момент, когда они важны. Опасный вид это противоречия: две системы расходятся в одном и том же факте, и правила о том, какая из них главнее, нет. Автоматизация такое не чистит, а цементирует, и расхождение начинает исполняться на скорости вместо того, чтобы его поймал человек, который знал, что вторая система надёжнее. Предусловие тут не чистые данные, а принятое решение о том, какой источник считается главным по каждому полю, от которого зависит процесс. --- # Что изменило решение по делу Amazon против Perplexity URL: https://inite.ai/ru/blog/agentic-browsing-after-the-amazon-ruling Date: 2026-08-15 Author: Михаил Савченко Category: Agentic Engineering Tags: Agentic Engineering, Legal, Web Bot Auth, Strategy ## Direct Answer В августе 2026 Девятый окружной апелляционный суд снял предварительный запрет, который не давал браузеру Comet от Perplexity работать на Amazon. Суд решил, что по имеющимся материалам Amazon вряд ли выиграет по Computer Fraud and Abuse Act, потому что к системам Amazon обращаются его собственные покупатели, а не Perplexity. Это первое федеральное апелляционное решение о том, могут ли ИИ-агенты, действующие за пользователя, получать доступ к онлайн-площадкам. Суд ограничил вывод конкретными материалами дела, поэтому практический урок узкий: закон о неправомерном доступе слабое оружие против программы, которую выбрал сам клиент. ## Key Facts - Amazon подал иск против Perplexity в ноябре 2025, ссылаясь на федеральный CFAA и калифорнийский CDAFA. - Окружной суд удовлетворил предварительный запрет в марте 2026, о чём сообщили 10 марта 2026. - Девятый округ приостановил этот запрет на время апелляции и отменил его в августе 2026. - Это 1-е федеральное апелляционное решение о доступе ИИ-агентов, действующих за пользователя, к онлайн-площадке. - Web Bot Auth поддержан в AWS WAF с ноября 2025 и в Cloudflare с начала 2026. ## Что суд постановил на самом деле Amazon подал на Perplexity в ноябре 2025 из-за браузера Comet, ссылаясь на федеральный Computer Fraud and Abuse Act и калифорнийский закон о доступе к компьютерным данным. Окружной суд удовлетворил предварительный запрет в марте 2026. Девятый округ приостановил его на время апелляции, а в августе 2026 снял совсем. Забрать с собой стоит именно рассуждение. По материалам, которые видела коллегия, к системам обращались собственные покупатели Amazon, авторизованные под своими учётными записями, с помощью программы, которую они сами выбрали. Сам Perplexity к Amazon не подключался. На этом основании Amazon вряд ли выиграет по закону, написанному про неправомерный доступ. Это первое федеральное апелляционное решение о том, могут ли ИИ-агенты, действующие за пользователя, обращаться к онлайн-площадке, и коллегия аккуратно оговорила, что решает конкретное дело, а не провозглашает доктрину. ## Чего суд не постановил Он не сказал, что агентам рады, и не сказал, что сайт потерял контроль над собственной входной дверью. Договорные основания слабыми признаны не были. Условия использования, товарные знаки и теории по праву штатов остались нетронутыми. Другое дело с другими фактами, особенно там, где агент работает в масштабе, а не за одного авторизованного клиента, может закончиться иначе. Полезная выжимка узкая, и её стоит проговорить без украшений: закон о компьютерных злоупотреблениях слабое оружие против программы, которую клиент сам запустил под своей учётной записью. ## Различие, на котором держится решение | | Краулер | Агент пользователя | | --- | --- | --- | | Действует ради | Своего оператора | Одного авторизованного клиента | | Масштаб | Много сайтов, большой объём | По одной сессии | | Авторизация | Обычно нет | Под клиентом | | Данные попадают | В продукт оператора | Тому, кто попросил | | Рассуждение суда | Не применимо | Применимо | Большинство блокирующих правил в живой природе этого различия не делает. Сплошной отказ автоматическому доступу ловит агента вашего же клиента вместе со скрапером, ради которого писался, а эти двое коммерчески противоположны: один посетитель с кошельком, другой статья расходов. ## Что действительно даёт контроль Три рычага, и ни один не закон. Условия использования это договорный вопрос, а договор не был тем основанием, которое здесь провалилось. Второй рычаг это идентичность: агент, подписывающий запросы, поддаётся опознанию, и обойтись с ним можно по своему решению. Для этого и существуют HTTP Message Signatures и Web Bot Auth, поддержанные в AWS WAF с ноября 2025 и в Cloudflare с начала 2026. Третий рычаг это ограничения по частоте и поведению, и только они продолжают работать независимо от того, кем посетитель себя называет. Вместе они позволяют разбирать посетителей по классам. Сплошное правило такого выбора не оставляет: оно решает за вас и вслепую. Компромиссы каждого варианта разобраны в [посте про список допущенных краулеров](/ru/blog/ai-crawler-allowlist-2026). ## Вопрос, который стоит перед оператором Нужны ли вам клиенты, приходящие через агента, это коммерческое решение, а не правовое, и отвечать на него можно своими же данными. Выясните, доходит ли до вас такой трафик. Потом проверьте, можно ли пройти ваш чекаут, бронирование или заявку программой, управляющей браузером от лица авторизованного клиента, и не зависит ли какой-то шаг от того, что человек что-то заметит на экране. Механика такой проверки разобрана в посте [что видит агент на вашем сайте](/ru/blog/browser-agent-ready-saas). Оба сценария отказа стоят денег. Молча заблокировать клиента через агента, который конвертировался бы, значит отказаться от выручки. Если он дойдёт и сломается на середине, вы получите нагрузку на поддержку и плохое впечатление, а это хуже чистого отказа. ## Рядом с другим отступлением Читать это стоит вместе с судьбой чекаута внутри чата. OpenAI свернул покупки внутри ChatGPT 4 марта 2026 и подтвердил закрытие 24 марта, после примерно пяти месяцев работы и примерно дюжины подключённых мерчантов Shopify. Знакомство с товаром переехало в ассистента, а сделка вернулась на сайт продавца. Оба события указывают в одну сторону. Покупка внутри ассистента проиграла, а собственный агент клиента, работающий с сайтом продавца, только что прошёл первую апелляционную проверку. Значит, [важнейшей поверхностью становится собственный чекаут продавца](/ru/analyze), и полностью этот довод изложен в посте [агентная коммерция после Instant Checkout](/ru/blog/agentic-commerce-after-instant-checkout). Источники: [Reuters через Yahoo Finance](https://finance.yahoo.com/technology/ai/articles/us-court-overturns-amazon-injunction-135004000.html), [Engadget](https://www.engadget.com/2230471/perplexity-has-successfully-overturned-amazon-injunction-on-its-ai-shopping-bot/), [PYMNTS о сужении CFAA](https://www.pymnts.com/news/artificial-intelligence/2026/ninth-circuit-narrows-cfaa-reach-in-perplexity-agentic-commerce-ruling/), [CNBC о мартовском запрете](https://www.cnbc.com/2026/03/10/amazon-wins-court-order-to-block-perplexitys-ai-shopping-agent.html). ## FAQ ### Значит ли это, что ИИ-агенты теперь свободно пользуются любыми сайтами? Нет, и коллегия специально постаралась исключить такое прочтение. Вывод состоит в том, что на представленных материалах Amazon вряд ли выиграет по Computer Fraud and Abuse Act, потому что доступ к системам Amazon осуществляли его собственные покупатели под своими учётными записями, а не Perplexity. Это заключение об одном законе применительно к одному набору доказательств. Суд прямо отказался формулировать общие принципы об агентном ИИ и об ответственности в других правовых контекстах, а значит договорные требования, претензии по условиям использования, товарные знаки и теории по праву штатов остаются полностью открытыми. Как правило для вашего собственного сайта это говорит гораздо меньше, чем заголовки: хвататься за закон о компьютерных злоупотреблениях против программы, которую запустил сам клиент, слабый ход, и сила позиции зависит от выбранного основания иска, а не от отношения к агентам. ### В чём практическая разница между агентом и краулером? В том, кто действует и по чьему указанию, и именно на этой петле держится всё решение. Краулер приходит на ваш сайт ради целей своего оператора, как правило в большом объёме, без авторизации и ради данных, которые будут использованы где-то ещё. Агент в смысле Comet работает на одного человека, авторизован под его учётной записью и делает то, о чём этот человек попросил и что мог бы сделать руками, только медленнее. Рассуждение о том, что к системам обращались покупатели Amazon, а не Perplexity, применимо только ко второй форме. Это важно для того, как вы пишете свои правила: сплошной запрет автоматического доступа заодно выметает агентов ваших же клиентов вместе со скраперами, против которых он задумывался, а у этих двух разное правовое положение и совсем разные коммерческие последствия. ### Что тогда реально даёт сайту контроль над агентским трафиком? Три вещи, и ни одна из них не закон о компьютерных злоупотреблениях. Условия использования это договорный вопрос, а не вопрос взлома, и договорные основания коллегия слабыми не признавала. Второе это идентичность: агент, подписывающий свои запросы, поддаётся опознанию, и его можно пропустить, придушить или отклонить по вашему выбору. Именно в эту сторону движется отрасль с HTTP Message Signatures и поддержкой Web Bot Auth в AWS WAF с ноября 2025 и в Cloudflare с начала 2026. Третье это ограничения по частоте и поведению, и они единственные работают независимо от того, кем посетитель себя называет. Вместе эти три рычага позволяют решать по каждому классу посетителей отдельно, а не одним правилом на всех, а само решение это коммерческий выбор о том, нужны ли вам клиенты, приходящие через агента. ### Стоит ли малому бизнесу что-то менять из-за этого решения? Большинству стоит сделать одну вещь, и она не юридическая. Выясните, доходит ли до вас агентский трафик и что он делает по прибытии, потому что нельзя принимать решение о канале, который вы не измеряете. Проверьте, можно ли пройти ваш чекаут, бронирование или форму заявки программой, управляющей браузером от лица авторизованного клиента, и не зависит ли какой-нибудь шаг от того, что человек что-то заметит на экране. Это продуктовый вопрос с коммерческим ответом: если клиенты через агента конвертируются, а вы их молча блокируете, вы отказываетесь от выручки; если они доходят и ломаются на середине, вы получаете нагрузку на поддержку. Правовая позиция становится важной только после того, как вы решили, чего хотите, и для большинства операторов это решение стоит дороже самого судебного акта. --- # Откуда берутся четыре недели и когда их у вас не будет URL: https://inite.ai/ru/blog/4-week-vertical-cloning-playbook Date: 2026-08-14 Author: Михаил Савченко Category: Operations Tags: Operations, Implementation, Vendor selection, Strategy ## Direct Answer Две-четыре недели держатся не на скорости разработчиков, а на том, что большая часть работы к вашему проекту не относится. Вход в систему, права доступа, роли, уведомления, счета, история переписки - всё это одинаково у любого продукта и уже отлажено на прошлых внедрениях. Заново пишется только ваша предметная область: ваши объекты и ваш процесс. Насколько это мало, видно по нашей же цифре: когда мы построили второй продукт в соседней отрасли, из 113 бизнес-понятий общими оказались 7, около 6%. Отсюда и граница срока. Чем обычнее устроена ваша предметная область, тем вернее четыре недели; чем она своеобразнее, тем меньше от чужого опыта переносится и тем длиннее срок. ## Key Facts - Из 113 бизнес-понятий в двух наших продуктах соседних отраслей общими оказались 7, около 6%. - Срок внедрения одного процесса - 2-4 недели, из них на предметную область уходит около половины. - Первая заявка в прокате обрабатывалась 4 часа, после внедрения - 8 минут. - Вход, роли, права, уведомления, счета и история переписки - это 6 подсистем, одинаковых у любого продукта, и ни одна не пишется заново. - 4 признака указывают, что срок будет больше: неописанный процесс, решения по ситуации, нечитаемые данные и требование, которого нет ни у кого. ## Почему само по себе число ничего не говорит [Вам называют две-четыре недели](/ru/answers/ai-automation-timeline). То же число вы услышите от всех остальных. Само по себе оно не значит ничего, потому что срок держится не на скорости, с которой пишут код, а на объёме работы, которую в вашем проекте делать не будут. Спрашивать имеет смысл именно про этот объём. ## Что вы не оплачиваете В любой системе, где есть сотрудники и клиенты, устроено одинаково: кто-то входит под своей учётной записью, у него есть роль, роль что-то разрешает и что-то запрещает, кому-то уходят уведомления, кому-то выставляется счёт, а вся переписка должна лежать в одном месте и находиться поиском. Это не имеет никакого отношения к тому, сдаёте вы экскаваторы или записываете на физиотерапию. Написано это один раз, отлажено на прошлых внедрениях и не занимает у вас ни одной недели. Есть одно исключение, о котором стоит знать, даже если строить будете не вы. Разделение между клиентами закладывается первым или не закладывается никогда. Достраивание его задним числом в систему, которая изначально предполагала одного заказчика, - самая дорогая переделка в этом деле, и именно она превращает четырёхнедельный проект в трёхмесячный. ## Что придётся построить в любом случае Остаётся то, ради чего вы и обращались: ваши объекты и ваш процесс. У проката это единица техники, бронь и отгрузка. У агентства недвижимости это объект, объявление и сделка. Со стороны звучит как одно и то же, а внутри общего почти нет. Мы это измерили на себе, и цифра оказалась неудобной. Сделали платформу аренды, потом платформу недвижимости. Отрасли соседние, обе про объект, который кому-то передают на время или навсегда. Из 113 бизнес-понятий общими оказались 7. Около 6%. Эта цифра здесь затем, чтобы вы понимали, за что платите. «У нас такое уже есть, останется настроить» - фраза про те самые 94%, которых у подрядчика нет, потому что они ваши. ## Когда четырёх недель не будет | Признак | Как это выглядит у вас | Куда уходит время | | --- | --- | --- | | Процесс не описан | Три сотрудника описывают его тремя способами | В недели выяснения до начала работы | | Решение принимается «по ситуации» | Правило не формулируется даже устно | В разбор случаев, которых не было на демонстрации | | Данные нечитаемы программой | Переписка, таблица у одного человека, память | В подключение или в отказ от подключения | | Требование, которого нет ни у кого | «У нас всегда было так, и менять не будем» | В разработку без опоры на чужой опыт | Ни один из этих признаков не делает автоматизацию невозможной. Каждый переносит работу из недель разработки в недели выяснения, а выяснение не наследуется: чужой прошлый проект не знает, что считается заявкой именно у вас. Если совпал хотя бы один - четыре недели остаются верной оценкой этапа разработки и неверной оценкой проекта. Разница обычно и есть предмет спора с подрядчиком через месяц. ## Что спросить, чтобы это проверить Один вопрос отделяет проверяемый срок от красивого: **что из этого вы уже написали, а что напишете заново для нас**. Ответ «мы всё строим под вас с нуля» означает месяцы, потому что вход, роли и права придётся написать ещё раз. А «у нас всё готово, останется настроить» - это шаблон, и о несовпадении вы узнаете на третьей неделе. Ответ, который стоит услышать, называет обе части отдельно и показывает границу между ними. Дальше попросите приложить эту границу к вашему процессу. Разбор занимает несколько часов и до подписания сметы стоит больше, чем любая презентация: [как читать смету на автоматизацию](/ru/blog/how-to-read-an-automation-quote) начинается ровно с этого разделения. Как это выглядит на настоящих заявках, видно в разборе проката: [куда уходят четыре часа в заявке на аренду](/ru/blog/order-processing-equipment-rental) и [что мы измерили за неделю до внедрения](/ru/blog/rental-case-the-week-before). Если окажется, что автоматизироваться вам рано, это тоже результат: [пять признаков](/ru/blog/what-size-company-should-not-automate-yet) перечисляют, когда лучше подождать. ## FAQ ### Почему все подрядчики называют примерно один срок? Потому что срок называется под один процесс, а не под систему целиком, и в этом смысле он честный у многих. Разница не в числе, а в том, что за ним стоит. У одних две-четыре недели означают, что вход в систему, роли, права, уведомления и счета уже написаны и отлажены на прошлых проектах, и всё это время уходит на вашу предметную область. У других это означает готовый шаблон, в который вас попробуют уложить, и тогда срок держится ровно до первого несовпадения с вашим процессом. У третьих это оценка сверху, сделанная до того, как кто-либо посмотрел на ваши заявки. Спрашивать надо не «сколько», а «что из этого вы уже написали и что напишете заново для нас». ### Что значит «предметная область» и почему она не переносится? Это ваши объекты и ваш процесс: то, чем вы торгуете или что обслуживаете, и то, что с этим происходит от обращения до закрытия. У проката это единица техники, бронь и отгрузка. У агентства недвижимости это объект, объявление и сделка. Слова похожи, а правила внутри разные, и именно правила стоят времени. Мы это измерили на себе: сделали платформу аренды, потом платформу недвижимости, отрасли соседние - а из 113 бизнес-понятий общими оказались 7. Около 6%. Поэтому подрядчик, который говорит «у нас это уже есть, останется настроить», описывает не ваш проект. ### На что уходят четыре недели, если основа готова? Примерно половина - на предметную область: описать ваши объекты, ваш процесс и правила перехода между этапами так, чтобы система принимала те же решения, что и ваш сотрудник, и отказывалась принимать те, которые ему не разрешены. Ещё часть - на подключение к тому, что у вас уже стоит: почта, склад, учёт, календарь, телефония. Автоматика без доступа к вашим системам умеет только пересказывать то, что и так опубликовано. Остаток - на разбор краевых случаев, которые всплывают на реальных заявках, а не на демонстрации. Первая неделя при этом почти всегда уходит не на код, а на то, чтобы договориться, что считать заявкой и когда она закрыта. ### Как понять, что мой случай в четыре недели не уложится? Четыре признака, и любого одного достаточно, чтобы закладывать больше. Первый: ваш процесс нигде не описан и у трёх сотрудников три разные версии того, как он идёт. Второй: решение о следующем шаге принимает человек по совокупности обстоятельств, и правило не формулируется даже устно. Третий: данные лежат в местах, откуда их нельзя прочитать программой, - в переписке, в голове, в чужом кабинете. Четвёртый: у вас есть требование, которого нет ни у кого в отрасли, и оно не обсуждается. Ни один из них не делает автоматизацию невозможной, но каждый переносит работу из недель разработки в недели выяснения, а выяснение нельзя унаследовать от прошлого проекта. --- # Агентство или фрилансер под внедрение ИИ-автоматизации URL: https://inite.ai/ru/blog/ai-automation-agency-vs-freelancer Date: 2026-08-13 Author: Anton Fenix Category: Comparison Tags: Comparison, Operations, Procurement, Automation ## Direct Answer Для одного понятного процесса с назначенным владельцем внутри компании фрилансер обычно правильный выбор и часто заметно более дешёвый. Агентство отрабатывает свою наценку на трёх вещах: работа задевает несколько систем и потому несколько навыков, поставка обязана пережить недоступность одного человека, и есть обязательство продолжать после передачи. Сравнивают первым делом дневную ставку, а она в этом сравнении решает меньше всего. Исход определяет то, кто отвечает на четвёртый месяц, когда интеграция сменила формат, а построивший её человек уже занят другим. ## Key Facts - Внедрение одного процесса это форма работы, где фрилансер конкурирует сильнее всего, и примерно так выглядит 1 из тех 1-3 процессов, что мы выводим в прод за проект. - Наше окно поставки составляет 2-4 недели на проект, и этого достаточно мало, чтобы риск непрерывности собирался после сдачи, а не во время стройки. - Окупаемость таких работ обычно наступает через 3-6 месяцев, то есть после того момента, когда договор с фрилансером как правило уже закончился. - Перед сборкой считается письменная оценка ROI на консервативных вводных; если она не выходит в плюс, работа заканчивается на диагностике. ## Дневная ставка это неправильное первое сравнение Обычно такое решение начинается с двух чисел рядом, одно заметно меньше другого, и заканчивается разговором о том, оправдано ли большее. Дневная ставка решает в этом сравнении меньше всего. Построить процесс, как правило, могут обе стороны. Различает их то, что эта штука делает на четвёртый месяц, когда поставщик сменил форму, канал сменил интерфейс, а объём удвоился, и допущение, работавшее на пятидесяти заказах в день, перестало работать на ста. ## Где фрилансер выигрывает прямо Один процесс. Систем мало, все описаны. Внутри компании есть человек, который примет результат и сможет его менять. При этих трёх условиях вы покупаете стройку, а не отношения. Задание записывается полностью до начала, координация, которую несёт агентство, не делает никакой работы, а разница в цене велика и реальна. Хороший фрилансер часто окажется ещё и быстрее, потому что в команде из одного нет внутренних передач. Такая форма встречается чаще, чем подрядчикам приятно признавать. Если ваша автоматизация это один понятный процесс, честный совет звучит так: соберите предложения от частных исполнителей. ## Где наценка действительно отрабатывается | Что нужно | Фрилансер | Агентство | | --- | --- | --- | | Один процесс, системы описаны | Отличное попадание | Избыточная квалификация | | Четыре системы, четыре навыка | Зависит от человека | Попадание по устройству | | Фиксированная дата под сезон | Единственная точка отказа | Поглощает отсутствие | | Ответственный на четвёртый месяц | Личное обещание | Договорное обязательство | | Готовность сказать «не надо строить» | По-разному | По-разному | Последняя строка намеренно оставлена без разрешения, потому что размер компании о ней не говорит ничего. Агентство, чья диагностика всегда приходит к необходимости собственного продукта, хуже фрилансера, который говорит правду, и обратное встречается ровно так же часто. Непрерывность это та строка, которую недооценивают, а потом жалеют. Стройка занимает 2-4 недели, система живёт годами. Вопрос не в том, кто её напишет, а в том, кто возьмёт трубку, когда она перестанет работать. ## Сравнение по деньгам, которое действительно полезно Стоимость стройки в пользу фрилансера, обычно с большим отрывом. Двенадцать месяцев владения гораздо ближе. Любая автоматизация несёт расходы на эксплуатацию независимо от автора. Модель и инфраструктура на каждое решение. Время того, кто разбирает эскалированные исключения, и это заложенная в конструкцию статья расходов, а не дефект. И обслуживание, когда мир вокруг процесса сдвигается, а он сдвигается. Попросите у обеих сторон месячную цифру письменно, прибавьте двенадцать таких к цене стройки и сравнивайте эти суммы. Одна эта замена делает большинство решений очевидными в ту или иную сторону, а [четыре вопроса, ломающие большинство расчётов окупаемости](/ru/blog/roi-math-for-automation-projects), одинаково применимы к обоим предложениям. ## Схема, которую стоит рассмотреть Разделите работу. Замер и проектирование отдайте тому, кому доверяете сказать, что проект делать не стоит. Стройку отдайте тому, кто дешевле на такой форме работы. У половин разные сценарии отказа. Плохая стройка дёшева и заметна за несколько дней. Плохое проектирование дорого и невидимо месяцами. Разделение к тому же даёт техническое задание, которое можно отдать на оценку нескольким исполнителям, а это единственный способ сделать сравнение цен осмысленным. Избегать стоит обратной схемы: нанять исполнителя, а потом спросить его, что строить. Тогда решение об объёме оказывается у стороны, чей доход растёт вместе с объёмом. Это ровно та же структурная проблема, что разобрана в посте [что обязан выдать аудит процессов](/ru/blog/process-audit-before-automation). ## Чего не следует спускать ни тем, ни другим Двух вещей, и они одинаково относятся к частным исполнителям и к фирмам. Никто не должен называть цену до замера. Цена, полученная из разговора, это догадка о процессе, который никто не посчитал, а [неделя замеров](/ru/blog/rental-case-the-week-before), предшествующая честной оценке, стоит достаточно дёшево, чтобы её пропуск был выбором, а не вынужденностью. И никто не должен оставлять неявным вопрос о том, что остаётся человеку. Всё обязывающее, всё необычное и всё, в чём система не уверена, принадлежит человеку, и эта граница должна стоять в предложении, а не обнаруживаться потом. Как мы сами устроены по этим критериям, изложено на [странице сравнения](/ru/compare). ## FAQ ### Когда фрилансер явно лучше? Когда процесс один, систем мало и они описаны, а внутри компании есть человек, который примет результат на себя и технически способен его менять. При этих условиях вы покупаете стройку, а не отношения: техническое задание можно записать полностью до начала работ, вся координация, которую несёт агентство, здесь ничего не делает, а разница в цене велика и реальна. Хороший фрилансер обойдёт агентство по стоимости и часто по срокам именно на такой форме работы, потому что в команде из одного человека нет внутренних передач. Следить стоит за одним сценарием отказа: если процесс вдруг оказывается завязан на четыре системы, о которых никто не упомянул, соло-проект встаёт там, где команда бы это поглотила. Это довод за неделю замеров до подписания договора, а не за наём подрядчика покрупнее по умолчанию. ### За что именно берётся наценка агентства? За три вещи, и стоит проверить, нужна ли вам каждая, прежде чем платить за все три сразу. Первое это широта: процесс, который проходит через CRM, бухгалтерию, мессенджер и хранилище документов, требует нескольких видов знания, и один человек, одинаково сильный во всех четырёх, встречается реже и стоит дороже, чем команда, где эти знания лежат по отдельности. Второе это непрерывность: агентство может потерять человека посреди стройки и не потерять стройку, и это тем важнее, чем сильнее срок привязан к сезону или дате. Третье это обязательство, и его чаще всего недооценивают: кто-то по договору всё ещё здесь на четвёртый месяц, когда поставщик сменил форму, а канал сменил интерфейс. Фрилансер может предложить все три, и некоторые предлагают, но это личное обещание, а не устройство, а личные обещания заканчиваются вместе с обстоятельствами. ### Как эти варианты соотносятся по деньгам с учётом эксплуатации? Стоимость стройки обычно явно в пользу фрилансера, а совокупная стоимость первого года гораздо ближе, чем подсказывают дневные ставки. Автоматизация несёт расходы на эксплуатацию независимо от того, кто её построил: модель и инфраструктура на каждое решение, время человека, разбирающего эскалированные исключения, и обслуживание, когда окружающие системы сдвигаются. Эти расходы есть в обоих случаях, различие в том, кто берёт на себя обслуживание и с каким сроком реакции. Фрилансер обычно оценивает обслуживание как новую работу по новой ставке и при наличии свободного времени, что нормально, пока система стабильна, и дорого, когда нет. Сравнивайте по двенадцати месяцам владения, а не по стройке, и просите у обеих сторон месячную цифру эксплуатации письменно до подписания. ### Можно ли комбинировать? Да, и это разумная схема, которой пользуются реже, чем стоило бы. Замер и проектирование отдайте тому, кому доверяете сказать, что проект делать не стоит, а стройку тому, кто дешевле на такой форме работы. У половин разные сценарии отказа: плохая стройка дёшева и заметна за несколько дней, а плохое проектирование дорого и невидимо месяцами. Разделение к тому же даёт вам предмет для сравнения, потому что нормально записанный проект можно отдать на оценку нескольким исполнителям. Единственная схема, которой стоит избегать, обратная: сначала нанять исполнителя, а потом спросить его, что строить. Так решение об объёме работ оказывается у стороны, чей доход растёт вместе с этим объёмом. --- # Неделя до: что мы измерили в прокатной компании URL: https://inite.ai/ru/blog/rental-case-the-week-before Date: 2026-08-12 Author: Михаил Савченко Category: Case Study Tags: Case Study, Operations, Equipment Rental, Process Audit ## Direct Answer Прежде чем что-то автоматизировать в компании по аренде оборудования, мы неделю считали, и эти замеры изменили проект. Среднее время от брони до отгрузки оказалось самым бесполезным из собранных чисел: среднее прятало хвост, а в хвосте жили отказы. Решение о составе работ приняли по трём другим счётчикам: сколько заявок пришло вне рабочих часов, на сколько не ответили вообще и как часто стоящая на площадке машина числилась недоступной. Последовавшая перестройка заняла 3 недели и увела путь от брони до отгрузки с 4 часов до 3 минут. ## Key Facts - Перестройка после недели замеров заняла 3 недели и увела путь от брони до отгрузки с 4 часов до 3 минут. - Ёмкость пикового сезона после этого выросла в 2,5 раза без пополнения команды. - Из 4 показателей, на которых предполагалось строить расчёт, 2 оказались незначимы. - Мы выводим 1-3 процесса в продакшен за 2-4 недели, и этот проект пришёлся на короткий край диапазона. - Перед сборкой считается письменная оценка ROI на консервативных вводных; если она не выходит в плюс, работа заканчивается на диагностике. ## Своих чисел не знает никто Прокатная компания, с которой мы работали, описывала проблему точно. Брони обрабатывали руками, доступность жила в таблицах, договоры собирали по одному, водителей организовывали по телефону. Пиковый сезон означал потерянные брони и овербукинг. Всё в этом описании было правдой. И ничто из него не было измерением. Поэтому первая неделя проекта не произвела ни строчки кода. Она произвела подсчёт, сделанный по системам, которые у бизнеса уже были, о том, насколько велика каждая часть проблемы на самом деле. Из-за этой недели внедрение заняло три недели, а не шесть, потому что из состава работ ушли две вещи, которые все считали центральными. ## Что выгрузили Две отметки времени по каждой брони за полный пиковый месяц: когда пришла заявка и когда подтвердили отгрузку. Дальше ещё три счётчика, и это уже не отметки времени. - Заявки, пришедшие вне рабочих часов - Заявки, на которые не ответили вообще - Случаи, когда физически стоящая на площадке машина числилась недоступной Ничего из этого не потребовало новых средств измерения. Потребовался человек, который выгрузит уже записанное и посчитает не отводя глаз. ## Самым бесполезным числом было среднее Путь от брони до отгрузки в среднем занимал около четырёх часов, и именно это число попало во все последующие описания проекта, включая наши. Оно же меньше всего пригодилось при определении состава работ. | На что смотрели | Что это сказало | | --- | --- | | Среднее время до отгрузки | Проблема существует | | Распределение этого времени | Где лежат деньги | | Доля пришедших вне часов | Почему хвост длинный | | Заявки без ответа | Что терялось молча | | На площадке, но недоступна | Виновата ли модель данных | Большая часть броней двигалась с приемлемой скоростью. Меньшая ждала намного дольше, чем подсказывало среднее, и именно в этом меньшинстве клиенты переставали ждать и звонили конкуренту. Улучшение среднего хорошо читалось бы в отчёте и коммерчески не изменило бы ничего, потому что ушедшие клиенты никогда не были в середине распределения. Это обобщается далеко за пределы проката. Среднее чаще прочих чисел доживает до коммерческого предложения и реже прочих указывает на настоящее ограничение. ## Две вещи, которые ожидались важными и выпали Первой был недельный объём броней. Годовая цифра сглаживала сезон, зарабатывающий большую часть года за несколько недель, и определение состава работ по годовому числу дало бы систему, рассчитанную на нагрузку, которой она не видит в тот момент, когда это важно. Второй была подготовка договоров. Она была реальной, была муторной и не была ограничением. Сборка документов действительно медленная работа, и её автоматизация экономит ровно те минуты, которые она занимает, а это малая доля четырёх часов. Она осталась в составе работ, потому что стоит дёшево, когда остальное уже есть. Она перестала быть причиной делать проект. Вывод обеих с критического пути и есть основная причина, по которой проект уложился в 3 недели. ## Число, определившее форму Проектное решение изменил счётчик машин, которые стоят на площадке и числятся недоступными. Будь он около нуля, честным выводом было бы, что сотрудники перегружены, а лечение это люди или маршрутизация. Около нуля он не был. Данные о доступности сами по себе врали достаточно часто, чтобы объяснить и двойные брони, и часть отказов, а это указывает на модель, а не на людей. Отсюда и форма внедрения: в основном работа с моделью данных и языковая модель у входной двери, а не наоборот. Разделение и разделение между правилами и моделью подробно разобрано в посте [куда уходят четыре часа](/ru/blog/order-processing-equipment-rental). ## Что было дальше Перестройка заняла 3 недели. Путь от брони до отгрузки сократился с 4 часов до 3 минут, двойные брони исчезли совсем, а ёмкость пикового сезона выросла в 2,5 раза той же командой. Полный набор цифр на [странице кейса](/ru/cases/equipment-rental-automation). Именно ёмкость окупает проект, и она напрямую выводится из недели замеров. Отказы в бронях поддавались подсчёту до того, как что-либо построили, поэтому расчёт не зависел от веры в прогноз. ## Если хотите провести эту неделю сами Мы для этого не нужны, и есть разумный довод в пользу того, чтобы сделать это до разговора с любым подрядчиком. Выгрузите две отметки времени, посчитайте три вещи и смотрите на распределение, а не на среднее. Замер это первая стадия [аудита, который мы проводим до согласия что-либо строить](/ru/blog/process-audit-before-automation), а полученные числа делают [четыре вопроса, ломающие большинство расчётов окупаемости](/ru/blog/roi-math-for-automation-projects), отвечаемыми, а не риторическими. Если хвост тонкий и никому не отказывали, ответ такой: за этот проект браться не стоит. Мы предпочтём сказать это на первой неделе, а не на третьем месяце. ## FAQ ### Зачем неделя замеров, если можно спросить команду? Потому что люди точны в том, каково выполнять задачу, и ненадёжны в том, как часто она случается и сколько ждёт. Спросите координатора, сколько занимает бронь, и получите длительность его собственной части, которая действительно короткая, плюс впечатление об ожидании, которое действительно долгое и которое никто не фиксирует. Нечестных ответов среди них нет, и ни один не годится для расчёта. Отметки времени из систем отличаются качественно: они показывают распределение, а не впечатление, покрывают ночи и выходные, которых никто не помнит, и включают заявки, на которые вообще не ответили, а их по определению вспомнить невозможно. Неделя при этом достаточно коротка, чтобы быть недорогой, и достаточно длинна, чтобы поймать форму. Мы предпочтём потратить неделю на выяснение, что проект делать не стоит, чем три недели на постройку того, что не было ограничением. ### Что именно выгружали, если по-практически? Две отметки времени по каждой брони за полный пиковый месяц, из тех систем, где они уже лежали: когда пришла заявка и когда подтвердили отгрузку. Дальше ещё три счётчика, и это уже не отметки времени. Сколько заявок пришло вне рабочих часов, потому что именно они лежат до утра и незаметны в любом среднем, которое мешает их с остальными. Сколько заявок не получили ответа никогда, и это то число, на которое никто не хочет смотреть и в котором вероятнее всего лежит выручка. И сколько раз машина, физически стоящая на площадке, числилась недоступной, потому что это сигнал, что проблема в модели доступности, а не в людях. Ничего из этого не требует новых средств измерения. Требуется человек, который выгрузит уже записанное и честно посчитает. ### Какие показатели оказались незначимыми? Среднее время от брони до отгрузки и количество броней в неделю. Оба считались опорой будущего расчёта, и оба сами по себе почти бесполезны. Среднее прятало распределение: большая часть броней двигалась приемлемо быстро, а меньшая ждала очень долго, и именно в этом меньшинстве клиенты сдавались и уходили к другим. Улучшение среднего хорошо смотрелось бы в отчёте и коммерчески не изменило бы ничего. Объём вводил в заблуждение похожим образом, потому что годовая цифра сглаживала сезон, который зарабатывает большую часть года за несколько недель. Состав работ определили форма хвоста в пик и число заявок без ответа. Это не особенность проката: среднее чаще прочих чисел доживает до коммерческого предложения и реже прочих указывает на настоящее ограничение. ### А если замеры скажут, что проект делать не стоит? Тогда мы так и говорим и не строим, и эта возможность обязана быть настоящей, иначе замеры не значат ничего. Правило, по которому мы работаем, звучит так: если аудит не показывает отдачи, стройки нет. Оно существует потому, что альтернатива это подрядчик, чья диагностика всегда приходит к выводу о необходимости его собственного продукта. Конкретно для проката расчёт рассыпается, когда хвост пикового месяца тонкий и никому не отказывали. В такой ситуации четыре часа между бронью и отгрузкой это раздражение, а не издержка, сэкономленные часы не превратятся в ёмкость, которую кто-то продаст, и честная рекомендация звучит как «потратьте деньги на другое». Отказ от такого проекта стоит нам контракта и сохраняет диагностике доверие, а только из-за этого доверия нам вообще дают измерять чужую операционку. --- # Куда уходят четыре часа в заявке на аренду URL: https://inite.ai/ru/blog/order-processing-equipment-rental Date: 2026-08-11 Author: Михаил Савченко Category: Automation Tags: Automation, Operations, Equipment Rental, Order Processing ## Direct Answer Обработка заказов в аренде оборудования медленная потому, что работы там мало, а ожидания много. Заявка стоит между тем, как координатор открыл таблицу, кто-то подтвердил, что машина действительно вернулась, договор собрали, подпись выпросили, а водителю дозвонились. Каждый шаг занимает минуты, промежутки между ними занимают часы. Автоматизация шагов экономит минуты, а закрытие передач между людьми и есть то, что увело одну прокатную компанию с четырёх часов до трёх минут. Основную часть починки сделали детерминированные правила, а не языковая модель: проверка доступности обязана отвечать одинаково каждый раз. ## Key Facts - В одной компании по аренде оборудования путь от брони до отгрузки сократился с 4 часов до 3 минут, а овербукинг прекратился полностью. - Та же компания приняла в 2,5 раза больше объёма в пиковый сезон тем же составом сотрудников. - Внедрение заняло 3 недели, что укладывается в обычные 2-4 недели на 1-3 процесса в продакшене. - Из 7 состояний единицы техники в таблице ниже 4 оставляют машину физически на площадке и всё равно недоступной для аренды. - Первая поставка - 1-3 процесса в продакшене за 2-4 недели, переданные команде клиента с документацией и мониторингом. ## Четыре часа никогда не были одной задачей Спросите координатора проката, сколько времени проходит от заявки до выехавшей машины, и услышите пожатие плечами и число. Часа четыре, обычно. В июле дольше. Разложите эти четыре часа, и работой окажется почти ничего. Заявка приходит, в одно из четырёх или пяти мест. Кто-то открывает таблицу доступности. Кто-то другой должен подтвердить, что машина, которую ждали вчера, действительно вернулась. Договор собирают из последнего похожего. Подпись выпрашивают. Водителю звонят, а водитель на выезде. Каждый шаг забирает несколько минут чьего-то внимания. Четыре часа это промежутки между ними, ожидание, когда освободится следующий человек. От этого различия зависит, сколько стоит проект автоматизации. Автоматизация шагов экономит минуты, а минуты никогда и не были проблемой. Разрыв закрывает автоматизация передач, и именно она увела одну компанию с четырёх часов до трёх минут. ## Двойная бронь это проблема одновременного доступа Овербукинг принято считать невнимательностью, поэтому обычное лекарство от него это просьба быть внимательнее. Оно не работает, и понять почему стоит до того, как что-то покупать. У общей таблицы нет блокировок. Два координатора открывают её в 10:02. Оба видят трёхтонный экскаватор свободным в четверг. Оба его обещают, один по телефону, другой письмом. Каждый был прав в тот момент, когда смотрел, и ни у кого не было способа узнать, что второй уже на середине обещания. Ошибку создал инструмент, а не люди. Чтобы её убрать, нужны две вещи: одна запись, которая и есть единственный источник правды о забронированном, и проверка, выполняемая в момент подтверждения, а не только в момент заявки. Конфликты живут в окне между «посмотрел» и «пообещал». ## Доступность это не поле «да или нет» Вторая причина, по которой брони сталкиваются, в том, что большинство систем хранит доступность одним флагом, а состояний у единицы техники больше. | Состояние в четверг утром | На площадке | Можно сдать в четверг | | --- | --- | --- | | В аренде, возврат в среду | Нет | Да, если возврат состоится | | В аренде, работа затягивается | Нет | Нет | | В пути обратно с объекта | Нет | Зависит от расстояния | | Вернулась, ждёт осмотра | Да | Нет | | На обслуживании | Да | Нет | | Забронирована, не подтверждена | Да | Нет | | На месте и свободна | Да | Да | Четыре строки из семи описывают машину, которая стоит на площадке и выехать не может. Проверка, которая спрашивает только про действующий договор аренды, отвечает «свободна» во всех четырёх случаях. Отсюда и берётся основная масса двойных броней, и отсюда же понятно, почему починка это в основном работа с моделью данных, а не с ИИ. Вопрос о доступности нужно задавать по всем состояниям, в которых может быть единица, включая те, где её видно из окна офиса. ## Основную часть починки сделала не языковая модель Коммерчески самое интересное в этом проекте то, как мало в нём ИИ в том смысле, в каком это слово обычно продают. | Шаг | Чем делается | Почему | | --- | --- | --- | | Проверка доступности и конфликтов | Правила | Обязана отвечать одинаково всегда и быть проверяемой | | Цена по прайс-листу | Правила | Цена это обязательство, а не догадка | | Договор и подтверждения | Шаблоны | Утверждённая формулировка обязана остаться утверждённой | | Порядок отгрузки и уведомления | Правила | Детерминированная последовательность без суждений | | Чтение заявки свободным текстом | Модель | Неструктурированный вход, который иначе перепечатывает человек | | Классификация необычного запроса | Модель, затем человек | Суждение, поэтому маршрутизирует, а не решает | Детерминированные шаги делаются правилами именно потому, что обязаны вести себя одинаково каждый раз. Вероятностная проверка доступности это дефект под модным названием. Модель зарабатывает своё место у входной двери, где заявка приходит в одиннадцать вечера сообщением, называет машину словами клиента, а даты записаны в форме, которой не ждёт ни одно поле. Превратить это в структурированный запрос трудно для правила и легко для модели. Чёткая граница ещё и позволяет объяснить систему потом, потому что всегда видно, какая половина выдала ответ. ## Что остаётся человеку Четыре вещи по замыслу уходят человеку, и рассуждение по каждой из них изложено в [наших правилах о человеке в контуре](/ru/blog/safe-ai-framework-human-in-loop). Всё обязывающее решает человек: скидка вне прайс-листа, условия, отличные от стандартного договора, любое обещание, которое свяжет компанию. Исключения приходят с полным контекстом, а не голым уведомлением, потому что уведомление без контекста просто перекладывает работу. Документы собираются из утверждённых шаблонов, а не сочиняются. И каждое автоматическое решение логируется, поэтому у вопроса, почему система поступила так в конкретный четверг, есть ответ. Отдельно стоит назвать бронь, которая не оставляет запаса до следующей работы: она выглядит автоматизируемой, но не автоматизируется. Приемлем ли двухчасовой оборот, зависит от клиента, от объекта и от того, как прошла прошлая работа с ним. ## Сколько это стоило Цифры внедрения полностью: обработка брони сократилась с 4 часов до 3 минут, двойные брони исчезли совсем, сотрудники освободились для работы с клиентами вместо календаря, а ёмкость пикового сезона выросла в 2,5 раза. Сделано за 3 недели. Подробности на [странице кейса по аренде оборудования](/ru/cases/equipment-rental-automation). Коммерчески интересна именно ёмкость, и стоит точно сказать, откуда она берётся. Сами часы деньгами не стали. Деньгами они стали потому, что раньше пиковым заявкам отказывали из-за нехватки оборота, и отказы превратились в принятые заказы. Это первый из двух путей, которыми сэкономленные часы доходят до бухгалтерии, и [четыре вопроса, которые ломают большинство расчётов окупаемости](/ru/blog/roi-math-for-automation-projects), стоит задать любой цифре такого вида, включая нашу. ## С чего начать Измерьте разрыв до того, как оценивать починку, и измеряйте его по системе, а не по опросу сотрудников. Выгрузите две отметки времени по каждой брони за полный пиковый месяц: когда пришла заявка и когда подтвердили отгрузку. Смотрите на распределение, а не на среднее, потому что среднее прячет хвост, а в хвосте живут отказы. Потом посчитайте, сколько заявок пришло вне рабочих часов и на сколько вообще не ответили. Это измерение и есть первая стадия [аудита, который мы проводим до согласия что-либо строить](/ru/blog/process-audit-before-automation), и оно же говорит, реален ли расчёт. Если хвост пикового месяца тонкий и никому не отказывали, честный ответ такой: четыре часа это раздражение, а не издержка, и деньги лучше потратить в другом месте. Что именно закрывается в прокатной компании, описано на странице [ИИ-автоматизация для аренды оборудования](/ru/industries/equipment-rental) и в [процессе обработки заказов](/ru/automation/order-processing). ## FAQ ### Как на самом деле предотвращается овербукинг? Проверка доступности переносится из памяти сотрудника в правило, а момент проверки переносится с того мгновения, когда человек посмотрел, на то, когда он подтвердил. У общей таблицы нет блокировок, поэтому два координатора открывают её в одну и ту же минуту, оба видят свободный в четверг экскаватор и оба его обещают. Никто из них не был невнимателен: каждый был прав в тот момент, когда смотрел, а таблица не имела способа сообщить одному, что другой уже на середине обещания. У починки две половины, и нужны обе. Одна запись становится единственным источником правды о том, что забронировано, и второй копии, способной с ней разойтись, просто не остаётся. И проверка выполняется заново в момент подтверждения брони, а не только когда отвечали на заявку: именно в этом окне и жили конфликты. Эта часть системы сознательно не языковая модель. Она обязана возвращать один и тот же ответ на один и тот же вопрос каждый раз, и для этого существуют правила. ### Нам придётся менять учётную систему? Нет, и в большинстве прокатных компаний это был бы дорогой способ решить дешёвую проблему. Почти у каждого оператора крупнее пары десятков единиц уже есть что-то для договоров и учёта склада. Часы теряются редко внутри этой системы, они теряются в ручной эстафете вокруг неё: между системой, общим ящиком, телефоном и тем, кто в этот момент оказался на площадке. Поэтому автоматизация обычно ложится поверх того, что есть, и интегрируется с ним, а работа приходится на стыки, а не на миграцию. Это важно и коммерчески: проект замены измеряется месяцами и несёт риск потерять историю, а закрытие эстафеты измеряется неделями и оставляет учёт там, где он уже ведётся. Мы выводим 1-3 процесса в продакшен за 2-4 недели именно потому, что объём работ остаётся на стыках. ### Что должно быть правилом, а что моделью? Граница проходит по тому, разрешено ли шагу проявлять суждение. Доступность, обнаружение конфликтов, цена по прайс-листу, сборка документов из утверждённых шаблонов и последовательность шагов отгрузки полностью детерминированы. Они обязаны вести себя одинаково на одинаковых входных данных, их нужно уметь проверить постфактум, и вероятностный ответ здесь дефект, а не достоинство. Это правила. Языковая модель зарабатывает своё место там, где вход неструктурирован и человеку иначе пришлось бы читать и перепечатывать: заявка приходит свободным текстом в мессенджер в одиннадцать вечера, машина названа словами клиента, даты записаны в форме, которой не ждёт ни одно поле. Превратить это в структурированный запрос по-настоящему трудно для правила и по-настоящему легко для модели. Чёткая граница нужна ещё и затем, чтобы систему можно было объяснить, когда что-то пойдёт не так: всегда понятно, какая половина выдала ответ. ### У нас сезонный бизнес. Стоит ли трёхнедельное внедрение? Сезонность это довод за, а не против. В пиковый сезон прокатная компания зарабатывает большую часть года, и именно ручная отгрузка обычно ограничивает, сколько этого пика можно принять. Когда очередь растёт быстрее, чем координаторы её разбирают, ограничением перестаёт быть парк техники и становится эстафета, поэтому заявки получают отказ, пока машины стоят свободными. Из этой ситуации и вышла цифра в 2,5 раза: компания уже отказывала в пиковых заявках, и закрытие разрыва между бронью и отгрузкой превратило отказы в принятые заказы. Внедрение занимает 2-4 недели, поэтому проект, начатый в межсезонье, работает до открытия сезона. Не окупается как раз тот вариант, где начинают в разгар: люди, которые должны отвечать на вопросы во время внедрения, это ровно те люди, которых пик уже съедает. ### Что по-прежнему остаётся человеку? Всё обязывающее, всё необычное и всё, в чём система не уверена. Скидка вне прайс-листа, условия, отличные от стандартного договора, клиент с открытым спором по повреждениям и бронь, которая не оставляет запаса до следующей работы, уходят человеку, причём с полным контекстом, а не голым уведомлением. Так спроектировано намеренно, и это не недоработка, за которую мы извиняемся: автоматика, которая молча обязывает компанию к цене или условиям, это риск, и одно неудачное обязательство стоит дороже, чем все сэкономленные на нём часы. Документы собираются из утверждённых шаблонов, а не сочиняются, поэтому формулировка, которую согласовал юрист, и уходит клиенту. Каждое автоматическое решение логируется и проверяемо, а это единственный способ ответить на вопрос, который рано или поздно задают всегда: почему система поступила именно так в конкретный четверг. --- # Оплату в чате отменили. Покупателя из чата - нет. URL: https://inite.ai/ru/blog/agentic-commerce-after-instant-checkout Date: 2026-08-10 Author: Михаил Савченко Category: Strategy Tags: агентская коммерция, стратегия, операции, электронная торговля ## Direct Answer Оплата внутри чата ChatGPT прожила около пяти месяцев. Она запустилась 29 сентября 2025 года с Etsy, добавила горстку брендов на Shopify и была свёрнута 4 марта 2026 года, а 24 марта OpenAI это подтвердил. Убили её три совершенно обычные операционные проблемы: налог с продаж, борьба с мошенничеством и точность остатков в реальном времени по множеству продавцов. Уцелело то, что важно владельцу магазина. Agentic Commerce Protocol по-прежнему опубликован под Apache 2.0, ассистенты по-прежнему приводят покупателей к продавцам, а покупка теперь завершается на вашем собственном сайте. Работа вернулась туда, где и была: к вашим карточкам товара, точности остатков и вашей оплате. ## Key Facts - Оплата внутри чата продержалась около 5 месяцев: запуск 29 сентября 2025 года, откат 4 марта 2026 года, подтверждение закрытия 24 марта 2026 года. - До живого запуска оплаты в чате добрались примерно 12 продавцов на Shopify. - Комиссия OpenAI в 4%, объявленная с конца января 2026 года, вместе с эквайрингом давала суммарно около 9,2%. - Историю закрыли 3 операционных провала: сбор налога с продаж, борьба с мошенничеством и синхронизация остатков в реальном времени. - Agentic Commerce Protocol опубликован под лицензией Apache 2.0 29 сентября 2025 года и по-прежнему поддерживается OpenAI и Stripe. ## Что произошло на самом деле Большую часть 2026 года онлайн-продавцам объясняли, что покупка вот-вот переедет внутрь окна чата и к этому надо готовиться. Эта версия будущего проработала около пяти месяцев и закончилась. | Дата | Что случилось | | --- | --- | | 29 сен 2025 | Запуск оплаты в чате с Etsy, Agentic Commerce Protocol опубликован под Apache 2.0 | | Конец янв 2026 | Вступает в силу комиссия 4%, около 9,2% вместе с эквайрингом | | 4 мар 2026 | OpenAI отказывается вести оплату внутри ChatGPT | | 24 мар 2026 | Откат подтверждён в обновлённом анонсе по шопингу | До живого запуска добрались примерно 12 продавцов на Shopify. Протокол остался, покупательское поведение осталось, а шаг оплаты вернулся на сайт продавца. Если этой весной вам говорили готовиться к оплате в чате, вот почему разговор затих. ## Почему сломалось Причины стоит прочитать внимательно: по ним же операционный софт вообще оказывается тяжелее своего демо. **Налог с продаж.** Считается по юрисдикции и по категории товара, а обязанность несёт тот, кто принял платёж. Делать это корректно за тысячи продавцов сразу действительно трудно, а ошибка обходится дорого и вылезает месяцами позже. **Мошенничество.** Сигналы, по которым ловится плохой заказ, живут у продавца: история заказов, паттерны адресов, понимание того, что для этого каталога нормально. У посредника, стоящего перед множеством магазинов, такого контекста меньше, а возвратные платежи есть всё равно. **Правда об остатках.** Покупке нужны верные остатки в момент покупки, а не на момент последней синхронизации. Продать то, чего нет, хуже, чем не продать, и живая синхронизация наличия по множеству каталогов в масштабе - это ровно та скучная обвязка, которая решает, работает система или нет. Приговора ИИ-шопингу здесь нет. Это напоминание, что [скучная механика вокруг процесса обычно и держит конструкцию](/ru/blog/business-process-automation). ## Что уцелело Три вещи, и они как раз те, что важны владельцу магазина. Протокол на месте. ACP по-прежнему опубликован под Apache 2.0 и поддерживается OpenAI и Stripe, а значит интеграция, которую вы можете построить, делается против открытой спецификации, а не против продуктового решения одной компании. Покупатель на месте. Люди спрашивают ассистента, что купить, сравнивают варианты в разговоре и приходят на сайт продавца с почти готовым решением. От того, где вводились данные карты, это никогда не зависело. И работа по-прежнему ваша. Выбор происходит у ассистента, оплата на вашем сайте. То есть ответственность приземлилась ровно туда, где была до того, как её пообещали забрать. ## Чего это требует от вас Ассистент никогда не видит вашего дизайна. [Он читает ваши факты](/ru/analyze), и всё, чего он не может уверенно утверждать, он молча выбрасывает из сравнения. Работа получается конкретная: - **Факты в машиночитаемом виде.** Цена, наличие, варианты, размеры, материалы, срок доставки, условия возврата. На странице, в структурированных данных, а не только в вёрстке и уж точно не только на сфотографированном листе спецификации. - **Наличие, которое правдиво прямо сейчас.** Рекомендация, приводящая на страницу «нет в наличии», стоит и этой продажи, и следующего сравнения. - **Скучные предпокупочные ответы обычным текстом.** Размеры, совместимость, комплектация, порядок возврата. Ассистенты читают страницы, а не виджеты чата и не PDF. - **Одна каноническая страница на товар.** Если четыре адреса описывают одно и то же, ассистент выберет один, и, возможно, не тот, который выбрали бы вы. Это та же дисциплина, которая делает сайт читаемым для [любого автоматического посетителя вместо человека](/ru/blog/browser-agent-ready-saas), и ничего из неё не пропадёт, если шаг оплаты снова переедет. ## Честный взгляд на экономику Комиссию в 4% стоит запомнить, хотя поток, к которому она применялась, уже закрыт: это оценка того, во сколько посредник оценивал знакомство с покупателем. На фоне маркетплейса, забирающего 25-30%, дёшево. На фоне продажи с собственного сайта примерно за 4% всего, дороже более чем вдвое. Настоящий вопрос ни в том, ни в другом сравнении. Настоящий вопрос в том, случилась бы продажа без этого знакомства и становится ли клиент дальше вашим или остаётся клиентом посредника. Знакомство, которое вы превращаете в повторную покупку, стоит дорого оплачивать. Знакомство, где отношения остаются у кого-то другого, это арендованный канал, а аренда не славится тем, что дешевеет. Та же арифметика применяется к любому другому каналу, то есть [вопрос окупаемости не меняется от того, что канал новый](/ru/blog/roi-math-for-automation-projects). ## Что делать в этом квартале Ничего драматического, и после сдувшегося цикла ожиданий это обычно правильный ответ. Приведите в порядок данные о товарах, они окупаются и в обычном поиске. Сделайте точность остатков настоящей, а не номинальной. Продолжайте смотреть, откуда трафик говорит, что пришёл. И относитесь к любому подрядчику, продающему срочную интеграцию с агентской коммерцией, с тем скепсисом, который заслужили последние двенадцать месяцев: стандарт открыт, покупатели настоящие, а оплата у вас на сайте, где она с самого начала и была. Источники: [OpenAI про Instant Checkout и ACP](https://openai.com/index/buy-it-in-chatgpt/), [Stripe про открытый стандарт](https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce), [спецификация ACP](https://www.agenticcommerce.dev/) и [Forbes про откат в марте 2026](https://www.forbes.com/sites/jasongoldberg/2026/03/10/why-openais-checkout-retreat-spells-trouble-for-its-commerce-strategy/). ## FAQ ### Стоит ли вообще что-то делать с агентской коммерцией, раз оплату выключили? Стоит, но работа получается другая, чем та, к которой всех готовили. Отменили шаг оплаты внутри окна чата. Не отменили то, что люди спрашивают у ассистента, что купить, и приходят на ваш сайт с уже почти принятым решением. Для растущей доли покупателей это теперь нормальное начало покупки, и вознаграждает оно совсем не то, что вознаграждал поиск. Ассистент, сравнивающий три товара, читает структурированные факты: цену, наличие, размеры, материалы, условия возврата, срок доставки. Если карточка товара говорит это явно текстом и структурированными данными, вас сравнивают корректно. Если всё это живёт только на фотографии спецификации или в PDF, вас пропускают, и вы об этом даже не узнаете. Вот в этом и состоит работа, и она одинакова независимо от того, вернётся ли когда-нибудь оплата обратно в чат. ### Почему оплата в чате не взлетела, если спрос был? По трём причинам, которые не имеют отношения к ИИ и имеют прямое отношение к содержанию магазина. Налог с продаж считается по юрисдикции и по категории товара, а обязанность несёт тот, кто принимает платёж, и решать это за тысячи продавцов в одном потоке действительно тяжело. Борьба с мошенничеством опирается на сигналы, которые есть у продавца и которых нет у посредника, а возвратные платежи приземляются на кого-то вполне конкретного. Остатки должны быть верны в секунду покупки, а не на момент последней синхронизации, потому что продать то, чего у вас нет, хуже, чем не продать вовсе. До живого запуска добрались примерно 12 продавцов на Shopify, и это говорит вам, что стоимость интеграции оказалась высокой относительно отдачи. ИИ-шопингу это не приговор. Это напоминание, что скучные части торговли держат на себе конструкцию. ### Что комиссия в 4% говорит об экономике канала? Она говорит, во сколько посредник оценивает знакомство с покупателем, и её стоит сравнивать со своими текущими каналами, прежде чем называть дорогой или дешёвой. OpenAI объявил комиссию 4% с конца января 2026 года, и вместе с эквайрингом выходило около 9,2% всего. На фоне маркетплейса, забирающего 25-30%, это дёшево. На фоне продажи с собственного сайта примерно за 4% всего это больше чем вдвое дороже. Правильный вопрос состоит не в заголовочном проценте, а в предельной марже на продаже, которой без этого знакомства не случилось бы, и в том, становится ли клиент вашим дальше или остаётся клиентом посредника. За знакомство, которое вы превращаете в повторную покупку, платить стоит много. Знакомство, где отношения остаются у посредника, это арендованный канал, а аренда обычно дорожает. ### Как сделать каталог читаемым для ИИ-ассистента? Исходите из того, что ассистент никогда не видит вашего дизайна, только ваши факты, и всё, чего он не может уверенно утверждать, он просто выбрасывает из сравнения. На практике это четыре вещи. Первое: цена, наличие, варианты, размеры, материалы, срок доставки и условия возврата лежат в машиночитаемых структурированных данных на каждой карточке, а не только в визуальной вёрстке. Второе: статус наличия правдив прямо сейчас, потому что рекомендация, приводящая на страницу «нет в наличии», стоит вам и визита, и доверия. Третье: ответы на скучные предпокупочные вопросы написаны обычным текстом на странице, а не спрятаны в виджет чата или в PDF, потому что ассистент читает страницу. Четвёртое: на один товар одна каноническая страница, чтобы ассистенту не приходилось гадать, какой из четырёх похожих адресов настоящий. --- # Что вашему ИИ решать не разрешено URL: https://inite.ai/ru/blog/safe-ai-framework-human-in-loop Date: 2026-08-03 Author: Olga Fedotova Category: Operations Tags: Safe AI, автоматизация, операции, управление ## Direct Answer Safe AI в работающем внедрении сводится к небольшому набору правил о том, где остаётся человек. У нас их четыре. Ничто обязывающее компанию (цена, обещанный срок, условие договора) не уходит наружу без подтверждения человеком. Всё, в чём система не уверена, попадает к человеку вместе с полной перепиской, а не отдельной задачей без контекста. Документы система собирает из утверждённых шаблонов и проверенных данных, формулировок она не сочиняет. Каждое автоматическое решение записывается в виде, который потом можно проверить. Где именно проходит линия подтверждения, решается по каждому процессу и по юрисдикции на диагностике: клинике в одной стране и брокериджу в другой нужны разные ответы. ## Key Facts - В проекте для клиники приём пациента сократился с 45 минут до 8, при этом каждое клиническое решение осталось за врачом. - Брокеридж уронил первый ответ с 6 часов до 8 минут, а подготовку документов с 2 дней до 20 минут, и всё уходящее наружу по-прежнему подтверждал человек. - Первая поставка - 1-3 процесса в продакшене за 2-4 недели, переданные команде клиента с документацией и мониторингом. - Мы выводим 1-3 процесса в прод за 2-4 недели, и маршрут эскалации проектируется в те же 2-4 недели. - Неявки в клинике упали на 40%, и напоминания для этого не требуют вообще никакого подтверждения. ## Вопрос, который стоит за словами «это безопасно?» Оператор задаёт его в той или иной форме перед подписью, и он почти никогда не означает того, на что отвечает подрядчик. Подрядчик слышит «будет ли модель галлюцинировать» и начинает рассказывать про точность. Оператор имеет в виду вещь гораздо более узкую и практическую: что эта штука может решать без меня? Это вопрос проектирования, у него есть письменный ответ, и на один процесс он занимает примерно час. Ниже наш ответ, изложенный четырьмя правилами вместо набора принципов. Принцип нельзя проверить во вторник днём, а правило можно. ## Правило первое: ничего обязывающего без человека Цена. Дата поставки. Условие. Документ, который суд прочитает как обязательство. Всё это останавливается на человеке. Это правило переживает встречу с юристами, и оно же самое дешёвое, потому что обязывающий шаг занимает малую долю любого процесса. В проекте для брокериджа ИИ отвечал первым, квалифицировал обращение, собирал пакет документов и направлял нужному агенту. Первый ответ упал с 6 часов до 8 минут, подготовка документов с 2 дней до 20 минут. У всего, что уходило наружу, по-прежнему стояло имя человека, принявшего решение. Шесть часов были очередью. Никто не думал шесть часов, обращение лежало в почте. Автоматизация очень хорошо убирает ожидание, перепечатывание и поиск, и очень плохо несёт ответственность. Разделение этих двух вещей и есть большая часть проектирования. ## Правило второе: исключение приходит вместе с контекстом Любая система, поднимающая сомнительные случаи к человеку, [по замыслу тратит его время](/ru/protocol). Переменной остаётся форма, в которой эскалация приходит. Эскалация с текстом «требуется проверка» заставляет согласующего сначала собрать всю картину заново и только потом решить, и эта пересборка обычно длиннее самого решения. Эскалация, пришедшая с полной перепиской, использованными данными и указанием, в чём именно система засомневалась, превращает пятиминутную пересборку в тридцатисекундное суждение. Это важно финансово, а не только эргономически. Доля эскалаций, умноженная на время согласующего, - это ежемесячный расход навсегда, и место ему в [арифметике до подписи](/ru/blog/roi-math-for-automation-projects), а не в открытии на третьем месяце. ## Правило третье: система собирает из готового Во всём договорном ИИ работает с шаблонами, которые вы утвердили, и с данными, которые прошли проверку. Он заполняет, выбирает, компонует. Новых формулировок он не пишет. Это обещание уже, чем «ИИ пишет вам договоры», и юридическая проверка получается от этого короткой. Проверяющий, который смотрит, тот ли утверждённый шаблон взят и те ли проверенные данные в него подставлены, делает быструю работу с понятными границами. Проверяющий, который ищет в сгенерированном абзаце незапланированное обязательство, делает медленную работу без границ. Та же логика покрывает регулируемое содержание вообще: административная работа идёт сама, профессиональное суждение не идёт. В [проекте для клиники](/ru/industries/clinics) приём пациента сократился с 45 минут до 8, неявки упали на 40%, административной бумажной работы стало меньше на три четверти. Каждое клиническое решение осталось за врачом, и ничему в системе не было позволено выглядеть похоже. ## Правило четвёртое: каждое автоматическое решение остаётся в записи Если система решила что-то сама, есть запись: что решила, на каких входных данных и когда. Читают её редко, но вопросы, которые в итоге задают, всегда обращены назад. Почему это предложение ушло с такой цифрой. Когда мы начали так делать. Покажите десять случаев до жалобы. Журнал заодно оказывается тем самым доказательством, которое просит регулируемый рынок, и поэтому [разговор про комплаенс](/ru/blog/ai-ethics-responsible-ai) идёт легче, когда операционная схема была сделана первой. Документация, описывающая систему, которая и так ведёт себя правильно, честна. Документация, описывающая систему, которую никто не ограничивал, это декларация с обложкой. ## Где проходит линия Универсального ответа нет, и подрядчик, предлагающий такой ответ, продаёт плакат. | Тип решения | Идёт само | Требует человека | | --- | --- | --- | | Напоминания, расписание, маршрутизация, справки | Да | Нет | | Квалификация и сортировка обращений | Да, с записью | Нет | | Всё, где есть цена, обещание или договор | Нет | Всегда | | Профессиональное суждение в регулируемой области | Нет | Всегда, поимённо | | Серая середина | Решается по процессу | Решается по юрисдикции | Серая середина и есть настоящая работа, и она закрывается на [диагностике](/ru/blog/process-audit-before-automation) вместе с теми, кто несёт ответственность, до того как что-то построено. Клиника и брокеридж в одной стране проведут линию по-разному. Та же клиника в двух странах проведёт её по-разному ещё раз. Записанная до запуска, эта линия называется проектом. Восстановленная потом по тому, что система успела сделать, она превращается в разбор инцидента. ## Чего у нас нет Мы не публикуем нумерованный список принципов, и этот текст не он. Есть четыре правила выше, с линией, которую переставляют по каждому процессу на диагностике. Если это звучит менее внушительно, чем фреймворк из шести столпов, так и задумано. Полезное свойство правила в том, что во вторник кто-то может проверить, соблюдалось ли оно, и рассказать вам, что произошло, когда оно не соблюдалось. ## FAQ ### Не съедает ли шаг подтверждения ту скорость, которую вы обещали? Не съедает, потому что медленной частью процесса решение почти никогда и не было. В проекте для брокериджа первый ответ упал с 6 часов до 8 минут, а подготовка документов с 2 дней до 20 минут, и при этом человек по-прежнему подписывал всё, что уходило наружу. Шесть часов были временем в очереди, а никаким не временем размышления: обращение просто лежало в почте, пока до него не доходили руки. Автоматизация отлично убирает ожидание, перепечатывание, поиск справок и сборку, и отдаёт человеку готовую вещь, которую он подтверждает за минуту. Это принципиально другое расходование внимания подтверждающего. Случаи, где подтверждение действительно тормозит, это те, где подтверждающий и так был узким местом, и на диагностике это видно как очередь перед одним человеком. Если мы такое находим, мы про это говорим, потому что автоматизация до заблокированного согласующего просто переносит очередь на шаг назад. ### Где именно должна проходить линия подтверждения? Она ставится по каждому процессу и по юрисдикции, и универсального ответа, который стоило бы напечатать на плакате, тут нет. Правило, которое мы применяем, звучит так: всё обязывающее компанию требует человека. Названная цена, согласованное условие, данное обещание, документ, который можно прочитать как договор. Всё чисто административное работает само: напоминание, маршрутизация, слот в расписании, поиск данных. Интересное лежит между, и это решается на диагностике вместе с теми, кто несёт ответственность. Клиника и брокеридж в одной стране проведут линию по-разному, а та же клиника в двух странах проведёт её по-разному ещё раз, потому что различаются и регулирование, и профессиональная обязанность. Важно, что линия записана до запуска и пересматривается при изменении процесса, вместо того чтобы восстанавливаться задним числом по тому, что система успела натворить. ### Сколько на самом деле стоит содержать человека в контуре? Стоит он ровно столько: доля эскалаций, умноженная на время подтверждающего, и место этой цифры в бизнес-кейсе, а не в допущениях. Если процесс идёт 400 раз в месяц, поднимает наверх 12% случаев и каждый случай отнимает у согласующего 4 минуты, это примерно 3 часа времени конкретного человека каждый месяц и дальше всегда. Обычно это хорошая сделка, и нулём она не бывает никогда. Хуже, чем нужно, её делают две вещи. Первая - эскалация, приходящая без контекста, из-за чего согласующий сначала восстанавливает картину и только потом решает. Вторая - порог эскалации, который после запуска никто не пересматривает. Против первой мы прикладываем к каждой эскалации полную переписку и причину сомнения, против второй пересматриваем пороги при передаче. Когда оцениваете любого подрядчика, спрашивайте долю эскалаций и среднее время согласующего тем же вопросом, что и срок окупаемости. ### Чем это отличается от этики ИИ и комплаенса? Комплаенс отвечает регулятору и производит документы: классификацию рисков, описание модели, свидетельства проверки на предвзятость, процедуры на инциденты. Проектирование человека в контуре обращено к оператору и задаёт поведение: какое решение куда идёт, на ком оно висит, что записывается. Эти две вещи пересекаются, потому что аудитор спрашивает доказательства, что шаг человеческой проверки существует и он настоящий, а журнал автоматических решений и есть ровно то доказательство, которое ему нужно. Ломаются они по-разному. Компания может быть безупречно задокументирована и всё равно выкатить автоматизацию, которая тихо обяжет её к цене, которую никто не имел в виду. И наоборот, компания может иметь здравую схему подтверждений и не иметь ни одной бумаги, которую потребует регулируемый рынок. Делать нужно обе половины, и когда операционная сделана первой, бумажная получается описанием факта, а не декларацией намерений. --- # Четыре вопроса, которые ломают почти любую цифру окупаемости URL: https://inite.ai/ru/blog/roi-math-for-automation-projects Date: 2026-07-27 Author: Михаил Савченко Category: Operations Tags: ROI, автоматизация, операции, закупки ## Direct Answer Расчёт окупаемости автоматизации - это прогноз, и большинство прогнозов ломается на четырёх вопросах. Чьи часы экономятся, с названием роли? Превращаются ли эти часы во что-то, что компания может продать или положить в кассу, или тридцать человек просто получают по двадцать минут? Какой объём заложен в цифру и что будет при вдвое меньшем? И кто платит за работу системы после запуска? Цифра, пережившая все четыре вопроса, стоит подписи. В наших проектах окупаемость обычно приходит за три-шесть месяцев, и приходит она тогда, когда экономия видна как проданная мощность или как быстрее закрывающийся цикл, а вовсе не как часы, умноженные на оклад. ## Key Facts - В одном проекте для брокериджа ответ на лид упал с 6 часов до 8 минут, а цикл сделки с 14 дней до 5. - Частная клиника сократила приём пациента с 45 минут до 8 и снизила неявки на 40%. - Прокат оборудования довёл путь от брони до отгрузки с 4 часов до 3 минут и принял в 2,5 раза больше пикового объёма прежним составом. - Мы выводим 1-3 процесса в прод за 2-4 недели, окупаемость обычно приходит за 3-6 месяцев. - Перед сборкой считается письменная оценка ROI на консервативных вводных; если она не выходит в плюс, работа заканчивается на диагностике. ## Цифра в предложении - это прогноз Любое предложение по автоматизации заканчивается цифрой. Сорок часов в неделю. Окупаемость за четыре месяца. Процент рядом со словом «эффективность». Эту цифру составляет сторона, которой выгодно, чтобы цифра выглядела хорошо. Это не повод разворачиваться и уходить, и обычно это даже не нечестность. Большинство завышенных расчётов собрано из кусков, каждый из которых защитим по отдельности, а вместе они дают фантастику. Четыре вопроса разбирают такую цифру на части. Они работают с любым подрядчиком, включая нас, и заданные одинаково каждый раз делают ответы сравнимыми между предложениями. ## Первый: чьи часы и как называется роль? «Экономит команде 40 часов в неделю» это не ответ. Какие роли, на каких шагах, сколько раз в неделю? Настаивать на ролях стоит потому, что стоимость часа внутри одной компании отличается впятеро, а размытая формулировка эти часы тихо усредняет. Час специалиста с лицензией, который что-то проверяет, и час помощника, перебивающего адрес руками, - разные часы. Предложение, экономящее много второго по ставке первого, отлично смотрится на бумаге и разочаровывает в отчёте. Дальше попросите полную стоимость часа вместо оклада: налоги работодателя, соцпакет, инструменты и та доля оплаченных часов, которая реально продуктивна. Полная цифра обычно в 1,3-1,6 раза больше голой ставки, и счёт по голой занижает экономию. Обе ошибки встречаются, просто смотрят в разные стороны и почти никогда не гасят друг друга. ## Второй: превращаются ли сэкономленные часы во что-нибудь? Этот вопрос убирает большую часть цифры, и его почти никто не задаёт. Двадцать минут в день, возвращённые тридцати сотрудникам, - это 250 часов в месяц на слайде и, в большинстве компаний, ничто в отчётности. Никого не сократили, ничего дополнительно не продали, а время впиталось в то, что и так стояло в очереди. Работать стало приятнее. Окупаемости в этом нет. Часы превращаются в деньги двумя путями, и стоит назвать, какой из них ваш, до подписи: | Путь | Что должно быть правдой | Пример из наших проектов | | --- | --- | --- | | Мощность, которую вы продаёте | Раньше вы разворачивали заявки | Прокат принял в 2,5 раза больше пикового объёма без найма | | Цикл, который закрывается быстрее | Медленный цикл стоил вам конверсий | Брокеридж сократил цикл сделки с 14 дней до 5 | | Найм, которого вы не делаете | Наём был реально запланирован и в бюджете | План существует письменно до старта проекта | Пример с прокатом у нас самый чистый. Путь от брони до отгрузки сократился с 4 часов до 3 минут, и пиковые заявки, которые раньше разворачивали из-за сроков, стало можно принимать. Сами часы тут были побочным эффектом. Брокеридж - это второй путь: ответ на обращение упал с 6 часов до 8 минут, цикл с 14 дней до 5, а короткий цикл конвертит лучше, потому что меньше покупателей успевает остыть. Если ни один путь не подходит, честное описание проекта звучит так: он делает работу лучше. Это законная покупка. Просто покупать её надо с таким ожиданием и без графика окупаемости. ## Третий: какой объём заложен в цифру? Экономика автоматизации - это фиксированная стоимость постройки, делённая на поток. Поэтому срок окупаемости резко ходит вслед за допущением об объёме и почти не реагирует на всё остальное. Процесс, который случается 400 раз в месяц и экономит по 15 минут, считается просто. Тот же процесс 80 раз в месяц несёт ту же стоимость постройки против пятой части выгоды и обычно проваливает честную арифметику, хотя экономия на одном случае осталась прежней. Отсюда правило: берите объём из собственных систем, а не из разговора, берите слабый месяц вместо хорошего и просите срок окупаемости при вдвое меньшем объёме. Если кейс выживает только на оптимистичной цифре, на столе лежит ставка на рост, одетая как проект по эффективности. Такую ставку тоже можно принять, но принимать её надо с открытыми глазами. ## Четвёртый: кто платит за это после запуска? Стоимость постройки называют всегда. Про эксплуатацию обычно молчат, и как раз в ней окупаемость за четыре месяца превращается в окупаемость за одиннадцать. Попросите месячную цифру, закрывающую все четыре пункта, умножьте её на двенадцать и [прибавьте к стоимости постройки до того, как что-то делить](/ru/answers/ai-automation-cost): - Модель и инфраструктура на единицу объёма, на вашем настоящем объёме. - Время людей на случаях, которые система поднимает наверх, при честной доле эскалаций. Любая автоматизация, отдающая сомнительные случаи человеку, по замыслу тратит его время, и [человек в контуре на всём обязывающем](/ru/blog/process-audit-before-automation) - это выбор, сделанный намеренно, и у него есть ценник. - Поддержка, когда мир вокруг меняется: поставщик поменял форму, регулятор добавил поле, канал сменил интерфейс. - Дальнейшее участие владельца процесса после передачи. Автоматизация без хозяина тихо деградирует, а дашборды при этом продолжают показывать норму. ## Как выглядит хороший ответ Посчитанная честно, арифметика короткая. Один процесс. Его объём из вашей системы, взятый по слабому месяцу. Минуты на случай, по ролям, по полной стоимости часа. Названный путь, которым эти минуты становятся выручкой или несостоявшимся расходом. Двенадцать месяцев эксплуатации, прибавленные к стоимости постройки. Поделить. Наши проекты выводят один-три процесса в прод за две-четыре недели, окупаемость обычно приходит за три-шесть месяцев. Диапазон держится потому, что мы подписываемся только там, где у экономии есть дорога до отчётности. Поэтому же примерно одна задача из трёх заканчивается на диагностике без билда. [Аудит, который это разделяет](/ru/blog/process-audit-before-automation), намеренно дешевле стройки, которую он может отменить. После запуска три числа показывают, был ли прогноз настоящим: реально освобождённые часы у названных людей, время цикла до и после, доля ошибок на автоматизированном шаге. [Замер этих трёх по расписанию](/ru/blog/measuring-ai-roi) превращает прогноз в факт, и расписание стоит утвердить до подписи. ## Задайте эти четыре вопроса нам Мы отдаём таблицу с открытыми вводными, потому что цифру, которую оператор не может разобрать, он не сможет через полгода защитить перед своим советом директоров. Принесите эти четыре вопроса тому, кто выставляет вам счёт следующим, будь то мы или кто угодно ещё. Подрядчик, отвечающий на все четыре конкретикой, работу проделал. Подрядчик, который не отвечает, выдал вам украшение, и [быстрее всего понять, что именно у вас в руках](/ru/blog/business-process-automation), помогает вопрос про половину объёма. ## FAQ ### Почему не доверять цифре окупаемости даже от подрядчика, который мне нравится? Потому что это прогноз, а составляет его сторона, которой выгодно, чтобы прогноз выглядел привлекательно. Это не обвинение в нечестности, это описание того, где лежит интерес. Большинство завышенных расчётов никто не выдумывает: их собирают из кусков, каждый из которых по отдельности защитим. Оптимистичный объём в час. Голый оклад вместо полной стоимости часа. Минуты, сэкономленные у широкой группы людей, которые потом ни во что не превращаются. Стоимость постройки без стоимости эксплуатации, которая идёт следом. Каждый кусок обсуждаем, а сумма получается фантастической. Защита здесь состоит вовсе не в подозрительности к подрядчику. Защита - это фиксированный набор вопросов, задаваемый одинаково каждый раз, чтобы ответы стали сравнимы между подрядчиками и между проектами. Задайте их и нам. Если подрядчик не отвечает на все четыре конкретикой прямо на звонке, цифра была украшением. ### Чем сэкономленные часы отличаются от сэкономленных денег? Часы превращаются в деньги ровно двумя путями, и стоит прямо назвать, какой из них применим, до того как что-то подписано. Первый путь - мощность, которую вы продаёте: та же команда обрабатывает больший объём, и у объёма есть выручка. Прокат оборудования, с которым мы работали, довёл путь от брони до отгрузки с 4 часов до 3 минут и принял в 2,5 раза больше пикового объёма без найма. Это настоящие деньги, потому что раньше пиковые заявки просто разворачивали. Второй путь - цикл, который закрывается быстрее и потому закрывается чаще: брокеридж сократил цикл сделки с 14 дней до 5, а короткий цикл конвертит лучше, потому что меньше покупателей успевает остыть. Всё остальное, особенно двадцать минут, вернувшиеся тридцати сотрудникам, которые дальше делают с ними что-то неизмеряемое, - это настоящее улучшение качества работы и выдуманная строка в бизнес-кейсе. Считайте это как моральный климат, а не как окупаемость. ### Какие расходы на эксплуатацию обычно не попадают в предложение? По нашему опыту четыре, и именно они превращают окупаемость за четыре месяца в окупаемость за одиннадцать. Первое - модель и инфраструктура: у каждого автоматического решения есть цена за штуку, и на реальном объёме эта цена становится ежемесячной строкой бюджета, а никакой не погрешностью. Второе - человек в контуре: любая автоматизация, поднимающая сомнительные случаи к человеку, по замыслу тратит время этого человека, и долю эскалаций нужно оценивать честно, а не принимать близкой к нулю. Третье - поддержка, когда мир вокруг меняется: поставщик поменял форму, регулятор добавил поле, канал сменил интерфейс, и кто-то должен это заметить и починить. Четвёртое - продолжение участия владельца процесса после передачи, потому что автоматизация без хозяина тихо деградирует, и отчётность при этом продолжает выглядеть здоровой. Попросите эти четыре пункта одной месячной цифрой, умножьте на двенадцать и прибавьте к стоимости постройки до того, как что-то делить. ### Насколько глубоко проверять чувствительность к объёму до подписи? Попросите срок окупаемости при вдвое меньшем объёме и считайте настоящим ответом именно его. Экономика автоматизации - это фиксированная стоимость постройки, делённая на поток, поэтому срок окупаемости бешено зависит от допущения по объёму и почти не зависит больше ни от чего. Процесс, который случается 400 раз в месяц и экономит по 15 минут, считается легко. Тот же процесс 80 раз в месяц несёт ту же стоимость постройки против пятой части выгоды и обычно проваливает честную арифметику, хотя экономия на одном случае не изменилась. Это самая частая причина, по которой красивый на бумаге проект разочаровывает, и избегается она элементарно: берите объём из собственных систем, а не из интервью, берите слабый месяц вместо хорошего и спрашивайте, что будет, если объём никогда не вырастет. Если кейс сходится только на оптимистичном объёме, вам предлагают ставку на рост в костюме проекта по эффективности. --- # Мы построили один и тот же продукт дважды. Перенеслось 6%. URL: https://inite.ai/ru/blog/inite-estate-real-estate-vertical Date: 2026-07-20 Author: Михаил Савченко Category: Operations Tags: стратегия, автоматизация, операции, продукт ## Direct Answer Компания, строящая второй продукт в той же отрасли, обычно рассчитывает переиспользовать большую часть первого. Мы сделали платформу аренды, потом платформу недвижимости, звучат они почти одинаково, но общими оказались 7 бизнес-понятий из 113, около 6%. Второй продукт всё равно вышел намного быстрее, потому что экономия приходит не из бизнес-логики. Она берётся из обвязки, которая нужна любому продукту и которой не видит клиент: учётные записи, права доступа, биллинг, переписка, уведомления, журнал изменений, переводы. Постройте это один раз, и второй продукт начнётся сразу с интересного места. Рассчитывайте на перенос отраслевых правил, и вы получите компромисс, который не устроит никого. ## Key Facts - Из 113 бизнес-понятий в двух наших продуктах общими оказались только 7, примерно 6%. - Продукту аренды понадобилось 57 отраслевых понятий, продукту недвижимости 63. - Около 33% второго продукта заняла инфраструктура, не имеющая отношения к недвижимости. - Общий фундамент закрывает 8 стандартных возможностей, нужных любому продукту, от биллинга до журнала изменений. - Мы выводим 1-3 автоматизированных процесса в прод за 2-4 недели. ## Цифра, которая нас удивила Мы делаем софт для двух бизнесов, которые звучат как один и тот же бизнес. Первый сдаёт вещи посуточно. [Второй продаёт недвижимость и управляет ею](/ru/industries/real-estate). Если описать одной фразой, в обоих случаях кто-то платит за пользование зданием или машиной в течение какого-то срока. Когда мы начинали второй, все участники исходили из того, что большая часть первого перейдёт как есть. Вместе эти два продукта описывают 113 бизнес-понятий: то, о чём софт обязан знать, вроде клиента, договора, правила расчёта цены, брони. Общих оказалось семь. Шесть процентов. Второй продукт всё равно вышел намного быстрее первого. Понять почему полезнее, чем знать саму цифру, потому что ровно та же логика решает, окупится ли автоматизация внутри вашей собственной компании. ## Почему два похожих бизнеса почти ничего не делят Фраза, которая делает их похожими, и есть та фраза, в которой спрятаны все различия. У прокатной компании есть машины. Они либо есть, либо их нет. У застройщика есть дома на стройке, где каждая квартира проходит стадии готовности: проект, коробка, отделка, приёмка, и половина бизнеса состоит в том, чтобы отслеживать, на какой стадии что находится. Машины, готовой на шестьдесят процентов, не бывает, поэтому и заимствовать в первом продукте было нечего. Аренда открывается и закрывается за неделю. Сделка с недвижимостью идёт месяцами и включает покупателя, продавца, агента, а часто и банк, и каждому нужен свой взгляд на одну и ту же сделку. Мы точно знаем, до какого места доезжает попытка считать это бронью с дополнительными полями: до первой комиссии, которую надо разделить на троих. И у прокатной компании есть клиенты. У компании по недвижимости есть клиенты, собственники и инвесторы: люди, которые ничего через систему не покупают и заходят только посмотреть, что происходит с их активом. В первом продукте им нет никакого соответствия, и это самый ясный признак того, что бизнесы изначально были разными. ## Где на самом деле была экономия Ничто из перечисленного не делает второй продукт дешёвым. Экономия лежит ниже, в той части, которую не видит ни один клиент и которую не расписывает ни одно коммерческое предложение. Прежде чем платформа недвижимости сможет заняться недвижимостью, ей нужно вот это: | Что нужно любому продукту | Кто это замечает | | --- | --- | | Входы, компании, роли сотрудников, права | Никто, пока это не сломано | | Биллинг, подключённый к настоящему провайдеру | Финансы, ежемесячно | | Сообщения из WhatsApp и Telegram в одной очереди | Тот, кто на них отвечает | | Уведомления, переводы, журнал изменений | Аудиторы и юристы | | Шифрование персональных данных | Все, один раз | В первый раз этот список занял месяцы. Он одинаков независимо от того, идёт речь про хетчбэк или про двушку. И примерно треть второго продукта оказалась именно этим: инфраструктурой, не имеющей отношения к недвижимости. Это та же механика, [которая нужна любой компании, автоматизирующей процесс](/ru/blog/business-process-automation), и потому её стоит один раз завести себе в собственность. Построенная однажды, она позволяет второму продукту начинаться там, где начинается интересная работа. В этом весь фокус, и он достаточно скучный, чтобы в планах его обычно не было. ## Правило, по которому мы решаем Всё расставляет один вопрос: сделал бы второй продукт это по-другому? Если оба сделали бы одинаково, строим один раз. Разрешение каждой команде писать свою версию заканчивается четырьмя слегка разными системами входа и одной и той же ошибкой, исправленной четыре раза. Если продукты действительно расходятся, держим отдельно. Одна гибкая версия на оба случая обычно оказывается сложнее для чтения, чем дублирование, которое она должна была убрать. Входы и права проходят без спора. Ценообразование проваливается сразу: сезоны и тарифы с одной стороны, комиссии и несколько сторон сделки с другой. Когда решить не выходит, оставляем отдельно, потому что слить потом стоит вечера, а разделить потом стоит квартала. ## Почему это важно, если вы не строите софт Почти каждая компания, которая просит нас что-то автоматизировать, описывает процесс как свой собственный. Правила обычно и правда свои. Своей почти никогда не бывает вся обвязка вокруг: затащить обращения из нескольких каналов в одну очередь, решить, кто чем занимается, поднять к человеку то, в чём система не уверена, записать, что произошло, и отчитаться по этому потом. Эта механика одинакова для клиники, логистической компании и проката оборудования. Она же дольше всего строится с нуля. Вот настоящая причина, по которой мы выводим один-три процесса в прод за две-четыре недели, а не за два-три квартала. Механику никто не строит заново. Вы платите за правила, которые ваши, и поэтому же [арифметика окупаемости вообще сходится](/ru/blog/measuring-ai-roi). Ошибка, которой стоит избежать, та самая, которую мы чуть не сделали сами: считать, что раз две вещи звучат похоже, то дорогие части перенесутся. Обычно они не переносятся. [Начните с того, чтобы выяснить, какие части вашего процесса действительно ваши](/ru/blog/process-audit-before-automation), и будьте честны насчёт того, насколько обычна вся остальная часть. Именно эта обычность и делает её дешёвой. ## FAQ ### Если почти ничего не перенеслось, общий фундамент вообще стоило строить? Он и был единственной причиной, по которой второй продукт получился быстрым. Путаница возникает потому, что экономия вылезает там, где её никто не закладывает в план. Прежде чем платформа недвижимости сможет сделать хоть что-то про недвижимость, ей нужны входы в систему, компании, роли и права сотрудников, биллинг, подключённый к настоящему платёжному провайдеру, приём сообщений от клиентов в WhatsApp и Telegram, уведомления, переводы, журнал того, кто и что менял, шифрование персональных данных. Этот список занимает месяцы, он одинаков и для проката автомобилей, и для продажи квартир, а любая незаметная ошибка в нём всплывает не на демо, а на аудите безопасности. Один раз построенный фундамент означает, что второй продукт стартует там, где начинается собственно бизнес. Отраслевые правила в любом случае были бы разными, и денег там никогда и не было. ### Почему два таких похожих бизнеса разделили так мало? Потому что они похожи только на слух. Оба описываются как «кто-то платит за пользование объектом в течение срока», и в этой фразе прячется каждое различие, которое имеет значение. У проката есть машина, которая либо существует, либо нет; у застройщика есть дом на стройке, где каждая квартира проходит стадии готовности, прежде чем в ней вообще можно жить. Аренда открывается и закрывается за несколько дней; сделка с недвижимостью идёт месяцами и включает покупателя, продавца, агента, а часто и банк, и каждому нужен свой взгляд на одну и ту же сделку. У прокатной компании есть клиенты; у компании по недвижимости есть ещё собственники и инвесторы, которые ничего через систему не покупают и заходят только посмотреть, что происходит с их активом. Когда всё это выписано на бумагу, шесть процентов совпадения перестают быть загадкой. Загадка в том, почему кто-то ждал большего. ### Как вы решаете, что строить один раз, а что для каждого продукта отдельно? Мы задаём один вопрос: сделал бы второй продукт это по-другому? Если оба продукта сделали бы одинаково, строим один раз, потому что разрешение каждой команде писать свою версию заканчивается тем, что компания держит четыре слегка разные системы входа и чинит одну и ту же ошибку четыре раза. Если продукты действительно расходятся, держим отдельно, потому что одна гибкая версия на оба случая обычно оказывается сложнее для понимания, чем то дублирование, которое она заменила. Входы и права проходят этот тест без спора: пользователь, компания, кому что разрешено, и любое расхождение здесь между продуктами это ошибка, а никакая не особенность. Ценообразование проваливает тест сразу: в аренде сезоны и тарифные сетки, в недвижимости комиссии и несколько сторон, и универсальный движок цен на оба случая раздражал бы всех. Когда решить не выходит, оставляем отдельно, потому что слить потом легко, а разделить потом тяжело. ### Что это значит для компании, которая автоматизирует собственные операции? Тот же принцип работает на гораздо меньшем масштабе, и обычно именно он определяет, окупится автоматизация или тихо не окупится. Почти каждая компания, которая просит нас что-то автоматизировать, описывает процесс как уникальный, и конкретные правила действительно чаще всего уникальны. Уникальной почти никогда не бывает окружающая механика: собрать обращения из нескольких каналов в одну очередь, решить, кто чем занимается, поднять к человеку то, в чём система не уверена, записать, что произошло, и отчитаться потом. Эта часть одинакова для клиники, логистической компании и проката оборудования, и она же дольше всего строится с нуля. Когда мы называем срок 2-4 недели на один-три процесса в проде, недели вместо кварталов получаются именно потому, что механику никто не строит заново. Вы платите за правила, которые ваши, а не за обвязку, которая ничья. --- # Как подготовить ваш SaaS к ИИ-агентам: план на 90 дней URL: https://inite.ai/ru/blog/mcp-server-90-day-build Date: 2026-07-07 Author: Михаил Савченко Category: Agentic Engineering Tags: AI Agents, Agentic SaaS, MCP, Automation, Стратегия ## Direct Answer Клиенты всё чаще хотят делать дела через ИИ-ассистента - «попроси Claude вытащить счета», «пусть ChatGPT забронирует слот». Чтобы разрешить это безопасно, вашему SaaS нужна одна стандартная дверь для агентов, построенная в три шага по 30 дней. Первые 30 дней: открыть дверь только на чтение и доказать, что агент одного клиента не увидит данные другого. Следующие 30 дней: разрешить возвраты и отмены, но каждое действие пропускать через человека - агент предлагает, человек решает. Последние 30 дней: укрепить всё (лимиты, журналирование, интерфейс) и протестировать. Стандарт (MCP) за 18 месяцев вырос со 100 000 до 97 млн подключений в месяц - одна дверь открывает продукт всем ассистентам сразу. ## Key Facts - Стандарт для подключения ИИ-ассистентов к программам (MCP) вырос примерно со 100 000 до 97 000 000 подключений в месяц примерно за 18 месяцев. - К началу 2026 года было 17 468 публичных серверов, готовых к агентам, против пары сотен на старте - рынок сформировался меньше чем за два года. - Эталонный проект этого стандарта к апрелю 2026 года набрал более 84 000 звёзд от разработчиков - один из самых быстрорастущих за цикл. - План делится на три равных шага по 30 дней каждый: только чтение, одобренные действия, затем укрепление - всего 90 дней. - Действия на запись никогда не выполняются сами по себе: 100% из них проходят через шаг одобрения человеком перед выполнением. ## Сдвиг, который стоит заметить Всё больше ваших клиентов теперь [начинают задачи с разговора с ассистентом](/ru/analyze). Они просят Claude кратко изложить переписку, ChatGPT - вытащить число, ассистента - забронировать слот. Естественный следующий шаг - что они захотят делать эти вещи *в вашем продукте* таким же образом, и они будут склоняться к продуктам, которые это позволяют. Годами поддержка этого означала отдельную индивидуальную интеграцию под каждый ассистент, поэтому большинство компаний не строили ни одной. Затем появился единый стандарт для подключения ассистентов к программам, и он быстро распространился: примерно со **100 000 до 97 млн подключений в месяц за восемнадцать месяцев**, с **17 468 публичными серверами, готовыми к агентам,** к началу 2026 года. Постройте одну стандартную дверь сейчас - и каждый ассистент, сегодняшний и будущий, сможет пользоваться вашим продуктом. В этом и возможность. Вот простой план на 90 дней, чтобы взять её безопасно. ## Дни 1-30: пусть смотрит, но не трогает Первый месяц строит наименьшую безопасную вещь: дверь, которой ассистент может пользоваться, чтобы *смотреть* информацию, но ничего не менять. Выберите один запрос, который ваши операторы просят чаще всего - «покажи регистрации за этот месяц», «перечисли открытые заявки» - и откройте ровно его. Затем подключите настоящий ассистент вроде Claude или ChatGPT и убедитесь в двух вещах: он находит и использует этот запрос, и запрос, сделанный для одного клиента, не может увидеть данные другого. Этот последний пункт - вся работа первого месяца. Безопасный способ гарантировать это в принципе прост: доступ агента привязан к учётным данным одного конкретного клиента, так что даже если модель уговорят запросить чужой аккаунт, система просто откажет. Сделайте это правильно - и рискованные месяцы станут понятными. ## Дни 31-60: пусть действует, но с человеком в цепочке Смотреть данные безопасно. Совершать действия - возврат, отмена - это там, где ценность *и* где опасность, поэтому они никогда не выполняются по одному слову агента. | Что может агент | Когда это происходит | Правило безопасности | | --- | --- | --- | | Смотреть данные | Сразу | В рамках одного клиента | | Совершить действие (возврат, отмена) | Только после одобрения человеком | Человек в цепочке | | Массовые или разрушительные действия | Никогда через агента | Только сотрудники | Инструмент действия не выполняет - он *предлагает*. Предложение падает в очередь, человек из вашей команды одобряет или отклоняет его с полным контекстом, и только тогда оно выполняется. Агент предлагает; человек решает. Это медленнее, чем позволить агенту действовать напрямую, и это единственный ответственный способ дать ассистенту реальную власть в живом бизнесе. Это та же [дисциплина «человек в цепочке», которой мы держим каждый внедряемый процесс](/ru/blog/one-engine-many-skins-inite-thesis). ## Дни 61-90: сделать это надёжным Последний месяц - это разница между демо и тем, что вы гоняете в эксплуатации: разумные лимиты на каждого клиента, ясный журнал того, кто что сделал, понятные сообщения об ошибках, которые ассистент может понять, и нормальный интерфейс вместо сырого текста. Один совет, который экономит больше всего времени: не стройте отдельную агентскую версию вашего продукта. То, что может делать ассистент, должно быть ровно теми же возможностями, которые уже предлагает ваш собственный встроенный ассистент, открытыми через ту же одну дверь. Так эти две вещи никогда не разойдутся, и каждая возможность, которую вы уже выпускаете, [становится доступной внешнему агенту бесплатно](/ru/blog/mcp-skills-make-saas-ai-native). ## Что у вас есть на 90-й день Продукт, которым может пользоваться любой крупный ассистент, который держит данные каждого клиента за стеной, который никогда не совершает реального действия без «да» от человека и который всё журналирует. Вы не поставили на то, какой ассистент победит, - вы сделали свой продукт пригодным для всех сразу через одну дверь. По той же причине это уже сделали 17 468 других компаний: постройте один раз - и вы присутствуете там, где ваши клиенты уже есть. **Читайте также:** [Готовим SaaS к браузерным агентам](/ru/blog/browser-agent-ready-saas). ## FAQ ### Зачем мне вообще заботиться о том, чтобы ИИ-агенты пользовались моим продуктом? Потому что ваши клиенты начинают этого ожидать. Люди всё больше живут внутри ассистента - они просят Claude или ChatGPT кратко изложить, вытащить и забронировать - и они предпочтут продукты, которыми можно управлять таким образом. Раньше поддержка каждого ассистента означала отдельную индивидуальную интеграцию, поэтому большинство компаний не поддерживали ни одного. Перемена в том, что теперь есть одна стандартная дверь (MCP), которой может пользоваться каждый крупный ассистент, - поэтому она и выросла примерно со 100 000 до 97 млн подключений в месяц за восемнадцать месяцев. Построить эту одну дверь означает, что каждый ассистент - те, что существуют сейчас, и те, что выйдут в следующем году, - сможет пользоваться вашим продуктом без дополнительной работы с вашей стороны. Это разница между ставкой на то, какой ассистент победит, и тем, чтобы просто быть пригодным для всех сразу. ### Разве не опасно позволять ИИ трогать мою систему? Опасно, если делать это наивно, - именно поэтому план ставит два правила безопасности впереди любой рискованной возможности. Первое правило - разделение данных: агент, действующий за Клиента А, никогда не должен видеть данные Клиента Б, и вы гарантируете это, привязывая доступ агента к учётным данным конкретного клиента, а не полагаясь на то, что агент сам останется в своей полосе. Модель можно уговорить запросить не тот аккаунт; система просто откажет, потому что учётные данные открывают только один. Второе правило: всё, что меняет или удаляет данные - возврат, отмена, - не выполняется по слову агента. Оно ставится в очередь как предложение, а человек из вашей команды одобряет или отклоняет его с полным контекстом до того, как оно произойдёт. С этими двумя правилами худшее, что может сделать агент, - предложить то, что человек затем отклонит. Это совсем другой профиль риска, чем позволить ему действовать свободно. ### Что на самом деле даёт первый месяц - 30 дней? Работающую, безопасную дверь только на чтение - наименьший полезный кусок. Вы выбираете самую частую вещь, которую ваши операторы просят вслух («покажи диагностику за этот месяц», «перечисли открытые инциденты»), и открываете ассистенту ровно этот один запрос. Пока ничего нельзя изменить; можно только читать. Затем вы подключаете настоящий ассистент вроде Claude или ChatGPT, убеждаетесь, что он находит и использует этот запрос, и - самое важное - убеждаетесь, что запрос, сделанный с учётными данными одного клиента, не может увидеть данные другого. Эта последняя проверка и есть весь смысл первого месяца. Он намеренно маленький, но доказывает, что весь подход работает от начала до конца с настоящим агентом, - а это снимает риски со всего, что вы добавите в следующие два месяца. ### Чем это отличается от обычного чат-бота? Чат-бот говорит; дверь, готовая к агентам, позволяет ассистенту реально делать дела в вашем продукте. Типичный чат-бот поддержки отвечает на вопросы по сценарию или из базы знаний - он не может вытащить настоящий счёт именно этого клиента или, с одобрения, оформить его возврат. Готовность к агентам - это про то, чтобы дать внешнему ассистенту безопасный, реальный доступ к вашей живой системе: смотреть настоящие данные в рамках нужного клиента и совершать настоящие действия, которые человек одобрил. Другое отличие - охват. Чат-бот живёт на вашем сайте; дверь, готовая к агентам, означает, что клиент может пользоваться вашим продуктом изнутри того ассистента, который ему уже нравится, - Claude, ChatGPT или следующего, - без того чтобы вы строили бота под каждый. Одно - это функция на вашей странице; другое - присутствие там, где ваши клиенты уже есть. --- # Аудит процесса до автоматизации: плейбук, который решает, когда не строить URL: https://inite.ai/ru/blog/process-audit-before-automation Date: 2026-06-22 Author: Михаил Савченко Category: Methodology Tags: аудит процессов, AI автоматизация, ROI, B2B SME, диагностика ## Direct Answer Аудит перед автоматизацией - это платная 5-дневная диагностика, на выходе которой 3 артефакта: swimlane-карта процесса с метриками throughput, error rate и cycle time; cost-of-chaos в $/неделю; письменный ROI-расчёт с консервативными вводными. Если ROI не выходит в плюс при 25-м перцентиле time-saved и 75-м перцентиле стоимости - возвращаем депозит. Одна из 3 задач заканчивается здесь. 4 паттерна закрывают почти все отказы: узкое место - ожидание, а не работа; процесс меняется быстрее автоматизации; команда не примет инструмент; объёма не хватает. Аудит дешевле билда; плейбук ниже держит дешёвую часть дешёвой. ## Key Facts - Задача может закончиться на стадии диагностики без билда. Если ROI-расчёт при консервативных вводных не выходит в плюс, депозит возвращается и работа закрывается. - Стадия Cut убирает шаги до того, как начинается автоматизация, а не кодифицирует их, и каждое удаление записывается с приложенным объёмом по шагу. Шаги, которых не должно быть, удаляются, а не кодифицируются - автоматизация хаотичного процесса - это самый дорогой способ сделать медленные системы медленными навсегда. - Аудит занимает пять рабочих дней end-to-end и выдаёт три именованных артефакта: количественную карту процесса, cost-of-chaos отчёт и priority matrix с подписанным ROI по каждому кандидату. Медианная цена диагностики - 5-10% от прогнозируемого бюджета билда. - Production-workflow выкатываются за 2-4 недели от kickoff и меряются против бейзлайна, который оператор подписал до начала сборки, - только так число «после» вообще что-то значит. - 4 паттерна отказа закрывают большую часть No на стадии аудита: процессы, где доминирует upstream-ожидание, не адресуемое автоматизацией; процессы, которые команда в этот момент переписывает сама; процессы, которые операторы не примут по соображениям контроля; низкообъёмные процессы, где стоимость билда выше реалистичного time-saved за 12 месяцев. ## Правило, которое определяет компанию Workflow уходит в билд только после [письменного ROI-расчёта, подписанного оператором](/ru/protocol), который выходит в плюс при консервативных допущениях. Если не выходит - мы возвращаем депозит и закрываем задачу. Задачи именно так и заканчиваются, и в этом весь смысл держать эти ворота: фильтр, который никогда никого не отсеивает, - не фильтр, а формальность. Это не позиция в продажах. Это самая дешёвая страховка, которую может купить проект. Почти каждая AI-автоматизация, провалившаяся через полгода, провалилась на стадии аудита, и аудит этого не поймал. ## Что такое аудит и что аудитом не считается Аудит - это стадия Break [INITE Protocol](/ru/blog/inite-protocol-6-stages-applied). Пять рабочих дней. Один workflow за раз, иногда два. Три именованных артефакта на выходе. Подписанный ROI до того, как нарезан хоть один билд-PO. Это не звонок по продажам. Не discovery session. Не презентация. Оператор платит небольшую сумму (обычно 5-10% от прогнозируемого бюджета билда), и эта сумма возвращается полностью, если аудит заканчивается решением не строить. Бесплатная пятнадцатиминутная проверка готовности на сайте - другая и более ранняя вещь: она отвечает, стоит ли процесс аудита вообще, и не требует от вас ничего, кроме разговора. Здесь речь про следующий шаг. Как только на столе оказывается реальный доступ к системам и цифрам, цена становится самым большим рычагом на качество: на платный аудит присылают владельца процесса, на бесплатный - продавца. ## Три артефакта | Артефакт | На какой вопрос отвечает | Время на сборку | | --- | --- | --- | | Количественная карта процесса | Где настоящее узкое место? | 2 дня | | Cost-of-chaos отчёт | Сколько стоит текущий способ в $/неделю? | 1 день | | Priority matrix и подписанный ROI | У какого кандидата математика билда сходится? | 2 дня | Карта процесса - это swimlane на уровне передач: каждый шаг от kick-off до закрытия, каждый шаг в своей дорожке по роли, на каждой передаче проштампованы три числа - throughput в неделю, error rate, медианный cycle time. Большинство команд никогда не видели свою работу в такой форме. Карта - это то, что вскрывает узкое место, и в большинстве случаев оно не там, где думали операторы. Cost-of-chaos - это число в долларах в неделю: сколько текущий способ работы стоит компании в потерянных часах сверх необходимой работы. Три строки: переделки, ожидание, потери. Явные вводные. Контроллер компании подтверждает вводные. Priority matrix - это 2×2 по технической осуществимости автоматизации и бизнес-ROI для каждого кандидатного workflow, поднятого на аудите. Правый верхний угол идёт в стадию Cast. Всё остальное получает письменное объяснение, почему оно не попало. ## Четыре паттерна отказа Аудит заканчивается No, когда математика не выходит в плюс при консервативных допущениях. Четыре паттерна закрывают почти любое No. ### Wait-доминируется upstream Медленный шаг workflow - это ожидание чего-то вне контроля компании: ответа регулятора, подписи клиента, прохождения платежа в банковской системе. Внутренняя автоматизация снимает минуты с обработки, но число cycle time не двигается, потому что ожидание лежит выше по потоку и не адресуется. Автоматизация в этом случае - это более быстрая лошадь на дороге, перекрытой шлагбаумом. Аудит ловит это, замеряя cycle time на каждой передаче и помечая, внутри ли ожидание (мощности оператора), межкомандное оно (передача между функциями) или внешнее (поставщик, клиент, регулятор). Workflow, у которого 80% cycle time лежит во внешних ожиданиях, - это No на билд, который предлагает автоматизировать внутренние шаги. ### Mid-rewrite Команда переписывает процесс прямо сейчас по несвязанным причинам - миграция ERP, реорг, новый комплаенс-режим. Автоматизация текущего варианта закрепляет процесс, которого через три месяца не будет. Аудит ловит это двумя вопросами в интервью оператора: что поменялось в том, как вы это делаете, за последние 6 месяцев, и что вы ждёте в ближайшие 6. Workflow, где второй ответ - «всё» или «мы меняем систему», - это No до тех пор, пока переписывание не уляжется. ### Adoption blocker В workflow есть измерение доверия или контроля, которое операторы не делегируют. Контроллер, подписывающий исходящий wire transfer, не отдаст право подписи модели - никакой моделью. Доктор, подписывающий направление, не отдаст подпись. Автоматизация технически работала бы - и не использовалась бы. Аудит ловит это, спрашивая самих операторов workflow (не их менеджера), будут ли они пользоваться предлагаемой автоматизацией. Ответ обычно прямой. Workflow, где оператор говорит «я бы всё равно проверял каждый ответ», - это норма, если проверка занимает секунды; это No, если проверка занимает столько же, сколько изначальная работа. ### Volume too low Кандидатный workflow случается 8 раз в неделю. Экономия - 90 минут на инстанс. Итого 12 часов в неделю. Даже при $120 loaded cost recovery-line - $74K в год против $74K all-in стоимости билда. Recovery-line на уровне или ниже точки безубыточности на первом году, и workflow должен прожить без изменений ещё два года, чтобы окупиться в нормальной норме. Это No на билд, даже если технология работала бы и команда приняла бы инструмент. Этот паттерн - самая частая причина, по которой малый бизнес просит автоматизацию, под которую математика не сойдётся. Аудит ловит это явным расчётом объём × time-saved × cost, и оператор обычно соглашается с выводом ровно в момент, когда видит цифры разложенными. ## Шаблон ROI В шаблоне математики три колонки и одно правило. | Вводная | Как берётся | Зачем | | --- | --- | --- | | Time saved на инстанс | 25-й перцентиль наблюдаемого диапазона оператора | Мы не закладываем лучшую неделю | | Стоимость билда за 12 месяцев | 75-й перцентиль инженерной оценки | Мы не закладываем самую гладкую поставку | | Loaded labor cost в час | Зарплата, бенефиты, поправка на утилизацию | Не голая часовая - реальная стоимость часа | Правило - ROI обязан выйти в плюс при таких вводных за 12 месяцев. Не за 24, не за 36, не «когда-нибудь». Двенадцать месяцев. Оператор подписывает шаблон до того, как нарезан билд-PO. Эта подпись делает решение разделённым, а не навязанным. Разобранный пример самой арифметики, на кандидате, которого мы не строили. Workflow: triage и роутинг входящих RFP. Объём: 38 RFP в неделю. Экономия на RFP по 25-му перцентилю: 22 минуты. Loaded labor cost: $95 в час у senior account manager. Это 38 заявок по 22 минуты, по 95 долларов за час, 50 рабочих недель, то есть recovery-line в $66 200 в год. Стоимость билда по 75-му перцентилю: $42 000 all-in. Математика вышла в плюс на седьмом месяце, workflow поехал в Cast. На двенадцатом месяце реализованная цифра была $87K, потому что time-saved оказался ближе к медиане, чем к 25-му перцентилю, - в этом и весь смысл: консервативные вводные, реальный апсайд. ## Математика «сорок часов мусора до автоматизации экономят сорок часов в неделю» Первая задача аудита - выяснить, тот ли workflow вообще предлагается автоматизировать. В сорока процентах случаев - не тот. У предлагаемого workflow есть реальная стоимость, но более крупная стоимость сидит в связанном workflow выше по потоку, или в ожидании между двумя workflow, или в переделках, причина которых - пропущенный ввод два шага назад. Поэтому стадия Cut, идущая после аудита, убирает шаги до того, как начинается автоматизация. Шаги, которых не должно быть, не кодифицируются. Аудит - это то, что делает этот срез видимым. Шире про сам шаблон билда - [«Автоматизация бизнес-процессов»](/ru/blog/business-process-automation) и [«Интеграция ИИ в бизнес»](/ru/blog/ai-integration-business). Разобранный паттерн. [Логистическая фирма](/ru/industries/logistics) пришла с задачей автоматизировать диспетчерское принятие решений. Аудит показал, что диспетчеры 60% времени тратят на выколачивание недостающих документов у водителей и только 25% - на решения, которые заменила бы предлагаемая автоматизация. Билд развернули на сбор документов со стороны водителя. Автоматизацию решений диспетчера отложили на вторую фазу - и в итоге она не понадобилась: после того как охота за документами ушла, у диспетчеров появился запас по мощности. Этот разворот и есть работа аудита. Без него билд поехал бы как изначально планировалось, диспетчеры пользовались бы инструментом вяло, узкое место осталось бы там, где было. ## Что покупает правило «не показали ROI - не строим» Три вещи, все они вниз по течению. Через полгода после запуска workflow оператор, который одобрил билд, уже не тот, кто разбирает результаты. Изначальный CEO ушёл, COO, подписавший заказ, в другой компании, head of operations новый. Математика ROI должна пережить эту смену. Подписанные консервативные вводные переживают. Маркетинговые оценки - нет. Команда, которая операционно ведёт workflow, должна доверять системе. Операторы очень быстро понимают, откажется ли поставщик от работы, которая не отбивается. Поставщики, которые отказываются, получают второй проект. Те, кто не отказывается, получают один - и потом вежливое прощание. Автоматизационная мощность компании должна копиться. Каждый запущенный workflow с честной математикой - это workflow, чьё ROI выдержит ревью бюджета. Каждый запущенный workflow с оптимистичной математикой тихо выключают, и следующий проект труднее профинансировать. Аудит - это самый дешёвый рычаг на то, согласуют ли следующие десять проектов. ## Что это значит для оператора, рассматривающего билд Три операционных следствия. Первое - закладывайте, что диагностика будет платной, что займёт пять дней и потребует реальных цифр про throughput и error rate. Цена небольшая. Изменение поведения, которое она вызывает у команды аудита, - самый большой одиночный рычаг на качестве. Второе - закладывайте реальную вероятность того, что аудит закончится No, и спросите поставщика, когда это случалось у него в последний раз. Если diagnostic-to-build conversion близка к 100%, то его диагностика - это продажи, а не диагностика. Вы хотите честный ответ, а не лестный. Третье - когда аудит заканчивается Yes, билд едет за 2-4 недели против подписанных цифр ROI, и прирост продуктивности меряется по бейзлайну, который вы подписали до начала. Прирост, померенный так, реален на workflow, которые прошли фильтр. Он не реален - ни в каком смысле, за который стоит платить, - на workflow, которые не следовало строить вовсе. Аудит - это то, что держит эту разницу видимой. Четыре вопроса, которые оператору стоит задать про любую цифру окупаемости, включая нашу, собраны в тексте [четыре вопроса, которые ломают почти любую цифру окупаемости](/ru/blog/roi-math-for-automation-projects). ## FAQ ### Если вы возвращаете депозит, когда математика говорит нет, что мешает вам просто штамповать математику? Три предохранителя. Первый - сама математика собрана с консервативными значениями по умолчанию. Time-saved берётся по 25-му перцентилю наблюдаемого диапазона недели оператора, стоимость билда - по 75-му перцентилю инженерной оценки, labor cost берётся loaded (зарплата плюс benefits плюс корректировка на utilization, а не голая часовая). Workflow обязан выйти в плюс при таких плохих допущениях, а не при оптимистичных. Второй - ROI-расчёт это подписанный артефакт. Оператор видит цифры, вводные и допущения до того, как подписан билд. Он соучастник решения, а не получатель. Третий - отклонённые задачи закрываются письменной запиской на страницу, в которой указано, какой из четырёх паттернов сработал; записка хранится и трекается. Примерно треть задач отваливается на этой стадии в среднем - это достаточно здоровая доля, чтобы фильтр действительно работал, а не симулировал работу. ### Как выглядит swimlane-карта, которую делает аудит? Картинка одного workflow на уровне передач - каждый шаг от kick-off до закрытия, каждый шаг в своей дорожке по роли, на каждой передаче проштампованы три числа: throughput в неделю, error rate (rework или коррекция), cycle time (медианное ожидание между передачами). Большинство команд никогда не видели свою собственную работу в такой форме. Карта - это то, что вскрывает узкое место, и в большинстве случаев оно не там, где думали операторы. Используем BPMN-нотацию, если команда с ней привыкла; обычные прямоугольники со стрелками - в остальных случаях. Нотация не важна. Важно, что три числа на передаче видны, и разговор о том, где автоматизировать, идёт по данным, а не по громкости голоса в комнате. Карта плюс три числа на передаче - это обычно два рабочих дня, включая интервью и наблюдение в поле. ### Что такое cost-of-chaos отчёт и как он считается? Долларовое число в неделю - сколько текущий способ ведения workflow стоит компании в потерянных часах, сверх необходимой работы. Это сумма трёх строк. Строка один - стоимость переделок: error rate на передаче умножить на медианное время переделки, умножить на throughput, умножить на loaded hourly cost роли, которая переделывает. Строка два - стоимость ожидания: медианный cycle time на передаче умножить на throughput, умножить на loaded cost того, кто простаивает (продавец, ждущий апрува по кредиту, стоит дороже, чем бухгалтер, ждущий подпись). Строка три - стоимость потерь: долларовая оценка работы, которая ушла из воронки из-за узкого места (потерянные сделки, возвраты, эскалации, закрытые скидками). У всех трёх строк есть явные вводные, все три видны в артефакте. Число консервативное, и контроллер компании подтверждает вводные. Это число, против которого считается ROI билда. ### Какие находки аудита чаще всего приводят к No? Четыре паттерна закрывают большую часть отказов. Wait-доминируется upstream - медленный шаг workflow это ожидание внешней стороны (регулятор, подпись клиента, проход платежа), и автоматизация любого внутреннего шага не двигает cycle time, потому что ожидание вне контроля компании. Mid-rewrite - команда в этот момент перестраивает процесс по несвязанным причинам (миграция ERP, реорг, новый комплаенс); автоматизировать текущий вариант - это зафиксировать процесс, которого не будет через три месяца. Adoption blocker - в workflow есть измерение доверия и контроля, которое операторы не делегируют (контроллер, апрувящий исходящий wire, доктор, подписывающий направление); автоматизация технически работала бы, но ею не пользовались бы. Volume too low - кандидатный workflow случается 8 раз в неделю, экономия 90 минут на инстанс, итого 12 часов в неделю против билда длиной 6 месяцев; даже при $120 loaded cost recovery-line не пересекается. У каждого паттерна - письменная записка, оператор видит, на что попал, и задача либо разворачивается на другой кандидатный workflow, либо закрывается. ### Почему диагностика платная? Почему не сделать аудит бесплатно как часть продаж? Сначала определение, потому что «диагностикой» здесь называют две разные вещи. Пятнадцатиминутная проверка готовности бесплатна и останется бесплатной - ей не нужно ничего, кроме разговора, и отвечает она только на вопрос, стоит ли процесс аудита. Этот вопрос про пятидневный аудит, которому нужен доступ к вашим системам и настоящим цифрам. Две причины, которые проявляются в поведении оператора, как только на столе появляются деньги. Бесплатные диагностики воспринимаются как продажные встречи - оператор присылает BD-удобного человека, доступ к настоящим цифрам остаётся закрытым, и аудит превращается в обмен сравнительными ответами для vendor selection, а не в исследование процесса. Платные диагностики воспринимаются как работа - оператор присылает реального process owner, открывает реальные системы и честно отвечает на скучные вопросы про throughput и error rate. Цена диагностики невелика (обычно 5-10% от прогнозируемого бюджета билда), но изменение поведения - самый большой одиночный рычаг на качестве аудита. Условие возврата делает цену психологически обратимой: если математика не сходится, минус оператора - потраченное время, а не наличные. Эта сделка - небольшая плата за честный доступ, с возвратом при no-build - даёт аудиты, которые реально влияют на решение, а не диагностики, которые подгоняют решение, нужное продавцу. --- # INITE Protocol: 6 этапов на реальном деплое Q2-2026 с артефактами URL: https://inite.ai/ru/blog/inite-protocol-6-stages-applied Date: 2026-05-25 Author: Михаил Савченко Category: Methodology Tags: INITE Protocol, AI Automation, Process Audit, B2B SME, ROI ## Direct Answer INITE Protocol - методология трансформации из 6 этапов: Break (неделя 1-2, диагностика), Hold (2-3, стабилизация), Track (3-4, измерение), Cut (месяц 2, упрощение), Cast (2-3, деплой 1-3 production-воркфлоу), Form (3-6, оптимизация). Первый автоматизированный процесс выходит в прод за 2-4 недели, полный цикл занимает 3-6 месяцев. Узким местом никогда не была технология - вопрос в том, найдёт ли диагностика процесс, чью автоматизацию математика делает оправданной. Если при консервативных вводных она не выходит в плюс, мы не строим, и работа заканчивается на диагностике. ## Key Facts - 6 последовательных этапов на полном цикле 3-6 месяцев: Break (неделя 1-2), Hold (неделя 2-3), Track (неделя 3-4), Cut (месяц 2), Cast (месяц 2-3), Form (месяц 3-6). Первый production-воркфлоу - за 2-4 недели. - Каждый этап обязан передать следующему именованный артефакт: Break - модель стоимости хаоса, Hold - стабилизированную карту процесса, Track - подписанный бейзлайн, Cut - журнал удалений, Cast - работающий воркфлоу, Form - дашборд мониторинга. - Этап Break имеет право закончить работу: если ROI-расчёт на консервативных вводных не выходит в плюс, депозит за диагностику возвращается и ничего не строится. - Этап Cut убирает шаги, а не кодифицирует их, и каждое удаление записывается с приложенным объёмом по шагу из Track - автоматизировать хаос это самый дорогой способ сделать медленные системы медленными навсегда. - Этап Cast поставляет 1-3 production-воркфлоу, не пилоты. На этом деплое первый воркфлоу прошёл путь от заморозки спецификации до живых лидов за 8 календарных дней. ## Что этот пост, и что - нет INITE Protocol - это методология из 6 этапов, стоящая за каждым B2B SME деплоем, который выпускает INITE. Break, Hold, Track, Cut, Cast, Form. Названия - это ярлыки этапов, и большинство читателей могут угадать смысл по слову. Что труднее передать - и что любой консалтинговый обзор методологии опускает - это что команда реально делает на каждом этапе, какие артефакты выходят и какие решения принимаются. Этот пост закрывает этот пробел. Он проводит один деплой Q2-2026 в фирме профессиональных услуг на 60 человек, двенадцать из которых - консультанты, приносящие выручку (анонимизировано; сектор, масштаб и паттерн процесса сохранены, имена и коммерчески чувствительные цифры убраны). Два production-воркфлоу выпущены за 19 календарных дней от старта Cast, против сборки в $24K. Первый год примерно выходит в ноль. Отдача сидит во втором. Такова настоящая форма первой автоматизации, и именно её большинство кейсов показывать не хочет. Каждое число ниже принадлежит одному этому проекту, и каждое выводится из другого числа на этой же странице: объёмы берутся из систем, часы - из объёмов, деньги - из часов по названной полной ставке. Там, где выгоду так посчитать нельзя, она названа и оставлена за пределами отдачи, а не оценена внутрь неё. INITE не публикует межклиентского среднего, потому что измеренного среднего не существует. Сам протокол задокументирован в `lib/brand-canonical.ts` (`whatShipped`), `locales//common/protocol.json` и HowTo JSON-LD в `components/StructuredData.tsx`. ## Этап 1 - Break (неделя 1-2): диагноз и перезагрузка Этап Break отвечает на один вопрос: есть ли здесь процесс, чья математика автоматизации выдерживает ревизию? Если да - продолжаем. Если нет - заканчиваем проект и возвращаем депозит за диагностику. **Что мы делаем.** Интервью со стейкхолдерами (CEO, COO, 1-2 операторов с переднего края - в этом случае партнёр, ведущий практику, офис-менеджер и 2 старших консультанта). Наблюдение за процессом - мы тенью ходим за реальной работой 4-8 часов на целевой воркфлоу. Выгрузка данных - мы загружаем 90 дней операционных данных из существующих систем (CRM, project tool, billing, time tracking). Базовое измерение - инструментируем текущий процесс таймингами, пропускной способностью и числом ошибок. **Произведённые артефакты.** 1. **Карта процесса с маркерами узких мест.** Swimlane-диаграмма каждого шага в целевом воркфлоу с количественной пропускной способностью, частотой ошибок и временем цикла на каждой передаче. На этом деплое мы расписали 3 воркфлоу-кандидата. **(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 в неделю**, в годовом выражении по 48 рабочим неделям, а не по 52, потому что отпуска и провальные недели автоматизацией не убираются: **$151K в год**. Это то число, с которым сверяется любое последующее утверждение. 38 часов до первого ответа и 24% лидов, оставшихся без ответа, в него не входят. И то и другое реально, и то и другое почти наверняка дороже часов, но чтобы перевести это в деньги, нужно предположить конверсию и размер сделки, а предположение - не измерение. Они остаются на странице как находки и вне отдачи. 3. **Матрица приоритетов.** Каждый воркфлоу оценён по автоматизируемости (техника, 0-100) против отдачи (бизнес, 0-100). Верх матрицы строится в Cast; низ явно откладывается. | Воркфлоу | Автоматизируемость | ROI | Решение | | --- | --- | --- | --- | | Квалификация входящих лидов | 82 | 88 | Строим в Cast (W1 в Cast) | | Обновления статуса проектов | 71 | 76 | Строим в Cast (W2 в Cast) | | Сверка инвойсов / time | 54 | 38 | Откладываем - нужны данные quality в Hold | Квалификация лидов набирает по отдаче больше, чем оправдывают её часы: это меньшая из двух строк, $1 133 в неделю против $1 647. Оценка - единственное место, где неоценённому отвалу позволено считаться, потому что матрица это ранжирование, а не сумма, а ранжирование может нести суждение. Деньги ниже не могут, поэтому тот же отвал остаётся за пределами всех цифр в остальной части поста. Сказать, что из двух происходит, - и есть вся разница между матрицей и догадкой. Третий воркфлоу на этом проекте не строится. Он задокументирован как кандидат на следующий цикл, но только после того как этап Hold подчистит проблемы качества данных, которые делают его одновременно менее автоматизируемым и менее ROI-выгодным сегодня. Честный отказ - часть методологии - мы не докладываем плохой воркфлоу, чтобы сделать проект жирнее. **Решение в конце Break.** Два воркфлоу, которые стоит строить, несут $2 780 в неделю из $3 140, то есть $133K в год. Модель заложила, что автоматизация вернёт 60% этих часов, а не все, потому что исключения остаются людям: **$70-85K в год**. Сборка оценена в $24K, мониторинг и настройка дальше - $750 в месяц. Воркфлоу выходят в конце третьего месяца, поэтому первый год собирает девять месяцев выгоды: примерно $52K против $33K затрат, чистыми около **+$19K с окупаемостью примерно на девятом месяце**. Второй год, когда остаётся только поддержка, - около +$61K. Решение: переходим в Hold. Никого в той комнате это не восхитило, и это правильная реакция и причина, по которой решение согласовали. Первая автоматизация, окупающаяся за год и дальше накапливающая, - нормальный хороший исход. Первая автоматизация, которой прогнозируют четырёхкратный возврат за двенадцать месяцев, - коммерческое предложение. Этап Break имеет право закончиться здесь отказом. Если бы арифметика на консервативных вводных не вышла в плюс - а третий воркфлоу сам по себе не выходит, - депозит за диагностику возвращается и работа прекращается. Это должно быть настоящим исходом, иначе всё измерение выше ничего не значит. ## Этап 2 - Hold (неделя 2-3): стабилизация и фикс Этап Hold отвечает: можно ли автоматизировать целевой процесс в его текущем состоянии или нужна сначала стабилизация? Автоматизация хаоса - самый дорогой способ сделать медленные системы медленными навсегда; этот этап это останавливает. **Что мы делаем.** Для каждого воркфлоу, который будет построен в Cast, мы выявляем upstream-источники данных, правила валидации и точки передачи, которые должны быть надёжны, чтобы автоматизация работала. Чиним сломанные. Документируем SOP (стандартные операционные процедуры) для ручных версий шагов, которые останутся человеческими - потому что новый автоматизированный воркфлоу всё равно будет передавать людям на краях, и человеческая сторона должна быть консистентной. **Произведённые артефакты.** 1. **SOP для ключевых воркфлоу.** На этом деплое: правила триажа писем для входящих лидов (что считается квалифицированным лидом, что эскалируется, что отбрасывается - впервые записано); шаблон обновления статуса, который команда импровизировала; требования к полям данных в CRM (какие обязательны при захвате лида и какие при конверсии). 2. **Фиксы качества данных.** В CRM было три значения lead-source, где должно было быть одно (`"website"`, `"web"`, `"Website"`). Мы их схлопнули. В project tool было 4 активных значения статуса, хотя команда пользовалась только 3. Мы убрали мёртвое. В инбоксе накопилось 14 правил входящей почты за 5 лет, половина - мёртвые. Подрезали до 6 активных. 3. **Быстрые ручные фиксы, экономящие время сразу.** Два узких места в воркфлоу квалификации лидов оказались чинимы без AI - одно было правило пересылки почты, маршрутизировавшее лиды на отпускной auto-responder; другое - баг с обязательным полем в CRM, заставлявший консультантов вводить одни и те же данные дважды. Оба пофикшены в Hold, до начала Cast. Экономия от одного только Hold составила около 6 часов в неделю на команду - небольшая победа до того, как поставлена хоть какая-то автоматизация, и эти часы сидят внутри цифр 12-й недели ниже, а не сверх них, потому что один и тот же час нельзя посчитать дважды. Hold - этап, который большинство методологий «AI-пилотов» пропускают, и именно он определяет, будут ли у итогового Cast-воркфлоу стабильные входы. LLM-воркфлоу, получающий несогласованные значения lead-source, неоднозначные статусы и письма, попавшие не в тот инбокс, будет производить мусор - и команда обвинит в этом AI. Hold обеспечивает, чтобы субстрат был чист. ## Этап 3 - Track (неделя 3-4): измерение и анализ Этап Track отвечает: как процесс реально выглядит в инструментированной проде, а не на интервью-карте, которую мы нарисовали в Break? **Что мы делаем.** Инструментируем каждый шаг воркфлоу логированием событий с таймштампами - обычно лёгким middleware, который записывает события процесса (лид получен, лид квалифицирован, лид конвертирован, обновление статуса отправлено и т.д.) с таймингом, идентичностью и исходом. Собираем 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 (автоматизируема с human-in-loop ревью), а финальная отправка клиенту - 38/100 (должна остаться человеческой, даже после AI-черновика). Track - это то, что превращает гипотезу этапа Break («этот процесс выглядит медленным и подверженным ошибкам») в спецификацию этапа Cast («у этого воркфлоу эти конкретные узкие места на этих конкретных шагах с этой конкретной формой данных»). Команда, пропускающая Track, выпускает Cast, чинящий не то. ## Этап 4 - Cut (месяц 2): упрощение и устранение Этап Cut отвечает: какие шаги в процессе вообще не должны существовать, до того как любой из них автоматизируется? **Что мы делаем.** Берём теперь-инструментированную карту процесса из Track и идём по ней шаг за шагом. Для каждого шага спрашиваем: добавляет ли этот шаг ценность или это рубцовая ткань от проблемы, которой больше нет? Устраняем те, что не добавляют. Сливаем дублирующие шаги. Переупорядочиваем шаги, где порядок произволен. Готовим вычищенный процесс как спецификацию для Cast. **Произведённые артефакты.** 1. **Оптимизированные потоки процесса.** Вычищенная версия каждого целевого воркфлоу, готовая к автоматизации. На этом деплое воркфлоу квалификации лидов уменьшился с 11 шагов до 6. Пять устранённых шагов: один дублирующий ввод данных (CRM обновлялась дважды по legacy-причинам, которые перестали быть истиной 18 месяцев назад), одно избыточное одобрение менеджера (добавлено во время прошлого инцидента с качеством, который был разрешён), два письма со статусом, которые никто не читал (мы измерили open rates - 4% и 7%), и один ручной экспорт данных, питавший отчёт, который никто больше не запускал. 2. **Устранённые избыточные шаги - счёт и категории.** По 2 целевым воркфлоу - 9 шагов устранено из 22 - 41%. Доля высокая, и причина конкретная, а не типовая: фирма не делала ревизию процессов 4 года, и рубцовая ткань накопилась. Категории: 4 дублирующих ввода данных, 2 избыточных одобрения, 2 мёртвых уведомления, 1 ручной фид в мёртвый отчёт. 3. **Спецификации, готовые к автоматизации.** Для каждого остающегося шага, который автоматизируется - письменная спецификация: форма входных данных, критерии успеха, обработка ошибок, путь эскалации, метрики мониторинга. Это артефакт, против которого строит Cast, и проверка её объёма одна: прочитает ли операционный руководитель её целиком за один присест, а не пролистает. Обе спецификации здесь эту проверку прошли. Письменные спецификации предотвращают самый частый режим отказа Cast, при котором инженерная команда строит не то, на что согласилась операционная команда в Track. Cut - этап, который большинство CTO-инициатив «давайте добавим AI» пропускают, потому что никто не хочет спорить с командой об устранении любимого шага. Мы спорим. Математика побеждает; решения об устранении записываются с пошаговым объёмом из Track в качестве доказательства. Команда, не делающая Cut, в итоге автоматизирует хаос и цементирует его. ## Этап 5 - Cast (месяц 2-3): сборка и деплой Этап Cast отвечает: попадают ли специфицированные воркфлоу в прод и выживают ли они в контакте с реальными пользователями? **Что мы делаем.** Строим каждый воркфлоу против спецификации, замороженной в Cut. Деплоим в прод - не в демо-среду, не в песочницу, в реальную среду с реальными пользователями. Прошиваем мониторинг до запуска. Интегрируем с существующими инструментами, которыми команда уже пользуется - CRM, инбокс, project tool - а не заменяем их. Для деплоев, лежащих на экосистеме Inite (см. компаньон-пост про [общий рантайм @inite/*](/ru/blog/one-engine-many-skins-inite-thesis)), этап Cast переиспользует `@inite/assistant` как LLM-раннер, `@inite/inbox` как поверхность разговоров, `@inite/api-kit` как паттерн обёртки запросов, `@inite/incidents` как путь эскалации с human-in-loop и `@inite/security` как PII-маскинг на audit log. Переиспользованная инфраструктура сжимает Cast из «строим всё» в «конфигурим большую часть и пишем доменную логику». На этом деплое воркфлоу квалификации лидов вышел за 8 календарных дней от заморозки спеки до живых лидов. **Произведённые артефакты.** 1. **1-3 автоматизированных воркфлоу в проде.** На этом деплое: (a) воркфлоу квалификации лидов живёт в CRM и почтовом ящике - 100% входящих лидов теперь идут через AI-триаж, с доступным operator-override на любом шаге; (b) воркфлоу обновления статуса проекта живёт в project tool и почте - генерирует черновики обновлений, которые консультант ревьюит и отправляет. Оба воркфлоу попали в прод в течение 19 календарных дней от старта Cast. 2. **Интеграция с существующими инструментами фирмы.** Никакого нового дашборда для команды, которому надо учиться. Воркфлоу лидов появляется как правила автоматизации и AI-генерированные комментарии внутри существующей CRM. Воркфлоу обновлений статуса появляется как черновики в существующем потоке email-compose. Ежедневные инструменты команды не изменились; AI - невидимая сантехника внутри них. Adoption - тихий убийца пилотов; сборка внутри существующего инструментария команды - это как Cast его избегает. Мы используем паттерн реестра инструментов `@inite/assistant`, чтобы экспонировать воркфлоу любому агенту, которому нужно их вызвать - включая [MCP-совместимых агентов, которыми CTO фирмы пользуется для code review](/ru/blog/mcp-skills-make-saas-ai-native). 3. **Тренинг команды и хэндовер.** Живая сессия 90 минут на воркфлоу с командой, которая будет им оперировать, плюс письменный runbook (3-5 страниц) на воркфлоу, покрывающий: как воркфлоу нормально работает, какие метрики мониторинга смотреть, что делать, когда срабатывает алерт, кто владеет воркфлоу внутри, как эскалировать к нам. Runbook - мост к Form. Cast - также этап, где [проверки готовности к browser-агентам](/ru/blog/browser-agent-ready-saas) применяются к любой operator-facing поверхности, которую экспонирует воркфлоу - потому что если AI-агент будет драйвить инструменты фирмы, чтобы помогать людям, сами инструменты должны быть читаемы агентами. Это маленькая, но всё более важная деталь в деплоях 2026. ## Этап 6 - Form (месяц 3-6): оптимизация и масштабирование Этап Form отвечает: выживает ли задеплоенный воркфлоу 12 месяцев реального использования, и накапливает ли команда способность вместо получения разового проекта? **Что мы делаем.** Наблюдаем за production-трафиком первые 90 дней. Настраиваем воркфлоу против реальных данных, не предполагаемых. Масштабируемся на дополнительные воркфлоу на той же платформе. Передаём операционное владение выявленному внутреннему владельцу. **Произведённые артефакты.** 1. **Дашборд мониторинга производительности.** Дашборд KPI из Track, теперь прошитый к production-воркфлоу и смотримый ежедневно внутренним владельцем. Замеры 12-й недели против бейзлайна, подписанного оператором в конце Track: медианное время до первого ответа на входящий лид с 38 часов до 1,4 часа; лиды без ответа за пять рабочих дней с 24% до 9%; время операционного координатора на разбор лидов с 12,5 до 3,5 часа в неделю; время консультантов на обновления статуса с 17,3 до 5,2 часа в неделю; переделка консультантами по неверно направленным лидам с 6 до 1,5 часа в неделю. Исключения по-прежнему уходят человеку, поэтому ни одна из этих цифр не падает в ноль, и поэтому предложение, обещающее ноль, стоит читать внимательно. 2. **Оптимизация на реальных данных использования.** Четыре раунда настройки в первые 90 дней. Неделя 3: классификатор слишком охотно помечал пограничные лиды неквалифицированными, поэтому порог сдвинули, и операционный координатор перестал каждое утро перепроверять отбракованное. Неделя 6: черновики читались слишком общо, поэтому добавили извлечение контекста по клиенту из project tool. Неделя 9: путь эскалации шумел настолько, что его начали игнорировать, поэтому перед ним поставили шлюз по уверенности. Неделя 12: журнал переопределений показал три типа лидов, которые никогда не должны авто-квалифицироваться, и они стали жёсткими правилами. Ничего из этого нельзя было сделать до запуска, потому что этих данных не существовало. 3. **План масштабирования на следующую волну автоматизации.** С живой платформой пропускная способность команды освобождается. Мы задокументировали 4 follow-on кандидата на следующий цикл: воркфлоу сверки инвойсов/time, отложенный в Break (теперь возможен, потому что Hold вычистил данные); автоматизация client-onboarding; ассистент написания предложений; автоматизация quarterly-business-review. Каждый оценён по той же матрице feasibility × ROI, что и в Break. Фирма выбрала 2 на Q3-2026; мы скоупим их как отдельный проект. Хэндовер - самая сложная часть Form. Внутренний владелец получает root-доступ к конфигу воркфлоу, дашборду мониторинга, реестру промптов и runbook эскалации. Мы остаёмся доступны на квартальном чек-ине первый год, но операционная ответственность - на них. Воркфлоу без выявленного внутреннего владельца с бюджетом на настройку - это те, что тихо гаснут через 6 месяцев. Мы отказываемся выпускать Cast без Form и отказываемся называть Form завершённым без внутреннего владельца. ## Сколько стоил деплой и что он произвёл | Метрика | База (Break) | Неделя 12 | Изменение | | --- | --- | --- | --- | | Медианное время до первого ответа | 38 часов | 1,4 часа | −96% | | Лиды без ответа за 5 рабочих дней | 24% | 9% | −15 п.п. | | Время координатора на разбор лидов | 12,5 ч/нед | 3,5 ч/нед | −9 ч/нед | | Время консультантов на статусы | 17,3 ч/нед | 5,2 ч/нед | −12,1 ч/нед | | Переделка по неверным лидам | 6 ч/нед | 1,5 ч/нед | −4,5 ч/нед | | Возвращённые часы по полной стоимости | - | $1 982/нед | $95K/год по 48 неделям | | Сборка плюс поддержка первого года | - | $33K | $24K сборка, $750/мес | | Чистыми год 1, выгода с 4-го месяца | - | +$38K | окупаемость на 8-м месяце | | Чистыми год 2, только поддержка | - | +$86K | - | Возвращённые часы вышли на $95K в год против смоделированных $70-85K. Это та сторона, в которую оценке и положено промахиваться, и это же причина, по которой модель закладывала возврат 60%, а не 90%. Улучшение по отвалу ни в одну из этих цифр не входит. Четверть входящих лидов, остававшихся без ответа, упавшая ниже десятой части, при размерах сделок этой фирмы почти наверняка стоит больше, чем все часы в таблице вместе взятые. Оно остаётся снаружи, потому что никто не померил, во что эти лиды конвертировались бы, а число, построенное на предполагаемой конверсии, сделало бы непроверяемой всю таблицу. Если фирма поставит на это счётчики в следующем году, оно станет измерением и войдёт внутрь. Цифры относятся к этому деплою и ни к чему больше. Опубликованного среднего INITE, с которым их можно было бы сравнить, нет, и не должно быть, пока оно не померено на выборке, которую не стыдно назвать. ## Что такое протокол в одном предложении [INITE Protocol - это то, как выглядит методология, построенная задом наперёд](/ru/protocol) из вопроса «выжил ли воркфлоу 12 месяцев реального использования?». Break / Hold / Track обеспечивают, что математика реальна. Cut обеспечивает, что субстрат стоит автоматизации. Cast выпускает production-grade софт против чистого процесса. Form делает изменение устойчивым. Пропуск любого из шести - это как умирают деньги AI-консалтинга. Следование всем шести - это как воркфлоу продолжает работать в следующем квартале после нашего ухода. Если ваша математика выжила в Break, ваша команда владеет Form. Всё между - это инженерия. ## FAQ ### Почему 6 этапов, а не просто «аудит, потом разработка»? Потому что «аудит, потом разработка» - самый дорогой способ провалиться. Два режима отказа повторяются каждый раз: (1) аудит находит реальное узкое место, но выбранная автоматизация его не чинит, потому что процесс недетерминированный выше по потоку - мы автоматизируем симптом, и узкое место смещается; (2) разработка поставляет работающий софт, которым никто не пользуется, потому что процесс вокруг него не изменился, и у команды нет причин переключаться. 6 этапов предотвращают оба. Break / Hold / Track создают измеренную базу. Cut устраняет шаги, которых не должно быть, до того как автоматизация их зацементирует. Cast поставляет production-grade софт против чистого процесса. Form делает изменение устойчивым. Пропуск любого из 6 - это размен краткосрочной скорости на долгосрочную уверенность, что воркфлоу тихо забросят через 6 месяцев. ### Что реально производит этап 1 - Break? Три артефакта. (1) Карта процесса с маркерами узких мест - обычно swimlane-диаграмма каждого шага в целевом воркфлоу с количественной пропускной способностью, частотой ошибок и временем цикла на каждой передаче. Мы используем нотацию BPMN, если команда её уже знает; иначе - обычные прямоугольники со стрелками. (2) Отчёт о стоимости хаоса - долларовая стоимость часов, теряемых в неделю на ручные переделки, упущенные передачи и ожидания. Это число, против которого позже измеряется ROI. (3) Матрица приоритетов - каждый кандидат-воркфлоу проранжирован по автоматизируемости (техника) × ROI (бизнес). Верх матрицы строится в Cast; низ явно откладывается. Если ни один кандидат не имеет положительного ROI даже на консервативных допущениях по сохранённому времени, мы заканчиваем проект и возвращаем деньги за диагностику, и этот исход должен быть доступен, иначе два других артефакта ничего не значат. ### Чем этап 5 - Cast отличается от типового «AI-пилота»? Тремя вещами. (1) Выход - это 1-3 воркфлоу в проде, а не демо-среда - та же auth, те же данные, те же операторы, тот же SLA, что и у остального стека компании. (2) Каждый воркфлоу поставляется с мониторингом, прошитым до запуска - латентность, частота ошибок, частота вмешательств (как часто нужен ручной override) и KPI на воркфлоу из этапа Cut. Мы отслеживаем это с первого дня, а не после того, как уляжется пыль запуска. (3) Сборка сидит поверх существующих инструментов, которыми команда уже пользуется - мы прошиваем AI в CRM, инбокс, таблицу, чат-инструмент - мы их не заменяем. Adoption - тихий убийца пилотов; сборка внутри существующего инструментария команды - это как Cast его избегает. ### Что происходит на этапе 6 - Form, чего нет на этапе 5 - Cast? Cast выводит воркфлоу в прод. Form делает так, чтобы он выжил 12 месяцев. В Form происходят три вещи. (1) Настройка против реальных данных использования - промпты, пороги извлечения, правила эскалации и логика маршрутизации корректируются по тому, как выглядит production-трафик, а не по тому, что предполагала спецификация. Обычно 3-5 раундов настройки в первые 90 дней. (2) Масштабирование на следующие 1-2 воркфлоу на той же платформе - второй воркфлоу занимает примерно 40% времени первого, потому что инфраструктура (auth, мониторинг, agent runtime, реестр промптов) переиспользуется. (3) Хэндовер с документацией, runbooks и выявленным внутренним владельцем - мы не долгосрочный оператор воркфлоу; команда - да. Form - это то, что превращает деплой в способность, а не в разовый проект. Пропуск Form - это как воркфлоу тихо выключают через 6 месяцев, когда уходит изначальный чемпион. ### Как протокол взаимодействует с более широкой экосистемой вертикального AI Inite? Протокол с виду продукт-агностичен - Break / Hold / Track / Cut / Cast / Form работали бы для любого B2B-проекта автоматизации. На практике, когда деплой ложится на экосистему Inite (общий рантайм @inite/*, описанный в компаньон-посте про тезис), временные стоимости значительно сжимаются: этап Cast переиспользует @inite/assistant как LLM-раннер, @inite/inbox как поверхность разговоров, @inite/api-kit как паттерн обёртки запросов и @inite/incidents как путь эскалации с human-in-loop. Воркфлоу, который с нуля заняла бы 3 недели, обычно выходит за 8 календарных дней, когда сидит на общем рантайме. Протокол остаётся тем же; субстрат - это то, что делает Cast дешёвым. ### Что значит на практике «если мы не можем показать ROI - мы не строим»? Это правило, определяющее компанию. До начала любой сборки этап Break производит письменную оценку ROI с тремя входами: сэкономленное время на инстанс процесса × инстансы в неделю × нагруженная стоимость труда в час, минус полная стоимость сборки за 12 месяцев (инженерия, мониторинг и настройка). Если это число неположительно при консервативных допущениях (мы используем оценку 25-го перцентиля для сэкономленного времени и 75-го перцентиля для стоимости сборки), проект заканчивается на диагностике, и мы возвращаем депозит. Дело не в придирчивости - дело в том, чтобы у каждого выпущенного воркфлоу была математика, выдерживающая ревизию через шесть месяцев, когда исходный CEO, подписавший проект, ушёл, а новый операционный директор спрашивает, во сколько эта штука обходится. --- # Одно ядро, восемнадцать записей в реестре и одна в проде URL: https://inite.ai/ru/blog/one-engine-many-skins-inite-thesis Date: 2026-05-18 Author: Михаил Савченко Category: Architecture Tags: Architecture, Multi-tenant, Strategy ## Direct Answer Наши отраслевые продукты стоят на одном основании: пять обязательных сущностей, девятнадцать пакетов-возможностей и три сервиса - вход, счета и ассистент. Написано один раз, под отрасль не переписывается. Заново идёт только предметная область, и доля её больше, чем принято думать: в CRM проката на 318 757 строк отраслевыми были 88% схемы данных, а между двумя нашими продуктами соседних отраслей совпали 7 бизнес-понятий из 113. В реестре сейчас 18 записей, из них 1 в проде и 2 в пилоте. Мы публикуем реестр статусов, а не счётчик продуктов, потому что ошибиться заметно может только второй. ## Key Facts - В реестре 18 записей, из них 1 в проде и 2 в пилоте, а статуса полного соответствия спецификации не имеет ни одна. - Обязательных сущностей 5: пользователь, компания, роль между ними, ключ доступа и переопределение прав для одной компании. - Пакетов-возможностей 19, горизонтальных сервисов 3: вход, счета и ассистент. - В CRM проката на 318 757 строк отраслевыми оказались 1650 строк схемы из 1872, то есть 88%. - Из 113 бизнес-понятий двух наших продуктов соседних отраслей общими оказались 7, около 6%. ## Что стоит под всеми продуктами сразу [В любой системе, где есть сотрудники и клиенты, повторяется одно и то же](/ru/industries). Кто-то входит под своей учётной записью. У него есть роль. Роль что-то разрешает и что-то запрещает. Кому-то уходят уведомления, кому-то выставляется счёт, переписка лежит в одном месте и находится поиском, а журнал помнит, кто что менял. Это пять обязательных сущностей - пользователь, компания, роль между ними, ключ доступа и переопределение прав для отдельной компании, - девятнадцать пакетов-возможностей и три сервиса: вход, счета и ассистент. Написано один раз, не переписывается ни под одну отрасль. Пятая сущность появилась не из проекта, а из случая. В прокате управляющему филиала понадобился доступ к отчётности для совладельцев парка, а обычная роль управляющего его не даёт. Таблица ролей этого выразить не могла. Повод был отраслевым, решение оказалось общим, и теперь его наследуют все. ## Сколько на самом деле переносится Здесь принято называть большую долю. Мы измерили дважды, и обе цифры оказались неудобными. CRM проката, которую мы перевели на общее основание, - это 318 757 строк и четыре года накопленных правил. Из 1872 строк схемы данных отраслевыми оказались 1650, то есть 88%. Общей обвязкой были 220 строк. Второй замер жёстче. Мы построили платформу аренды, потом платформу недвижимости. Отрасли соседние, обе про объект, который кому-то передают на время или навсегда. Из 113 бизнес-понятий двух продуктов общими нашлись семь. [Около 6%](/ru/blog/inite-estate-real-estate-vertical), и разбор этой цифры стоит отдельного чтения. Отсюда следствие, полезное далеко за пределами нашей кухни. «У нас такое уже есть, останется настроить» - фраза про обвязку, а не про ваш бизнес. [Откуда берутся четыре недели](/ru/blog/4-week-vertical-cloning-playbook) разбирает то же самое со стороны того, кто выбирает подрядчика. ## Чем это подтверждено Перевод проката занял четыре недели, операторы работали в перестроенном приложении с третьей и вели через него настоящие брони. Узким местом были не сроки разработки. Трижды выходило так, что настоящие данные проката противоречили спецификации основания, и каждый раз мы переписывали спецификацию, а не данные. Основание, которое не выдерживает контакта с четырёхлетним работающим продуктом, ещё не основание. Один побочный результат оказался важнее запланированных. Бизнес-правила вроде «нет выдачи машины, пока договор не подписан и залог не внесён» мы вписали прямо в тот слой, который вызывают внешние ИИ-агенты. Теперь агент не может обойти правило, даже не зная о его существовании: слой возвращает отказ с указанием на нарушенное условие. Каждый следующий продукт получает это даром. ## Табло, без прикрас | Статус | Штук | | --- | ---: | | В проде | 1 | | Пилот | 2 | | Ждут миграции | 4 | | Расходятся со спецификацией | 4 | | Не приведены к основанию | 2 | | Названы, не начаты | 3 | | Заменены другими | 2 | | **Полное соответствие спецификации** | **0** | Восемнадцать записей. Одна в проде. И статуса, который спецификация назначила целью, нет пока ни у одной. Счётчик продуктов - маркетинговое число, реестр статусов - инженерное, и ошибиться заметно может только первое. «Восемнадцать продуктов на общем основании» переживёт любое расхождение под собой. «Одна в проде, ноль в полном соответствии» создаёт работу. Тем, кто строит семейство продуктов у себя, отсюда переносится не наш код, а привычка: решить до первого продукта, какому слою разрешено иметь мнение, поставить общее основание под версию и вести реестр честно - настолько честно, чтобы на него было неприятно смотреть. Реестр, от которого никто не морщится, никто и не обновляет. Как это выглядит со стороны заказчика, а не разработчика, разобрано в [сроках внедрения](/ru/blog/what-to-automate-first-in-a-small-company). ## FAQ ### Что именно общее, а что пишется каждый раз заново? Общее - то, что устроено одинаково в любой системе, где есть сотрудники и клиенты: кто вошёл под своей учётной записью, какая у него роль, что роль разрешает и запрещает, кому уходят уведомления, кому выставляется счёт, где лежит переписка и кто что менял. Сюда же шифрование персональных данных и переводы. Ничего из этого не зависит от того, сдаёте вы экскаваторы или продаёте квартиры, поэтому пишется один раз. Заново пишется предметная область: объекты отрасли и правила перехода между этапами. У проката это единица техники, бронь и отгрузка. У агентства недвижимости это объект, объявление и сделка. Слова похожи, правила внутри разные, и время стоят именно правила. ### Насколько велика доля, которую приходится писать заново? Больше, чем ожидают почти все, включая нас самих в начале. Две цифры, обе измеренные. Первая: в CRM проката, которую мы перевели на общее основание, из 1872 строк схемы данных 1650 оказались отраслевыми, то есть 88%, и только 220 строк были той обвязкой, которую даёт основание. Вторая жёстче: когда мы построили второй продукт в соседней отрасли, из 113 бизнес-понятий двух продуктов общими оказались семь. Около 6%. Отсюда простое следствие для любого, кто выбирает подрядчика: фраза «у нас такое уже есть, останется настроить» описывает обвязку, а не ваш бизнес. Разбор второго случая мы вынесли отдельно, потому что цифра там неудобная и заслуживает подробностей. ### Зачем вообще строить общее основание, если переносится так мало? Потому что экономия приходит не оттуда, где её ищут. Прежде чем новый продукт сможет заняться своей отраслью, ему нужны входы, компании, роли и права, счета, подключённые к настоящему платёжному провайдеру, приём сообщений от клиентов, уведомления, переводы, журнал изменений и шифрование персональных данных. В первый раз этот список занимает месяцы, он одинаков для любой отрасли, и любая незаметная ошибка в нём всплывает не на демонстрации, а на аудите безопасности. Построенное однажды, оно позволяет следующему продукту начинаться там, где начинается собственно бизнес. Отраслевые правила в любом случае были бы разными, и выигрыша там никогда и не было. ### Почему вы публикуете реестр статусов, а не число продуктов? Потому что счётчик продуктов - маркетинговое число, а реестр статусов - инженерное, и ошибиться заметно может только первое. Фраза «восемнадцать продуктов на общем основании» переживёт любое расхождение под собой: она остаётся верной, пока хоть что-то работает. Строка «одна в проде, две в пилоте, полного соответствия спецификации нет ни у одной» создаёт работу, потому что каждый статус кто-то должен сдвинуть. Реестр ведётся руками и обновляется на каждом релизе спецификации ровно затем, чтобы не сползти тихо к первой формулировке. Отсюда же правило держать репозиторий спецификации свободным от исполняемого кода: спецификация, которая поставляет рантайм, перестаёт быть проверяемой хоть по чему-нибудь. --- # SaaS, готовый к браузерным агентам: Operator и Claude Computer Use 2026 URL: https://inite.ai/ru/blog/browser-agent-ready-saas Date: 2026-05-11 Author: Olga Fedotova Category: Agentic Engineering Tags: Browser Agents, Operator, ChatGPT Agent, Computer Use, Accessibility ## Direct Answer SaaS, готовый к браузерным агентам, - тот, где Operator, ChatGPT Agent и Claude Computer Use без вмешательства человека проходят основные сценарии (войти, найти, заполнить форму, оплатить, забрать результат). Пять обязательных требований: (1) стабильные селекторы, которые переживают редеплой; (2) поля форм с осмысленными name/label/autocomplete; (3) отсутствие стен из Cloudflare Turnstile / hCaptcha на read-flows; (4) понятные тексты ошибок, по которым агент может скорректировать ввод; (5) манифест в духе llms.txt со ссылками на action-API. Сайты, которые этим требованиям не отвечают, агент бросает за 60-90 секунд. ## Key Facts - Computer-Using Agent - модель, на которой работает Operator, - набирает 58,1% на WebArena и 38,1% на OSWorld; человеческий baseline на WebArena - около 78%. - Claude 4.5 Computer Use показывает 87,4% на бенчмарке OSWorld, если у форм есть атрибут autocomplete, и 52,1% - если его нет. - Проверка, которую агент не может пройти, обрывает сессию: сам Cloudflare советует включать challenge по риску, а не сплошняком, потому что опознанный агент и скрейпер - это разные посетители. - Страницы со стабильными `data-testid` или `aria-label` дают в 3,4 раза более высокий процент выполнения агентских задач, чем идентичные страницы с хешированными именами CSS-классов. - К апрелю 2026 года 14% регистраций на отслеживаемых SaaS-сайтах пришли из агентских сессий (по сравнению с 0,3% в апреле 2025-го). В 2026 году ваш покупатель - это не всегда тот, кто кликнул на ваш баннер. Это может быть агент, которому он делегировал задачу. OpenAI Operator в I квартале 2026-го забронировал 1,2 миллиона ночёвок в отелях. Claude Computer Use оформляет триал в B2B SaaS. ChatGPT Agent заполняет государственные формы. Browser Use лежит в основе автоматизации каждого соло-фаундера. Каждый из них - это LLM с компьютерным зрением, открывающий ваш сайт в настоящем Chromium, смотрящий на экран, принимающий решение и переписывающий действие при ошибке. Они доходят до конца там, где страница семантически читаема, и бросают там, где нет. Разрыв между «agent-friendly» и «agent-hostile» в 2026-м - это тот же разрыв, который в 2010-м решал мобильную совместимость, а в 2018-м - доступность: уже не роскошь, а новый сегмент клиента. Это аудит-лист 2026 года. ## Как агент видит страницу Три режима восприятия, в зависимости от агента: 1. **Чистое зрение** (базовый Operator, дефолт Browser Use): агент делает скриншот и спрашивает модель: «куда кликнуть, чтобы сделать X?». Главный ключ - координаты. 2. **Зрение + дерево доступности** (Claude Computer Use, ChatGPT Agent): агент видит и пиксели, и разобранное ARIA/role/label-дерево. Надёжность кратно выше, потому что модель может целиться по имени. 3. **DOM tap** (новые сборки Operator, dom_mode у Browser Use): агент читает отрендеренный DOM, извлекает обогащённое представление (селектор + роль + bbox + предки) и принимает решение по структурированным данным. Выбирать режим за посетителя нельзя. Поэтому проектировать надо под третий (самый требовательный) - первые два получат бонус автоматически. ## Пять требований ### 1. Стабильные селекторы Каждый интерактивный элемент, который вам важен, получает атрибут `data-testid` или `data-agent-action`. Значение переживает редеплой, ребрендинг и обновление tailwind. Работает: ```html Корзина (3) ``` Не работает: ```html …
…
``` Если ваш стек CSS-in-JS отдаёт хешированные имена классов, селектор после deploy-N и после deploy-N+1 - разные строки. Плейбук агента (написанный какой-то LLM-моделью с семидневным cut-off-датасетом) ломается при каждом редеплое. `data-testid` инвариантен по соглашению. ### 2. Семантические атрибуты в формах Каждый input получает как минимум `name`, `id`, `type`, `autocomplete` и связанный с ним `