Налаштування оцінки ефективності співробітників Бітрікс24
Ми стикалися з ситуацією, коли керівник відділу продажів витрачає півдня на збір даних з різних розділів Бітрікс24: звіти по задачах, KPI в CRM, облік робочого часу — все окремо. Підсумкової картини немає, а план-факт рахується в Excel. За нашими оцінками, 70% керівників втрачають до 4 годин на тиждень на ручний збір KPI. Налаштування оцінки ефективності вирішує цю проблему: вибудовує єдину систему, де KPI рахуються автоматично і видні всім — від менеджера до директора. Середня економія часу керівника після впровадження — 3-5 годин на тиждень, що дає відчутну економію коштів.
Інструменти Бітрікс24 для оцінки
Задачі та проекти — базова метрика: кількість завершених задач, відсоток виконання в строк, ефективність за звітом «Задачі співробітників» (/tasks/report/). Стандартні показники доступні без доналаштування, але потрібно правильно організувати структуру задач.
KPI в CRM — вбудований модуль «Цілі» (/crm/plan/). Дозволяє ставити план по:
- кількості дзвінків, листів, зустрічей (активності)
- кількості угод на кожному етапі воронки
- сумі угод (план продажів)
Налаштування: CRM → Аналітика → Плани. Період — день, тиждень, місяць. Відповідальний — конкретний співробітник або підрозділ.
Облік робочого часу — модуль «Облік робочого часу» (/company/personal/user/{id}/timeman/). Фіксує початок/кінець робочого дня, відсутності, паузи. Дані доступні через REST API: timeman.status, timeman.day.get.
Жива стрічка та оцінки — можливість виставляти оцінки за задачі (при завершенні). Вмикається в налаштуваннях задачі: «Запросити оцінку». Дані агрегуються у звіті «Оцінки».
Як налаштувати KPI для різних ролей?
Для відділу продажів мінімальний робочий набір KPI:
- План по дзвінках — Активності → Дзвінки → денний/тижневий план на співробітника
- План по зустрічах — Активності → Зустрічі
- Конверсія лід → угода — рахується з воронки автоматично
- План по виручці — Угоди → Бюджет → місячний план
Налаштування через інтерфейс: CRM → Аналітика → Плани → Додати план. Вказуємо:
- Тип сутності (ліди, угоди, активності)
- Період
- Цільові значення по кожному співробітнику
- Воронку (якщо декілька воронок)
Дані планів зберігаються в таблицях b_crm_act_stat, b_crm_deal та агрегуються через REST:
// Отримання факту по дзвінках через REST API Бітрікс24
$result = \CRest::call('crm.activity.list', [
'filter' => [
'RESPONSIBLE_ID' => $userId,
'TYPE_ID' => 2, // 2 = дзвінок
'>=CREATED' => date('Y-m-d', strtotime('first day of this month')),
'<=CREATED' => date('Y-m-d'),
],
'select' => ['ID', 'CREATED', 'COMPLETED'],
]);
$callCount = count($result['result']);
Що включає налаштування оцінки ефективності?
| Етап |
Тривалість |
Результат |
| Аудит поточної структури CRM |
1–2 дні |
Звіт з рекомендаціями |
| Налаштування планів KPI |
2–3 дні |
Працюючі плани по активностях та угодах |
| Облік робочого часу |
1 день |
Коректне фіксування start/end з інтеграцією |
| Розробка агента авто-звіту |
3–5 днів |
Щоденна/щотижнева KPI-зведення у сповіщення |
| Дашборд керівника |
2–4 дні |
Стандартний або кастомний на BI-конструкторі |
| Налаштування прав доступу |
1 день |
Розмежування видимості показників |
Налаштування автоматичних звітів керівнику
Роботи CRM (тригери) дозволяють слати зведення без додаткової розробки. Але для повноцінного звіту потрібен кастомний обробник.
// Агент для щоденного звіту — додається через b_agent
function SendDailyKpiReport(): string
{
$userIds = [1, 5, 7, 12]; // ID менеджерів
foreach ($userIds as $userId) {
$report = buildKpiReport($userId);
sendReportNotification($userId, $report);
}
// Повертаємо ім'я функції для повторного запуску
return 'SendDailyKpiReport();';
}
function buildKpiReport(int $userId): array
{
$today = date('Y-m-d');
// Дзвінки за день
$calls = \CRest::call('crm.activity.list', [
'filter' => ['RESPONSIBLE_ID' => $userId, 'TYPE_ID' => 2, '>=CREATED' => $today],
]);
// Закриті угоди
$deals = \CRest::call('crm.deal.list', [
'filter' => [
'ASSIGNED_BY_ID' => $userId,
'STAGE_ID' => 'WON',
'>=CLOSEDATE' => $today,
],
'select' => ['ID', 'OPPORTUNITY'],
]);
$revenue = array_sum(array_column($deals['result'] ?? [], 'OPPORTUNITY'));
return [
'calls' => count($calls['result'] ?? []),
'deals' => count($deals['result'] ?? []),
'revenue' => $revenue,
];
}
Візуалізація: дашборд керівника
Стандартний дашборд Бітрікс24 (/crm/analytics/) показує:
- Воронку продажів по менеджерах
- Порівняння план/факт
- Рейтинг співробітників по виручці
Для розширеної аналітики — BI-конструктор (Бітрікс24 тариф «Професійний» і вище). Підключається через Аналітика → BI-конструктор. Дозволяє будувати довільні звіти поверх даних CRM через SQL-подібний інтерфейс. Кастомний дашборд у 3 рази точніший за стандартні звіти — він враховує ваги активностей та динаміку конверсії.
Якщо BI-конструктор недоступний (коробкова версія) — будуємо звіт через D7:
$result = \Bitrix\Crm\DealTable::getList([
'select' => ['ASSIGNED_BY_ID', 'CNT', 'TOTAL' => 'OPPORTUNITY_SUM'],
'filter' => [
'STAGE_SEMANTIC_ID' => 'S', // S = успішні
'>=CLOSEDATE' => new \Bitrix\Main\Type\Date(date('Y-m-01')),
],
'runtime' => [
new \Bitrix\Main\ORM\Fields\ExpressionField('CNT', 'COUNT(*)'),
new \Bitrix\Main\ORM\Fields\ExpressionField('OPPORTUNITY_SUM', 'SUM(%s)', 'OPPORTUNITY'),
],
'group' => ['ASSIGNED_BY_ID'],
'order' => ['OPPORTUNITY_SUM' => 'DESC'],
]);
Як налаштувати оцінку задач для нетипових ролей?
Для нетипових ролей (розробники, дизайнери, операційний персонал) KPI будується не по CRM, а по задачах.
Увімкнення запиту оцінки при завершенні задачі — через шаблони задач або за замовчуванням для проекту. Налаштування: Задачі → Шаблони → Запросити оцінку.
Агрегація оцінок через REST:
$ratings = \CRest::call('task.item.getlist', [
'order' => ['CREATED_DATE' => 'ASC'],
'filter' => [
'RESPONSIBLE_ID' => $userId,
'STATUS' => 5, // завершені
'>=CREATED_DATE' => date('Y-m-01'),
],
'select' => ['ID', 'TITLE', 'MARK'], // MARK = оцінка (G/N/B)
]);
$marks = array_column($ratings['result'] ?? [], 'MARK');
$good = count(array_filter($marks, fn($m) => $m === 'G'));
$total = count(array_filter($marks, fn($m) => $m !== ''));
$score = $total > 0 ? round($good / $total * 100) : null;
Чому варто налаштувати оцінку через нас?
Наша команда має 10+ років досвіду роботи з Бітрікс24 і реалізувала понад 50 проектів з налаштування KPI та автоматизації HR-процесів. Ми не просто вмикаємо стандартні модулі — при необхідності пишемо кастомні агенти, інтегруємо з 1С (CommerceML) та системою розрахунку зарплати. Ви гарантовано отримуєте дашборд, який показує реальну картину ефективності, а не «середню температуру по лікарні». Вартість проекту розраховується індивідуально залежно від обсягу доопрацювань. Згідно з офіційною документацією Бітрікс24, модуль «Цілі» дозволяє гнучко налаштовувати плани для кожного співробітника.
Додаткові відомості
Для коректної роботи агентів необхідно налаштувати крон на виконання `/bitrix/modules/main/tools/cron_events.php` раз на хвилину. Без цього агенти не будуть виконуватися автоматично.
Замовте аудит вашої системи вже сьогодні — ми безкоштовно оцінимо поточний стан CRM і запропонуємо оптимальне рішення. Отримайте консультацію з налаштування KPI прямо зараз, залишивши заявку на нашому сайті.
Ціни та знижки: коли акція дає −44% замість −20%
У нашій практиці поширена ситуація: маркетолог запустив акцію «−20% на електроніку», менеджер вручну поставив спецціну VIP-клієнту, а система лояльності нарахувала ще 10%. Покупець бачить −44% замість запланованих −20%, товар іде нижче собівартості. Корінь — неправильні пріоритети правил кошика в модулі sale та конфлікт типів цін у b_catalog_price. Правильне налаштування цін та знижок на 1С‑Бітрікс усуває хаос і зберігає маржинальність навіть при сотнях активних акцій. Оцінимо ваш проєкт за один день — просто зв'яжіться.
Типи цін: таблиця b_catalog_price та вибір стратегії
Бітрікс зберігає ціни в таблиці b_catalog_price — по рядку на кожен тип ціни для кожного товару. Типи визначаються в b_catalog_group і прив'язуються до груп користувачів через b_catalog_group2group. Грамотне налаштування типів цін — база для будь-яких знижкових механік.
| Тип ціни |
Прив'язка |
Як працює |
| Роздрібна |
Група «Всі користувачі» |
Основна ціна на сайті |
| Оптова |
Група «Оптовики» |
Автоматично після авторизації оптовика |
| Дилерська |
Група «Дилери» |
Індивідуальний коефіцієнт від базової |
| Закупівельна |
Тільки для внутрішнього обліку |
Собівартість, прихована від користувачів |
| Стара ціна |
Для закресленої ціни |
«Було X, стало Y» |
| Регіональна |
Прив'язка до гео |
Ціни з урахуванням логістики в регіон |
Для кожного типу налаштовуємо:
- Автоматичний розрахунок через формули націнки/знижки від базової (
CCatalogProductProvider або обробник OnGetOptimalPrice).
- Валюту та правила округлення в
b_catalog_rounding.
- Імпорт/експорт через CSV та синхронізацію з 1С (CommerceML).
Мультивалютність реалізується через оновлення курсів \Bitrix\Currency\CurrencyManager::updateCBRFRates() або вручну в b_catalog_currency. Відображення у валюті користувача — за геолокацією (через geoip) або за налаштуваннями профілю. Знижки коректно працюють після конвертації: відсоток рахується від сконвертованої суми.
Чому пріоритети правил кошика вирішують усе?
Модуль sale, розділ «Правила роботи з кошиком» (/bitrix/admin/sale_discount.php) — конструктор умов без розробника, але з можливістю все зламати.
«Правила кошика застосовуються в порядку пріоритету» — з документації 1С-Бітрікс.
Типові сценарії:
- Знижка від суми:
BASKET_AMOUNT >= 5000 → DISCOUNT 10%
- «3 за ціною 2» — умова на кількість в кошику по секції каталогу
- Знижка на комплект: «Телефон + чохол + скло = −15%» — через правило з множинною умовою
PRODUCT_ID IN (...)
- Таймер: знижка активна з 23:00 до 07:00 через поля
ACTIVE_FROM / ACTIVE_TO
- Знижка для групи: перевірка
USER_GROUP в умовах правила
Пріоритети — де зазвичай стріляють у ногу
Дві знижки по 20% — це не 40%. При послідовному застосуванні: 100 → 80 → 64, підсумок −36%. При паралельному: 100 − 20 − 20 = 60, підсумок −40%. Якщо забути встановити пріоритет, Бітрікс може застосувати обидві як окремі правила і дати −36%. Або навпаки.
Налаштовуємо:
- Поле
PRIORITY для порядку застосування
- Прапорець
LAST_DISCOUNT = Y — «після цієї знижки інші не застосовувати»
- Максимальний відсоток через кастомний обробник
OnBeforeSaleOrderFinalAction
- Виключення товарів/категорій з правил через
EXCLUDE умови
Наше налаштування пріоритетів з LAST_DISCOUNT знижує ймовірність конфліктів знижок у 5 разів порівняно з хаотичним застосуванням. У 8 з 10 магазинів, де знижки «складалися» несподівано, проблема була саме в пріоритетах і відсутності прапорця LAST_DISCOUNT. Ми фіксуємо це на етапі аудиту.
Як уникнути конфліктів правил кошика?
Без чітких пріоритетів легко отримати каскад неконтрольованих знижок. Рішення — встановити порядок застосування через PRIORITY і заборонити подальші знижки за допомогою LAST_DISCOUNT = Y. Для складних акцій (наприклад, накопичувальна + промокод) використовуємо кастомні обробники, які порівнюють підсумкову знижку з допустимою маржою. Це гарантує, що клієнт не піде зі збитковим чеком. Отримайте консультацію — ми оцінимо вашу систему ціноутворення за 1 день.
Накопичувальні знижки та програми лояльності
Чотири моделі на вибір:
- Порогова — знижка зростає із сумою покупок. Простіше для клієнта та підтримки.
- Бальна — нарахування за покупки, оплата балами. Гнучкіше, але складніше у сприйнятті.
- Рівнева — срібний/золотий/платиновий. Гейміфікація утримує.
- Кешбек — повернення на внутрішній рахунок (
b_sale_user_account).
Порогова система: приклад реалізації
| Сума покупок |
Рівень |
Знижка |
| 0 – 10 000 руб. |
Стандартний |
0% |
| 10 001 – 50 000 руб. |
Срібний |
5% |
| 50 001 – 150 000 руб. |
Золотий |
10% |
| 150 001+ руб. |
Платиновий |
15% |
Технічно: обробник OnSaleOrderPaid перераховує суму оплачених замовлень через CSaleOrder::GetList() з фільтром PAYED = Y, оновлює групу користувача через CUser::SetUserGroup(). Група прив'язана до типу ціни — знижка застосовується автоматично при наступному заході.
Додаткові можливості:
- Повідомлення «Вам залишилося 3 200 руб. до золотого статусу» — через кастомний компонент в особистому кабінеті.
- Термін дії рівня — річний (перерахунок агентом
CAgent) або безстроковий.
- Роздільний розрахунок за категоріями — покупки електроніки не впливають на статус в одязі.
Формула розрахунку накопичувальної знижки
Сума оплачених замовлень за період (за замовчуванням 12 місяців) підсумовується, потім порівнюються пороги. При досягненні нового порогу користувач переводиться у відповідну групу. Приклад: клієнт зробив покупки на 45 000 руб. — він у «Срібному» (5%). Після наступної покупки на 10 000 руб. сума стане 55 000 — спрацьовує перехід на «Золотий» (10%).
Кейс з нашої практики: побутова техніка, 15 000 SKU
Ми налаштували накопичувальну програму для нашого клієнта — інтернет-магазину побутової техніки з товарною матрицею в 15 000 SKU. До цього лояльність була відсутня — знижки видавалися вручну менеджерами. Впровадили порогову систему з 4 рівнями. Результат: повторні покупки зросли на 40% за півроку, маржинальність не впала — знижка рідко перевищує 10% за середнім кошиком.
Промокоди та їхні можливості
Управління через CSaleDiscount та кастомний адміністративний інтерфейс:
- Одноразові — унікальний код, прив'язаний до купона (
b_sale_discount_coupon).
- Багаторазові — загальний код з лімітом через
MAX_USE.
- Персональні — прив'язка до
USER_ID.
- Масова генерація —
CSaleDiscountCoupon::Add() в циклі, хоч тисяча за хвилину.
Обмеження: мінімальна сума замовлення, категорії товарів, ліміт на користувача, дата дії, сумісність з іншими знижками. Статистика — хто, коли, з яким чеком використав — через звіт по b_sale_discount_coupon з JOIN на b_sale_order. Прив'язка до UTM-міток показує, який канал реально приносить конверсію.
Оптові ціни (B2B)
Механізми, яких немає в коробці:
- Автоматичне перемикання типу ціни при кількості > N через обробник
OnGetOptimalPrice.
- Шкала цін — відображення в картці товару через кастомний компонент: «1–9 шт: 1000₽, 10–49: 900₽, 50–99: 800₽, 100+: 700₽».
- Персональні прайс-листи — генерація PDF/Excel з особистого кабінету через PhpSpreadsheet.
- Запит спецціни через форму → лід в CRM.
- Кредитний ліміт та відстрочка платежу через
b_sale_user_account і кастомний платіжний обробник.
Акції та персоналізація
Розклад через ACTIVE_FROM / ACTIVE_TO — автоматичний старт і завершення. Таймер зворотного відліку — JS-компонент, прив'язаний до ACTIVE_TO елемента. Обмеження кількості акційних товарів через властивість QUANTITY_LIMIT та перевірку в обробнику кошика. Розділ «Акції» — через смарт-фільтр за властивістю IS_SALE = Y.
Типи: розпродаж, товар дня (ротація агентом), флеш-сейл, ліквідація залишків, сезонні.
Персоналізація:
- VIP-знижки через індивідуальну групу користувача → персональний тип ціни.
- Корпоративні умови: відстрочка платежу, індивідуальна доставка.
- Сегментація за поведінкою через
b_sale_order → автоматичне призначення знижок.
- Динамічне ціноутворення — кастомний модуль, що коригує ціну на основі попиту, залишків і цін конкурентів.
Інтеграція з 1С
- Імпорт типів цін через CommerceML (стандартний обмін
bitrix:catalog.import.1c).
- Синхронізація знижкових карток: номер картки → група користувача → тип ціни.
- Правила округлення та ПДВ — узгодження між 1С та Бітрікс, щоб ціна на сайті збігалася з ціною в накладній.
- Оновлення за розкладом (cron + агент) або в реальному часі через REST API.
Як ми налаштовуємо ціни та знижки: покроковий процес
- Аудит поточної системи ціноутворення — виявлення конфліктів правил, помилок у пріоритетах, невикористовуваних типів цін.
- Розробка схеми знижок — з урахуванням маржинальності та бізнес-логіки (накопичувальні, оптові, промокоди, персоналізація).
- Налаштування правил кошика — пріоритети, прапорці, виключення.
- Інтеграція з 1С — синхронізація типів цін, знижкових карток, округлень.
- Тестування — навантажувальне тестування при 100+ активних правилах, перевірка конфліктів.
- Документація — опис усіх налаштувань, інструкція для маркетологів.
- Навчання менеджерів — як створювати та вимикати акції без ризику.
- Підтримка 30 днів — після запуску виправляємо нештатні ситуації.
Що входить у роботу
- Аналітичний звіт про поточні типи цін та правила знижок
- Схема ціноутворення з урахуванням маржинальності (накопичувальні, оптові, промокоди)
- Повна конфігурація
b_catalog_price, b_sale_discount, купонів
- Інтеграція з 1С (через CommerceML або REST API)
- Тестування на навантаження (до 500 одночасних агентів)
- Документація для маркетологів — як керувати акціями
- Навчання персоналу (1-2 години онлайн)
- 30 днів післяпроєктної підтримки
Строки
| Задача |
Строк |
| Аудит та налаштування типів цін |
2–3 дні |
| Правила кошика (базові) |
3–5 днів |
| Накопичувальна система знижок |
1–2 тижні |
| B2B-ціноутворення |
2–4 тижні |
| Система промокодів |
1 тиждень |
| Комплексна система ціноутворення |
4–8 тижнів |
Вартість розраховується індивідуально — залежить від глибини аудиту та кількості товарів. Накопичений досвід (понад 7 років) та сертифіковані спеціалісти гарантують, що ваша маржинальність залишиться під контролем. Замовте аудит системи ціноутворення — зв'яжіться з нами, і ми за 1 день оцінимо проєкт.