Turnkey setup of employee rating in Bitrix24

Bitrix24 employee rating: where the setup breaks

The Bitrix24 employee rating breaks not when it is enabled, but when the rules are agreed upon. The scoring mechanism in Bitrix24 is assembled from actions tied to portal events: a closed task, an accepted request, a completed course, a manager's evaluation.

If the same achievement is awarded points twice — for changing a task stage and for completing it — the employee sees one number, while the monthly calculation produces another. Such failures in point accrual surface after the fact, when people begin to dispute the calculation.

Data discrepancies across departments are the second typical cause. Sales, support, and development measure different things, but in a shared table the metrics are combined without bringing them to a single scale: somewhere a point for a large deal, somewhere for response speed.

The portal adds together incompatible values, and a department's place in the rating depends not on its work but on the scale chosen by its manager.

Hence manual spreadsheets instead of the system. The manager does not trust the numbers and keeps their own calculation in a file, while the portal remains a showcase.

A month later the two versions diverge, the rating is discussed in a meeting rather than in the interface, and employee rating setup loses its meaning: the data exists, but no decisions are made based on it.

Below we break down how this is closed — with unified accrual rules, access differentiation, and reconciliation where the portal and external reports produce the same number.

What changes after implementation: effect in numbers and time

An employee rating is not a "board of honor" but a calculation layer on top of data that already exists in the system: deals, tasks, deadlines, customer requests, labor costs by project.

Evaluation rules are set once — which metrics are included, with what weight, and for what period; after that the system calculates them itself when tasks and deals are closed.

A department summary that previously took hours of manual sampling and reconciliation is assembled automatically in minutes — and by a single algorithm for everyone.

Unified evaluation rules remove an entire class of conflicts: the argument "why is his coefficient higher" turns into a review of metrics, because both the formula and the source data are visible.

Transparency works both ways. The employee sees what their position is made of and influences it through actions, not negotiations.

The manager sees the dynamics: who declined over the month, which metric declined, where the workload is unevenly distributed — and steps in before the result falls.

Next, rating data feeds into bonuses, development plans, and project redistribution — decisions are made based on accumulated history, not the latest conversation.

In Bitrix24 the rating lives on the same objects as day-to-day work, so separate accounting is not needed: metrics update together with tasks and deals.

Rating modes: manual, calculated, and hybrid

The three approaches differ in the source of points: in one the manager assigns them, in another the system calculates them, in the third the system calculates and the manager can adjust the result.

Rating calculation options are chosen not by interface convenience but by how formalizable the criteria are and whether the accounting loop has reliable data — tasks, deals, hours worked, quality metrics.

In practice, the hybrid evaluation mode proves workable: automatic point accrual handles the routine, while the manager makes an adjustment with a mandatory comment.

The log retains who changed the score and why — this removes the main dispute of "why does he have more."

The limitations of rating modes show up in the data, not in the settings.

If tasks have no assignee filled in or statuses are closed in a batch on the last day of the month, the calculation will show a distorted picture: first the reference data and closing regulations are put in order, and only then are points for events enabled.

Rating implementation stages: from audit to handover

The rating implementation stages are arranged so that each subsequent change relies on a verified previous one: first we fix the rules, then calculate on historical data, and only then show the numbers to employees. The reverse order produces a rating no one trusts and a wave of disputes instead of motivation.

1. Audit of accrual rules. We review bonus policies, regulations, and how managers calculate contribution manually. We fix the list of metrics, data sources, and disputed cases, and for each we determine who makes the decision.

2. Calculation scheme. We agree on the metric matrix, weights, frequency, rounding rules, and behavior when data is missing — vacation, a new employee, a replacement. The output is an algorithm that is reproduced identically by any responsible person.

3. Calculation setup. We implement the logic on accounting data and differentiate access: an employee sees their own result, a manager sees a slice for the department.

4. Testing the calculation on real data. We run closed periods and compare with manually calculated numbers. We trace every discrepancy to its cause — source, weight, or rule.

5. Training responsible employees. We show how to recalculate a period, what to do when a metric changes, and how to explain the result to an employee. This removes most requests after launch.

6. Handover and support after launch. We provide documentation on rules and settings and stay in touch for the first accrual periods: weights and new metrics change without rebuilding the logic.

Setup package and rating documentation

We hand over the package not as a set of files "for show" but as a working loop: with it, the administrator maintains the employee rating in Bitrix24, the manager reads slices, and rule changes do not break already calculated history.

• Point accrual regulation — a table "action → rule → weight → period": what earns a point, what deducts one, how rounding works, when points expire, and how a manual adjustment is made.
• Configured calculation rules: which sources are taken into account — tasks, deals, deadlines, discipline — with what weights and for what period the total is recalculated.
• Rating access rights: an employee sees their own metrics, a manager sees their department, the consolidated slice is for a limited circle; every manual edit goes into the log.
• Metric report templates: slices by department, period, and employee with a breakdown — which actions made up the score.
• Administrator instructions: how to add a metric, change a weight, recalculate a closed period, roll back an erroneous accrual, and what to do when there is a discrepancy with the data source.
• Rating documentation: calculation scheme, integration points, limitations, and behavior during synchronization failure.
• Amendment procedure: who approves a change in weights and how the date from which the rule applies is recorded.

