A company sells ready-made goods and custom projects. Its shared pipeline includes both “confirm stock” and “approve drawing.” One salesperson searches for the right stage while another skips irrelevant ones. This hypothetical example shows different processes squeezed into one corridor.
A separate pipeline for every product is not always helpful either. Separate working processes rather than product names alone.
What a pipeline separates
A sales pipeline is a sequence of stages through which a particular sale progresses. A useful stage describes the deal’s state and the outcome of a step, rather than every employee action.
Bitrix24 supports multiple pipelines with their own records and access settings. The number depends on the plan, as the official instructions explain.
Before adding one, describe the current process in words. If the only difference is product, city, or inquiry source, consider a separate field and filter first.
Compare two sales using five questions
- Is the main sequence of steps the same?
- Is the outcome required for moving forward the same?
- Who accepts the work at the next step?
- What counts as successful completion?
- Does management need to evaluate process duration and outcomes separately?
Consistently different answers may justify separate pipelines. If the journey is the same, splitting it often adds maintenance.
Do not create a separate pipeline solely to restrict visibility. Review permissions first: the organisational problem may be solved without copying the process.
A hypothetical example: goods and projects
Ready-made goods require stock confirmation, order agreement, and payment. A custom project first needs requirements, an estimate, and approval of a proposed solution. In this training example, separate pipelines are worth considering.
One customer remains one customer. Create separate sales when orders genuinely differ, instead of duplicating the person for every department.
Agree where selling ends and fulfilment begins. A second production record must not quietly double reported revenue. Test the handoff and record relationship separately.
Test transitions before adding automation
Use training records to walk through the normal path, rejection, and a return for clarification. Check who sees the record and receives notifications. If automation copies or moves data, test repeated execution too.
For a team in Kazakhstan, agree on understandable stage names in working languages. Translating an interface will not resolve two departments’ different meanings of “ready.”
Do not move all existing deals in bulk immediately after setup. Check a small sample, reports, and current working rules first.
Choosing without unnecessary complexity
Draw two customer journeys and mark real differences. QQDev configures pipelines and permissions in existing Bitrix24 systems. Use the configuration page to discuss where a separate process is needed and where a field is enough. A useful outcome lets employees understand their path without a tour of ten empty pipelines.

