Меловая метафора перехода от набора платформенных инструментов к одному работающему механизму

Каким должен стать IT-интегратор в 2027 году

Денис
20 мин чтения
Если, в двух словах ...

Как меняется модель IT-интегратора: от внедрения платформ и приложений к цифровым сотрудникам, продуктовой модели и цели 10 млн ₽ чистой прибыли.

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

Лаборатория автоматизации LOG [IN] OFF много лет была связана прежде всего с Битрикс24. Мы внедряли CRM, автоматизировали процессы, делали интеграции, собственные доработки и приложения.

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

Я специально говорю только про нашу компанию. Я не знаю, что происходит у каждого интегратора Битрикс24, 1С или других платформ, и не хочу из собственной ситуации делать вывод, что весь рынок интеграции заканчивается.

Но собственного сигнала мне достаточно, чтобы перед вопросом:

Где взять больше лидов?

задать другой:

Какую компанию я вообще хочу получить, если лидов действительно станет больше?

Можно поменять сайт, запустить рекламу, вернуться на Avito, построить холодные продажи.

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

Почему одной платформенной экспертизы становится недостаточно

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

Основной актив такой компании - экспертиза вокруг конкретной системы.
Но сами платформы становятся функциональнее.
Появляется больше стандартной автоматизации, готовых интеграций, no-code инструментов и AI.

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

Мы лучше других знаем, как настроить эту платформу

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

Просто заменить Битрикс24 на AI-агентов тоже недостаточно

На поверхности есть очевидный следующий шаг:

Раньше внедряли CRM, теперь будем внедрять AI-агентов.

Но стратегически это может оказаться той же моделью.
Мы опять определяем компанию через технологию.

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

Поэтому мне интереснее подняться на один уровень выше.
Не спрашивать:

Какую технологию вам внедрить?

А спрашивать:

Какую повторяющуюся работу ваши сотрудники делают руками каждый день?

И уже после этого выбирать технологию.
Где-то понадобится Битрикс24.
Где-то другая CRM.
Где-то обычный алгоритм.
Где-то собственный микросервис.
Где-то web-интерфейс.
Где-то AI.

А чаще всего - комбинация нескольких технологий.
Клиент может называть всё это AI-агентом. Это нормальный язык рынка.

Но внутри компании нам важнее другой принцип:

продавать выполненную работу, а не технологию внутри неё.

LOG [IN] OFF 1.0 - широкий интегратор

Если грубо разделить развитие Лаборатории автоматизации на этапы, первая версия была классической интеграторской компанией.
Есть Битрикс24.
Есть задача клиента.
Мы умеем разобраться, настроить CRM, автоматизировать процесс, связать системы и при необходимости написать собственное решение.

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

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

Если сервисная компания хочет получать 5 млн рублей чистой прибыли при 20% рентабельности, ей требуется около 25 млн рублей выручки в месяц.
А дальше финансовая цель превращается в большое количество клиентов, специалистов и управленческого слоя.
Получается совсем другая компания.

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

LOG [IN] OFF 2.0 - приложения

Следующим этапом мы начали задавать другой вопрос:

Если мы уже решили эту задачу одному клиенту, можем ли не решать её заново следующему?

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

Остаётся актив:

  • код;
  • алгоритм;
  • интерфейс;
  • инфраструктура;
  • опыт эксплуатации;
  • повторные подключения.

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

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

В какой конкретной работе мы должны стать настолько сильными, чтобы нас было сложно заменить?

Для себя я считаю этап LOG [IN] OFF 2.0 заканчивающимся.
Следующая единица продукта должна быть крупнее отдельной функции.

”Дожми Продажи” уже похож на следующую модель

И здесь важно, что мы начинаем не с нуля.
У нас уже есть один продукт, который достаточно хорошо показывает, что я имею в виду.
Это “Дожми Продажи”.

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

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

Но человек не исчезает.
Руководитель определяет, что именно для него важно.
Критерии нужно калибровать.
Спорные случаи нужно проверять.
Управленческое решение остаётся за человеком.
Именно такая модель цифрового сотрудника мне кажется намного реалистичнее идеи:

AI полностью заменит РОПа.

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

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

Сначала нужно определить LOG [IN] OFF 4.0

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

Не начинать со списка идей.
Сначала определить точку Б и посчитать назад.
Рабочая гипотеза выглядит так:

LOG [IN] OFF 4.0 должна стать продуктовой компанией с примерно 10 млн рублей чистой прибыли в месяц при целевой чистой рентабельности около 30%.

Это не прогноз. И 30% пока не является доказанной рентабельностью будущей модели.
Это целевая конструкция, относительно которой можно проверять текущие решения.
При чистой рентабельности 30% для 10 млн рублей прибыли требуется примерно 33,3 млн рублей месячной выручки.
Около 400 млн рублей в год.

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

Сколько может стоить цифровой сотрудник

Это ещё одна рабочая гипотеза.

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

