Kommo slows your growth once you start running multi-stage deals with several stakeholders, the board demands multi-touch attribution, and your data no longer fits the “lead-contact-company” model. Six signs: pipelines can’t hold a complex B2B cycle, board reporting is assembled by hand, there are no custom objects for your entity, access rights are too coarse for a distributed team, the API hits a ceiling of 7 requests per second at scale, and there is no native revenue reporting. If three or more match - you have outgrown the platform.
Kommo is a strong CRM for sales teams that work through messengers and linear pipelines. This is not a “why Kommo is bad” article. It is about a specific ceiling: at what scale and process complexity the platform stops being neutral and starts costing you speed. Across migration and custom development projects on Kommo, we see the same pattern - a company didn’t “fall out of love” with the CRM, it grew into tasks Kommo was never designed for.
The pain is felt not by the rank-and-file rep, but by the head of sales and the CMO. The rep still finds the pipeline convenient. But when a founder asks “show me where the closed deals came from last quarter and how many touches it took before signing” - it turns out the answer is assembled by hand in Google Sheets, takes a day, and can’t be trusted. That is when the CRM turns from an asset into technical debt.
CRM technical debt: a situation where the system formally works, but the workarounds around it (manual exports, third-party spreadsheets, automation hacks) cost the team more time than a proper architecture would have saved.
Sign 1: multi-stage deals don’t fit the pipeline
The first sign - you keep spawning pipelines to describe one complex deal cycle. Kommo is built on a linear digital pipeline: a lead moves through stages from left to right. For transactional sales, this is ideal. For complex B2B, it is not.
In an enterprise deal, several processes run in parallel: technical evaluation, legal review, the client’s budget cycle, working with several decision-makers. In Kommo you can’t reflect this in a single deal - the stages are mutually exclusive, a deal can’t be both “in contract review” and “in technical pilot” at the same time.
Teams work around this by creating 3-4 pipelines and manually dragging the deal between them, duplicating cards. As a result, one real deal exists as several objects, conversion reporting gets distorted, and the forecast stops being reliable. If you have more than three active pipelines for one product - that’s not flexibility, it’s a symptom. We covered the basic pipeline logic in our overview of Kommo CRM features, and that’s exactly where the limit of the linear model shows.
Sign 2: board reporting is assembled by hand
The second sign - before every board meeting, someone spends a day pulling numbers together in a spreadsheet. Kommo’s built-in analytics answers the sales manager’s questions: how many deals are in progress, what the conversion is by stage, who on the team is falling behind. It does not answer the board’s questions.
The board asks something different: pipeline by acquisition cohort, average deal size dynamics by segment, the impact of specific campaigns on closed revenue, a two-quarter forecast broken down by source. As of Q2 2026, Kommo has no report builder at this level - even the platform itself admits it is limited in custom reporting compared to Salesforce.
The “make-do” solution is a weekly export to Google Sheets and manual dashboard assembly. That is technical debt: each report is a person-day, the numbers diverge between versions, and none of them can be updated in real time. If preparing the sales portion of a board deck takes you more than two hours - you are paying for the absence of a proper reporting layer with an employee’s salary.
Sign 3: your entity isn’t in the data model
The third sign - you cram an important business entity into deal fields because there is no dedicated object for it. Kommo’s data model is fixed: leads, contacts, companies, customers. That’s all.
Custom object: a user-defined record type in the CRM (for example “Property”, “Subscription”, “Policy”, “Project”) that lives as a standalone entity with its own fields and relationships, rather than as a set of custom fields inside a deal.
If your business operates on an entity that doesn’t reduce to a deal - a property with a dozen related deals, a subscription with a renewal history, an insurance policy, a unit of equipment under service - Kommo forces you to model it through custom fields in a deal or contact. This works until the first analytics task: you simply won’t be able to calculate LTV by property rather than by deal.
This is exactly where the line between Kommo and HubSpot runs. HubSpot supports custom objects as full-fledged entities with associations. This is a structural difference, not a cosmetic one - we covered it in detail in Kommo vs HubSpot: the difference in data models. If you catch yourself saying “we keep this in a custom deal field, but really it’s a separate thing” - you have hit the data model.
Sign 4: access rights are too coarse for the team
The fourth sign - you can’t grant access the way your team structure requires. While there are five reps sitting in one office, Kommo’s role model is sufficient. With a distributed team across several regions and legal entities, it starts to crack.
The real requirements of a growing company: a manager sees only their own deals, a team lead - their group’s deals, a regional director - their region but not others, finance - the totals across everything without access to correspondence, a partner - only deals in their segment. This is a matrix of permissions, not a list of roles.
Kommo’s settings granularity is designed for a simple hierarchy. When you need permissions at the level of individual groups, regions, and data types simultaneously, teams start rigging up parallel accounts or granting excess access “to avoid the hassle.” Excess access in a distributed team is a risk of the database leaking when an employee leaves. If the question “who sees what” is solved by compromise rather than configuration - that’s the fourth sign.
Sign 5: the API hits its limit at your volume
The fifth sign - your integrations start catching errors under load. The Kommo API has a hard limit: no more than 7 requests per second. When exceeded, the API returns HTTP 429, and on repeated violations the account is blocked and any request returns HTTP 403.
Rate limit: a cap on the number of API calls per unit of time; when exceeded, the server rejects requests with code 429, protecting itself from overload.
For a small business, 7 requests per second is infinity. For a company with a high inbound flow, two-way sync with several systems, and nightly bulk operations, this is a ceiling you genuinely hit. A naive integration that worked at the start begins losing data on 429s and breaking the sync once volume grows.
This is fixed not by switching CRM, but by proper integration architecture: a request queue, throttling to a safe rps, exponential backoff on 429, idempotency of operations so a retry doesn’t create duplicates. If your current integrations are built without this and already fail - the problem isn’t that Kommo is “weak,” it’s that its limits require an engineering approach that no-code tools don’t provide.
Sign 6: no native revenue reporting
The sixth sign - you can’t answer the question “how much did a closed deal cost” inside the CRM. Kommo shows the deal amount and pipeline conversion. It does not show revenue in the breakdown a growing company needs.
Revenue reporting for growing B2B is not “the sum of won deals.” It is the link between marketing spend and closed revenue: cost per deal by channel, multi-touch attribution across all customer touches, MRR and its dynamics for subscription models, the impact of a specific campaign on revenue weeks after the click. This data isn’t in Kommo, because it lives at the intersection of the CRM and ad accounts.
Multi-touch attribution: a model that distributes the contribution to a closed deal across all customer touchpoints (ads, content, calls), rather than attributing the result to a single last source.
You can close this gap with a separate analytics layer on top of the CRM - for example Prooflytics connects ad accounts to the pipeline and shows the cost of a closed deal, not CPL. This doesn’t require leaving Kommo. But if you make budget decisions “by feel” because the CRM doesn’t link spend to revenue - that’s the sixth sign, and often the most expensive one.
What to do: migrate to HubSpot or build custom on Kommo
The short answer: count how many signs match and what the nature of the ceiling is. Not every sign requires switching CRM.
Stay on Kommo and build the custom layer if the ceiling is engineering, not structural. In most cases signs 1, 4, 5, and 6 are solved with development: pipelines can be augmented with external state logic, rights with a middleware layer, the API limit with a queue and backoff, revenue reporting with an analytics overlay. This is cheaper than migration and preserves the interface the team is used to. Which integrations Kommo supports at the API level we described in our Kommo CRM overview.
Consider moving to HubSpot if the ceiling is structural - that is, you hit signs 2 and 3 at the same time. Board-level custom reporting and custom objects as full-fledged entities are about the data model and platform architecture, not about an add-on. Here it is cheaper to move than to work around the limitation for years. A proper migration is a separate engineering task: how to transfer activity history and relationships without loss we covered in our guide to migrating Kommo to HubSpot.
The most expensive mistake is switching CRM when an add-on would have been enough, or patching holes for years when it was long past time to move. The decision starts with an honest diagnosis of your stack, not with picking a vendor. For an independent review, come to Exceltic.dev.
A real example: a typical diagnostic project
In a typical project, a growing company reaches out with the framing “Kommo is slowing us down, probably time for HubSpot.” A team of 24 people, around 4,000 active deals, four pipelines for one product, a sales board deck assembled by hand a day and a half before every meeting.
The diagnosis usually reveals a mixed ceiling. Of the six signs, four match: pipeline fragmentation (1), manual reporting (2), coarse rights for a team across three regions (4), and 429 errors in the billing integration under volume (5). Signs 3 and 6 - custom objects and revenue reporting - aren’t critical: the business entity fits the standard model.
The conclusion in this scenario is not migration. The ceiling is engineering, and a move to HubSpot would have cost 3-4 times more than the development without solving the root problems. Instead: an external state layer on top of the pipelines removes deal duplicates, an analytics overlay turns the board deck from a day and a half into a real-time dashboard, middleware closes the permissions matrix, and a queue with throttling to 6 rps and backoff on 429 fixes the integration. The team stays on the familiar CRM. Had signs 2 and 3 matched together - the conclusion would have been the opposite.
Who this is relevant for
This diagnosis is for companies of 15-20 people and up with a meaningful B2B sales cycle: several stakeholders per deal, reporting to a board or investors, marketing with paid channels, a distributed team. If you are a founder, CMO, or head of sales and catch yourself thinking “the CRM has become a bottleneck” - this is for you. If you have linear transactional sales and a team in one office - Kommo most likely suits you for a long time yet, and there is no need to change it.
Frequently asked questions
How many signs must match to leave Kommo?
The count is not what matters; the nature of the signs is. If only the engineering ones match (1, 4, 5, 6) - you don’t need to leave, it is cheaper and faster to extend Kommo through custom development. A move to HubSpot is justified when you hit structural limitations: board-level custom reporting (2) and custom objects as full-fledged entities (3). Even two structural signs are a stronger argument for migration than four engineering ones. Start with diagnosing the nature of the ceiling, not with counting checkmarks.
Can the reporting problem be solved without switching CRM?
Yes, in most cases. Kommo’s limitation is in the built-in report builder, not in the data. The data itself is available through the API. An analytics layer on top of the CRM (a BI tool or a specialized attribution platform) pulls data from Kommo, links it to ad accounts, and builds reporting of any complexity - including multi-touch attribution and cost per deal, which Kommo doesn’t have natively. This is cheaper than migration and doesn’t disrupt the team’s work. Switching CRM for reporting alone is almost always an overkill decision.
What is the 7-requests-per-second limit and when does it get in the way?
It is a Kommo API restriction: no more than seven calls per second from one account. When exceeded, the server returns code 429, and on systematic violations it blocks the account with code 403. For a small business, this limit is unnoticeable. It becomes a problem with a large lead flow, two-way sync with several systems, or mass nightly operations. It is solved not by switching CRM, but by integration architecture: a request queue, throttling, exponential backoff, and idempotency. Naive integrations without these mechanisms lose data under load.
Is Kommo suitable for complex B2B at all?
For complex B2B, Kommo is suitable up to a certain complexity ceiling. A linear pipeline describes cycles with a clear sequence of stages well, even long ones. Problems start when a deal runs parallel independent processes (legal, technical, budgetary) and several decision-makers, or when a business entity doesn’t reduce to a deal. Then you either build external logic via the API, or move to a platform with a flexible data model like HubSpot. Complex B2B in itself is not a death sentence for Kommo; what matters is the specific structure of your processes.
Bottom line
- Count not the number of signs, but their nature: engineering ones (1, 4, 5, 6) are solved by extending Kommo, structural ones (2, 3) are a reason to look at HubSpot
- Manual reporting and the absence of custom objects are the weightiest arguments for migration
- The API limit, access rights, and revenue reporting are almost always fixed with custom development without switching CRM
- The most expensive mistake is switching platforms when an add-on would have been enough, or patching holes when it was time to move
If you are currently assessing whether you have outgrown Kommo - describe your data volume, number of pipelines, and current integrations to the Exceltic.dev team. We’ll work out what kind of ceiling you have - engineering or structural - and give you an honest assessment: extend or migrate.