Корпоративная геймификация в Битрикс24 для технологической компании
8
Клиент - крупная технологическая компания с командой больше 1000 человек. Она разрабатывает инфраструктурные решения для операторов связи и крупных корпоративных заказчиков: продукты, которые работают на стыке телеком-инфраструктуры, интеграций и высоких требований к надежности.
У такой компании большая техническая команда, много внутренних процессов и отдельный фокус на удержании экспертизы внутри коллектива. Корпоративный портал на Битрикс24 уже развивался как внутренняя HR-среда: для сервисов, коммуникаций сотрудников и сценариев вовлечения.
Для большой распределенной команды портал должен быть не просто справочником или местом, куда сотрудник заходит по необходимости. Он может стать ежедневной точкой взаимодействия с компанией: здесь сотрудники пользуются внутренними сервисами, участвуют в жизни команды, благодарят коллег, предлагают идеи и получают понятную обратную связь.
Компания решила усилить этот сценарий через геймификацию. Идея была не в том, чтобы связать игровые механики с KPI или продажами, а в том, чтобы сделать внутренние HR-процессы заметнее и живее: мотивировать сотрудников отмечать вклад коллег, делиться идеями, получать признание за полезные действия и чаще возвращаться в корпоративный портал.
В первый объем вошли несколько связанных блоков:
Готовый модуль программы лояльности нужно было адаптировать под процессы заказчика. В проекте появились свои правила работы с кошельками, требования к начислениям и списаниям, сценарии администрирования магазина и интеграция с календарем мероприятий, который находится в смежной системе.
Отдельные блоки разрабатывались с нуля: банк идей, функциональность благодарностей и кошельки, в которых отображается движение баллов и лимитов на благодарности.
Для сотрудников это выглядит как единый маршрут внутри портала. Они могут получать благодарности, видеть начисления в кошельке, копить баллы и тратить их на мерч. Также они могут подавать идеи и отслеживать их движение по стадиям.
Для HR портал становится инструментом вовлечения. Вместо разрозненных активностей появляется система, где участие сотрудников фиксируется, идеи проходят понятный маршрут, а признание коллег становится частью ежедневной коммуникации.
Для администраторов и руководителей появляется управляемый слой: роли, статусы, модерация, назначение исполнителей, обработка заказов и контроль движения внутренней валюты.
Первый кошелек отражает накопленные баллы сотрудника. Это баланс, который формируется за полезные действия и может использоваться во внутреннем магазине, например для покупки корпоративного мерча.
К полезным действиям относятся участие в мероприятиях компании, спортивные активности, менторство, выступления, участие в конференциях и другие сценарии, которые заказчик решит включить в правила начисления.
Второй кошелек связан с благодарностями. Это отдельный лимит, который сотрудник может использовать, чтобы благодарить коллег. Баллы для благодарностей начисляются ежемесячно, имеют ограничения по использованию и сгорают в конце месяца, если не были потрачены.
Такой подход помогает поддерживать регулярную культуру признания: сотрудникам не нужно ждать формальной оценки сверху, они могут отмечать вклад коллег в повседневной работе. При этом разные кошельки не смешиваются между собой, потому что у них разные задачи и разные правила движения баллов.
Поэтому в системе разделены "баллы" и "благодарности": баллы можно накапливать и обменивать на мерч, а благодарности используются для ежемесячного признания коллег.
Благодарность может отправить любой сотрудник. Это важная часть логики: признание идет не только сверху от руководителя или HR, а от человека, который действительно хочет отметить вклад коллеги.
В модуле реализован раздел благодарностей. Сотрудник выбирает коллегу, тип благодарности и оставляет комментарий. Получатель видит благодарность в отдельной ленте и в своем профиле.
Каждая благодарность связана с бейджем. Бейджи отличаются визуально, могут зависеть от роли пользователя и иметь разную стоимость в баллах. При получении благодарности сотруднику начисляются внутренние баллы.
Отдельно был добавлен механизм простого расширения набора бейджей через новый инфоблок. Администраторы смогут добавлять собственные бейджи без отдельной разработки, а в стартовый комплект уже входят пять новых бейджей.
Логика лимитов по благодарностям остается отдельным предметом настройки. Для кейса важно зафиксировать сам принцип: благодарности становятся регулярным инструментом признания, а не разовой ручной активностью HR.
Сотрудники смогут тратить накопленные баллы на корпоративный мерч: футболки, рюкзаки, куртки и другие позиции, которые заказчик решит добавить в каталог.
В текущем объеме магазин запускается без полноценной автоматизации складских остатков. Это сознательное упрощение первого релиза: мерча пока немного, поэтому остатки и заказы удобнее обрабатывать вручную.
За обработку заказов отвечают администраторы магазина на стороне заказчика. Обычно это несколько сотрудников HR или другой внутренней команды, которым выдан доступ. Они видят заказы, сверяют наличие товаров и вручную меняют статусы.
При этом сценарий можно развивать дальше. Если объем мерча и заказов вырастет, в следующих итерациях можно реализовать полноценную автоматизацию интернет-магазина: учет остатков, списание товаров после заказа и более детальную логику обработки заявок.
В проекте не закладывалась интеграция с Outlook или Контур.Толк. Вместо этого геймификация должна быть связана с календарем мероприятий, который разрабатывает другой подрядчик.
Календарь нужен для планирования и отображения внутренних активностей: спортивных событий, корпоративных встреч и других мероприятий компании. Геймификационный контур учитывает участие сотрудника в мероприятиях и начисляет за него баллы.
По актуальной логике баллы начисляются за участие во всех мероприятиях, в которых участвовал сотрудник.
Базовая логика выглядит так: сотрудник заполняет форму идеи, идея попадает на рассмотрение, проходит модерацию и дальше двигается по канбан-стадиям. Инициатор получает уведомления о смене статуса, поэтому идея не пропадает в переписке и не остается без обратной связи.
В форме подачи идеи предусмотрены:
Идея должна проходить двухуровневое согласование. Сначала ее смотрит эксперт по категории. Эксперт может отклонить идею с указанием причины, согласовать и отправить руководителю или вернуть инициатору на доработку.
После эксперта идея попадает к руководителю. Руководитель принимает финальное решение, назначает исполнителя или команду и определяет сложность идеи: простая, средняя или сложная. От сложности в дальнейшем должно зависеть начисление коинов при реализации.
Если идея принята, она переходит в работу. Если реализована, ее видят все сотрудники. При этом у HR-модератора должна быть возможность скрыть идею от всех, кроме модераторов.
Если идея отклонена, это финальный статус. Для случаев, когда идею можно улучшить, используется отдельный сценарий доработки.
В системе участвуют:
Уведомления остаются внутри портала: инициатор видит, что идея перешла на следующий этап, а ответственные участники процесса получают сигнал о своих действиях.
Такой уровень уведомлений важен для HR-сценария: сотрудник должен понимать, что его идея действительно движется, а ответственные участники процесса не пропускают задачи.
Если в системе есть два типа кошельков, начисления, списания и товары, важно заранее определить, какие действия вознаграждаются, кто может начислять баллы, чем баллы отличаются от благодарностей, как обрабатываются спорные ситуации и как система защищается от некорректного использования.
На старте было принято решение детально продумать концептуальную логику начислений и списаний, чтобы внутренние баллы нельзя было использовать недобросовестно. Это не отдельная "надстройка безопасности", а часть нормального проектирования мотивационной системы.
Вторая сложность - изменение требований. Пока проект обсуждался, появлялись новые процессы, функции и ожидания. В работу пошла не вся большая концепция, а ее практическая часть: программа лояльности, кошельки, благодарности, бейджи, магазин мерча, интеграция с мероприятиями и банк идей.
Третья сложность - несколько участников проекта. Календарь мероприятий находится в смежной системе и разрабатывается другим подрядчиком, а PWD отвечает за свой контур геймификации. Поэтому важно было заранее определить точки интеграции и не описывать мероприятия как отдельный раздел внутри корпоративного портала.
В результате портал получает:
Измеримый эффект можно будет оценить после запуска: сейчас у команды еще нет точных цифр по благодарностям, идеям и активности сотрудников. Главный ожидаемый эффект - рост вовлеченности и активности сотрудников в корпоративном портале.
Для HR появляется инструмент, который помогает развивать вовлеченность не через разовые активности, а через постоянную механику внутри портала. Участие сотрудников фиксируется, идеи проходят понятный маршрут, а благодарности становятся частью культуры признания.
Для руководителей и администраторов решение дает управляемость: роли, статусы, согласования, назначение исполнителей, контроль начислений и обработка заказов собраны в одном контуре.
У такой компании большая техническая команда, много внутренних процессов и отдельный фокус на удержании экспертизы внутри коллектива. Корпоративный портал на Битрикс24 уже развивался как внутренняя HR-среда: для сервисов, коммуникаций сотрудников и сценариев вовлечения.
Для большой распределенной команды портал должен быть не просто справочником или местом, куда сотрудник заходит по необходимости. Он может стать ежедневной точкой взаимодействия с компанией: здесь сотрудники пользуются внутренними сервисами, участвуют в жизни команды, благодарят коллег, предлагают идеи и получают понятную обратную связь.
Компания решила усилить этот сценарий через геймификацию. Идея была не в том, чтобы связать игровые механики с KPI или продажами, а в том, чтобы сделать внутренние HR-процессы заметнее и живее: мотивировать сотрудников отмечать вклад коллег, делиться идеями, получать признание за полезные действия и чаще возвращаться в корпоративный портал.
Задача
Перед PWD стояла задача доработать корпоративный портал клиента и внедрить в него программу лояльности с внутренней системой мотивации.В первый объем вошли несколько связанных блоков:
- программа лояльности на базе готового модуля PWD;
- два типа внутренних кошельков с разной логикой;
- начисление и списание баллов;
- благодарности между сотрудниками;
- бейджи, связанные с благодарностями и признанием заслуг;
- внутренний магазин мерча;
- интеграция с внешним календарем мероприятий;
- банк идей как отдельный смарт-процесс;
- ролевая модель для сотрудников, HR, руководителей и администраторов.
Готовый модуль программы лояльности нужно было адаптировать под процессы заказчика. В проекте появились свои правила работы с кошельками, требования к начислениям и списаниям, сценарии администрирования магазина и интеграция с календарем мероприятий, который находится в смежной системе.
Отдельные блоки разрабатывались с нуля: банк идей, функциональность благодарностей и кошельки, в которых отображается движение баллов и лимитов на благодарности.
Решение
Мы адаптируем программу лояльности под корпоративный портал клиента и собираем вокруг нее несколько HR-сценариев.Для сотрудников это выглядит как единый маршрут внутри портала. Они могут получать благодарности, видеть начисления в кошельке, копить баллы и тратить их на мерч. Также они могут подавать идеи и отслеживать их движение по стадиям.
Для HR портал становится инструментом вовлечения. Вместо разрозненных активностей появляется система, где участие сотрудников фиксируется, идеи проходят понятный маршрут, а признание коллег становится частью ежедневной коммуникации.
Для администраторов и руководителей появляется управляемый слой: роли, статусы, модерация, назначение исполнителей, обработка заказов и контроль движения внутренней валюты.
Баллы и кошельки
Внутренняя система мотивации строится вокруг баллов и двух типов кошельков.Первый кошелек отражает накопленные баллы сотрудника. Это баланс, который формируется за полезные действия и может использоваться во внутреннем магазине, например для покупки корпоративного мерча.
К полезным действиям относятся участие в мероприятиях компании, спортивные активности, менторство, выступления, участие в конференциях и другие сценарии, которые заказчик решит включить в правила начисления.
Второй кошелек связан с благодарностями. Это отдельный лимит, который сотрудник может использовать, чтобы благодарить коллег. Баллы для благодарностей начисляются ежемесячно, имеют ограничения по использованию и сгорают в конце месяца, если не были потрачены.
Такой подход помогает поддерживать регулярную культуру признания: сотрудникам не нужно ждать формальной оценки сверху, они могут отмечать вклад коллег в повседневной работе. При этом разные кошельки не смешиваются между собой, потому что у них разные задачи и разные правила движения баллов.
Поэтому в системе разделены "баллы" и "благодарности": баллы можно накапливать и обменивать на мерч, а благодарности используются для ежемесячного признания коллег.
Благодарности и бейджи
Один из ключевых сценариев - благодарности между сотрудниками.Благодарность может отправить любой сотрудник. Это важная часть логики: признание идет не только сверху от руководителя или HR, а от человека, который действительно хочет отметить вклад коллеги.
В модуле реализован раздел благодарностей. Сотрудник выбирает коллегу, тип благодарности и оставляет комментарий. Получатель видит благодарность в отдельной ленте и в своем профиле.
Каждая благодарность связана с бейджем. Бейджи отличаются визуально, могут зависеть от роли пользователя и иметь разную стоимость в баллах. При получении благодарности сотруднику начисляются внутренние баллы.
Отдельно был добавлен механизм простого расширения набора бейджей через новый инфоблок. Администраторы смогут добавлять собственные бейджи без отдельной разработки, а в стартовый комплект уже входят пять новых бейджей.
Логика лимитов по благодарностям остается отдельным предметом настройки. Для кейса важно зафиксировать сам принцип: благодарности становятся регулярным инструментом признания, а не разовой ручной активностью HR.
Магазин мерча
Второй прикладной сценарий - внутренний магазин.Сотрудники смогут тратить накопленные баллы на корпоративный мерч: футболки, рюкзаки, куртки и другие позиции, которые заказчик решит добавить в каталог.
В текущем объеме магазин запускается без полноценной автоматизации складских остатков. Это сознательное упрощение первого релиза: мерча пока немного, поэтому остатки и заказы удобнее обрабатывать вручную.
За обработку заказов отвечают администраторы магазина на стороне заказчика. Обычно это несколько сотрудников HR или другой внутренней команды, которым выдан доступ. Они видят заказы, сверяют наличие товаров и вручную меняют статусы.
При этом сценарий можно развивать дальше. Если объем мерча и заказов вырастет, в следующих итерациях можно реализовать полноценную автоматизацию интернет-магазина: учет остатков, списание товаров после заказа и более детальную логику обработки заявок.
Мероприятия
Еще один источник вовлеченности - корпоративные мероприятия. Сам календарь мероприятий находится в смежной системе, а портал получает связь с этим сценарием через геймификацию.В проекте не закладывалась интеграция с Outlook или Контур.Толк. Вместо этого геймификация должна быть связана с календарем мероприятий, который разрабатывает другой подрядчик.
Календарь нужен для планирования и отображения внутренних активностей: спортивных событий, корпоративных встреч и других мероприятий компании. Геймификационный контур учитывает участие сотрудника в мероприятиях и начисляет за него баллы.
По актуальной логике баллы начисляются за участие во всех мероприятиях, в которых участвовал сотрудник.
Банк идей
Банк идей - отдельный смарт-процесс внутри портала. Его задача - дать сотрудникам понятный способ предлагать улучшения и отслеживать, что происходит с предложенной идеей.Базовая логика выглядит так: сотрудник заполняет форму идеи, идея попадает на рассмотрение, проходит модерацию и дальше двигается по канбан-стадиям. Инициатор получает уведомления о смене статуса, поэтому идея не пропадает в переписке и не остается без обратной связи.
В форме подачи идеи предусмотрены:
- категория;
- название;
- описание;
- польза идеи;
- файл при необходимости.
Идея должна проходить двухуровневое согласование. Сначала ее смотрит эксперт по категории. Эксперт может отклонить идею с указанием причины, согласовать и отправить руководителю или вернуть инициатору на доработку.
После эксперта идея попадает к руководителю. Руководитель принимает финальное решение, назначает исполнителя или команду и определяет сложность идеи: простая, средняя или сложная. От сложности в дальнейшем должно зависеть начисление коинов при реализации.
Если идея принята, она переходит в работу. Если реализована, ее видят все сотрудники. При этом у HR-модератора должна быть возможность скрыть идею от всех, кроме модераторов.
Если идея отклонена, это финальный статус. Для случаев, когда идею можно улучшить, используется отдельный сценарий доработки.
Уведомления и роли
В проекте важно было продумать не только стадии, но и роли.В системе участвуют:
- рядовой сотрудник, который подает идеи, отправляет благодарности и участвует в активностях;
- HR, который модерирует систему и отвечает за часть внутренних процессов;
- эксперт по категории идеи;
- руководитель, который согласует идею и назначает исполнителей;
- администратор, который управляет настройками и магазином.
Уведомления остаются внутри портала: инициатор видит, что идея перешла на следующий этап, а ответственные участники процесса получают сигнал о своих действиях.
Такой уровень уведомлений важен для HR-сценария: сотрудник должен понимать, что его идея действительно движется, а ответственные участники процесса не пропускают задачи.
Сложности
Главная сложность проекта была не в том, чтобы добавить баллы или нарисовать витрину мерча. Нужно было спроектировать правила для внутренней экономики портала.Если в системе есть два типа кошельков, начисления, списания и товары, важно заранее определить, какие действия вознаграждаются, кто может начислять баллы, чем баллы отличаются от благодарностей, как обрабатываются спорные ситуации и как система защищается от некорректного использования.
На старте было принято решение детально продумать концептуальную логику начислений и списаний, чтобы внутренние баллы нельзя было использовать недобросовестно. Это не отдельная "надстройка безопасности", а часть нормального проектирования мотивационной системы.
Вторая сложность - изменение требований. Пока проект обсуждался, появлялись новые процессы, функции и ожидания. В работу пошла не вся большая концепция, а ее практическая часть: программа лояльности, кошельки, благодарности, бейджи, магазин мерча, интеграция с мероприятиями и банк идей.
Третья сложность - несколько участников проекта. Календарь мероприятий находится в смежной системе и разрабатывается другим подрядчиком, а PWD отвечает за свой контур геймификации. Поэтому важно было заранее определить точки интеграции и не описывать мероприятия как отдельный раздел внутри корпоративного портала.
Что получилось
PWD готовит корпоративный портал клиента к запуску HR-геймификации для большой команды.В результате портал получает:
- программу лояльности внутри Битрикс24;
- баллы для HR-активностей;
- два типа кошельков и историю транзакций;
- благодарности между сотрудниками;
- бейджи с возможностью добавлять новые через инфоблок;
- магазин мерча с ручной обработкой заказов;
- связь с календарем мероприятий в смежной системе;
- банк идей с модерацией и двухуровневым согласованием;
- роли для сотрудников, HR, экспертов, руководителей и администраторов.
Измеримый эффект можно будет оценить после запуска: сейчас у команды еще нет точных цифр по благодарностям, идеям и активности сотрудников. Главный ожидаемый эффект - рост вовлеченности и активности сотрудников в корпоративном портале.
Ценность для клиента
Для сотрудников портал становится более живой внутренней средой. В нем можно не только проходить обязательные HR-сценарии, но и благодарить коллег, видеть признание своего вклада, предлагать идеи и получать обратную связь.Для HR появляется инструмент, который помогает развивать вовлеченность не через разовые активности, а через постоянную механику внутри портала. Участие сотрудников фиксируется, идеи проходят понятный маршрут, а благодарности становятся частью культуры признания.
Для руководителей и администраторов решение дает управляемость: роли, статусы, согласования, назначение исполнителей, контроль начислений и обработка заказов собраны в одном контуре.
