Setting up thank-yous and badges in Bitrix24: a complete guide

Why Gratitude in Bitrix24 Doesn't Work

Setting up Gratitude in Bitrix24 most often ends with enabling the section: a set of badges is selected, employees are shown where to click.

For the first weeks, marks are given, then activity drops to isolated cases, and a month later the recognition system on the portal lives its own life — it marks birthdays and years of service, not work.

The disconnect from tasks is the second reason. Gratitude cannot be sent from a task card, a manager does not mark a completed stage in one click, and an employee does not see the connection between their contribution and recognition.

Badges do not work as a signal: they are issued manually and out of context, they are tied neither to the result nor to the criteria by which they should be given at all.

The third is the lack of feedback at the manager level. While statistics are not collected, it is impossible to answer simple questions: who is recognized more often, for what types of work, which department has dropped out of the process entirely.

Without this data, there is nothing to manage recognition with: neither to refine criteria nor to show the team that contribution has been noticed.

Next, employee engagement is lost: a tool that gives neither quick reaction nor visible result simply stops being opened. Formally, recognition exists; whether it works is unclear. Let's break down how this is solved.

What Changes on the Portal After Recognition Setup

Recognition in Bitrix24 is not a feed of pleasant words but a feedback loop: to whom, for what, and how often thanks are said.

After correctly setting up rules, badges, and levels, the portal starts producing numbers that show whether the tool works or simply takes up space in the menu.

Recognition Statistics: Share of Employees Over a Period

We count by unique recipients, not by the number of records: the report shows what share of the team received at least one thank-you per month. On active portals, this share stays above half — if it is closer to a third, the contribution of half the people is simply not recorded.

Newcomer Onboarding Speed

A badge for the first completed stage or a thank-you from a mentor gives a newcomer a point of support earlier than the formal onboarding period. The log shows on which day a person receives their first recognition — and this period is reduced severalfold, not by percentages.

Transparency of Department Contribution Assessment

Rules are tied to a department and type of merit, so a cross-section by department shows where helping colleagues has become the norm and where it has not. A manager gets a comparable picture across all areas instead of subjective impressions.

Eliminating the Failure Class 'Setup Exists, No Result'

We separately check that badges are not issued manually by a narrow circle and that recipients see notifications — otherwise activity fades after a couple of weeks. Together with levels and auto-reminders, the flow of recognition remains steady rather than a spike after launch.

Modes of Awarding Gratitude and Badges in Bitrix24

Awarding gratitude in Bitrix24 is based on three approaches: a person issues a badge, a rule assigns it based on portal events, or a combination works.

The choice is dictated not by administrator convenience but by how much an employee's result is already formalized in the portal data — a closed task, a deal stage, an entry in the knowledge base.

Thresholds and levels are set as a second layer. The awarding rule counts points or a streak, and the threshold converts them into the next badge — the employee sees how many steps remain to a new level.

Thresholds are fixed once and revised based on accumulated statistics, otherwise part of the team gets stuck at the lower level forever, and the badge stops meaning anything.

Implementation Stages: From Portal Audit to Handover of Regulations

Implementation begins not with setting up rules but with analyzing how the portal is currently structured: the real department structure, duplicates and archived departments, the access rights matrix for sections, groups, and entities, as well as who currently gives out thank-yous manually and on what occasion.

This picture determines which badge scheme will work at all and which will turn into manual distribution a month later and lose value.

1. Portal audit. We collect the structure of departments and groups, check rights for sections, profiles, tasks, and entities, and record manual points of issuing thank-yous. The result is a map that shows where an automatic rule will work and where it will hit closed rights or get lost in a department branch.
2. Badge scheme design. We define the list of events and awarding rules: what we give for, who confirms, what weight each badge has in the rating, and who can see it. Here we also decide what is awarded automatically and what remains with the manager.
3. Rule setup. We tie badges to deal stages, tasks, projects, and groups, set trigger conditions, frequency limits, and rights for manual issuance.
4. Test environment. We transfer the structure and rights to a separate portal or test group and run scenarios on a copy of real data without affecting production accounts.
5. Rule verification. We compare the awarding log with the expected logic: repeated awarding, rollback, rating recalculation, edge cases — transfer between departments, dismissal, long absence.
6. Corrections and rerun. We eliminate discrepancies, refine conditions, and check that rules do not fall apart after an organizational structure change.
7. Handover of regulations. We train the portal administrator: how to add an event, change badge weight, view awarding history, and what to do if there is a discrepancy in the report. We provide instructions and a description of the logic so that edits do not require us.

Set of Settings and Documentation on Output

Setup is considered complete not when badges appear in profiles, but when the portal can be handed over to another administrator without losing the logic. Therefore, the package includes not only configuration but also documents by which rules live, change, and are checked.

