Разработка гибридной системы геймификации и мотивации операторов

Крупная финансовая организация столкнулась с классической проблемой "обезличенного" труда операторов. Стандартная KPI-система (проценты и планы) перестала мотивировать сотрудников. Руководство поставило амбициозную задачу: превратить рутинную выдачу кредитов и оформление услуг в увлекательный процесс с элементами игры, сохранив при этом строгий финансовый учет и исключив возможность махинаций.

Ключевая сложность заключалась в том, что мотивационная система должна была стать "прозрачной" для бизнеса: бонусы нельзя просто дарить, они должны быть заработаны и окупаться.

Архитектурные и проектные решения

Проект изначально позиционировался как отдельный микросервис (модуль), а не доработка монолитного Личного кабинета. Это решение позволило изолировать бизнес-логику геймификации и обеспечить высокую нагрузку (до 200 групп по 3000 пользователей).

1. "Реактивная" обработка событий

Мы построили систему на базе event-driven архитектуры, что позволило обрабатывать потоковые данные в реальном времени без потерь производительности.

• Входящий поток: Модуль подписан на топики Kafka (конвейер сообщений), куда основная система сбрасывает все события по сделкам. В пиковые нагрузки через систему проходит огромное количество транзакций, и важно было не создавать узких мест.

• Умная предварительная фильтрация: Прежде чем запускать ресурсоемкие процессы начисления бонусов и проверки условий, система выполняет быстрый префильтр. Модуль анализирует входящий поток и "выдергивает" только те события, которые:

  • относятся к операторам, являющимся участниками активных акций (проверка по ID оператора и группе управления);

  • содержат продукты, участвующие в бонусной программе (кредиты, страховки, доп. услуги);

  • соответствуют минимальным пороговым значениям (например, сумма кредита > 10 000 руб.).

Это позволило отсеивать до 70% "шума" еще на входе, не нагружая ядро системы бесполезными вычислениями.

• Фильтрация второго уровня: После первичного отбора, данные попадают в процессор правил, где анализируются на соответствие критериям конкретной акции (например, "кредит + страховка + ставка выше 21%").

• Ключевая особенность — мультиактивность: Мы предусмотрели сценарий, при котором одна сделка может триггерить достижения сразу в нескольких параллельных акциях. Архитектурно это было реализовано через механизм "брокера правил": событие проходит через список активных промо-кампаний, и каждая кампания независимо проверяет, является ли данная сделка достижением именно для нее. Например, один и тот же кредит со страховкой мог приносить монеты и в акции "Путевка на море", и в акции "Новичок месяца". Система корректно обрабатывала такие пересечения, не создавая двойных списаний и конфликтов.

• Масштабируемость: Такой подход с двухуровневой фильтрацией позволил нам легко масштабировать систему до 200 одновременно работающих акций и 3 000 участников в каждой группе, так как большая часть данных отбрасывалась на самом раннем этапе, не доходя до сложной бизнес-логики.

2. Работа со сложными счетчиками

Мы реализовали два типа счетчиков целевых показателей, что позволило создавать разные сценарии мотивации:

• Однократные счетчики: Идеально для обучения (выдай первый кредит — получи медаль). Достиг уровня — получил награду, счетчик умер.

• Многократные (возобновляемые) счетчики: Для постоянной мотивации. Оператор набрал сумму кредитов на 100 000 руб. — получил N монет. Счетчик сбросился в ноль, и копим заново. Это создает эффект "бесконечной" игры без потолка.

3. "Умный" виджет

Вместо того чтобы заставлять оператора заходить на отдельный портал, мы разработали JS-виджет, встраиваемый прямо в интерфейс ЛК.

• Идентификация: Мы предложили схему двухфакторной аутентификации через составной токен. Это позволило автоматически авторизовать пользователя в виджете и подгрузить его текущие данные и акции. 

• Обратная связь: Виджет умеет показывать не только статистику, но и интерактивные сообщения: подтверждения действий, опросы ("Как вам новая акция?"). Сообщения имели "срок жизни" и исчезали, если оператор на них не реагировал.

4. Механика "Билетной лотереи" 

Самая интересная часть с точки зрения математики и доверия.

