Setting Up Manager Control in Bitrix24 CRM

Manager control in CRM: where deal accounting breaks down

Deal accounting breaks down not at the moment of sale, but earlier — when a card is created without an owner, duplicated on a repeat inquiry, or gets stuck at a stage that no one is obligated to move.

In Bitrix24 this shows up in three symptoms: deals without an owner appear in reports, the funnel shows conversion higher than reality, and managers stop trusting the numbers and keep parallel records in spreadsheets.

The first failure is a deal without an owner. Such cards don't make it into a specific employee's sales plan, but they remain in the total sum, and the distortion of reports accumulates over months.

The second is duplicates in CRM: a client submitted a request on the website, then called, then wrote in a messenger — and instead of one deal with a communication history, three appear, each with its own owner.

The third and most costly is stages without regulations. If the transition between stages isn't tied to a mandatory action (call, invoice, contract), deals either don't move at all or skip into "successfully" without grounds. The funnel report in that case describes not sales, but the habits of specific employees.

Let's break down how this is closed at the level of CRM settings, rather than by persuading people to "work more carefully": rules for filling in required fields, automatic assignment of a deal owner, finding and merging duplicates by key requisites, stage regulations with transition blocking.

What well-established control delivers: the effect in numbers

Well-established manager control in the CRM stops being "surveillance" and becomes a measurable value.

Before deal discipline is implemented, the picture usually looks like this: a request sits in the queue for more than a day before the first touch, some stages go overdue and simply never close, card fields are half-filled, and the CRM report and the manager's spreadsheet show different numbers.

After rules and automatic reminders are set up, request processing speed drops severalfold — the first touch falls within the standard minutes rather than hours.

The share of overdue stages falls predictably: the system itself bumps the task to the top and notifies the owner before the deal "goes cold." Card completeness levels out because required fields block the transition to the next stage — a manager physically cannot push a deal through with an empty amount or without a contact. This eliminates manual checks and "I did fill it in" arguments.

Report convergence is a separate effect. When all actions are recorded in the CRM by uniform rules, the export for the manager and the funnel data match: the numbers stop diverging, and decisions are made based on a single version of the truth.

Manager control turns from manual reconciliation into a background process that runs without the manager's involvement.

We set up such rules for your actual deal cycle — taking into account how the stages, roles, and regulations are structured specifically for you. Describe your task — we'll come back with an estimate and a plan.

Control methods: regulations, robots, manual review

Control of managers in Bitrix24 is built from three layers, and each covers its own class of problems.

Regulations define what is even considered the norm: required fields at a stage, lead response time, prohibition on moving a deal to "won" without a task for the next step. Automatic rules monitor compliance without the manager's involvement.

Manual review catches what cannot be formalized — the quality of dialogue, the adequacy of a commercial proposal, the reality of agreements.

The practice is this: automation takes on the routine — robots record a violation, create a task for the manager, escalate on repeat. Manual review remains for sampling: 5-10% of deals where the cost of an error is high or the manager is in onboarding.

The boundaries of these approaches are rigid. Automatic rules are useless with flawed regulations — they will require filling in a field that doesn't exist in the process.

Manual review without automation doesn't scale: the manager drowns in reviews and stops doing them after a month. The hybrid scheme works when rules are configured for the real stages of the pipeline, not for a generic out-of-the-box template.

How we implement control: stages of work

We begin implementing control not with settings, but with an audit: we look at which pipelines and stages are actually used, where required fields are empty in records, how many deals are stuck without movement, and how permissions are distributed.

Often, already at this step it becomes clear that some of the problems are not in the managers' discipline, but in the logic of the stages: for example, the "Approval" stage is passed in a minute because it requires nothing from the employee.

Next, we design the scheme of stages and permissions: which fields become required upon transition, who can change the stage and the amount, where a second approver is needed, and where a notification is sufficient.

We agree on the scheme with you before configuration — this way changes in the CRM do not break the usual sales scenarios, and roles and responsible parties remain transparent.

1. CRM audit — export of current data, analysis of pipelines, stages, fields, and access permissions; we identify bottlenecks and discrepancies between the regulations and actual work.
2. Scheme of stages and permissions — we design the logic of transitions, required fields, roles, and approval points; we agree with the department head.
3. Configuration of rules — robots and triggers on transitions, automatic tasks and reminders, deadline control at the stage, recording the reason for rejection.
4. Testing on real deals — we run scenarios on live records: close deals, roll back stages, check notifications and reports; we fix what hinders the work.
5. Training and handover of regulations — we show managers and the department head how to read reports and analyze deviations, and we provide instructions and checklists.
6. Support after launch — for the first weeks we monitor statistics by stages and adjust the rules if control somewhere hinders a deal rather than helps it.