Первую исследовательскую вилку я сейчас вижу примерно такой:

30-100 тысяч рублей в месяц за стабильную цифровую рабочую функцию.

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

Если сотрудник стоит компании 180 тысяч рублей, а автоматизация снимает только 20% его нагрузки, нельзя говорить, что мы заменили сотрудника за 50 тысяч.
Поэтому нас должны интересовать не маленькие функции.
Нам нужны достаточно крупные законченные работы, которые сами по себе стоят бизнесу существенных денег.

Рабочая гипотеза - цифровой вариант такой работы должен обходиться клиенту примерно в 2-4 раза дешевле эквивалентного ручного выполнения.
Тогда переход начинает иметь понятный экономический смысл.

Что означают 33-35 млн рублей выручки

Грубая сценарная математика выглядит так.

При среднем платеже 30 тысяч рублей потребуется больше 1100 активных подключений.
При 50 тысячах - около 670.
При 70 тысячах - примерно 475.
При 100 тысячах - около 330.

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

Гораздо интереснее найти несколько крупных работ с высокой регулярной ценностью.
Например:

5 сильных цифровых сотрудников x 100 активных подключений x 70 тысяч рублей = 35 млн рублей регулярной месячной выручки.

При целевой чистой рентабельности 30% такая конструкция даёт около 10,5 млн рублей чистой прибыли.
Это всего лишь сценарий.
Реальная цена, валовая маржа, стоимость привлечения, отказы продлений, стоимость внедрения и поддержки ещё неизвестны.
Но этот расчёт уже позволяет понять, что именно нам нужно искать сегодня.

Почему я не хочу снова делать 100 продуктов и смотреть, что выстрелит

Здесь есть и другая вполне логичная гипотеза.

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

Исследователю - инструмент для разбора интервью.
Маркетологу - для отдельной аналитической работы.
Рекрутеру - для своей повторяющейся операции.
Предпринимателю - ещё для одной.

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

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

Для 10 млн рублей чистой прибыли при целевой рентабельности 30% нам всё так же нужны примерно 33,3 млн рублей выручки в месяц.
Если личный AI-инструмент стоит 1 000 рублей в месяц, нужно около 33 300 платных подписок.
При 3 000 рублей - около 11 100.
При 5 000 рублей - около 6 700.
Даже при 10 000 рублей понадобится больше 3 300 активных платящих пользователей.

Это уже совсем другая компания. Ей нужен:

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

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

У меня здесь есть ещё один важный фильтр из собственного опыта.
За годы я запускал больше 150 IT-стартапов и продуктовых гипотез. Во многих случаях механика была примерно такой:

Сделаем достаточно много продуктов, а рынок сам покажет, какие из них нужны.

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

Даже если для грубого сценария предположить, что из 100 созданных продуктов только 4 становятся по-настоящему прибыльными, ресурсы сначала были потрачены не на четыре.
яни были потрачены на сто.
И если эти четыре продукта должны вместе давать 33,3 млн рублей месячной выручки, на каждый приходится в среднем больше 8 млн рублей выручки.

При цене 3 000 рублей в месяц это примерно 2 800 платящих пользователей на каждый из четырёх продуктов.
При 5 000 рублей - около 1 700.

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

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

AI снижает стоимость создания первой версии. Но он не отменяет стоимость:

  • поиска хорошей задачи;
  • привлечения пользователей;
  • удержания;
  • поддержки;
  • продуктового развития;
  • эксплуатации неудачных гипотез.

Поэтому мне хочется двигаться иначе.
Не сначала делать 100 продуктов, а потом смотреть, кому они понадобились.

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

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

Но он должен пройти тот же обратный расчёт.
Кто платит?
Сколько таких покупателей существует?
Какой реальный регулярный чек?
Сколько платящих пользователей потребуется для нашей точки Б?
Во сколько обойдётся их привлечение и поддержка?

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

Поэтому вопрос LOG [IN] OFF 3.0 для меня окончательно формулируется не так:

Что ещё мы можем автоматизировать?

И даже не так:

Каких AI-агентов мы можем сделать?

А так:

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

LOG [IN] OFF 3.5 - доказать, что найденная работа является продуктом

Между широким поиском и 4.0 должен быть ещё один этап.
Пусть это будет 3.5.

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

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

Примерно к 10 внедрениям уже должно становиться видно:

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

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

LOG [IN] OFF 3.0 - найти другие дорогие повторяющиеся работы

Теперь становится понятно, зачем нужен этап 3.0.
Не для того, чтобы снова стать компанией, которая делает всё подряд.
И не для того, чтобы выпустить максимальное количество AI-агентов.

Задача другая:

найти ещё несколько человеческих работ, похожих на “Дожми Продажи” не функционально, а экономически и продуктово.

Нас должны интересовать работы, которые:

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

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

Поэтому главный объект поиска 3.0 - не автоматизация как таковая.

Нас интересуют дорогие повторяющиеся работы.