• Эмиссия билетов: При покупке билета за монеты, система генерировала порядковый номер билета в пуле и присваивала ему рандомный номер (от 0001 до 9999). Это разделение нужно для того, чтобы мы знали, кому принадлежит билет, но номер для розыгрыша был случайным.

  Заказчик пожелал отказаться от классического случайного формата. Вместо этого используется привязка к внешнему, неподконтрольному нам источнику — например, к курсу юаня ЦБ РФ.

• Пример: Курс 11,6295 → ищем билет с номером 6295.

• Нюанс: Если такого номера нет, то берем следующий билет по возрастающей.

• Доверие: Ни мы, ни заказчик не можем "назначить" победителя, так как курс публикуется ЦБ и не зависит от нас.

5. Транзакционная целостность и отмена бонусов

Самый сложный момент с точки зрения проектирования БД и логики.

• Проблема: Оператор получил кредит, купил на бонусы билеты, выиграл приз. Через неделю клиент закрыл кредит досрочно и отказался от страховки. Деньги банка за приз потрачены, бонусы у оператора остались.

• Решение: Мы внедрили механизм "обратного списания" по чек-поинтам. Если приходит событие refund или cancellation по сделке, система ищет все начисления, связанные с этой сделкой, и списывает эквивалентное количество монет. Если монет на балансе нет (потрачены на билеты), баланс уходит в минус (технический долг). Пока оператор не закроет этот минус новыми продажами, он не может покупать билеты. Это повысило ответственность операторов и мотивировало их следить за качеством продаж, а не только за количеством.

6. Кастомные стили (White Label)

Мы спроектировали админ-панель так, что маркетолог мог создать новый "стиль" одним действием:

• Виджет менял цветовую гамму.

• Терминология: Массово заменялись слова "Бонусы" на "Монеты", "Достижения" на "Майнинг", "Розыгрыш" на "Пул".

• Ассеты: Подгружались уникальные иконки (медали, финики, звезды) в зависимости от тематики акции.

Интересные моменты реализации

1. Подарочные билеты: В ТЗ был пункт о том, что билеты можно дарить бесплатно. Мы реализовали это через отдельный тип транзакции (gift), которая не требовала списания монет, но создавала точно такой же номерной билет в пуле. Это позволило поощрять отстающих, не выбивая их из игровой механики.

2. Памятные знаки как элемент коллекционирования: Мы добавили раздел "Награды", куда зачислялись значки за первые действия. Это создало эффект коллекционирования — операторы стремились собрать полный "сет" наград (медаль, знак за страховку, знак за допуслугу), что дополнительно повышало активность.

3. Промежуточные розыгрыши: Мы настроили систему так, что билет, выигравший промежуточный приз (кружку), не удалялся из розыгрыша главного приза (путевки). Это добавило азарта: "Сегодня выиграл кружку, а вдруг через месяц и путевку тем же билетом?".
   

История оператора: как монеты превращаются в путевку

Старт. Анна заходит в ЛК, видит виджет и получает 300 приветственных монет. Сразу покупает первый билет — получает памятный значок «Первый билет».

Майнинг. Оформляет кредит 200 000 ₽ со страховкой. Система ловит событие, проверяет условия и начисляет 2000 монет. Анна видит всплывающее окно popup: «+2000 монет!» и новые значки в профиле.

Билеты. Накопив 5000 монет, покупает еще 10 билетов. Теперь у нее 11 номеров в пуле.

Промежуточный выигрыш. Курс юаня 11,4490 → выигрышный номер 4490. У Анны есть ближайший — она получает корпоративную кружку. Билет продолжает участвовать в главном розыгрыше.

Отмена. Клиент отказывается от страховки. Система списывает 2000 монет. Баланс уходит в минус — новые билеты покупать нельзя, пока не закроет долг. Анна понимает: халявы нет, надо работать качественно.

Главный приз. Конец акции, курс 11,8150. У Анны билет 8149 — он оказывается ближайшим к выигрышному 8150. Анна выигрывает путевку на море.

Итог для бизнеса: качественные продажи, защита бюджета от отмен, вовлеченный оператор, который теперь мотивирует коллег личным примером.