A pipeline in Bitrix24 is a sequence of stages a deal moves through, from first contact to payment. Setting up the stages takes ten minutes; the value appears once automation sits on the stages and tunnels connect the pipelines. Let's cover creating pipelines, the typical mistakes in stages, and a playbook: which robots to place on each stage so the pipeline moves deals on its own.
How do you create a pipeline and set up the stages?
CRM → Deals → pipelines menu (≡) → "Sales pipelines and tunnels" → "Add pipeline". Stages are edited in the kanban or in the stage directory: name, color, order. The number of pipelines depends on your plan; the default "General" pipeline can't be deleted, but it can be renamed. The main rule for stages: a stage is a state of the deal, not an action by the manager. "Thinking it over" is a bad stage (it's unclear whose state it is and when it ends), "Quote sent" is a good one: a fact has occurred, and automation can fire on it. Seven to nine stages is the practical maximum: beyond that the kanban stops being readable and the conversion report loses its meaning.
When do you need several pipelines, and what are tunnels?
A separate pipeline is needed when the process has different stages or a different team: new sales versus contract renewal, retail versus wholesale, sale versus installation. If the stages are the same and only the source differs, one pipeline and a "Source" field are enough. A tunnel is an automatic move between pipelines: a deal closes in "Sales" — the tunnel creates a deal in "Installation" with the data carried over. It's configured in "Pipelines and tunnels" by dragging a link between stages. The subtlety people forget: a tunnel creates a new deal rather than moving the old one — for end-to-end reporting, link them and watch for duplicates. The Find deal robot, run before creation, looks up an already-existing installation deal for the same contact.
Which robots to place on each stage: the playbook
A working minimum, by stage, for a typical pipeline. Entry stage ("New deal"): data normalization — the Format phone robot brings the number to a single form so duplicate search and telephony work downstream; plus a "make contact" task for the manager with a deadline. Qualification: a completeness check before moving on — Compound condition confirms that budget, decision-maker, and timeline are filled in (if not, the deal doesn't move on and the manager gets a task). "Quote sent": a control deadline for the response — Date + N business days computes the follow-up date by the production calendar, and a reminder is set by it. "Contract": launch of an approval business process. Final stages: a notification to the manager about large wins (the threshold via the same Compound condition) and moving the loss reason into a field for reporting.
The pipeline isn't working: common ailments
Deals pile up on one stage — the stage is too broad or has no automation with a deadline: split it or add a control deadline. Managers jump across stages — turn on required fields per stage and condition checks on the move. The conversion report lies — deals are dragged into "Lost" after the fact from any stage: set a rule to close only with a filled-in reason (a required field on the final stage). Tunnels breed duplicates — check for existing deals before creating, see above.
Bottom line
A pipeline works when stages are facts, every stage has an automatic action, and the moves are protected by checks. The set of stage robots — normalization, conditions, deadlines, deal search — is in the Roboteka catalog: free, in the same robot editor as the stock ones.