Kommo + OpenAI: Automated Lead Qualification in Your Pipeline

A Kommo and OpenAI integration closes one specific gap: every new lead automatically gets a score, tags, and a short summary in the deal card before a sales rep ever reaches it. Technically, this is a Kommo webhook on lead creation, an OpenAI call with a qualification prompt, and writing the result back into the deal fields via the Kommo API. At a volume of 300+ leads per month, this removes manual sorting and hands the rep an already-ranked queue.

In Exceltic.dev projects we regularly see the same picture: the pipeline fills up faster than the team can read the inquiries. A rep opens the card, rereads the conversation, estimates budget and segment, sets a tag by hand - and repeats this for every lead. At 20 inquiries a day this is tolerable; at 80 it becomes a bottleneck through which hot leads leak out together with junk.

Manual qualification is not about discipline, it is about arithmetic. When the lead flow exceeds a person’s throughput, any BANT or ICP scoring methodology turns into a formality. The rep either assigns tags at random or puts qualification off until later, and by the time of first contact the lead has already gone cold.

Why manual qualification does not scale

Manual qualification runs into three constraints, and none of them is solved by hiring another rep.

Time per lead is constant. To read an inquiry, open the conversation, and make a BANT decision, a rep needs 3-5 minutes. That does not compress. At 80 leads a day, qualification alone takes up to 6 hours - that is the full workday of someone who could have been making calls.

Criteria drift. One rep considers a 15-employee company a target, another does not. Scoring becomes subjective, and source analytics stops being reliable: you do not know whether the problem is in the traffic or in who tagged it.

Peak load breaks the SLA. After an ad campaign or a webinar, the lead flow grows several times over. People do not scale instantly, the qualification queue grows, and time to first response slips from 15 minutes to several hours. That is exactly the moment when conversion drops the most.

An LLM removes all three constraints at once: time per lead is measured in seconds, the criteria are fixed in the prompt and identical for every inquiry, and peak load is processed in parallel without losing speed. If you are still choosing a CRM for this scenario, start with the Kommo CRM review - it breaks down the pipeline and field architecture this integration relies on.

What gets built

The whole scheme fits into three steps: Kommo notifies you of a new lead, OpenAI evaluates it, the result is written back into the card. Below are the technical details of each link.

Kommo webhook on a new lead

Kommo sends a webhook to your endpoint on a lead-creation event or its transition to a specific pipeline stage. The payload contains the deal ID, field values, and related entities. The event subscription is configured in the developer section; the format and the list of events are described in the Kommo webhooks documentation.

An important nuance: the webhook on lead creation often arrives while the card is still empty - the conversation and the fields will populate seconds later. So in practice we hang the trigger not on “created” but on the transition to a “New inquiry” stage or on the appearance of the first message, so the model has context to evaluate.

OpenAI call with a qualification prompt

The request goes to the Chat Completions API. The prompt receives the inquiry text, the conversation, and a description of the target profile (ICP, BANT signals). The response must be strictly structured, otherwise JSON parsing will be fragile.

This is where Structured Outputs comes in - a mode in which the model is guaranteed to return JSON matching a given schema. Unlike the old JSON mode, with strict: true the model will not skip a required field or invent an enum value outside the schema. This is confirmed by the OpenAI structured outputs documentation. The qualification schema usually looks like this:

{
  "name": "lead_qualification",
  "strict": true,
  "schema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["score", "segment", "summary", "next_action"],
    "properties": {
      "score": { "type": "integer", "description": "0-100, readiness to buy" },
      "segment": { "type": "string", "enum": ["hot", "warm", "cold", "spam"] },
      "summary": { "type": "string", "description": "inquiry summary in 1-2 sentences" },
      "next_action": { "type": "string" }
    }
  }
}

In strict mode, additionalProperties must be false, and every field must be listed in required; optional fields are marked with a union type that includes null.

Model choice. For qualification, gpt-4o-mini is almost always enough: the task is classification and extraction, not reasoning. According to OpenAI, gpt-4o-mini costs 0.15 dollars per 1M input tokens and 0.60 dollars per 1M output tokens (OpenAI pricing). One lead is roughly 800-1500 input tokens (prompt plus conversation) and 100-200 output tokens. Moving to a larger model only makes sense if qualification requires complex logic across several data sources.

Writing the score back into Kommo

The result is written into the deal fields via the Kommo API update method (PATCH /api/v4/leads/{id}): a numeric field for the score, a list field for the segment, a text field for the summary. In parallel, you can set tags and, if needed, change the responsible user or the stage. The method reference is in the Kommo developer documentation.

Idempotency. The same Kommo webhook can arrive twice. Without protection, the lead is evaluated again, tokens are spent twice, and fields are overwritten. The solution is an idempotency key based on the lead ID plus a content hash: if a lead with that hash has already been processed, the request to OpenAI is not sent.

Latency. The full cycle of webhook -> OpenAI -> write to Kommo usually takes 2-5 seconds, most of which is the model response. For qualification this is unnoticeable: the rep opens the card later anyway. Processing should be done asynchronously through a queue so as not to hold the webhook connection open.