As a result, you get a working system where deviations are visible in reports rather than discovered at a planning meeting. Describe your task — we will come back with an estimate and a plan of stages for your pipeline.

Setting up permissions, stages, and required fields

Control in a CRM rests not on a supervisor but on configuration: if permissions, stages, and required fields are set up coherently, the system itself won't let a deal "stall" or go to the archive without an owner. Below is a list of what we configure so that control works without manual checks.

• Role-based access permissions. We delineate the visibility of deals, contacts, and reports: a manager sees their own block, a department head sees their teams, and leadership sees the overall picture. We separately lock down database export and record deletion — these are the most common leak points.
• Deal stages and transition logic. We map out the pipeline to match the real sales cycle, not the "default" one: which stages are mandatory, which can be skipped, and where a deal automatically moves to lost. Every transition is recorded in the history — you can see who moved the deal and when.
• Required fields at stages. We configure what can't be left unfilled when closing a stage: the amount, source, next contact date, and loss reason. This way the database is filled with data as work progresses, not retroactively.
• Data entry rules. We set formats and allowed values: a single source reference list, valid phone numbers and emails, and a ban on duplicates by key fields. The manager selects from a list rather than typing manually — reports stop "drifting."
• Deviation notifications. We set up alerts for the manager: a deal with no activity longer than the deadline, a mandatory stage skipped, a deal closed without a loss reason. The signal arrives via messenger or email — reaction the same day, not at the end-of-month planning meeting.

We separately configure robots and reminders: automatic task assignment to the manager when a stage changes, and escalation to the manager if a task is overdue. This removes manual labor from control — the system itself highlights where a deal has fallen out of the process.

We document each item in a regulation: what is configured, why exactly this way, and how it changes as the department grows. Describe your pipeline and roles — we'll come back with a setup plan and an estimate.

What the client receives after implementation

Implementation of control is not "turn on the report and watch." At the end, the client receives a set of artifacts that let the system run without us: roles, a stage scheme, automation, instructions, and a review regulation. Below is exactly what we hand over and why each element is needed in daily work.

Access and stage logic

• Configured roles and permissions. Separation by department and position: a manager sees their own deals, a department head sees the entire department, top management sees the consolidated picture. Editing, deletion, and export rights are locked down so that history cannot be rewritten after the fact.
• Funnel stage scheme. An agreed list of stages with required fields at each one: without a completed field, the deal does not move forward. This is the point where control stops depending on the manager's memory.
• Automation rules. Robots and triggers: an auto-task when a stage changes, a reminder about a stalled deal, escalation to the manager if a task is overdue. The logic is described in an "event → action → owner" table so it can be changed without us.

What the team keeps

• Instructions for managers. Short cheat sheets for each stage: what to fill in, what to attach, when to set a task. A new employee reaches working mode by following the instructions, not by listening to colleagues' stories.
• Review regulation. Who, when, and by which reports reviews the funnel: daily monitoring of stalled deals, weekly reconciliation by stages, monthly conversion analysis. With an indication of which deviations are considered normal and which require investigation.
• Manager's dashboard. A summary by managers: speed of passing through stages, share of deals without movement, on-time task completion. Data updates automatically, and manual report assembly goes away.
• Change log and training. We record what changed in the settings and when, and we conduct a handover: we show the manager how to edit stages and robots independently.

Such a package closes the main risk — control resting on a specific person. Describe how your sales department and funnel are set up, and we will come back with an assessment and an implementation plan.

How is control in CRM different from manual reports?

A manual report is a snapshot of the state that someone compiled by hand: exported deals, consolidated them into a table, calculated conversion by stage.

Between the moment a manager sent an email to a client and the moment it made it into the summary, anywhere from a few hours to the end of the week passes.

All that time the manager makes decisions based on an outdated picture: a problematic deal has already gone cold, but in the report it is still "in progress."

The main weakness of manual summaries is their dependence on the person doing the work. Someone forgot to set a stage, someone merged two calls into one row, someone "adjusted" the numbers to fit the plan.

The report becomes not a measurement but an interpretation, and it is impossible to verify it without re-examining the primary data.

