Kommo - is it a CRM? | HowToUseACRM.com

Every verdict, with its evidence

Core objects

In full

Kommo carries four separate entity families in its API - leads at /api/v4/leads, contacts at /api/v4/contacts, companies at /api/v4/companies and tasks at /api/v4/tasks - and each of the first three is a distinct custom-field target, with the vendor stating that custom fields can be added to leads, contacts, companies and lists. Contacts and companies are not two types of one object: they have their own endpoints and their own attribute sets, and a contact carries linked companies while a company carries linked contacts and linked leads. A task carries entity_type and entity_id and can be attached to a lead, a contact or a company. Linking a lead to a contact or to a company is offered as optional when the lead is created.

Source: https://developers.kommo.com/reference/leads-list.md, https://developers.kommo.com/reference/contacts-list.md, https://developers.kommo.com/reference/companies-list.md, https://developers.kommo.com/reference/tasks-list.md, https://developers.kommo.com/reference/custom-fields.md, https://support.kommo.com/docs/handle-incoming-leads.md, https://support.kommo.com/docs/manage-leads-in-kommo.md

Verification: Verified

Pipeline stages

In full

A lead carries pipeline_id and status_id, the identifier of the stage it occupies in that pipeline. The stage object itself carries sort, described as the sequence number of the stage in the pipeline, so the order is held on the data rather than on a view. Stages can be added, renamed, reordered, recolored and deleted, and an account can hold up to 50 pipelines of up to 100 stages each including the system stages.

Source: https://developers.kommo.com/reference/leads-list.md, https://developers.kommo.com/reference/stages-list.md, https://developers.kommo.com/reference/leads-pipelines-and-stages.md, https://support.kommo.com/docs/add-rename-stages.md, https://support.kommo.com/docs/pipelines-overview.md

Verification: Verified

Status

Not at all

The enumerated attributes of the lead object are id, name, price, responsible_user_id, group_id, status_id, pipeline_id, loss_reason_id, source_id, created_by, updated_by, created_at, updated_at, closed_at, closest_task_at, custom_fields_values, score, account_id, labor_cost, is_price_modified_by_robot and is_deleted. None of them says whether the lead is open or settled. status_id is the stage, and settled work is expressed by two reserved stages present in every pipeline, id 142 "Closed - won" and id 143 "Closed - lost", which the API returns with is_editable false and fixed sort values, and which the knowledge base says cannot be deleted or moved but can be renamed. The fact is therefore recorded structurally, in the identity of the stage, rather than as an attribute of the lead. The lead does carry closed_at, but the vendor states that Kommo locks the closing date the first time a lead is closed and does not update it afterwards, so its presence does not track whether the lead is currently open. Ruled 30 Aug 2026: status and stage must be completely separate values, so an outcome read from which stage the record occupies is not a status attribute at all.

Source: https://developers.kommo.com/reference/leads-list.md, https://developers.kommo.com/reference/stages-list.md, https://support.kommo.com/docs/add-rename-stages.md, https://support.kommo.com/docs/win-loss-statistics.md

Verification: Verified

Resolution

In part

Won and lost are the two reserved terminal stages, 142 and 143, so the outcome is read from the stage the lead ended in rather than from an attribute whose job is the outcome. The lead does carry loss_reason_id, and an account-level collection of loss reasons exists, but that records why a lead was lost rather than that it was, and there is no matching attribute for a win. The interface applies the outcome by dragging the lead onto a Won or Lost target, which sets its stage.

Source: https://developers.kommo.com/reference/leads-list.md, https://developers.kommo.com/reference/stages-list.md, https://support.kommo.com/docs/move-leads-through-pipeline-stages.md, https://support.kommo.com/docs/add-rename-stages.md

Verification: Verified

Value

In full

price ships on the lead and is documented as the lead sale value. Kommo treats it as money: the account object carries currency and currency_symbol, linking a product to a lead calculates the total sale value automatically from quantity and price, and the ROI report reads revenue from the Sale fields of all won leads.

Source: https://developers.kommo.com/reference/leads-list.md, https://developers.kommo.com/reference/account-parameters.md, https://support.kommo.com/docs/link-products-to-leads.md, https://support.kommo.com/docs/roi-reports-overview.md