Errors and retries. The OpenAI API can return a rate limit (429) or a temporary error (5xx). You need retries with exponential backoff - usually 3 attempts. If all of them fail, the lead is marked with a “needs manual qualification” tag so it does not get lost between automation and people. A silent failure here is the worst-case scenario: the lead looks processed, but there is no score.

How it works step by step

1. A lead is created in Kommo and lands on the “New inquiry” stage.
2. Kommo sends a webhook to your service with the deal ID and fields.
3. The service checks the idempotency key - whether the lead has been processed before.
4. The conversation and field values are pulled from Kommo for context.
5. A request to OpenAI is assembled: a system prompt with ICP and BANT plus the lead data, and the Structured Outputs schema.
6. The model returns JSON with the score, segment, summary, and recommended action.
7. The service writes the result into the deal fields via PATCH and sets tags.
8. On error - a retry; when attempts are exhausted - the manual-qualification tag.

From there, Kommo’s native mechanics take over: automation by tag/field distributes leads, sets tasks, and triggers the right stage. If the pipeline is not yet set up for this scenario, work through its structure with the guide on how to set up a pipeline in Kommo CRM - scoring is useful exactly to the extent that the pipeline can react to it.

A real case with numbers

A B2B company, services for mid-market businesses, a flow of about 1400 leads per month from paid search, webinars, and a website form. Before the integration, two reps handled qualification, spending around 5 hours a day in total.

After implementation:

• Time to qualify a lead: from 3-5 minutes down to a 3-4 second automatic cycle.
• Match with expert judgment: on a control sample of 200 leads, the auto-tagging matched the senior rep’s decision in 89% of cases by hot/warm/cold segment; most of the disagreement was on borderline warm leads, where even people argue among themselves.
• Cost: at 1400 leads per month and gpt-4o-mini, the API spend is around 1.5-2 dollars per month. Not a typo: at this model and this token volume, it is pennies.
• Effect on the team: the freed-up 5 hours a day went into calls on hot leads. Time to first contact for hot inquiries dropped from several hours at peak to minutes, because they were automatically pushed to the front of the queue.

One thing to note separately: the value is not in “replacing the rep,” but in the fact that the person stopped spending their best hours on sorting and started spending them on selling.

Who it fits

The integration is justified if at least one condition holds:

• A flow of 300-400+ leads per month, and qualification eats up a noticeable share of the team’s time.
• There are pronounced peaks after campaigns, when the qualification queue breaks the SLA on first response.
• The qualification criteria are formalizable - you can describe in words what a target lead is.

You can stay in manual mode if there are few leads (up to 10-15 a day) or if each lead is so unique that an expert handles it anyway - then automation adds complexity with no payoff.

Term: BANT - the classic qualification model based on four signals: Budget, Authority (the power to make the decision), Need, and Timeline. In the OpenAI prompt, these signals are set as lead evaluation criteria.

Term: Structured Outputs - an OpenAI API mode in which the model response is guaranteed to match a given JSON schema. With strict: true the model will not skip a required field and will not go beyond the listed values, which makes parsing the response reliable for writing into the CRM.

Term: idempotency - the property of an operation to produce the same result when executed again. For a webhook, this means that re-delivery of the same event will not lead to double evaluation of a lead and unnecessary token spend.

Frequently asked questions

How much does this cost per month in API? On gpt-4o-mini, at a volume of about 1000-1500 leads per month, the OpenAI API spend is single-digit dollars: an input token costs 0.15 dollars per 1M, an output token 0.60 dollars per 1M, and one lead fits within 1-2 thousand tokens. The main project costs are not tokens, but the development and maintenance of the integration.

How accurate is automated qualification? In practice, the match with an experienced rep’s decision on basic segmentation stays in the 85-90% range, if the prompt describes the ICP well. The disagreements concentrate on borderline leads. So the score should be used to prioritize the queue, not as a final verdict - the final decision stays with a person.

What about client data privacy? Lead data goes to the OpenAI API. Under OpenAI’s terms, API requests are not used to train models by default. Still, you should pass only what is needed for qualification into the prompt and not send unnecessary personal data. If data requirements are strict, options with a data processing zone or enterprise terms are considered - this is clarified before the project starts.

Won’t everything break on webhook duplicates? No, if idempotency is built in. A key based on the lead ID and content hash filters out repeated processing, so a duplicate delivery leads to neither double scoring nor extra spend.

Can the qualification criteria be changed without rewriting code? Yes. The criteria live in the prompt and the Structured Outputs schema, not in the service logic. Changing the definition of a target lead or adding a new segment is an edit to the prompt text, not a release of a new integration version.

Bottom line

Kommo and OpenAI close a bottleneck that hiring does not fix: qualifying leads at scale. A webhook, a model call with Structured Outputs, and writing the score back into the card give the team an already-ranked queue in seconds and for a few dollars a month. At a volume of 300-400+ leads, it pays off through the reps’ freed-up time and the drop in time to first contact on hot inquiries.

If you have hit the wall of manual qualification and want to understand whether this scheme fits your pipeline, at Exceltic.dev we break down a case for your lead flow and run the economics before the work begins.