Handover follows a checklist: the administrator makes a test edit in our presence and confirms that the report has recalculated. After that the rating lives without us — there is something to come back to.

Case study: a rebuilt employee rating in a sales department

A sales department of 40 people calculated its rating manually: the manager exported deals from CRM, reconciled them with tasks and calls, and consolidated them into a table. Preparing the summary took 6-8 hours per week, and the table still diverged from the data in the system.

The accrual rules lived in the manager's head and in explanations, so the same deal gave different scores for different employees.

Over a month 20-25 disputed accruals accumulated: employees came with questions, and the manager dealt with them instead of working with the department.

What was changed

We assembled the sales department's employee rating inside Bitrix24 as a formal set of rules: which events earn a point, with what weight, for what period, how a deal returning to a previous stage and task removal are accounted for.

The calculation was assigned to robots and automation rules — spreadsheets and manual data transfer were removed from the process.

What was achieved

The summary builds itself: the same 6-8 hours per week turned into 15 minutes for spot checks. Point accrual accuracy rose from 70% to 99% — discrepancies are caught at the calculation stage rather than during a discussion with the employee. Manual adjustments remained only for non-standard deals.

The number of disputed accruals fell to a few per month, and almost every one is closed with a link to the event in the card. The rating became a working argument in conversations about bonuses: the numbers are transparent, there is nothing to dispute.

How does a calculated rating differ from manual evaluation?

A calculated rating is based on data that already lives in Bitrix24: closed tasks and deadlines, overdue items, deal stages, response time to requests, activity in work chats.

Collection is performed by a robot on a schedule, the formula is the same for all departments, so the result is reproducible: for the same period, two managers will get identical numbers. Manual employee evaluation does not provide such repeatability by definition.

The weak spot of automation is that it sees only what is digitized. Mentoring, sorting out someone else's failure, a difficult client handled by two people — in tasks these look like an ordinary overdue item.

The less often work leaves a trace in the system, the more the calculated rating diverges from real contribution.

Manual evaluation captures context but pays for it with subjectivity: each manager has their own scale, and the weight of the latest conversation outweighs the results of the quarter.

When there are many evaluations and they are not digitized, the Bitrix24 employee rating ceases to be an argument in disputes about workload and compensation.

The working scheme is a hybrid. Automatic evaluation provides base points with weighting coefficients by activity type, and the manager adjusts them within a limited corridor, for example up to one-fifth of the total, with a mandatory written justification.

Every adjustment of automatic points is recorded in the log with the author and reason, and after the period is closed, the points do not change.

The choice of evaluation method depends on what rating decisions are made. For workload distribution and payments, the base should be calculated — protection from bias matters there.

For development plans, the decisive role remains with the manager, because some of an employee's strengths are not reflected in numbers at all.

Rating limitations and technical implementation issues

The rating counts only what the system already measures: closed deals, tasks with an actual completion date, hours in time tracking.

If part of the work is done outside Bitrix24 or tasks are closed in a batch at the end of the month, the points describe card-filling discipline rather than results.

Before setting up the calculation, we verify the completeness of sources with the manager: how many deals bypass the funnel and what share of tasks are closed without an assignee.

The second limitation is the behavior the rating provokes: as soon as the calculation rule becomes known, some employees optimize the metric instead of the result — splitting deals, closing tasks without an outcome, exchanging endorsements.

This is removed by metric weights, a minimum value threshold, and anomaly control via the change log. We change processes for the rating in stages: the calculation lives in a separate smart process, rollout is by department, and working funnels are not stopped.

What should be done if the source data is incomplete or points are being inflated?

First we close the sources: mandatory fields at stages, auto-filling details from the accounting system, a report on omissions. While the share of completed cards is below the agreed threshold, the rating is a guideline, not a basis for HR decisions.

Calculated fields are closed to manual input, edits are recorded by the change log, and adjustments are available to one or two responsible persons.

Let's discuss the task: what to prepare for our meeting

To come back with an estimate and work plan rather than clarifying questions, it is useful to gather project inputs in advance. Below is the minimum set of source data for an estimate: it covers almost any discussion about employee rating setup.

• Departments, positions, and roles for which the rating is calculated: consolidated for the company and separate for managers are different calculation models.
• Data sources in the system: tasks and their statuses, deals and stages, manager evaluations, deadline discipline — what is already recorded and what will have to be entered manually.
• Calculation rules: which metrics are included, with what weights, for what period statistics are taken, and how often the total is recalculated.
• Rights and roles: who sees the summary panel, who can adjust values manually, who handles disputed cases.
• Output format: a dashboard inside the portal, a regular report email, or an export to a table for review.
• A draft of the current calculation — a table, file, or simply a description of the logic: it removes half the questions about how to calculate.
• Limitations: internal regulations, requirements for evaluation visibility, portal load when recalculating large periods.

Ideally, nothing needs to be prepared — a draft or a short description of the task is enough.

Tell us how the rating should work for you, and we will come back with an estimate and work plan: what is configured with standard tools, where customization is needed, and in what order to roll it out.