On top of that, the preparation itself eats up the manager's time — that is, the time of the person who at that moment should be working with the client.

Rules in CRM are structured differently: they trigger on an event, not on a schedule. A manager moved a deal to a stage — the system recorded the time, the author, and the previous state. No call within the specified deadline — the task automatically went to the manager.

A deal stalled without movement — it landed in the "requires attention" selection without anyone's involvement.

Hence the key difference — continuity. Manual control is discrete: once a day or once a week. Control through rules in CRM works continuously and identically for all employees, regardless of tenure and personal habits.

The manager sees not a retelling but primary events with timestamps, and can drill into any deal to understand exactly where the process broke down.

The practical effect is a shift from post-mortem analysis to real-time reaction. Data lag is reduced from days to minutes, and the argument "I called" is replaced by a record in the card.

Manual reports do not disappear in the process — they remain for strategic snapshots, but they cease to be the only source of truth about the department's work.

Case study: how manager control changed the work of a department

A sales department of 14 managers worked "on trust": requests from the website and messengers were distributed manually, some leads remained unanswered for several hours, and no one could see at which stage deals were getting stuck.

The manager learned about problems from weekly reports — that is, with a week's delay, when the client had already gone to a competitor.

We set up a pipeline with mandatory stages and distribution rules: a new request is automatically assigned to a manager based on schedule and workload, if idle longer than a specified time it moves to the next one, and changing a stage requires filling in the deal fields.

We built a manager's dashboard: first response speed, conversion by stages, share of deals without movement, activity by calls and emails. Manager control stopped being manual — the system itself highlights deviations.

Metrics before and after implementation in the sales department:

The result of implementation rests not on discipline, but on rules: the manager sees their tasks and deadlines, the manager sees the bottlenecks of the pipeline in real time. Feedback from the head of the sales department: "Previously I dealt with failures after the fact.

Now in the morning I open the dashboard and see where the department is slowing down — we make corrections the same day, not a week later."

Such a control loop scales to new lines of business and branches without rewriting the logic — pipelines and distribution rules are added. If you want a similar result, describe your task: we will come back with an assessment and an implementation plan for your department.

Common technical concerns when setting up control

Before enabling control, the same questions almost always come up: will we have to rebuild an already deployed CRM, will current deals be affected, are the standard settings enough or is system customization needed, and what about access rights. Below are short answers to each.

Will current deals break while the rules are running?

Rules are introduced in stages and first in observation mode: the system records deviations but does not block anything. Once it's clear the logic is correct, we enable stage restrictions.

Deals in progress continue to move, and disputed cases are handled individually rather than in bulk.

Is system customization needed, or are the standard settings enough?

Part of the control is covered by settings without code: required fields, stage deadlines, reminders. Customization is needed where non-standard conditions are required — custom calculation rules, automatic escalations, summary dashboards by department. We determine the scope of customization after reviewing your processes.

What about access rights to control data?

Rights are configured by role: a manager sees their department, a sales rep sees only their own deals, an administrator sees everything. Control reports don't expose anything extra: an employee won't get access to other people's clients through the dashboard. We configure data retention and access separation before launch.

If your case isn't on the list — describe your task, and we'll come back with an estimate and a plan.

Let's discuss the control task in your CRM

Before changing anything, we need to understand the current state of the CRM: which roles are set up, how permissions are configured, and exactly where the tracking breaks down.

Most often the problem is not the discipline of the managers, but the configuration — deal stages are not tied to responsible parties, there are no required fields, and automation does not record status changes. Let's discuss the task — and start with diagnostics, not with template settings.

During the meeting we will go over what already works and what causes failures. You will show us where leads get lost, where deals stall without movement, and where a manager closes a stage without completing the required actions.

Based on these points we build the plan: configured roles, order in the deal stages, and automated checks instead of manual control.

What we will clarify during the first conversation:

• which roles and access permissions are already configured in the CRM and who uses them;
• at which deal stages tracking failures most often occur — stalled deals, duplicates, lost leads;
• how leads are currently distributed among managers and whether there are reassignment rules;
• which manager actions should be mandatory when moving through the stages;
• which reports and dashboards management reviews today and what is missing in them;
• who is responsible for CRM administration within the company and what level of access we need.

Based on the results of the conversation, we will come back with an estimate and a plan: what we will configure, in what order, and which deal stages and roles we will bring into a working state. Describe the task — and we will propose a specific sequence of work for your CRM.