Stage markup and parking stages
Why the same deals yield 66% and 84%, what the widget treats as a parking stage, which thresholds it uses to find them and who signs off the result.
A parking stage: the deal is not moving there, it is waiting
Any living pipeline has stages that are not steps of a sale. A deal is put there when the client could not be reached, asked to come back in six months, or the project was paused. Deals leave a parking stage forward, backward and sideways; a deal can pass through it more than once. The stock “Sales analysis” report keeps such stages in the chain alongside sales stages and treats them as steps.
In the pilot account’s main pipeline, 3 stages turned out to be parking stages. Each was found by its own sign — not by its name and not by our guess at what a pipeline should look like:
| Stage | Entered in July 2026 | Sign | How it was measured |
|---|---|---|---|
| «РЕАКТИВАЦИЯ НОВОГО ПРОЕКТА» | 115 | deals come back to it | 77% of entries come from further down the pipeline, 400 of them straight from “Закрыто и не реализовано” |
| «Нет контакта» | 860 | dumping ground | 1,289 entries, 70% of exits go to lost |
| «Отложенный спрос» | 71 | deals get pulled back out | 85% of exits go backwards along the pipeline |
anonymised property developer account · “Продажи новым клиентам” pipeline · June–July 2026 · exit shares are computed only over transitions within one pipeline
What markup gives: two pairs of numbers
A parking stage inside the chain swallows flow that later returns to the sale. On the pilot, “Нет контакта” received 860 deals in a month — more than the main sales stage “Взято в работу” with its 782. Cumulative conversion breaks on this row, although not a single deal in it is lost: it is waiting.
The same history, 32,478 deals, not a single change in the CRM. The whole difference is whether parking stages count as funnel steps. That is the price of markup — and the reason a mistake there costs more than anywhere else in the product.
anonymised property developer account · cumulative funnel over 32,478 deals · the stock amoCRM “Sales analysis” report
The second number depends on markup too. Counting “any gap in stage order” gives 1,357 skips; a jumped-over parking stage is not a skip, and 30 real ones remain. The largest false row is leaving work for a parking stage: that is waiting, not a jump over a step. The widget shows both numbers and explains the difference.
July 2026 · 3,240 transitions analysed, 408 of them rollbacks · rule: skipping a parking stage does not count as a skip
Five kinds of stage and what each one does
The stage kind is the only thing the widget adds to the amoCRM reference data. The order of decisions is fixed: the CRM’s own structural attributes come first and cannot be overridden, then a person’s decision, and only then the heuristic thresholds.
| Kind | How it is determined | What changes in the report |
|---|---|---|
| sales sales | Everything that did not match the other four kinds. The default kind. | Gets a position in the sales chain: numbered from one, consecutively, separately in each pipeline. Conversion is computed only between adjacent positions — never across one, never cumulatively from the first stage. |
| parking parking | By transition statistics — the thresholds are further down the page. Or by a person’s decision, which overrides the thresholds. | Leaves the conversion denominator and is shown as a separate list with its own numbers: how many entered each parking stage, how they share the flow between them and what share of all pipeline movement settled there. Entering a parking stage does not count as a skipped stage. |
| unsorted unsorted | A structural attribute of amoCRM: stage type 1, “Unsorted”. | Shown in the table, not included in the conversion chain. |
| won won | A structural attribute of amoCRM: id 142, the same in every pipeline of the account. | Shown, not included in the chain. Separately: moving to won is not a sign of a dumping ground — that is exactly where the heuristic once went wrong. |
| lost lost | A structural attribute of amoCRM: id 143, also shared by all pipelines. | Shown, not included in the chain. The share of exits from a stage to lost is the input of the third parking sign. |
Chain positions are numbered over sales stages only, so won and lost never enter the conversion at all. Otherwise every deal closing would read as a jump over the whole remaining pipeline: closing stages have an amoCRM sort order that is always greater than any sales stage. A stage key is always the pair “pipeline + stage”, never the name: stages get renamed, and the won and lost ids repeat across all pipelines at once.
How the demo pipeline is marked up
The same markup the widget uses to build the “Funnel” tab: sales stages carry a position number, everything else has none and stays outside the conversion calculation.
demo data · anonymised property developer account · July 2026
| Stage | Kind | Chain position | Entered in July 2026 |
|---|---|---|---|
| НОВЫЙ ЛИД | sales | 1 | 181 |
| Взято в работу | sales | 2 | 782 |
| РЕАКТИВАЦИЯ НОВОГО ПРОЕКТА | parking | — | 115 |
| Нет контакта | parking | — | 860 |
| Клиент квалифицирован | sales | 3 | 216 |
| ВСТРЕЧА НАЗНАЧЕНА | sales | 4 | 48 |
| ВСТРЕЧА ПРОВЕДЕНА КЭВ | sales | 5 | 46 |
| Резерв квартиры | sales | 6 | 3 |
| Договор подписан | sales | 7 | 1 |
| Отложенный спрос | parking | — | 71 |
| Успешно реализовано | won | — | 5 |
| Закрыто и не реализовано | lost | — | 912 |
anonymised property developer account · “Продажи новым клиентам” pipeline · July 2026 · computed from status change events
There is no “Unsorted” in this table: the demo data has no row for it, and we will not invent numbers for one. In a live account a stage of type 1 is marked as unsorted and does not enter the conversion.
The heuristic: one filter and three signs
The heuristic looks not at stage names but at how deals move through them. First the common filter — “few deals leave the stage forward along the sales chain”. A stage that passes the filter becomes a parking stage if at least one of the three signs fires.
| What is checked | Threshold | Why |
|---|---|---|
| Entry base | 30 entries or more | Below this the shares are unstable, and the heuristic stays silent instead of guessing. |
| Common filter: exits forward along the chain | at most 35% | A stage from which deals mostly move forward is never a parking stage. If the filter is not passed, the signs are not checked. |
| Sign 1: entries from further down the pipeline | 25% or more | “Deals come back to it”: deals arrive from stages that stand later in the order. |
| Sign 2: exits backwards along the pipeline | 60% or more | “Deals get pulled back out of it”: a deal was put there and later taken back to earlier stages. |
| Sign 3: exits to lost | 50% or more with a base of 200 or more | A dumping ground. The base is higher than the common one: tail sales stages have a small flow and a naturally high share of losses — on such a base the two cannot be told apart. |
thresholds in code — DEFAULT_PARKING_THRESHOLDS, src/core/stage-map.ts · any entry into a stage counts, including deal creation and arrival from another pipeline
What the signs deliberately leave out
The share of exits into another parking stage forward in stage order. With it, “Взято в работу” becomes a parking stage — the account’s main sales stage, from which 79% of exits go to “Нет контакта”. An exit into a parking stage counts only when it goes backwards along the pipeline.
Why there is more than one pass
Markup and transitions form a loop: the stage kind is computed from the transition flow, and the flow is labelled by kinds. The loop is broken by iteration — the markup is recomputed until it stops changing. The limit is 3 passes; in practice the second one is enough.
A person confirms, not an algorithm
On the pilot’s full history — 7 years — this same heuristic declared 7 stages as parking instead of 3, including the one from which 98% of closings go to won. The cause was found and fixed, but the last false positive cannot be fixed by a threshold at all: the false stage has 70% of exits to lost, the real parking stage — 72.6%, and any threshold separating them would be a fit to a single account. The full post-mortem — with numbers, cause and fix.
anonymised property developer account · full history, 7 years · analysed 25.08.2026
Hence the rule: the heuristic proposes, the decision is signed by whoever knows their pipeline. A confirmed stage kind is stored together with the author of the decision, and from that moment a heuristic recalculation does not touch that stage — even if its statistics change. It is the only markup that overrides the thresholds.
There is no confirmation screen inside the widget yet
in developmentThe mechanism behind it is written and covered by tests: a person’s decision overrides the heuristic, is stored with its author and recalculates the reports at once. The button is not written. Until it exists, we agree the markup in writing: tell us which stage to treat as parking and which as sales, and we set it on your account. We reply during business hours on weekdays, usually the same working day. Write to support
How to change the markup later
The markup is not carved in stone at onboarding. It can be changed at any time, and it is a cheap operation: exactly one transition attribute depends on the stage kind — the stage skip. A rollback is computed from stage order, a pipeline change from the pipeline, time in stage from time; none of them reads the markup. So changing a kind rewrites one column and renumbers the chain positions, while the event history and the transitions themselves are not rebuilt. There is no need to reload the account and wait for the first load again.
A sales stage that has not yet been given a chain position does not drop out of the funnel: it goes to the end of the chain and is ordered by amoCRM stage order. A stage cannot silently vanish from the report — that rule matters more than a tidy picture.
What to read next
How percentages come out of the marked-up chain — metrics and formulas: flow and cohort, stage-to-stage conversion, median time, rollbacks and skips. Why a breakdown by field is sometimes not built at all — data quality. All calculation rules in one place — how we count. What the stock report loses on the same data — the comparison with “Sales analysis”.