Verification: Verified

Scope of work

In full

Kommo ships a product catalog whose products are linked to a lead with a quantity, the total sale value is recalculated from those line items, and the purchased items are stored on the lead profile as purchase history. The lead object exposes the linked items as _embedded catalog_elements, each with a quantity and its catalog id. Catalog fields themselves can be added, removed or renamed.

Source: https://support.kommo.com/docs/link-products-to-leads.md, https://support.kommo.com/docs/product-catalogs-overview.md, https://support.kommo.com/docs/customize-your-product-catalog.md, https://developers.kommo.com/reference/leads-list.md

Verification: Verified

Expected close date

Not at all

No expected close date is among the lead object's enumerated attributes: the only dates it carries are created_at, updated_at, closed_at and closest_task_at. The vendor's own list of the fields a lead is created with is name, tag, pipeline, stage, responsible user and sale amount. A buyer can add a Date or Date and time custom field to leads and use it for the purpose, which is why this is not a flat absence. Kommo's own forecast does not rest on such a date either: the Prospective sales analysis groups expected sales by an estimated closing time the product predicts from historical data rather than from a date anyone entered. Ruled 30 Aug 2026: the expected close date must be a native system field. A field the buyer has to build is not a pass.

Source: https://developers.kommo.com/reference/leads-list.md, https://support.kommo.com/docs/manage-leads-in-kommo.md, https://developers.kommo.com/reference/custom-fields.md, https://support.kommo.com/docs/win-loss-statistics.md

Verification: Verified

Actual close date

In full

closed_at ships on the lead and is documented as the Unix timestamp of when the lead was closed. It is set by the platform: the vendor states that when a lead is closed for the first time Kommo permanently locks that closing date and will not update it if the lead is later moved to another closed stage. Leads can be filtered on a closed_at range.

Source: https://developers.kommo.com/reference/leads-list.md, https://support.kommo.com/docs/win-loss-statistics.md

Verification: Verified

Opportunity owner

In full

responsible_user_id ships on the lead as the lead's responsible user, distinct from created_by and updated_by. Ownership drives the product elsewhere: permissions can restrict a user to only the items they are responsible for, and the reports attribute won and lost leads to the currently responsible user.

Source: https://developers.kommo.com/reference/leads-list.md, https://support.kommo.com/docs/set-permissions.md, https://support.kommo.com/docs/track-your-sales-performance.md

Verification: Verified

Linked buyer

In full

A lead carries linked contacts, returned as _embedded contacts, alongside a separate _embedded companies. The interface adds a person to the lead through Add contact on the lead card, and Kommo also links incoming email to the matching contact and lead automatically. The company link is a separate action, so a lead can reach a person without going through an organization.

Source: https://developers.kommo.com/reference/leads-list.md, https://support.kommo.com/docs/handle-incoming-leads.md, https://support.kommo.com/docs/mail-overview.md

Verification: Verified

Record preservation

In full

Closing a lead takes it off the pipeline board but not out of the account: the vendor says the closing stages exist for reporting and analytics and that closed leads are reached with the Won leads and Lost leads filters. They stay inside Kommo's own reporting. The Win-Loss analysis counts, per stage, the leads marked lost or closed while in it, and offers a Closed view of the lead life cycle; the Won leads and Lost leads dashboard widgets are clickable through to the underlying lead lists; and the ROI report sums revenue from the sale fields of won leads.

Source: https://support.kommo.com/docs/add-rename-stages.md, https://support.kommo.com/docs/win-loss-statistics.md, https://support.kommo.com/docs/create-custom-widgets-on-your-dashboard.md, https://support.kommo.com/docs/roi-reports-overview.md

Verification: Verified

Structured lost reasons

No verdict

A structured reason exists. The lead object carries loss_reason_id, the account exposes a defined collection of loss reasons at /api/v4/leads/loss_reasons each with an id, a name and a sort order, the reason can be embedded on the lead as _embedded loss_reason, and the account object carries an is_loss_reason_enabled flag. What no vendor documentation states is whether anything can count them. The knowledge base has no article on loss reasons at all; the Win-Loss analysis breaks losses down by the stage they happened in rather than by reason; no loss reason filter appears among the documented lead filters; and the guidance on reviewing sales performance names Lost reasons only as something to check on individual leads. Since the spec treats an uncountable reason and a countable one differently, and the vendor documents neither, this is left without a verdict.