• Level scheme — how many points are needed for each level, how points for different types of thank-yous are counted, and what happens to the level when a record is removed.
• Access rights matrix — who awards, who removes, who approves disputed cases, and who edits the badge directory; breakdown by roles and departments.
• Recognition regulation — which actions are considered grounds for a thank-you, by what deadline it must be confirmed, and under what conditions the record is annulled.
• Configured rules for awarding and revoking — binding to business processes and robots, trigger conditions, notifications to participants, and automatic removal when a task is canceled.
• Administrator instructions — how to add a badge, change a level threshold, roll back an unsuccessful rule, and where to view the settings change log.
• Manager memo — how to issue and revoke a thank-you, which comments are mandatory, and within what deadlines to respond to a disputed situation.
• Portal documentation — a settings map with links to sections, a diagram of how levels relate to the org structure, and the procedure for synchronizing departments from the accounting system.
• Reporting — which cross-sections by badges and levels are displayed on the dashboard, how often to pull them, and how to read discrepancies.

Case Study: Fragmented Badges in a Retail Chain — What Changed

A chain of several dozen retail locations came with a typical problem: employee recognition lived in local chats. Each location manager issued thank-yous according to their own arrangements — in some places for exceeding the plan, in others for covering a shift.

Badges in profiles accumulated unsystematically, and the HR service had no consolidated picture: who received recognition for the quarter and who was never recognized.

What Was Changed

On the Bitrix24 portal, a single scheme was assembled instead of local rules.

A badge directory with transparent issuance conditions was created, badges were tied to departments and roles, and automatic thank-yous were configured for events: closing a task, mentoring, length of service.

Manual issuance was left as one action from the employee card — without approvals or chat correspondence.

Metrics Before and After

Before implementation, 22% of employees received recognition for the quarter, and active managers — those who issued at least one thank-you — accounted for 31%.

After launching the single scheme, the share of employees with recognition grew to 68%, and the share of active managers to 84%: a location manager now sees ready-made occasions and spends seconds marking an employee, rather than initiative and time on paperwork.

Reporting also stopped being manual: a cross-section by location, department, and period is built in the portal without exports to spreadsheets.

Employees of the distributed chain see recognition of colleagues from other cities, and recognition no longer depends on how active a particular manager is.

How Achievement Badges Differ from Public Recognition

Both mechanisms live in the same employee profile and the same feed, so they are often confused. The difference is in the source of truth: an achievement badge records a fact confirmed by data — closed tasks, a completed plan.

Public recognition is an action by people: a colleague or manager explicitly notes a contribution, and the value here is in the gesture itself, not in the number.

Hence the different life cycles. A badge is awarded by a rule based on an event and lives as long as the condition remains met: if the task is rolled back, the mark goes away.

Recognition is tied to a moment and an author, lives as a feed entry, and over time loses weight, but it influences visibility within the team. In Bitrix24, they have different trigger rules and destination points — mixing them in one counter is not worth it.

Duplication of awards is the most common implementation defect. It is treated by separation: a fact is written to one directory, social evaluation to another, and the aggregate for the rating is calculated on the fly.

The rule must be idempotent by the pair 'employee + condition + period', otherwise a repeated processing run will add weight a second time.

The choice of tool is dictated by the question you are answering. If you need a measurable indicator and a transparent history, you set up badges. If you need to enable mutual feedback, you start with public recognition.

A workable scheme is both mechanisms, but with different weights in the rating, otherwise the icon will begin to substitute for the result.

Frequent Questions on Awards, Rights, and Recognition History

Rights to issue thank-yous and badges in Bitrix24 are separated in the module settings: any active employee can thank colleagues, but only a role with a separate access level can assign badges. Below we analyze the situations administrators most often come with.

How can you protect against gaming?

Restrictions are set by rules: a daily limit of thank-yous, a ban on thanking yourself and the same colleague more than a set number of times, mandatory binding to a task or project.

Plus moderation — disputed records are sent to the administrator for confirmation, and gaming stops working.

What happens to recognition history when an employee is transferred?

History is tied to the profile, not to the department, so during a transfer it is preserved in full and visible in the new department.

Upon dismissal, the profile is deactivated, but records remain in the database: they are available in reports and in the card if the employee returns.

Our portal is already set up — do we have to redo everything?

No. First we inventory the current rules and badges, export the settings, and look for conflicts. Then we make targeted changes: adjust limits, add missing badges, and, if necessary, transfer history. Already issued thank-yous and titles remain untouched.

Let's Discuss the Task: Where to Start Setup on Your Portal

Setting up thank-yous and badges rests on three things: portal structure, role rights, and awarding rules. An error in any of them means that a month later everything has to be redone — already with accumulated statistics that need to be reset. Therefore, we start with a conversation, not with edits in the live feed.

To come back with an estimate of work and an implementation plan, at the first conversation we need inputs on the portal:

• structure: how many departments, divisions, and workgroups, and where visibility boundaries lie;
• roles and rights: who awards thank-yous, who approves badges, who sees consolidated reports;
• current state: which rules are already enabled, what works, and what fails;
• expected statistics: which engagement indicators are needed and how often to review them;
• stage deadlines: by what date a working environment is needed and when a mass launch is planned;
• connections with other portal blocks: tasks, CRM, external systems from which events come.

This is enough to propose an awarding scheme, a trigger threshold, and the procedure for displaying badges. Describe the task — we will come back with a stage-by-stage estimate and a work plan, where we separately note what launches immediately and what requires data preparation.