Почему широкий маркетинг теперь становится логичным

Это отвечает и на другой вопрос, который я раньше отдельно разбирал:

Как вообще рекламировать такую компанию?

“Внедрение Битрикс24” слишком ограничивает нас одной платформой.
“Разработка программного обеспечения” почти ничего не говорит клиенту.
“Автоматизация бизнес-процессов” настолько широкая формулировка, что под ней может находиться практически всё.
“Цифровой сотрудник” пока тоже не обязательно является термином, который клиент сам использует для описания задачи.

Поэтому маркетинговый вход на этапе 3.0 может оставаться достаточно широким.
Например:

Автоматизируем повторяющуюся работу сотрудников.

Или:

Разрабатываем AI-агентов для бизнеса.

Клиент может сформулировать запрос именно так.
Но внутри компании мы должны задавать более строгий вопрос:

Какая конкретная работа находится за этим запросом и может ли она стать повторяемым продуктом?

Маркетинг в этот период становится одновременно каналом продаж и инструментом поиска продуктов.

Но искать по всему рынку вслепую тоже не нужно

И здесь появляется следующий практический шаг.

За годы работы с Битрикс24 у нас уже накопилась широкая карта отраслей и типов компаний, где используются CRM и автоматизация.
Поэтому я не вижу смысла идти по всему рынку и задавать абстрактный вопрос:

Какую работу вам хотелось бы автоматизировать?

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

Дальше внутри каждой отрасли можно разбирать конкретные роли и повторяющиеся операции.
Так же, как мы уже отдельно исследовали, например, оптовые B2B-продажи.
Какие работы выполняются регулярно?
Кто их делает?
Сколько человеческого времени они потребляют?
Сколько стоит это ручное выполнение?
Какие из работ достаточно типовые?
Что можно автоматизировать уже сейчас?
Какая доля решения потенциально будет одинаковой у десятков похожих компаний?
И есть ли там возможность построить продукт с регулярным чеком в интересующем нас диапазоне?

Вот это уже гораздо более конкретный алгоритм поиска.

Старый инженерный опыт здесь становится преимуществом

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

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

Причина часто находится не в конкретной строке кода, а в зависимостях, состоянии, архитектуре или отсутствии проверки регрессий.

Кроме самого кода есть:

  • данные;
  • архитектура;
  • интеграции;
  • права доступа;
  • безопасность;
  • тестирование;
  • регрессии;
  • эксплуатация;
  • обновления;
  • обратная совместимость.

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

То есть в новую модель мы приходим не из мира промтов.
Мы приходим из автоматизации и инженерии.

Как выглядит весь переход

Для себя я сейчас фиксирую его так.
LOG [IN] OFF 1.0 - широкий интегратор Битрикс24.
Основной продукт - экспертиза внедрения платформы.

LOG [IN] OFF 2.0 - интегратор плюс собственные приложения.
Мы научились превращать повторяющуюся функцию в продукт и использовать её у следующих клиентов.
Этот этап сейчас заканчивается.

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

LOG [IN] OFF 3.0 - управляемый широкий поиск.
Ищем другие дорогие повторяющиеся работы, потенциально способные стать цифровыми сотрудниками.
Главный результат этапа - не максимальная выручка от кастомной разработки, а найденные продуктовые гипотезы.

LOG [IN] OFF 3.5 - концентрация и доказательство.
Берём наиболее сильные работы и целенаправленно ищем следующих клиентов с той же задачей.
Проверяем повторяемость, цену, скорость подключения, поддержку и удержание.

LOG [IN] OFF 4.0 - продуктовая компания цифровых сотрудников.
Несколько доказанных работ превращены в стандартные продукты.
Целевая конструкция - около 33-35 млн рублей регулярной месячной выручки и около 10 млн рублей чистой прибыли при целевой рентабельности порядка 30%.

Рост клиентской базы при этом не должен требовать линейного роста производственной команды.

Как понять, что гипотеза оказалась неправильной

Мне важно заранее зафиксировать и обратные критерии.

Если окажется, что:

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

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

Что дальше

Сейчас этап LOG [IN] OFF 2.0 для меня заканчивается не готовым ответом, а планом следующего движения.

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

Остаётся главный практический вопрос:

Где искать следующие дорогие повторяющиеся работы?

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

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

И как выделить те несколько работ, которые потенциально способны пройти путь:

3.0 -> 3.5 -> LOG [IN] OFF 4.0.

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

FAQ

Что такое цифровой сотрудник в этой модели?

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

Почему недостаточно просто делать AI-агентов для бизнеса?

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

Почему целевой чек находится в диапазоне 30-100 тысяч рублей в месяц?

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

Что должно произойти, чтобы решение стало продуктом 4.0?

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

Зачем нужен этап 3.5?

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

Почему не делать много маленьких AI-инструментов для отдельных специалистов?

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

Как будет устроен поиск идей для 3.0?

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