# INITE AI — Full Content Dump > Turn chaos into profit with AI automation INITE AI automates operations with AI: we deploy 1-3 workflows in production in 2-4 weeks. Productivity gains 40-60%, ROI in 3-6 months. We start with diagnostics; if we cannot show ROI we do not build. Source URL: https://inite.ai Locale: ru Generated: 2026-08-15T21:26:27.160Z --- # Что изменило решение по делу 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. Знакомство с товаром переехало в ассистента, а сделка вернулась на сайт продавца. Оба события указывают в одну сторону. Покупка внутри ассистента проиграла, а собственный агент клиента, работающий с сайтом продавца, только что прошёл первую апелляционную проверку. Значит, важнейшей поверхностью становится собственный чекаут продавца, и полностью этот довод изложен в посте [агентная коммерция после 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 признака указывают, что срок будет больше: неописанный процесс, решения по ситуации, нечитаемые данные и требование, которого нет ни у кого. ## Почему само по себе число ничего не говорит Вам называют две-четыре недели. То же число вы услышите от всех остальных. Само по себе оно не значит ничего, потому что срок держится не на скорости, с которой пишут код, а на объёме работы, которую в вашем проекте делать не будут. Спрашивать имеет смысл именно про этот объём. ## Что вы не оплачиваете В любой системе, где есть сотрудники и клиенты, устроено одинаково: кто-то входит под своей учётной записью, у него есть роль, роль что-то разрешает и что-то запрещает, кому-то уходят уведомления, кому-то выставляется счёт, а вся переписка должна лежать в одном месте и находиться поиском. Это не имеет никакого отношения к тому, сдаёте вы экскаваторы или записываете на физиотерапию. Написано это один раз, отлажено на прошлых внедрениях и не занимает у вас ни одной недели. Есть одно исключение, о котором стоит знать, даже если строить будете не вы. Разделение между клиентами закладывается первым или не закладывается никогда. Достраивание его задним числом в систему, которая изначально предполагала одного заказчика, - самая дорогая переделка в этом деле, и именно она превращает четырёхнедельный проект в трёхмесячный. ## Что придётся построить в любом случае Остаётся то, ради чего вы и обращались: ваши объекты и ваш процесс. У проката это единица техники, бронь и отгрузка. У агентства недвижимости это объект, объявление и сделка. Со стороны звучит как одно и то же, а внутри общего почти нет. Мы это измерили на себе, и цифра оказалась неудобной. Сделали платформу аренды, потом платформу недвижимости. Отрасли соседние, обе про объект, который кому-то передают на время или навсегда. Из 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: Михаил Савченко Category: Comparison Tags: Comparison, Operations, Procurement, Automation ## Direct Answer Для одного понятного процесса с назначенным владельцем внутри компании фрилансер обычно правильный выбор и часто заметно более дешёвый. Агентство отрабатывает свою наценку на трёх вещах: работа задевает несколько систем и потому несколько навыков, поставка обязана пережить недоступность одного человека, и есть обязательство продолжать после передачи. Сравнивают первым делом дневную ставку, а она в этом сравнении решает меньше всего. Исход определяет то, кто отвечает на четвёртый месяц, когда интеграция сменила формат, а построивший её человек уже занят другим. ## Key Facts - Внедрение одного процесса это форма работы, где фрилансер конкурирует сильнее всего, и примерно так выглядит 1 из тех 1-3 процессов, что мы выводим в прод за проект. - Наше окно поставки составляет 2-4 недели на проект, и этого достаточно мало, чтобы риск непрерывности собирался после сдачи, а не во время стройки. - Окупаемость таких работ обычно наступает через 3-6 месяцев, то есть после того момента, когда договор с фрилансером как правило уже закончился. - На 200+ внедрённых процессах в 50+ компаниях прирост эффективности на автоматизированной части составляет 40-60%. ## Дневная ставка это неправильное первое сравнение Обычно такое решение начинается с двух чисел рядом, одно заметно меньше другого, и заканчивается разговором о том, оправдано ли большее. Дневная ставка решает в этом сравнении меньше всего. Построить процесс, как правило, могут обе стороны. Различает их то, что эта штука делает на четвёртый месяц, когда поставщик сменил форму, канал сменил интерфейс, а объём удвоился, и допущение, работавшее на пятидесяти заказах в день, перестало работать на ста. ## Где фрилансер выигрывает прямо Один процесс. Систем мало, все описаны. Внутри компании есть человек, который примет результат и сможет его менять. При этих трёх условиях вы покупаете стройку, а не отношения. Задание записывается полностью до начала, координация, которую несёт агентство, не делает никакой работы, а разница в цене велика и реальна. Хороший фрилансер часто окажется ещё и быстрее, потому что в команде из одного нет внутренних передач. Такая форма встречается чаще, чем подрядчикам приятно признавать. Если ваша автоматизация это один понятный процесс, честный совет звучит так: соберите предложения от частных исполнителей. ## Где наценка действительно отрабатывается | Что нужно | Фрилансер | Агентство | | --- | --- | --- | | Один процесс, системы описаны | Отличное попадание | Избыточная квалификация | | Четыре системы, четыре навыка | Зависит от человека | Попадание по устройству | | Фиксированная дата под сезон | Единственная точка отказа | Поглощает отсутствие | | Ответственный на четвёртый месяц | Личное обещание | Договорное обязательство | | Готовность сказать «не надо строить» | По-разному | По-разному | Последняя строка намеренно оставлена без разрешения, потому что размер компании о ней не говорит ничего. Агентство, чья диагностика всегда приходит к необходимости собственного продукта, хуже фрилансера, который говорит правду, и обратное встречается ровно так же часто. Непрерывность это та строка, которую недооценивают, а потом жалеют. Стройка занимает 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 недели, и этот проект пришёлся на короткий край диапазона. - На 200+ внедрённых процессах в 50+ компаниях прирост эффективности на автоматизированной части составляет 40-60%. ## Своих чисел не знает никто Прокатная компания, с которой мы работали, описывала проблему точно. Брони обрабатывали руками, доступность жила в таблицах, договоры собирали по одному, водителей организовывали по телефону. Пиковый сезон означал потерянные брони и овербукинг. Всё в этом описании было правдой. И ничто из него не было измерением. Поэтому первая неделя проекта не произвела ни строчки кода. Она произвела подсчёт, сделанный по системам, которые у бизнеса уже были, о том, насколько велика каждая часть проблемы на самом деле. Из-за этой недели внедрение заняло три недели, а не шесть, потому что из состава работ ушли две вещи, которые все считали центральными. ## Что выгрузили Две отметки времени по каждой брони за полный пиковый месяц: когда пришла заявка и когда подтвердили отгрузку. Дальше три счётчика, которые отметками времени не являются. - Заявки, пришедшие вне рабочих часов - Заявки, на которые не ответили вообще - Случаи, когда физически стоящая на площадке машина числилась недоступной Ничего из этого не потребовало новых средств измерения. Потребовался человек, который выгрузит уже записанное и посчитает не отводя глаз. ## Самым бесполезным числом было среднее Путь от брони до отгрузки в среднем занимал около четырёх часов, и именно это число попало во все последующие описания проекта, включая наши. Оно же меньше всего пригодилось при определении состава работ. | На что смотрели | Что это сказало | | --- | --- | | Среднее время до отгрузки | Проблема существует | | Распределение этого времени | Где лежат деньги | | Доля пришедших вне часов | Почему хвост длинный | | Заявки без ответа | Что терялось молча | | На площадке, но недоступна | Виновата ли модель данных | Большая часть броней двигалась с приемлемой скоростью. Меньшая ждала намного дольше, чем подсказывало среднее, и именно в этом меньшинстве клиенты переставали ждать и звонили конкуренту. Улучшение среднего хорошо читалось бы в отчёте и коммерчески не изменило бы ничего, потому что ушедшие клиенты никогда не были в середине распределения. Это обобщается далеко за пределы проката. Среднее чаще прочих чисел доживает до коммерческого предложения и реже прочих указывает на настоящее ограничение. ## Две вещи, которые ожидались важными и выпали Первой был недельный объём броней. Годовая цифра сглаживала сезон, зарабатывающий большую часть года за несколько недель, и определение состава работ по годовому числу дало бы систему, рассчитанную на нагрузку, которой она не видит в тот момент, когда это важно. Второй была подготовка договоров. Она была реальной, была муторной и не была ограничением. Сборка документов действительно медленная работа, и её автоматизация экономит ровно те минуты, которые она занимает, а это малая доля четырёх часов. Она осталась в составе работ, потому что стоит дёшево, когда остальное уже есть. Она перестала быть причиной делать проект. Вывод обеих с критического пути и есть основная причина, по которой проект уложился в 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 оставляют машину физически на площадке и всё равно недоступной для аренды. - На 200+ внедрённых процессах в 50+ компаниях прирост эффективности на автоматизированной части составляет 40-60%. ## Четыре часа никогда не были одной задачей Спросите координатора проката, сколько времени проходит от заявки до выехавшей машины, и услышите пожатие плечами и число. Часа четыре, обычно. В июле дольше. Разложите эти четыре часа, и работой окажется почти ничего. Заявка приходит, в одно из четырёх или пяти мест. Кто-то открывает таблицу доступности. Кто-то другой должен подтвердить, что машина, которую ждали вчера, действительно вернулась. Договор собирают из последнего похожего. Подпись выпрашивают. Водителю звонят, а водитель на выезде. Каждый шаг забирает несколько минут чьего-то внимания. Четыре часа это промежутки между ними, ожидание, когда освободится следующий человек. От этого различия зависит, сколько стоит проект автоматизации. Автоматизация шагов экономит минуты, а минуты никогда и не были проблемой. Разрыв закрывает автоматизация передач, и именно она увела одну компанию с четырёх часов до трёх минут. ## Двойная бронь это проблема одновременного доступа Овербукинг принято считать невнимательностью, поэтому обычное лекарство от него это просьба быть внимательнее. Оно не работает, и понять почему стоит до того, как что-то покупать. У общей таблицы нет блокировок. Два координатора открывают её в 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, а значит интеграция, которую вы можете построить, делается против открытой спецификации, а не против продуктового решения одной компании. Покупатель на месте. Люди спрашивают ассистента, что купить, сравнивают варианты в разговоре и приходят на сайт продавца с почти готовым решением. От того, где вводились данные карты, это никогда не зависело. И работа по-прежнему ваша. Выбор происходит у ассистента, оплата на вашем сайте. То есть ответственность приземлилась ровно туда, где была до того, как её пообещали забрать. ## Чего это требует от вас Ассистент никогда не видит вашего дизайна. Он читает ваши факты, и всё, чего он не может уверенно утверждать, он молча выбрасывает из сравнения. Работа получается конкретная: - **Факты в машиночитаемом виде.** Цена, наличие, варианты, размеры, материалы, срок доставки, условия возврата. На странице, в структурированных данных, а не только в вёрстке и уж точно не только на сфотографированном листе спецификации. - **Наличие, которое правдиво прямо сейчас.** Рекомендация, приводящая на страницу «нет в наличии», стоит и этой продажи, и следующего сравнения. - **Скучные предпокупочные ответы обычным текстом.** Размеры, совместимость, комплектация, порядок возврата. Ассистенты читают страницы, а не виджеты чата и не 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: Михаил Савченко Category: Operations Tags: Safe AI, автоматизация, операции, управление ## Direct Answer Safe AI в работающем внедрении сводится к небольшому набору правил о том, где остаётся человек. У нас их четыре. Ничто обязывающее компанию (цена, обещанный срок, условие договора) не уходит наружу без подтверждения человеком. Всё, в чём система не уверена, попадает к человеку вместе с полной перепиской, а не отдельной задачей без контекста. Документы система собирает из утверждённых шаблонов и проверенных данных, формулировок она не сочиняет. Каждое автоматическое решение записывается в виде, который потом можно проверить. Где именно проходит линия подтверждения, решается по каждому процессу и по юрисдикции на диагностике: клинике в одной стране и брокериджу в другой нужны разные ответы. ## Key Facts - В проекте для клиники приём пациента сократился с 45 минут до 8, при этом каждое клиническое решение осталось за врачом. - Брокеридж уронил первый ответ с 6 часов до 8 минут, а подготовку документов с 2 дней до 20 минут, и всё уходящее наружу по-прежнему подтверждал человек. - На 200+ выкаченных процессах в 50+ компаниях эффективность на автоматизированной части составляет 40-60%. - Мы выводим 1-3 процесса в прод за 2-4 недели, и маршрут эскалации проектируется в те же 2-4 недели. - Неявки в клинике упали на 40%, и напоминания для этого не требуют вообще никакого подтверждения. ## Вопрос, который стоит за словами «это безопасно?» Оператор задаёт его в той или иной форме перед подписью, и он почти никогда не означает того, на что отвечает подрядчик. Подрядчик слышит «будет ли модель галлюцинировать» и начинает рассказывать про точность. Оператор имеет в виду вещь гораздо более узкую и практическую: что эта штука может решать без меня? Это вопрос проектирования, у него есть письменный ответ, и на один процесс он занимает примерно час. Ниже наш ответ, изложенный четырьмя правилами вместо набора принципов. Принцип нельзя проверить во вторник днём, а правило можно. ## Правило первое: ничего обязывающего без человека Цена. Дата поставки. Условие. Документ, который суд прочитает как обязательство. Всё это останавливается на человеке. Это правило переживает встречу с юристами, и оно же самое дешёвое, потому что обязывающий шаг занимает малую долю любого процесса. В проекте для брокериджа ИИ отвечал первым, квалифицировал обращение, собирал пакет документов и направлял нужному агенту. Первый ответ упал с 6 часов до 8 минут, подготовка документов с 2 дней до 20 минут. У всего, что уходило наружу, по-прежнему стояло имя человека, принявшего решение. Шесть часов были очередью. Никто не думал шесть часов, обращение лежало в почте. Автоматизация очень хорошо убирает ожидание, перепечатывание и поиск, и очень плохо несёт ответственность. Разделение этих двух вещей и есть большая часть проектирования. ## Правило второе: исключение приходит вместе с контекстом Любая система, поднимающая сомнительные случаи к человеку, по замыслу тратит его время. Переменной остаётся форма, в которой эскалация приходит. Эскалация с текстом «требуется проверка» заставляет согласующего сначала собрать всю картину заново и только потом решить, и эта пересборка обычно длиннее самого решения. Эскалация, пришедшая с полной перепиской, использованными данными и указанием, в чём именно система засомневалась, превращает пятиминутную пересборку в тридцатисекундное суждение. Это важно финансово, а не только эргономически. Доля эскалаций, умноженная на время согласующего, - это ежемесячный расход навсегда, и место ему в [арифметике до подписи](/ru/blog/roi-math-for-automation-projects), а не в открытии на третьем месяце. ## Правило третье: система собирает из готового Во всём договорном ИИ работает с шаблонами, которые вы утвердили, и с данными, которые прошли проверку. Он заполняет, выбирает, компонует. Новых формулировок он не пишет. Это обещание уже, чем «ИИ пишет вам договоры», и юридическая проверка получается от этого короткой. Проверяющий, который смотрит, тот ли утверждённый шаблон взят и те ли проверенные данные в него подставлены, делает быструю работу с понятными границами. Проверяющий, который ищет в сгенерированном абзаце незапланированное обязательство, делает медленную работу без границ. Та же логика покрывает регулируемое содержание вообще: административная работа идёт сама, профессиональное суждение не идёт. В проекте для клиники приём пациента сократился с 45 минут до 8, неявки упали на 40%, административной бумажной работы стало меньше на три четверти. Каждое клиническое решение осталось за врачом, и ничему в системе не было позволено выглядеть похоже. ## Правило четвёртое: каждое автоматическое решение остаётся в записи Если система решила что-то сама, есть запись: что решила, на каких входных данных и когда. Читают её редко, но вопросы, которые в итоге задают, всегда обращены назад. Почему это предложение ушло с такой цифрой. Когда мы начали так делать. Покажите десять случаев до жалобы. Журнал заодно оказывается тем самым доказательством, которое просит регулируемый рынок, и поэтому [разговор про комплаенс](/ru/blog/ai-ethics-responsible-ai) идёт легче, когда операционная схема была сделана первой. Документация, описывающая систему, которая и так ведёт себя правильно, честна. Документация, описывающая систему, которую никто не ограничивал, является декларацией с обложкой. ## Где проходит линия Универсального ответа нет, и подрядчик, предлагающий такой ответ, продаёт плакат. | Тип решения | Идёт само | Требует человека | | --- | --- | --- | | Напоминания, расписание, маршрутизация, справки | Да | Нет | | Квалификация и сортировка обращений | Да, с записью | Нет | | Всё, где есть цена, обещание или договор | Нет | Всегда | | Профессиональное суждение в регулируемой области | Нет | Всегда, поимённо | | Серая середина | Решается по процессу | Решается по юрисдикции | Серая середина и есть настоящая работа, и она закрывается на [диагностике](/ru/blog/process-audit-before-automation) вместе с теми, кто несёт ответственность, до того как что-то построено. Клиника и брокеридж в одной стране проведут линию по-разному. Та же клиника в двух странах проведёт её по-разному ещё раз. Записанная до запуска, эта линия называется проектом. Восстановленная потом по тому, что система успела сделать, она превращается в разбор инцидента. ## Чего у нас нет Мы не публикуем нумерованный список принципов, и этот текст таким списком не является. Есть четыре правила выше, применённые на 200+ выкаченных процессах в 50+ компаниях, с линией, которую переставляют по каждому процессу на диагностике. Если это звучит менее внушительно, чем фреймворк из шести столпов, так и задумано. Полезное свойство правила в том, что во вторник кто-то может проверить, соблюдалось ли оно, и рассказать вам, что произошло, когда оно не соблюдалось. ## 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 месяцев. - На 200+ выкаченных процессах в 50+ компаниях прирост эффективности на автоматизированной части составляет 40-60%. ## Цифра в предложении - это прогноз Любое предложение по автоматизации заканчивается цифрой. Сорок часов в неделю. Окупаемость за четыре месяца. Процент рядом со словом «эффективность». Эту цифру составляет сторона, которой выгодно, чтобы цифра выглядела хорошо. Это не повод разворачиваться и уходить, и обычно это даже не нечестность. Большинство завышенных расчётов собрано из кусков, каждый из которых защитим по отдельности, а вместе они дают фантастику. Четыре вопроса разбирают такую цифру на части. Они работают с любым подрядчиком, включая нас, и заданные одинаково каждый раз делают ответы сравнимыми между предложениями. ## Первый: чьи часы и как называется роль? «Экономит команде 40 часов в неделю» ответом не является. Какие роли, на каких шагах, сколько раз в неделю? Настаивать на ролях стоит потому, что стоимость часа внутри одной компании отличается впятеро, а размытая формулировка эти часы тихо усредняет. Час специалиста с лицензией, который что-то проверяет, и час помощника, перебивающего адрес руками, - разные часы. Предложение, экономящее много второго по ставке первого, отлично смотрится на бумаге и разочаровывает в отчёте. Дальше попросите полную стоимость часа вместо оклада: налоги работодателя, соцпакет, инструменты и та доля оплаченных часов, которая реально продуктивна. Полная цифра обычно в 1,3-1,6 раза больше голой ставки, и счёт по голой занижает экономию. Обе ошибки встречаются, просто смотрят в разные стороны и почти никогда не гасят друг друга. ## Второй: превращаются ли сэкономленные часы во что-нибудь? Этот вопрос убирает большую часть цифры, и его почти никто не задаёт. Двадцать минут в день, возвращённые тридцати сотрудникам, - это 250 часов в месяц на слайде и, в большинстве компаний, ничто в отчётности. Никого не сократили, ничего дополнительно не продали, а время впиталось в то, что и так стояло в очереди. Работать стало приятнее. Окупаемости в этом нет. Часы превращаются в деньги двумя путями, и стоит назвать, какой из них ваш, до подписи: | Путь | Что должно быть правдой | Пример из наших проектов | | --- | --- | --- | | Мощность, которую вы продаёте | Раньше вы разворачивали заявки | Прокат принял в 2,5 раза больше пикового объёма без найма | | Цикл, который закрывается быстрее | Медленный цикл стоил вам конверсий | Брокеридж сократил цикл сделки с 14 дней до 5 | | Найм, которого вы не делаете | Наём был реально запланирован и в бюджете | План существует письменно до старта проекта | Пример с прокатом у нас самый чистый. Путь от брони до отгрузки сократился с 4 часов до 3 минут, и пиковые заявки, которые раньше разворачивали из-за сроков, стало можно принимать. Сами часы тут были побочным эффектом. Брокеридж - это второй путь: ответ на обращение упал с 6 часов до 8 минут, цикл с 14 дней до 5, а короткий цикл конвертит лучше, потому что меньше покупателей успевает остыть. Если ни один путь не подходит, честное описание проекта звучит так: он делает работу лучше. Это законная покупка. Просто покупать её надо с таким ожиданием и без графика окупаемости. ## Третий: какой объём заложен в цифру? Экономика автоматизации - это фиксированная стоимость постройки, делённая на поток. Поэтому срок окупаемости резко ходит вслед за допущением об объёме и почти не реагирует на всё остальное. Процесс, который случается 400 раз в месяц и экономит по 15 минут, считается просто. Тот же процесс 80 раз в месяц несёт ту же стоимость постройки против пятой части выгоды и обычно проваливает честную арифметику, хотя экономия на одном случае осталась прежней. Отсюда правило: берите объём из собственных систем, а не из разговора, берите слабый месяц вместо хорошего и просите срок окупаемости при вдвое меньшем объёме. Если кейс выживает только на оптимистичной цифре, на столе лежит ставка на рост, одетая как проект по эффективности. Такую ставку тоже можно принять, но принимать её надо с открытыми глазами. ## Четвёртый: кто платит за это после запуска? Стоимость постройки называют всегда. Про эксплуатацию обычно молчат, и как раз в ней окупаемость за четыре месяца превращается в окупаемость за одиннадцать. Попросите месячную цифру, закрывающую все четыре пункта, умножьте её на двенадцать и прибавьте к стоимости постройки до того, как что-то делить: - Модель и инфраструктура на единицу объёма, на вашем настоящем объёме. - Время людей на случаях, которые система поднимает наверх, при честной доле эскалаций. Любая автоматизация, отдающая сомнительные случаи человеку, по замыслу тратит его время, и [человек в контуре на всём обязывающем](/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 недели. ## Цифра, которая нас удивила Мы делаем софт для двух бизнесов, которые звучат как один и тот же бизнес. Первый сдаёт вещи посуточно. Второй продаёт недвижимость и управляет ею. Если описать одной фразой, в обоих случаях кто-то платит за пользование зданием или машиной в течение какого-то срока. Когда мы начинали второй, все участники исходили из того, что большая часть первого перейдёт как есть. Вместе эти два продукта описывают 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% из них проходят через шаг одобрения человеком перед выполнением. ## Сдвиг, который стоит заметить Всё больше ваших клиентов теперь начинают задачи с разговора с ассистентом. Они просят 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-расчёт при консервативных вводных не выходит в плюс - мы возвращаем депозит и закрываем задачу. Эта доля держится стабильной за 200+ выкаченных workflow на 50+ компаниях. - Стадия Cut обычно убирает 30-40% шагов процесса до того, как начинается автоматизация. Шаги, которых не должно быть, удаляются, а не кодифицируются - автоматизация хаотичного процесса - это самый дорогой способ сделать медленные системы медленными навсегда. - Аудит занимает пять рабочих дней end-to-end и выдаёт три именованных артефакта: количественную карту процесса, cost-of-chaos отчёт и priority matrix с подписанным ROI по каждому кандидату. Медианная цена диагностики - 5-10% от прогнозируемого бюджета билда. - Production-workflow выкатываются за 2-4 недели от kickoff и дают 40-60% прирост продуктивности на автоматизированной части. Полная отдача (стоимость билда отбита через time-saved и loaded labor cost) приходит за 3-6 месяцев на тех задачах, что прошли фильтр. - 4 паттерна отказа закрывают большую часть No на стадии аудита: процессы, где доминирует upstream-ожидание, не адресуемое автоматизацией; процессы, которые команда в этот момент переписывает сама; процессы, которые операторы не примут по соображениям контроля; низкообъёмные процессы, где стоимость билда выше реалистичного time-saved за 12 месяцев. ## Правило, которое определяет компанию Workflow уходит в билд только после письменного ROI-расчёта, подписанного оператором, который выходит в плюс при консервативных допущениях. Если не выходит - мы возвращаем депозит и закрываем задачу. Примерно одна из трёх задач именно так и заканчивается. За 200+ выкаченными workflow в 50+ компаниях доля отказа остаётся стабильной - это и есть то, что хочется видеть от фильтра, который реально работает. Это не позиция в продажах. Это самая дешёвая страховка, которую может купить проект. Почти каждая 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 в час | Зарплата + benefits + utilization-corrected | Не голая часовая - реальная стоимость часа | Правило - ROI обязан выйти в плюс при таких вводных за 12 месяцев. Не за 24, не за 36, не «когда-нибудь». Двенадцать месяцев. Оператор подписывает шаблон до того, как нарезан билд-PO. Эта подпись делает решение разделённым, а не навязанным. Разобранный пример, анонимизированный из Q2-2026 деплоя в профессиональных услугах, 60 человек в штате. Workflow: triage и роутинг входящих RFP. Объём: 38 RFP в неделю. Экономия на RFP по 25-му перцентилю: 22 минуты. Loaded labor cost: $95 в час (senior account manager). Recovery-line: 38 × 22/60 × 95 × 50 недель = $66 200 в год. Стоимость билда по 75-му перцентилю: $42 000 all-in. Математика вышла в плюс на седьмом месяце, workflow поехал в Cast. На двенадцатом месяце реализованная цифра была $87K, потому что time-saved оказался ближе к медиане, чем к 25-му перцентилю, - в этом и весь смысл: консервативные вводные, реальный апсайд. ## Математика «сорок часов мусора до автоматизации экономят сорок часов в неделю» Первая задача аудита - выяснить, тот ли workflow вообще предлагается автоматизировать. В сорока процентах случаев - не тот. У предлагаемого workflow есть реальная стоимость, но более крупная стоимость сидит в связанном workflow выше по потоку, или в ожидании между двумя workflow, или в переделках, причина которых - пропущенный ввод два шага назад. Поэтому стадия Cut, идущая после аудита, убирает 30-40% шагов процесса до того, как начинается автоматизация. Шаги, которых не должно быть, не кодифицируются. Аудит - это то, что делает этот срез видимым. Шире про сам шаблон билда - [«Автоматизация бизнес-процессов»](/ru/blog/business-process-automation) и [«Интеграция ИИ в бизнес»](/ru/blog/ai-integration-business). Разобранный паттерн. Логистическая фирма пришла с задачей автоматизировать диспетчерское принятие решений. Аудит показал, что диспетчеры 60% времени тратят на выколачивание недостающих документов у водителей и только 25% - на решения, которые заменила бы предлагаемая автоматизация. Билд развернули на сбор документов со стороны водителя. Автоматизацию решений диспетчера отложили на вторую фазу - и в итоге она не понадобилась: после того как охота за документами ушла, у диспетчеров появился запас по мощности. Этот разворот и есть работа аудита. Без него билд поехал бы как изначально планировалось, диспетчеры пользовались бы инструментом вяло, узкое место осталось бы там, где было. ## Что покупает правило «не показали ROI - не строим» Три вещи, все они вниз по течению. Через полгода после запуска workflow оператор, который одобрил билд, уже не тот, кто разбирает результаты. Изначальный CEO ушёл, COO, подписавший заказ, в другой компании, head of operations новый. Математика ROI должна пережить эту смену. Подписанные консервативные вводные переживают. Маркетинговые оценки - нет. Команда, которая операционно ведёт workflow, должна доверять системе. Операторы очень быстро понимают, откажется ли поставщик от работы, которая не отбивается. Поставщики, которые отказываются, получают второй проект. Те, кто не отказывается, получают один - и потом вежливое прощание. Автоматизационная мощность компании должна копиться. Каждый запущенный workflow с честной математикой - это workflow, чьё ROI выдержит ревью бюджета. Каждый запущенный workflow с оптимистичной математикой тихо выключают, и следующий проект труднее профинансировать. Аудит - это самый дешёвый рычаг на то, согласуют ли следующие десять проектов. ## Что это значит для оператора, рассматривающего билд Три операционных следствия. Первое - закладывайте, что диагностика будет платной, что займёт пять дней и потребует реальных цифр про throughput и error rate. Цена небольшая. Изменение поведения, которое она вызывает у команды аудита, - самый большой одиночный рычаг на качестве. Второе - закладывайте 1 из 3 на то, что аудит закончится No. Если diagnostic-to-build conversion у поставщика 95%, то его диагностика - это продажи, а не диагностика. Вы хотите честный ответ, а не лестный. Третье - когда аудит заканчивается Yes, билд едет за 2-4 недели против подписанных цифр ROI, и прирост продуктивности меряется по бейзлайну, который вы подписали до начала. 40-60% - это реальная цифра на 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 - даёт аудиты, которые реально влияют на решение, а не диагностики, которые подгоняют решение, нужное продавцу. --- # llms.txt мёртв в 2026? Что нашло SE Ranking на 300К доменов URL: https://inite.ai/ru/blog/is-llms-txt-dead-2026 Date: 2026-06-08 Author: Михаил Савченко Category: AEO Tags: llms.txt, AEO, Schema.org, Citation Lift, AI Search ## Direct Answer llms.txt не мёртв, но это не рычаг цитируемости, обещанный историей начала 2025. SE Ranking май 2026 на ~300К доменов показал 10,13% общего внедрения, 0% среди топ-1000 и никакого прироста цитируемости от llms.txt при контроле на authority, schema и свежесть. Что двигало рейт цитирования: FAQPage (+34% Perplexity, +28% ChatGPT search), ClaimReview на stat-плотном контенте (+41% AI Mode), SameAs (+22% entity-disambiguation), speakable cssSelector на блоках прямого ответа (+18% AI Mode). Identity disambiguation реальна, но это один вход; без schema-substrate вокруг измеримых изменений не даёт. ## Key Facts - Исследование SE Ranking за май 2026, проанализировано ~300К индексированных доменов: 10,13% общего внедрения llms.txt (около 30 400 доменов), рост с 0,4% в апреле 2025. Внедрение реально и растёт, примерно в 25 раз за 13 месяцев. - 0% внедрения среди топ-1000 доменов по трафику в том же датасете (май 2026). Высокотрафиковый веб не публикует llms.txt - кривая внедрения сосредоточена на mid-tier сайтах и SaaS-поверхностях. - FAQPage structured data коррелирует с +34% к рейту цитирования в Perplexity и +28% в ChatGPT search в том же исследовании, при контроле на свежесть контента и domain authority. ClaimReview-схема на stat-плотном контенте: +41% к рейту цитирования в AI Mode. - Связки SameAs из Organization-schema на Wikidata + LinkedIn + Crunchbase + GitHub: +22% точности entity-disambiguation (правильный бренд, правильная company-entity) по четырём изученным AI-движкам (ChatGPT, Claude, Perplexity, Google AI Mode). - Speakable-схема с cssSelector, целящимся в блоки прямого ответа (.aeo-direct-answer или пары h1+h2): +18% точности извлечения ответа в AI Mode-результатах, где цитированный сниппет совпадал с speakable-помеченным текстом. ## Честное обновление В апреле 2026 года мы опубликовали руководство, где утверждали, что llms.txt - де-факто стандарт ИИ-идентичности и вот-вот станет универсальным. Там цитировалось раннее исследование: сайты с llms.txt в 1,6 раза чаще цитируются корректно в Perplexity. Это руководство сведено в текущий пост, потому что утверждение, на котором оно стояло, не пережило большей выборки. SE Ranking провёл крупнейший на сегодня анализ llms.txt в мае 2026 - примерно 300 000 индексированных доменов, контролированных на authority сайта, плотность schema и свежесть контента. Находки не поддерживают сильную версию того более раннего утверждения. Они поддерживают мягкую. Этот пост - обновление. Заголовочные цифры из датасета SE Ranking: | Метрика | Май 2026 | Апр 2025 | | --- | --- | --- | | Внедрение llms.txt, все домены | 10,13% | 0,4% | | Внедрение llms.txt, топ-1000 доменов | 0% | 0% | | Прирост цитируемости от llms.txt (контролируемый) | статистически не значим | (малое N) сообщалось +60% | | Оптимальная длина по регрессии рейта цитирования | ≈ 800 знаков | (рекомендовалось) 800-3000 знаков | Внедрение выросло ~25× за 13 месяцев - это настоящее. Сигнал реален. Рычаг на цитируемость - не такой, как обещала версия начала 2025. Верх веба - высокотрафиковые издатели и платформы, чьё внедрение заставило бы AI-движки относиться к файлу как к авторитетному, - не сдвинулся. Середина веба внедрила интенсивно, потому-то агрегатное внедрение выглядит как хоккейная клюшка снизу и плоская линия сверху. ## Что это за файл и какие три стоят рядом llms.txt - это markdown-файл в корне домена, который объясняет ИИ-движку, что это за сайт и где лежат страницы, которые стоит читать. Свободные заголовки, цитата-описание, списки ссылок. Сегодня его читают пять краулеров: GPTBot, ClaudeBot, PerplexityBot, Google-Extended и Amazonbot. Рабочий файл короткий. Средний размер в 2026 году - 2,4 КБ, а регрессия по частоте цитирования в данных SE Ranking кладёт оптимум ближе к 800 знакам, что меньше, чем обычно ожидают. ``` # INITE AI > Intelligent automation consultancy. We put 1-3 automated workflows > into production in 2-4 weeks. ## Products - [Diagnostics](https://inite.ai/en/diagnostica): paid 5-day process audit - [AEO analyzer](/analyze): citation-readiness audit ## Key URLs - [Pricing](https://inite.ai/en/pricing) - [Cases](https://inite.ai/en/cases) ## Contact - info@inite.ai ``` Рядом с ним живут ещё три файла, и работа у них разная. Путаница между ними - самая частая ошибка в этой теме. | Файл | Задача | Формат | Внедрение, топ-10K | | --- | --- | --- | --- | | `robots.txt` | Кому что можно обходить | Директивы | около 99% | | `llms.txt` | Что за сайт и что читать | Markdown | 11% | | `ai.txt` | Машиночитаемый профиль сущности | Ключ-значение | 9% | | `identity.json` | Каноническая запись о сущности | JSON-LD | 7% | Доступом управляет только robots.txt. Остальные три описывают, а описание для движка - подсказка, а не договор. Отсюда и берётся большая часть разрыва между обещанным рычагом и настоящим. ## Что на самом деле меряли ранние цифры Цифра '1,6× к точности цитирования', широко цитируемая с апреля 2025, была малым-N ранним исследованием на уровне нескольких тысяч доменов, без контроля на authority сайта, плотность schema или свежесть контента. Более крупное исследование SE Ranking реплицировало методологию на масштабе ~300К доменов с добавленными контролями. Лифт, относимый именно к наличию llms.txt - при прочих равных - сжался до незначимого эффекта. Чистейшая интерпретация: исходный 1,6×-лифт был конфаундом population-of-publishers. Издатели, ранние принявшие llms.txt в 2025, были также издателями, делавшими все остальные AEO-best-practices - FAQPage-разметку, content-recency, структурированные Q&A, внутреннее линкование, всё. Лифт цитируемости пришёл от бандла практик, которые ранние принявшие отгружали вместе, не от самого файла llms.txt. Это стандартный паттерн, когда новый сигнал получает сильное раннее показание. Ранние принявшие самоотбираются; лифт выглядит относимым к новому сигналу; репликация на большем N с контролями растворяет эффект. Это случалось с PageRank-смежными сигналами в 2010-х, со structured-data-сигналами в 2010-х, а теперь с llms.txt в 2025-2026. Правильный ответ в каждом случае один: обновить модель. ## Что данные мая 2026 показывают как лифт цитируемости Positive-control set исследования SE Ranking фиксировал наличие llms.txt и варьировал плотность schema-разметки на самом контенте. Результаты по четырём изученным крупным AI-движкам - ChatGPT search, Claude, Perplexity и Google AI Mode - показали четыре чистых сигнала. ### FAQPage с реальными парами Q/A FAQPage с 4+ парами Question/Answer, привязанными к вопросам, которые пользователи реально задают, с ответами не короче 300 знаков каждый: **+34% к рейту цитирования в Perplexity, +28% в ChatGPT search**, при контроле на content-recency и domain authority. Механика механическая. AI-движки тянут FAQPage-размеченные пары Q/A почти дословно в свои сниппеты цитирования, когда вопрос совпадает с пользовательским запросом. Страница с 6 хорошо размеченными парами Q/A, адресующими 6 разных пользовательских интентов - это эффективно 6 возможностей цитирования, конкурирующих за 6 разных запросов. Страница с тем же контентом в текущей прозе - 1 возможность цитирования, и AI-движку приходится делать работу извлечения самому, что он делает менее надёжно. Паттерн целиком разобран в [гайде по AEO](/ru/blog/aeo-complete-guide-2026), и операционные советы не изменились - 4-6 пар Q/A на content-страницу, каждая не короче 300 знаков, каждая адресует разный пользовательский вопрос, каждая скорится против реальных поисковых запросов, на которые целится страница. ### ClaimReview на stat-плотных абзацах ClaimReview с `claimReviewed` и `reviewRating`, обёрнутые вокруг верифицируемых статистических утверждений: **+41% к рейту цитирования в AI Mode** на размеченном контенте в том же исследовании. Механика - сигнал. Большинство stat-плотных абзацев в вебе без источника; AI Mode их пенализует. Абзац, обёрнутый в ClaimReview, говорит движку, что утверждение прошло ревью и рейтинг, что поднимает его над конкурирующими бессрочными утверждениями, даже когда базовые цифры идентичны. Налог на имплементацию реален - каждый ClaimReview-блок требует `claimReviewed` (рассматриваемое утверждение), `reviewRating` (числовой, по определённой шкале), `author` (ревьюер), `datePublished` и `itemReviewed.url` (источник, который ревьюится). Для контент-команды, отгружающей 4 stat-плотных поста в месяц, овeрхед разметки на пост - около 15 минут. Лифт на AI Mode-цитирование с лихвой окупает это время. ### Связки SameAs Organization-schema с SameAs URL'ами на Wikidata, LinkedIn, Crunchbase, GitHub и (где применимо) Twitter и YouTube: **+22% точности entity-disambiguation** по четырём изученным движкам. Механика - верификация. Существуют как минимум 4 компании по имени "Inite" в путешествиях, фитнесе и консалтинге. Существуют как минимум 12 софтверных продуктов "Apex". Когда AI-движок резолвит entity-reference в пользовательском запросе → entity → URL сайта, он кросс-чекает SameAs-цели, чтобы подтвердить, что мапит в правильную entity. SameAs на Wikidata - сильнейший одиночный сигнал, потому что Wikidata - канонический entity-граф, на который крупные движки оборачиваются. Три SameAs URL'а - Wikidata + LinkedIn + GitHub - дали примерно 80% лифта entity-disambiguation в данных SE Ranking. 4-я и 5-я цели добавили маленькие предельные лифты. После 5-6 целей лифт плато'ит. ### Speakable с cssSelector Speakable-схема с `cssSelector`, целящим в блоки прямого ответа (`.aeo-direct-answer` или пары H1+H2): **+18% точности извлечения ответа в AI Mode**, где цитированный сниппет совпадал с speakable-помеченным текстом, а не другим пассажем на той же странице. Механика - подсказка. Свойство speakable говорит движку 'этот пассаж - чистый ответ на вопрос и подходит для voice/answer-извлечения'. AI Mode - движок, слушающий этот сигнал агрессивнее всего. ChatGPT и Claude слушают меньше; Perplexity, в исследовании SE Ranking, не показал измеримой реакции на speakable конкретно (хотя их логика цитирования, кажется, благоволит коротким, декларативным, фронт-лоадет пассажам - что и характеризует speakable-размеченные пассажи). Паттерн разобран в [гайде по AEO](/ru/blog/aeo-complete-guide-2026), и анализатор inite.ai проверяет его на каждом аудите. ## Что llms.txt всё ещё делает хорошо Контрариан-фрейминг не должен переторгировать. llms.txt остаётся правильной поверхностью для двух конкретных задач, не измеряемых метриками рейта цитирования SE Ranking напрямую. **Entity disambiguation.** Если у вашего бренда неуникальное имя, llms.txt - один из нескольких входов AI-движка для решения, какая вы entity. Исследование SE Ranking не измеряло точность entity-disambiguation как функцию наличия llms.txt; меряло рейт цитирования. Пока нет опубликованного исследования на большом N, изолирующего вклад llms.txt в entity-disambiguation. Механика правдоподобна - чистый H1 с легальным именем, однострочное описание и недвусмысленный SameAs-якорь в markdown помогают движку пришпилить entity - но количественный кейс не сделан. **Программная маршрутизация инструкций.** Если хотите, чтобы AI-агенты тянули из `/docs/llm-overview.md`, а не из sales-лендинга, llms.txt - то место, где маршрутизация декларируется. По мере того как agentic browsing переходит 5-10% входящего трафика в 2026, это важнее, не наоборот. Датасет SE Ranking меряет рейты цитирования из search-flavour-интерфейсов (ChatGPT search, Perplexity, AI Mode), не маршрутизацию agentic-трафика - так что это измерение вне того, что меряли. Ни одно из них не мапится в чистый прирост рейта цитирования в майских 2026 цифрах. Оба реальны. Честная позиция в середине 2026: отгружайте llms.txt, отгружайте его хорошо, но не выставляйте работу как citation-lift-проект. Лифт идёт от FAQPage / ClaimReview / SameAs / speakable substrate вокруг. ## Как выложить его нормально за час Файл всё ещё стоит выложить ради различения сущности и маршрутизации агентов, и стоит он дёшево. Все четыре файла вместе занимают час-два. - Корень домена, отдаётся как `text/plain` или `text/markdown`, HTTP 200, без цепочки редиректов. - Один H1 с юридическим названием, дальше одна строка цитатой о том, чем компания занимается. - Разделы про продукты, ключевые URL и контакты. Адреса абсолютные, а не относительные. - Меньше 3 КБ. Ближе к 800 знакам лучше, чем ближе к 3000. - Перегенерировать при изменениях на сайте. Протухший llms.txt, описывающий прошлогодние продукты, хуже отсутствующего, потому что он уверенно врёт. Повторяющиеся ошибки: свалить туда весь sitemap, написать рекламный текст там, где нужно описание, и дать файлу устареть, потому что за него никто не отвечает. ## Куда должно идти время Если у команды есть 8 часов AEO-времени в неделю в середине 2026, находки SE Ranking указывают на чистое распределение. Мы используем это распределение в [/analyze-инструменте](/ru/analyze) и собственной контент-команде: | Часов/нед | Активность | База лифта цитируемости | | --- | --- | --- | | 4 | FAQPage + ClaimReview + speakable-разметка на новом и существующем контенте | +28-41% на движок | | 2 | SameAs-поддержка + content-recency-обновление на топ-20 цитируемых страниц | +22% disambiguation, избегнутый −12% staleness-пенальти | | 1 | Identity-tier (llms.txt, ai.txt, robots-ai.txt, .well-known/agent-actions) | substrate; нет изолированного лифта | | 1 | Citation-tracking + измерение (пять метрик - в [гайде по AEO](/ru/blog/aeo-complete-guide-2026)) | feedback-петля | Это - обратное распределение апреля 2025, когда команды отгружали большие файлы llms.txt + ai.txt первыми, а schema-разметку добавляли позже. Майские данные 2026 перевернули приоритет. ## Что изменило бы наше мнение Две вещи должны стать правдой, чтобы llms.txt значил больше в 2027, чем в 2026. **Внедрение в топ-1000 должно перевалить 25-40%.** Пока верх веба не публикует llms.txt, AI-движки строят свои пайплайны цитирования без него как первичного входа. Они не могут сделать файл авторитетным, когда 0 из 1000 верхних сайтов его публикуют. Быстрейший путь вперёд - дефолт крупной платформы: Shopify, Vercel, WordPress или Squarespace, отгружающие llms.txt по умолчанию на каждом клиентском сайте. Ничего из этого не случилось. Если случится - калькуляция изменится. **Спека должна стандартизоваться на маленькой машиночитаемой схеме.** Текущая спека - freeform markdown, что значит, что каждый AI-движок парсит её по-своему и относится как к подсказке, а не контракту. IETF-draft по AI Identity - неформально трекаемый рядом с [Web Bot Auth](/ru/blog/ai-crawler-allowlist-2026) HTTP Message Signatures - указывает на JSON-LD-совместимый identity-профиль, на который движки могли бы опираться как на контракт. Если маленькая, строгая схема приземлится и крупные движки обещают её чтить - файл станет высокорычажным снова. Ни одно изменение не близко. Перепроверим в октябре 2026 с H2-обновлением SE Ranking. ## Что изменилось в анализаторе Перевзвешивание citation-readiness-скора [инструмента /analyze](/analyze), мотивированное напрямую находками SE Ranking: | Компонент скора | Старый вес | Новый вес | | --- | --- | --- | | Identity-поверхность (llms.txt, ai.txt, robots-ai.txt, .well-known/agent-actions) | 35% | 15% | | Schema-паттерны (FAQPage, ClaimReview, SameAs, speakable, Organization) | 30% | 50% | | Content-recency + плотность прямых ответов | 25% | 25% | | Robots-policy + гигиена crawler-allowlist'а | 10% | 10% | Новый скор лучше отражает, где эмпирический лифт реально живёт в середине 2026. Находки в отчёте анализатора теперь несут per-finding оценку лифта цитирования, привязанную к датасету SE Ranking - так что команда, отгрузившая FAQPage с 6 парами Q/A, видит явное "+34% Perplexity citation rate (SE Ranking 2026 estimate)", прикреплённое к этой находке. Другие [инструменты анализатора - citation tracking, ai-crawler allowlist, browser-agent readiness](/ru/blog/browser-agent-ready-saas) - все сидят в том же продукте. Перевзвешивание - одно обновление, не релонч. ## Резюме одним предложением llms.txt не мёртв и не бесполезен, но это не рычаг цитируемости, который обещала история начала 2025; майское исследование SE Ranking 2026 говорит нам, где лифт реально живёт в середине 2026 - в substrate Schema.org: FAQPage, ClaimReview, SameAs, speakable - и именно туда команды с 8 часами AEO-времени в неделю должны его тратить. Обновляйте модель, когда данные на большем N это велят. Перераспределяйте. Продолжайте отгружать. ## FAQ ### Если у 10,13% доменов есть llms.txt и он не лифтит цитируемость, зачем его вообще публиковать? Потому что отсутствие измеримого прироста цитируемости в агрегате - не то же самое, что бесполезность файла. llms.txt остаётся правильной поверхностью для двух конкретных задач, не измеряемых метрикой рейта цитирования. (1) Entity disambiguation - если у вашего бренда неуникальное имя (есть как минимум 4 компании с именем 'Inite' в путешествиях, фитнесе и консалтинге), llms.txt - один из входов AI-движка для решения, какая вы entity. SE Ranking-исследование не измеряло точность entity-disambiguation напрямую; оно меряло рейт цитирования. (2) Программная маршрутизация инструкций - если хотите, чтобы AI-агенты ходили в /docs/llm-overview.md, а не в sales-лендинг, llms.txt - то место, где декларируется эта маршрутизация. Ни одна из них не мапится чисто в прирост рейта цитирования, но обе реальны и обе важны, как только трафик от agentic browsing переваливает за 5% от общего. Честная позиция в середине 2026: отгружайте llms.txt, отгружайте его хорошо, но не выставляйте эту работу как citation-lift-проект. Лифт идёт от FAQPage / ClaimReview / SameAs / speakable substrate, который идёт вокруг. ### В чём ошиблась апрельская 2025 история про llms.txt? В трёх вещах. (1) Цифра '1,6× к точности цитирования', часто цитируемая из малого-N раннего исследования, не пережила репликацию на большем N. Анализ SE Ranking на ~300К доменов в масштабе не показал статистически значимого лифта в рейте цитирования, относимого к наличию llms.txt, при контроле на конфаундеры. Изначальная находка выглядит как эффект populace-of-publishers: издатели, ранние принявшие llms.txt, делали и все остальные AEO-практики, и лифт цитируемости пришёл от бандла, а не от файла. (2) Внедрение прогнозировалось по траектории robots.txt к универсальному покрытию. На практике оно застряло в mid-tier и совсем не пробило топ-1000 высокотрафикового веба. Крупные контент-платформы, крупные ретейлеры, крупные media-houses - ни у кого нет llms.txt по состоянию на май 2026, что означает, что AI-движки не могут опираться на него как на первичный сигнал, даже если бы хотели. (3) Контракт был переспецифицирован - ранние шаблоны предлагали 3-5 KB markdown-файлы с детальными product-деревьями. Большинство AI-движков, когда они вообще берут llms.txt, относятся к нему как к подсказке, а не контракту. llms.txt на 144 строки против 39 строк не даёт измеримой разницы ни в точности entity-disambiguation, ни в рейте цитирования. Оптимальная длина по SE Ranking-данным - ближе к 800 знакам, чем к 3 KB. ### Тогда что двигает иглу цитируемости в середине 2026? Schema.org-разметка непосредственно на контенте, который нужно цитировать, не декларативные identity-файлы в корне. Positive-control set датасета SE Ranking - сайты с одинаковым наличием llms.txt и разной плотностью schema - показал чистую линейную корреляцию между числом schema-маркеров и рейтом цитирования. Четыре конкретных паттерна разметки дали чистейшие лифты. (1) FAQPage с 4+ парами Question/Answer под вопросы, которые пользователи реально задают: +34% Perplexity, +28% ChatGPT search. Механика механическая - AI-движки тянут это прямиком в свои сниппеты цитирования. (2) ClaimReview с claimReviewed + reviewRating, обёрнутые вокруг верифицируемых статистических утверждений: +41% рейт цитирования в AI Mode на размеченном контенте. Механика - сигнал - схема говорит движку, что утверждение прошло ревью, что поднимает его над конкурирующими источниковоми. (3) Organization с SameAs URL'ами на Wikidata, LinkedIn, Crunchbase, GitHub и (где применимо) Twitter и YouTube: +22% точности entity-disambiguation. Механика - верификация - AI-движки кросс-чекают SameAs-записи, чтобы подтвердить, что говорят про правильную entity. (4) Speakable с cssSelector, целящим в блоки прямого ответа: +18% точности извлечения ответа в AI Mode. Механика - подсказка - схема говорит движку 'этот пассаж - чистый ответ на вопрос', что поднимает его над конкурирующими пассажами на той же странице. Сложите все четыре на странице - и предельные лифты компаундятся, скромно. Никому из четырёх не нужен llms.txt, чтобы работать. ### Как команде в середине 2026 реально вкладывать AEO-время? Три tier'а приоритета. Tier 1 - отгружайте четыре schema-паттерна выше на каждой content-странице, которую нужно цитировать. FAQPage с реальными, разными, полезными парами Q/A не короче 300 знаков каждая. ClaimReview на stat-плотных абзацах. Organization SameAs в корне сайта. Speakable на блоках прямого ответа. Здесь живут лифты рейта цитирования 18-41%. Tier 2 - сделайте entity-identity-поверхность правильно. Опубликуйте llms.txt (маленький, ~800 знаков, плотный), ai.txt с SEMrush-grade детализацией из [сравнения четырёх файлов выше](#что-это-за-файл-и-какие-три-стоят-рядом), .well-known/agent-actions для agentic-checkout эндпоинтов, если они есть, и чистый robots.txt, явно allowlist'ящий GPTBot/ClaudeBot/PerplexityBot/Google-Extended. Это - substrate, который даёт всем остальным сигналам приземлиться. Лифт не измеряем в изоляции, но отсутствие этого tier'а молча лимитирует остальные. Tier 3 - более тяжёлая, медленная работа, дающая накапливающийся лифт. [Паттерн direct-answer блока](/ru/blog/aeo-complete-guide-2026) - один абзац на 300-700 знаков на страницу, чисто отвечающий на главный вопрос страницы. [Citation-tracking метрики](/ru/blog/aeo-complete-guide-2026), позволяющие меряться своим лифтом неделя-к-неделе. Дисциплина content-recency, чтобы вас пере-краулили. Паттерн внутреннего линкования, консолидирующий topical authority. Это 80% потолка цитируемости. Тратить Tier-3-время на идеальный llms.txt - неправильное распределение капитала. ### Что это значит для AEO-анализатора inite.ai конкретно? Анализатор на [/analyze](/ru/analyze) проверяет llms.txt, ai.txt, .well-known/agent-actions, robots.txt и полный граф разметки Schema.org - тот же 9-шаговый пайплайн, что всегда. Что меняется в H2-2026 итерации продукта, мотивировано напрямую находками SE Ranking: возвращаемый анализатором citation-readiness-скор перевзвешивается. Текущая весовая модель была substrate-heavy (llms.txt + ai.txt + robots-ai.txt составляли 35% скора). Mid-2026-перевзвешивание двигает это к 15% и поднимает вес schema-паттернов с 30% до 50%. Наличие и качество FAQPage / ClaimReview / SameAs / speakable - теперь доминирующая ось скора, content-recency и плотность прямых ответов на 25%, identity-поверхность на 15%. Полный отчёт анализатора теперь поставляется с per-finding оценкой лифта цитирования, привязанной к датасету SE Ranking - так что команда, отгрузившая FAQPage с 6 парами Q/A, видит явное '+34% к рейту цитирования в Perplexity (SE Ranking 2026 оценка)' на этой находке. Работа продукта - говорить командам, где лифт реально живёт в середине 2026, а не где он жил в середине 2025. ### Вернётся ли llms.txt? Что должно быть правдой, чтобы он значил больше? Две вещи должны измениться. (1) Внедрение в топ-1000 должно перевалить какой-то порог - вероятно 25-40% - чтобы AI-движки относились к отсутствию llms.txt как к недостающему сигналу. Пока верх веба его не публикует, движки строят свои пайплайны без него как первичного входа, что означает, что публикация остаётся низкорычажной. Быстрейший путь к топ-1000-внедрению - мандат крупной платформы: Shopify, Vercel, WordPress или Squarespace, отгружающие llms.txt по умолчанию на каждом клиентском сайте, - чего не случилось. (2) Спека должна стандартизоваться на маленькой машиночитаемой схеме, а не freeform markdown. IETF-draft по AI Identity (неформально трекаемый рядом со спекой Web Bot Auth HTTP Message Signatures) указывает в эту сторону. Стандартизованный identity-профиль - вероятно JSON-LD-совместимый, вероятно строгий суперсет Schema.org Organization - стал бы той версией llms.txt, на которую AI-движки могли бы опираться как на контракт, а не подсказку. Если оба случатся - файл больше значит в 2027. Если ни одно - llms.txt остаётся полезной, но вторичной поверхностью, ровно как сейчас. --- # 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, оптимизация). Медианный деплой: прирост 40-60%, ROI за 3-6 месяцев, первые воркфлоу в проде за 2-4 недели. На 200+ деплоях у 50+ компаний узким местом никогда не была технология - вопрос в том, найдёт ли диагностика процесс, чью автоматизацию математика делает оправданной. Если нет - мы не строим. ## 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 недели. - Измеренные результаты на 200+ деплоях у 50+ компаний (типично 10-200 сотрудников): 40-60% прироста производительности на автоматизированном воркфлоу; ROI за 3-6 месяцев; 30-40% шагов процесса удаляются на этапе Cut. - Этап Break отклоняет примерно 1 из 3 проектов - диагностика не находит автоматизации, где математика сохранённого времени бьёт математику стоимости разработки. Такие мы не строим. - Средний Cut: 30-40% шагов процесса устранены перед автоматизацией - автоматизировать хаос это самый дорогой способ сделать медленные системы медленными навсегда. - Этап Cast поставляет 1-3 production-воркфлоу, не пилоты. Медианное время от заморозки спецификации до живых пользователей на первом воркфлоу: 8 календарных дней. ## Что этот пост, и что - нет INITE Protocol - это методология из 6 этапов, стоящая за каждым B2B SME деплоем, который выпускает INITE AI. Break, Hold, Track, Cut, Cast, Form. Названия - это ярлыки этапов, и большинство читателей могут угадать смысл по слову. Что труднее передать - и что любой консалтинговый обзор методологии опускает - это что команда реально делает на каждом этапе, какие артефакты выходят и какие решения принимаются. Этот пост закрывает этот пробел. Он проводит один реальный деплой Q2-2026 в фирме профессиональных услуг на 60 человек (анонимизировано; сектор, масштаб и паттерн процесса сохранены; конкретные имена и числа удалены там, где требует контракт). Деплой выпустил 2 production-воркфлоу за 19 календарных дней от kick-off. Прогноз ROI на 12 месяцев - +$340K против полной стоимости сборки $74K. Команда пользуется воркфлоу ежедневно и не просила нас вернуться - что и есть цель. Каждый артефакт ниже - реальный deliverable из реального проекта. Сам протокол задокументирован в `lib/brand-canonical.ts` (`whatShipped`), `locales//common/protocol.json` и HowTo JSON-LD в `components/StructuredData.tsx`. Цифры пруфа (40-60% эффективности, ROI 3-6 месяцев, 50+ компаний, 200+ воркфлоу) - это отчётный агрегат компании по всем проектам. ## Этап 1 - Break (неделя 1-2): диагноз и перезагрузка Этап Break отвечает на один вопрос: есть ли здесь процесс, чья математика автоматизации выдерживает ревизию? Если да - продолжаем. Если нет - заканчиваем проект и возвращаем депозит за диагностику. **Что мы делаем.** Интервью со стейкхолдерами (CEO, COO, 1-2 операторов с переднего края - в этом случае партнёр, ведущий практику, офис-менеджер и 2 старших консультанта). Наблюдение за процессом - мы тенью ходим за реальной работой 4-8 часов на целевой воркфлоу. Выгрузка данных - мы загружаем 90 дней операционных данных из существующих систем (CRM, project tool, billing, time tracking). Базовое измерение - инструментируем текущий процесс таймингами, пропускной способностью и числом ошибок. **Произведённые артефакты.** 1. **Карта процесса с маркерами узких мест.** Swimlane-диаграмма каждого шага в целевом воркфлоу с количественной пропускной способностью, частотой ошибок и временем цикла на каждой передаче. На этом деплое мы расписали 3 воркфлоу-кандидата: (a) квалификация входящих лидов (медианное время цикла 38 часов, 24% drop-off), (b) коммуникации о статусе проекта (4,5 часа/неделю на консультанта, 12 консультантов), (c) сверка инвойсов / time-entry (8 часов/неделю, 22% ошибок). 2. **Отчёт о стоимости хаоса.** Долларовая стоимость часов, теряемых в неделю на ручные переделки, упущенные передачи и ожидания. На этом деплое стоимость хаоса составила $11,200/неделю по 3 кандидатам - число, против которого позже измеряется ROI. 3. **Матрица приоритетов.** Каждый воркфлоу оценён по автоматизируемости (техника, 0-100) × ROI (бизнес, 0-100). Верх матрицы строится в Cast; низ явно откладывается. Матрица ниже - реальная (числа сохранены). | Воркфлоу | Автоматизируемость | ROI | Решение | | --- | --- | --- | --- | | Квалификация входящих лидов | 82 | 88 | Строим в Cast (W1 в Cast) | | Обновления статуса проектов | 71 | 76 | Строим в Cast (W2 в Cast) | | Сверка инвойсов / time | 54 | 38 | Откладываем - нужны данные quality в Hold | Третий воркфлоу на этом проекте не строится. Он задокументирован как кандидат на следующий цикл, но только после того как этап Hold подчистит проблемы качества данных, которые делают его одновременно менее автоматизируемым и менее ROI-выгодным сегодня. Честный отказ - часть методологии - мы не докладываем плохой воркфлоу, чтобы сделать проект жирнее. **Решение в конце Break.** Стоимость хаоса $11,200/неделю → годовая $560K → топ-2 воркфлоу оценены вернуть 50-60% от этого = $280-340K/год. Стоимость сборки оценена в $74K all-in на 12 месяцев (инженерия + мониторинг + настройка). Консервативная оценка ROI: +$200K в год 1, окупаемость на 4-м месяце. Решение: переходим в Hold. Примерно 1 из 3 наших Break-проектов кончается решением *не* продолжать. Диагностика не находит кандидата, у которого консервативная ROI-математика положительна. Мы возвращаем депозит и пишем причины. Это звучит как маркетинговое заявление; на практике это правило, которое держит остальную методологию честной. ## Этап 2 - Hold (неделя 2-3): стабилизация и фикс Этап Hold отвечает: можно ли автоматизировать целевой процесс в его текущем состоянии или нужна сначала стабилизация? Автоматизация хаоса - самый дорогой способ сделать медленные системы медленными навсегда; этот этап это останавливает. **Что мы делаем.** Для каждого воркфлоу, который будет построен в Cast, мы выявляем upstream-источники данных, правила валидации и точки передачи, которые должны быть надёжны, чтобы автоматизация работала. Чиним сломанные. Документируем SOP (стандартные операционные процедуры) для ручных версий шагов, которые останутся человеческими - потому что новый автоматизированный воркфлоу всё равно будет передавать людям на краях, и человеческая сторона должна быть консистентной. **Произведённые артефакты.** 1. **SOP для ключевых воркфлоу.** На этом деплое: правила триажа писем для входящих лидов (что считается квалифицированным лидом, что эскалируется, что отбрасывается - впервые записано); шаблон обновления статуса, который команда импровизировала; требования к полям данных в CRM (какие обязательны при захвате лида vs при конверсии). 2. **Фиксы качества данных.** В CRM было три значения lead-source, где должно было быть одно (`"website"`, `"web"`, `"Website"`). Мы их схлопнули. В project tool было 4 активных значения статуса, хотя команда пользовалась только 3. Мы убрали мёртвое. В инбоксе накопилось 14 правил входящей почты за 5 лет, половина - мёртвые. Подрезали до 6 активных. 3. **Быстрые ручные фиксы, экономящие время сразу.** Два узких места в воркфлоу квалификации лидов оказались чинимы без AI - одно было правило пересылки почты, маршрутизировавшее лиды на отпускной auto-responder; другое - баг с обязательным полем в CRM, заставлявший консультантов вводить одни и те же данные дважды. Оба пофикшены в Hold, до начала Cast. Экономия от одного только Hold составила около 6 часов/неделю на команду - небольшая, но измеримая победа до того, как поставлена хоть какая-то автоматизация. 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) Обновления статуса были в 2,3 раза длиннее, когда писались между 16:00 и 18:00 в пятницу, чем в другое время - подозреваем усталость в спешке; автоматизация может это нормализовать. (c) Консультанты, писавшие самые длинные обновления статуса, имели самые высокие оценки удовлетворённости клиентов - нельзя слепо автоматизировать их в краткость; длинноформатное качество - фича. 3. **Оценки автоматизируемости на шаг процесса.** Построчная оценка того, какие шаги в каждом воркфлоу - хорошие кандидаты на автоматизацию (высокий объём, хорошо определённые входы, ясные критерии успеха) vs какие должны остаться человеческими (низкий объём, неоднозначные входы, оценочные суждения). На этом деплое квалификация лидов набрала 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%. Медиана устранения на этапе Cut в наших деплоях - 30-40%; этот проект - на верхнем конце, потому что фирма не делала ревизию процессов 4 года, и рубцовая ткань накопилась. Категории: 4 дублирующих ввода данных, 2 избыточных одобрения, 2 мёртвых уведомления, 1 ручной фид в мёртвый отчёт. 3. **Спецификации, готовые к автоматизации.** Для каждого остающегося шага, который автоматизируется - письменная спецификация: форма входных данных, критерии успеха, обработка ошибок, путь эскалации, метрики мониторинга. Это артефакт, против которого строит Cast. Для воркфлоу квалификации лидов спецификация - 11 страниц. Для воркфлоу обновлений статуса - 7 страниц. Письменные спецификации предотвращают самый частый режим отказа 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 + email-инбоксе - 100% входящих лидов теперь идут через AI-триаж, с доступным operator-override на любом шаге; (b) воркфлоу обновления статуса проекта живёт в project tool + email - генерирует черновики обновлений, которые консультант ревьюит и отправляет. Оба воркфлоу попали в прод в течение 14 календарных дней от старта 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-й неделе: время цикла квалификации лидов упало с 38 часов до 1,4 часа (сокращение 96%), drop-off с 24% до 9%; время консультанта на обновление статуса с 4,5 ч/неделю до 0,8 ч/неделю (сокращение 82%), оценка удовлетворённости консультантов (по Лайкерту 1-5) выросла с 3,1 до 4,4. Заявление 40-60% эффективности в протоколе держится - этот деплой на верхнем конце. 2. **Оптимизация на реальных данных использования.** 4 раунда настройки в первые 90 дней. Раунд 1 (неделя 3): AI слишком агрессивно классифицировал пограничные лиды как неквалифицированные - мы поправили порог, и частота false-negative упала с 11% до 3%. Раунд 2 (неделя 6): черновики обновлений статуса были слишком общими - мы добавили извлечение контекста по клиенту из project tool. Раунд 3 (неделя 9): путь эскалации был слишком шумным - мы добавили шлюз по порогу уверенности. Раунд 4 (неделя 12): паттерн override консультантами показал, что 3 конкретных типа лидов никогда не должны авто-квалифицироваться - мы добавили их как жёсткие правила. Настройка не опциональна; это то, что делает воркфлоу хорошим, а не просто функциональным. 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) | После Form (неделя 12) | Изменение | | --- | --- | --- | --- | | Время цикла квалификации лидов | 38 часов | 1,4 часа | −96% | | Drop-off лидов | 24% | 9% | −62% | | Время на обновление статуса на консультанта | 4,5 ч/неделю | 0,8 ч/неделю | −82% | | Удовлетворённость консультантов (1-5) | 3,1 | 4,4 | +1,3 | | Возвращённая стоимость хаоса | - | $7,300/неделю | $380K/год прогноз | | All-in стоимость сборки (12 месяцев) | - | $74K | разово + текущая настройка | | Чистый ROI год 1 | - | +$306K (4,1x) | окупаемость на 3-м месяце | Цифры реальные для этого конкретного деплоя. Агрегат по 200+ воркфлоу, выпущенным у 50+ компаний, сидит в полосе прироста производительности 40-60% и окупаемости 3-6 месяцев. Отдельные проекты варьируются выше и ниже; этот был на лучшем конце, потому что фирма гоняла ручные процессы 4+ года, и этап Cut нашёл необычно много рубцовой ткани. ## Что такое протокол в одном предложении INITE Protocol - это то, как выглядит методология, построенная задом наперёд из вопроса «выжил ли воркфлоу 12 месяцев реального использования?». Break / Hold / Track обеспечивают, что математика реальна. Cut обеспечивает, что субстрат стоит автоматизации. Cast выпускает production-grade софт против чистого процесса. Form делает изменение устойчивым. Пропуск любого из шести - это как умирают деньги AI-консалтинга. Следование всем шести - это как 200+ воркфлоу у 50+ компаний продолжают работать после нашего ухода. Если ваша математика выжила в 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 даже на консервативных допущениях по сохранённому времени, мы заканчиваем проект и возвращаем деньги за диагностику. Примерно 1 из 3 проектов заканчивается здесь. ### Чем этап 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-го перцентиля для стоимости сборки), проект заканчивается на диагностике, и мы возвращаем депозит. Примерно 1 из 3 проектов заканчивается здесь. Дело не в придирчивости - дело в том, чтобы у каждого выпущенного воркфлоу была математика, выдерживающая ревизию через шесть месяцев, когда исходный 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%. ## Что стоит под всеми продуктами сразу В любой системе, где есть сотрудники и клиенты, повторяется одно и то же. Кто-то входит под своей учётной записью. У него есть роль. Роль что-то разрешает и что-то запрещает. Кому-то уходят уведомления, кому-то выставляется счёт, переписка лежит в одном месте и находится поиском, а журнал помнит, кто что менял. Это пять обязательных сущностей - пользователь, компания, роль между ними, ключ доступа и переопределение прав для отдельной компании, - девятнадцать пакетов-возможностей и три сервиса: вход, счета и ассистент. Написано один раз, не переписывается ни под одну отрасль. Пятая сущность появилась не из проекта, а из случая. В прокате управляющему филиала понадобился доступ к отчётности для совладельцев парка, а обычная роль управляющего его не даёт. Таблица ролей этого выразить не могла. Повод был отраслевым, решение оказалось общим, и теперь его наследуют все. ## Сколько на самом деле переносится Здесь принято называть большую долю. Мы измерили дважды, и обе цифры оказались неудобными. 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: Михаил Савченко Category: AI Visibility 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 - OpenAI Operator (запуск - январь 2025 года) выполняет 78% задач WebArena, но падает до 41% на сайтах, где React-компоненты названы без семантики. - Claude 4.5 Computer Use показывает 87,4% на бенчмарке OSWorld, если у форм есть атрибут autocomplete, и 52,1% - если его нет. - Сайты, которые закрывают основные read-flows за Cloudflare Turnstile, теряют 96% агентских сессий в первые 60 секунд. - Страницы со стабильными `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` и связанный с ним `