Kommo тормозит рост, когда у вас появляются многоступенчатые сделки с несколькими стейкхолдерами, борд требует multi-touch attribution, а данные не укладываются в модель «лид-контакт-компания». Шесть признаков: воронки не вмещают сложный B2B-цикл, отчётность для борда собирается вручную, нет custom objects под вашу сущность, права доступа слишком грубые для распределённой команды, API упирается в 7 запросов в секунду при объёме, и нет нативного revenue reporting. Если совпадают три и больше - вы переросли платформу.
Kommo - сильная CRM для команд продаж, которые работают через мессенджеры и линейные воронки. Это не статья «почему Kommo плохая». Это про конкретный потолок: на каком масштабе и при какой сложности процессов платформа перестаёт быть нейтральной и начинает стоить вам скорости. В проектах миграции и кастомной разработки на Kommo мы видим один и тот же паттерн - компания не «разлюбила» CRM, она доросла до задач, под которые Kommo не проектировалась.
Боль ощущает не рядовой менеджер, а head of sales и CMO. Менеджеру в воронке всё ещё удобно. Но когда фаундер просит «покажи, откуда пришли закрытые сделки за квартал и сколько касаний было до подписания» - выясняется, что ответ собирается руками в Google Sheets, занимает день, и его нельзя доверять. Вот когда CRM из актива превращается в технический долг.
Технический долг CRM: ситуация, когда система формально работает, но обходные решения вокруг неё (ручные выгрузки, сторонние таблицы, костыли в автоматизации) стоят команде больше времени, чем сэкономила бы правильная архитектура.
Признак 1: многоступенчатые сделки не помещаются в воронку
Первый признак - вы плодите воронки, чтобы описать один сложный цикл сделки. Kommo построена на линейной digital pipeline: лид движется по этапам слева направо. Для транзакционных продаж это идеально. Для сложного B2B - нет.
В enterprise-сделке параллельно идут несколько процессов: технический evaluation, юридическое согласование, бюджетный цикл у клиента, работа с несколькими лицами, принимающими решение. В Kommo это невозможно отразить одной сделкой - этапы взаимоисключающие, сделка не может быть одновременно «на согласовании договора» и «на техническом пилоте».
Команды обходят это так: создают 3-4 воронки и вручную перетаскивают сделку между ними, дублируя карточки. В результате одна реальная сделка существует как несколько объектов, отчётность по конверсии искажается, а forecast перестаёт быть достоверным. Если у вас больше трёх активных воронок на один продукт - это не гибкость, это симптом. Базовую логику воронок мы разбирали в обзоре функций Kommo CRM, и именно там виден предел линейной модели.
Признак 2: отчётность для борда собирается вручную
Второй признак - перед каждым советом директоров кто-то сутки сводит цифры в таблице. Встроенная аналитика Kommo отвечает на вопросы менеджера по продажам: сколько сделок в работе, какая конверсия по этапам, кто из команды отстаёт. Она не отвечает на вопросы борда.
Борд спрашивает другое: пайплайн по когортам привлечения, динамика среднего чека по сегментам, влияние конкретных кампаний на закрытую выручку, прогноз на два квартала вперёд с разбивкой по источникам. По состоянию на Q2 2026 в Kommo нет конструктора отчётов такого уровня - даже сама платформа в сравнении с Salesforce признаётся ограниченной в кастомной отчётности.
Решение «через колено» - еженедельный экспорт в Google Sheets и ручная сборка дашборда. Это и есть технический долг: каждый отчёт - человеко-день, цифры расходятся между версиями, и ни один из них нельзя обновить в реальном времени. Если подготовка board deck в части продаж занимает у вас больше двух часов - вы оплачиваете отсутствие нормального reporting-слоя зарплатой сотрудника.
Признак 3: вашей сущности нет в модели данных
Третий признак - вы запихиваете важную бизнес-сущность в поля сделки, потому что под неё нет отдельного объекта. Модель данных Kommo фиксирована: лиды, контакты, компании, покупатели. Это всё.
Custom object: пользовательский тип записи в CRM (например «Объект недвижимости», «Подписка», «Полис», «Проект»), который живёт как самостоятельная сущность со своими полями и связями, а не как набор кастомных полей внутри сделки.
Если ваш бизнес оперирует сущностью, которая не сводится к сделке - объект недвижимости с десятком связанных сделок, подписка с историей продлений, страховой полис, единица оборудования на обслуживании - Kommo заставит вас моделировать её через кастомные поля в сделке или контакте. Это работает до первой задачи аналитики: посчитать LTV по объекту, а не по сделке, вы уже не сможете.
Именно здесь проходит граница между Kommo и HubSpot. HubSpot поддерживает custom objects как полноценные сущности с ассоциациями. Это структурное, а не косметическое различие - подробно мы разобрали его в статье Kommo vs HubSpot: различие моделей данных. Если вы ловите себя на фразе «у нас это лежит в кастомном поле сделки, но вообще-то это отдельная штука» - вы уперлись в модель данных.
Признак 4: права доступа слишком грубые для команды
Четвёртый признак - вы не можете выдать доступ так, как требует структура команды. Пока продажников пятеро и сидят в одном офисе, ролевая модель Kommo достаточна. На распределённой команде из нескольких регионов и юрлиц она трещит.
Реальные требования растущей компании: менеджер видит только свои сделки, тимлид - сделки своей группы, региональный директор - свой регион, но не чужой, финансы - суммы по всем без доступа к переписке, партнёр - только сделки по своему сегменту. Это матрица прав, а не список ролей.
Гранулярность настроек Kommo рассчитана на простую иерархию. Когда нужны права на уровне отдельных групп, регионов и типов данных одновременно, команды начинают городить параллельные аккаунты или давать лишний доступ «чтобы не возиться». Лишний доступ при распределённой команде - это риск утечки базы при уходе сотрудника. Если вопрос «кто что видит» решается компромиссом, а не настройкой - это четвёртый признак.
Признак 5: API упирается в лимит при вашем объёме
Пятый признак - ваши интеграции начинают ловить ошибки под нагрузкой. У Kommo API есть жёсткий лимит: не более 7 запросов в секунду. При превышении API возвращает HTTP 429, а при повторных нарушениях аккаунт блокируется и любой запрос отдаёт HTTP 403.
Rate limit: ограничение на число обращений к API за единицу времени; при превышении сервер отклоняет запросы кодом 429, защищая себя от перегрузки.
Для небольшого бизнеса 7 запросов в секунду - бесконечность. Для компании с массовым входящим потоком, двусторонней синхронизацией с несколькими системами и ночными bulk-операциями это потолок, в который реально упираются. Наивная интеграция, которая на старте работала, под выросшим объёмом начинает терять данные на 429 и валить синхронизацию.
Это лечится не сменой CRM, а правильной архитектурой интеграции: очередь запросов, throttling до безопасного rps, exponential backoff на 429, идемпотентность операций чтобы повтор не создавал дубли. Если ваши текущие интеграции построены без этого и уже сбоят - проблема не в том, что Kommo «слабая», а в том, что её ограничения требуют инженерного подхода, которого no-code инструменты не дают.
Признак 6: нет нативного revenue reporting
Шестой признак - вы не можете ответить на вопрос «сколько стоила закрытая сделка» внутри CRM. Kommo показывает сумму сделки и конверсию воронки. Она не показывает revenue в разрезе, который нужен растущей компании.
Revenue reporting растущего B2B - это не «сумма выигранных сделок». Это связка маркетинговых затрат с закрытой выручкой: cost per deal по каналам, multi-touch attribution через все касания клиента, MRR и его динамика для подписочных моделей, влияние конкретной кампании на выручку через недели после клика. Этих данных в Kommo нет, потому что они живут на стыке CRM и рекламных кабинетов.
Multi-touch attribution: модель, которая распределяет вклад в закрытую сделку между всеми точками касания клиента (реклама, контент, звонки), а не приписывает результат одному последнему источнику.
Закрыть этот разрыв можно отдельным аналитическим слоем поверх CRM - например Prooflytics замыкает рекламные кабинеты на воронку и показывает стоимость закрытой сделки, а не CPL. Это не требует ухода с Kommo. Но если вы принимаете решения о бюджете «на глаз», потому что CRM не связывает затраты с выручкой - это шестой признак, и часто самый дорогой.
Что делать: миграция на HubSpot или кастомная разработка на Kommo
Короткий ответ: считайте, сколько признаков совпало и какой природы потолок. Не каждый признак требует смены CRM.
Оставайтесь на Kommo и достройте кастом, если потолок инженерный, а не структурный. Признаки 1, 4, 5 и 6 в большинстве случаев решаются разработкой: воронки можно дополнить внешней логикой состояний, права - middleware-слоем, API-лимит - очередью и backoff, revenue reporting - аналитической надстройкой. Это дешевле миграции и сохраняет привычный команде интерфейс. Какие интеграции Kommo поддерживает на уровне API, мы описывали в обзоре Kommo CRM.
Рассмотрите переход на HubSpot, если потолок структурный - то есть упираетесь в признаки 2 и 3 одновременно. Кастомная отчётность уровня борда и custom objects как полноценные сущности - это про модель данных и архитектуру платформы, а не про доработку. Здесь дешевле переехать, чем годами обходить ограничение. Правильная миграция при этом - отдельная инженерная задача: как переносить историю активностей и связи без потерь, мы разбирали в гайде по миграции Kommo в HubSpot.
Самая дорогая ошибка - менять CRM, когда хватило бы доработки, или годами латать дырки, когда давно пора было переехать. Решение начинается с честной диагностики стека, а не с выбора вендора. За независимым разбором приходите в Exceltic.dev.
Реальный пример: типовой проект диагностики
В типовом проекте растущая компания обращается с формулировкой «Kommo нас тормозит, наверное пора на HubSpot». Команда из 24 человек, около 4 000 активных сделок, четыре воронки на один продукт, board deck по продажам собирается вручную полтора дня перед каждым советом.
Диагностика обычно выявляет смешанный потолок. Из шести признаков совпадают четыре: фрагментация воронок (1), ручная отчётность (2), грубые права на команду из трёх регионов (4) и 429-ошибки в интеграции с биллингом под объёмом (5). Признаки 3 и 6 - custom objects и revenue reporting - не критичны: бизнес-сущность укладывается в стандартную модель.
Вывод в таком сценарии - не миграция. Потолок инженерный, и переезд на HubSpot обошёлся бы в 3-4 раза дороже доработки без решения корневых проблем. Вместо этого: внешний слой состояний поверх воронок убирает дубли сделок, аналитическая надстройка превращает board deck из полутора дней в дашборд реального времени, middleware закрывает матрицу прав, а очередь с throttling до 6 rps и backoff на 429 чинит интеграцию. Команда остаётся на знакомой CRM. Если бы совпали признаки 2 и 3 вместе - вывод был бы обратным.
Для кого это актуально
Эта диагностика для компаний от 15-20 человек с осмысленным B2B-циклом продаж: несколько стейкхолдеров в сделке, отчётность перед бордом или инвесторами, маркетинг с платными каналами, распределённая команда. Если вы фаундер, CMO или head of sales и ловите себя на мысли «CRM стала узким местом» - вам сюда. Если у вас линейные транзакционные продажи и команда в одном офисе - Kommo вам, скорее всего, ещё долго подходит, и менять её не нужно.
Часто задаваемые вопросы
Сколько признаков должно совпасть, чтобы уходить с Kommo?
Количество - не главное, важна природа признаков. Если совпадают только инженерные (1, 4, 5, 6) - уходить не нужно, дешевле и быстрее доработать Kommo через кастомную разработку. Уход на HubSpot оправдан, когда упираетесь в структурные ограничения: кастомная отчётность уровня борда (2) и custom objects как полноценные сущности (3). Даже два структурных признака - более веский аргумент за миграцию, чем четыре инженерных. Начните с диагностики природы потолка, а не с подсчёта галочек.
Можно ли решить проблему отчётности без смены CRM?
Да, в большинстве случаев. Ограничение Kommo - во встроенном конструкторе отчётов, а не в данных. Сами данные доступны через API. Аналитический слой поверх CRM (BI-инструмент или специализированная платформа атрибуции) забирает данные из Kommo, связывает их с рекламными кабинетами и строит отчётность любого уровня сложности - включая multi-touch attribution и cost per deal, которых в Kommo нет нативно. Это дешевле миграции и не ломает работу команды. Смена CRM ради одной только отчётности - почти всегда избыточное решение.
Что такое лимит 7 запросов в секунду и когда он мешает?
Это ограничение Kommo API: не более семи обращений в секунду с одного аккаунта. При превышении сервер возвращает код 429, а при систематических нарушениях блокирует аккаунт кодом 403. Малому бизнесу этот лимит незаметен. Он становится проблемой при большом потоке лидов, двусторонней синхронизации с несколькими системами или массовых ночных операциях. Решается не сменой CRM, а архитектурой интеграции: очередь запросов, throttling, exponential backoff и идемпотентность. Наивные интеграции без этих механизмов теряют данные под нагрузкой.
Kommo подходит для сложного B2B вообще?
Для сложного B2B Kommo подходит до определённого потолка сложности. Линейная воронка хорошо описывает циклы с понятной последовательностью этапов, даже длинные. Проблемы начинаются, когда в сделке идут параллельные независимые процессы (юридический, технический, бюджетный) и несколько лиц, принимающих решение, или когда бизнес-сущность не сводится к сделке. Тогда либо достраивают внешнюю логику через API, либо переходят на платформу с гибкой моделью данных вроде HubSpot. Сам по себе сложный B2B - не приговор для Kommo, важна конкретная структура ваших процессов.
Bottom line
- Считайте не число признаков, а их природу: инженерные (1, 4, 5, 6) решаются доработкой Kommo, структурные (2, 3) - повод смотреть на HubSpot
- Ручная отчётность и отсутствие custom objects - самые весомые аргументы за миграцию
- API-лимит, права доступа и revenue reporting почти всегда чинятся кастомной разработкой без смены CRM
- Самая дорогая ошибка - менять платформу, когда хватило бы доработки, или латать дырки, когда пора переезжать
Если вы сейчас оцениваете, переросли ли вы Kommo - опишите ваш объём данных, число воронок и текущие интеграции команде Exceltic.dev. Разберём, какой у вас потолок - инженерный или структурный, и дадим честную оценку: доработка или миграция.