Source: https://developers.kommo.com/reference/leads-list.md, https://developers.kommo.com/reference/loss-reasons.md, https://developers.kommo.com/reference/account-parameters.md, https://support.kommo.com/docs/win-loss-statistics.md, https://support.kommo.com/docs/filter-search.md, https://support.kommo.com/docs/track-your-sales-performance.md

Searched: Searched the full knowledge base index for any article whose title or description mentions a reason for loss and found none; read the Win-Loss analysis, Consolidated, Report by activities and dashboard widget documentation in full for a loss reason breakdown; read the documented query filters for GET /api/v4/leads and the filter and search article for a loss reason filter. None of them says whether a loss reason can be grouped or counted.

Verification: Pending vendor verification

Email sync

In full

A mailbox is connected to Kommo over IMAP and SMTP, with Gmail, Outlook and Yahoo named, and the sync runs both ways in the sense the feature requires: incoming mail appears in Kommo automatically linked to the matching contacts and leads, and the Sent folder is synced too, so mail sent from the user's own client also reaches the record. Mail can be written and replied to from inside Kommo, including from the lead card, and the lead keeps a full history of sent and received mail. The documented constraint is folder coverage: Kommo syncs Inbox and Sent only.

Source: https://support.kommo.com/docs/connect-and-manage-mailboxes.md, https://support.kommo.com/docs/mail-overview.md, https://support.kommo.com/docs/manage-emails-in-kommo.md

Verification: Verified

Calendar sync

In full

Kommo connects to Google Calendar and the vendor states that events created in Google Calendar appear in Kommo, events created in Kommo appear in Google Calendar, and changes are synced both ways. The sync is on the schedulable objects themselves - events, tasks and appointments - not on a date field. Two constraints are documented: items created before the integration is connected do not sync, and Google Calendar is the only external calendar Kommo documents.

Source: https://support.kommo.com/docs/google-calendar-overview.md, https://support.kommo.com/docs/google-calendar-connect.md, https://support.kommo.com/docs/tasks-calendar-overview.md

Verification: Verified

Schedulable activity types

In full

The task object ships a task_type_id alongside a responsible user, a deadline, a linked record and a result, and the account exposes its task types as a collection with id, name, color and icon. Kommo ships Follow-up and Meeting, and an administrator creates further types of their own under Calendar and Manage event types. The types are reportable: the Consolidated report breaks tasks down by task type across the account.

Source: https://developers.kommo.com/reference/tasks-list.md, https://developers.kommo.com/reference/account-parameters.md, https://support.kommo.com/docs/create-assign-tasks.md, https://support.kommo.com/docs/tasks-calendar-overview.md, https://support.kommo.com/docs/consolidated-statistics.md

Verification: Verified

Opportunity reporting

Not at all

One of the three is native and the rule requires two. Forecasting is real: the Prospective sales analysis estimates how many active leads will become closed-won and what they are worth, grouped into forecast periods, and a Prospective sales dashboard widget repeats it. The other two are not expressed as rates anywhere in the report documentation. The Win-Loss analysis gives, for each stage, the number and value of leads within the stage, the number and value that entered it, and the number and value lost in it, with percentage bars showing how leads are distributed across stages - a distribution, not the proportion that moved from one stage to the next. Win and loss appear everywhere as counts: Won leads and Lost leads widgets, won and lost totals per user in the Report by activities, and won or lost lead targets in the Goal report, with no report stating won over closed. Custom widgets are built from saved filters and produce counts, and the ROI report calculates only investment, revenue and a return percentage. Kommo's own analytics overview page asserts in its summary that users can measure lead conversion rates across stages and pipelines, but no report page documents such a measure, and the only conversion Kommo defines in detail is request-to-lead. Analyst mode, which answers questions about workspace data, needs the Pro plan and consumes purchasable AI credits, and its documented answers are counts and comparisons.

Verification: Verified