Как вести бонусные баллы клиентов в CRM-системе

Бонусные баллы давно перестали быть простым подарком покупателю. Для финансового сайта и бизнеса, который работает с платежами, рассрочками, картами, подписками или программами лояльности, это полноценный цифровой актив внутри клиентской системы.

У него есть правила начисления, срок действия, стоимость для компании, ограничения по использованию и потенциальные налоговые последствия.

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

CRM-система позволяет собрать в одном контуре сведения о клиенте, операциях, бонусном счете и коммуникациях.

Но сама по себе CRM не делает учет правильным. Нужно заранее определить финансовую модель, структуру данных, порядок проведения операций, права сотрудников и контрольные процедуры.

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

Что такое бонусные баллы с точки зрения финансового учета

Бонусный балл - условная единица, которую компания начисляет клиенту за действие: покупку, оплату картой, использование сервиса, рекомендацию, своевременное погашение обязательства или участие в акции. В отличие от денег на банковском счете, баллы обычно нельзя свободно вывести, перевести на карту или использовать вне правил конкретной программы.

Однако для бизнеса они все равно имеют экономическую ценность: клиент может обменять их на скидку, товар, услугу, комиссионную льготу или иной бонус.

В CRM важно разделять номинал балла и его реальную себестоимость. Например, один балл может давать скидку в один рубль, но фактические расходы компании будут ниже, если часть клиентов не использует баллы, выбирает товары с высокой маржой или сталкивается с ограничениями программы.

В финансовой модели обычно рассматривают как минимум четыре показателя: начислено, списано, сгорело и находится в резерве. Простое поле "баланс" для этого недостаточно.

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

Текущий баланс = начисленные баллы − списанные баллы − сгоревшие баллы + возвращенные баллы.

Если клиенту отменили покупку, связанное начисление обычно нужно сторнировать. Если ранее списанные баллы возвращаются, CRM должна создать отдельную операцию возврата, а не просто вручную увеличить баланс.

Такой подход сохраняет историю и помогает ответить на вопросы службы поддержки, внутреннего контроля и бухгалтерии.

В финансовой сфере особенно важна юридическая точность формулировок. Если баллы фактически работают как электронные деньги, могут возникнуть дополнительные требования к договору, информированию клиента и внутреннему контролю.

Поэтому до настройки CRM стоит привлечь юриста и финансового специалиста: программа лояльности не должна случайно обещать клиенту больше, чем компания способна исполнить.

Какие данные хранить в CRM

Базовая карточка клиента должна содержать не только общий остаток.

Минимальная структура включает идентификатор участника, статус программы, уровень лояльности, дату подключения, согласия на обработку данных, дату последнего изменения баланса и историю операций.

Если программа связана с финансовыми продуктами, дополнительно нужны сведения о договоре, тарифе, канале подключения и признаке прохождения обязательной идентификации, если это требуется для конкретной услуги.

Баланс лучше хранить в двух видах. Первый - оперативный, рассчитанный для быстрого отображения в личном кабинете и операторском интерфейсе. Второй - детальный журнал проводок, из которого этот баланс можно восстановить.

Когда хранится только итоговое число, исправление одной ошибки превращается в ручной поиск по письмам, платежам и выгрузкам. Журнал операций делает систему проверяемой.

• Идентификатор операции. Нужен для поиска, повторной обработки и связи с платежом.
• Тип операции. Начисление, списание, отмена, возврат, корректировка, сгорание или блокировка.
• Количество баллов. Сумма в целых или дробных единицах согласно правилам программы.
• Основание. Покупка, платеж, акция, промокод, рекомендация или ручная корректировка.
• Дата создания и дата вступления в силу. Эти даты могут различаться при отложенном начислении.
• Срок действия. Критически важен для автоматического сгорания.
• Статус. Проведена, ожидает подтверждения, отменена, заблокирована или обработана с ошибкой.
• Сотрудник или сервис-источник. Показывает, кто или что создало операцию.

Для каждой операции стоит хранить не только сумму баллов, но и денежную базу начисления. Допустим, клиент получил 1 балл за каждые 100 рублей оплаты. В CRM нужно записать и 7 баллов, и платежную сумму 700 рублей, и примененный тариф.

Это позволит проверить расчеты после изменения правил и понять, почему клиенту была начислена именно такая сумма.

Отдельное внимание уделяется персональным данным. В карточке не следует дублировать паспортные сведения, реквизиты карт и другую чувствительную информацию без необходимости. CRM должна хранить только тот объем данных, который нужен для работы программы.

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

Как спроектировать правила начисления

Правила начисления должны быть простыми для клиента и однозначными для CRM. Формулировка "до 10 процентов бонусами" выглядит привлекательно, но для автоматизации слишком расплывчата.

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

Например, финансовая компания может начислять один балл за каждые 100 рублей комиссии, оплаченной клиентом. Тогда необходимо определить, начисляются ли баллы за все комиссии или только за обслуживание выбранного тарифа.

Если клиент оплатил 850 рублей, получит он 8 баллов, 8,5 или 9? На практике обычно выбирают целые баллы и фиксируют правило округления: вниз, математическое или до ближайшего допустимого значения.

Хорошее правило можно описать в виде карточки:

CRM должна поддерживать приоритеты правил. Если одновременно действуют базовое начисление, акция для нового клиента и повышенный коэффициент для премиального уровня, система обязана понимать, складываются они или применяется только одно из условий.

Иначе один и тот же платеж может дать клиенту трижды рассчитанное вознаграждение.

Полезно вводить версионность. Правило, действовавшее в январе, нельзя молча переписывать в марте, если по нему уже начислялись баллы. В системе должна оставаться версия с датой начала и окончания действия. При пересчете старая операция должна использовать старую формулу, а новые операции - новую. Это особенно важно при спорных ситуациях и проверках.

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

Такой набор выявляет большую часть ошибок еще до того, как они затронут реальных пользователей.

Начисление, списание и возврат баллов

Главный принцип надежной системы - любая операция проводится только один раз, даже если внешний сервис отправил повторное уведомление. Для этого применяется уникальный ключ операции.

Например, платежный шлюз передает идентификатор транзакции, а CRM проверяет, не был ли он уже использован для начисления. Если уведомление пришло повторно, система возвращает результат уже выполненной операции, но не создает новую.

Начисление часто делают отложенным. Баллы появляются не в момент авторизации платежа, а после подтверждения операции, окончания периода возврата или выполнения дополнительного условия. В CRM это отражается статусами "ожидает", "доступно" и "отменено".

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

Списание выполняется по принципу резерва. Сначала CRM проверяет доступный остаток и блокирует необходимое количество. Затем проводится основная операция - например, оплата комиссии баллами или предоставление скидки. После успешного завершения резерв списывается окончательно. При ошибке резерв снимается.

Без такого механизма два параллельных запроса могут одновременно увидеть один и тот же баланс и позволить использовать его дважды.

1. Получить запрос на использование баллов.
2. Проверить статус клиента, доступный остаток, срок действия и ограничения.
3. Создать резерв с уникальным идентификатором.
4. Подтвердить основную финансовую операцию.
5. Перевести резерв в статус окончательного списания.
6. Зафиксировать результат в журнале и уведомить клиента.

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

При полном возврате часто восстанавливают списанные баллы, но могут уменьшить ранее начисленное вознаграждение. При частичном возврате расчет должен быть пропорциональным либо соответствовать заранее утвержденным правилам.

Ручные корректировки допустимы только при наличии причины и второго уровня контроля. Оператор не должен менять баланс напрямую.

Он создает заявку, выбирает основание, указывает сумму и прикладывает комментарий. После подтверждения система создает самостоятельную корректирующую операцию, а не переписывает старую запись.

Срок действия и сгорание бонусов

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

Разные механики дают совершенно разный финансовый и маркетинговый эффект.

Для CRM удобнее всего хранить дату истечения каждой партии баллов. Тогда применяется принцип "первым сгорает то, что раньше истекает".

При списании система сначала использует старые баллы, а новые сохраняет. Это снижает число жалоб и упрощает прогнозирование. Если срок считается от последней активности, нужно регулярно пересчитывать дату окончания и фиксировать основание изменения.

Клиенту стоит показывать не только общий баланс, но и ближайшую дату сгорания. Например: "240 баллов действуют до 15 ноября".

Напоминания можно отправлять за 30, 7 и 1 день. Однако частота уведомлений должна учитывать согласия клиента и его коммуникационные настройки. Слишком агрессивные сообщения воспринимаются как давление, особенно в финансовых продуктах.

Финансовый анализ сгорания строится на коэффициенте погашения: доле начисленных баллов, которые были использованы клиентами.

Если за квартал начислено 10 миллионов баллов, списано 4 миллиона, а сгорело 3 миллиона, оставшиеся 3 миллиона могут стать будущим обязательством. Нельзя автоматически считать все неиспользованные баллы чистой экономией: часть из них будет погашена позже.

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

Интеграция CRM с платежными и учетными системами

CRM обычно не является единственным источником данных. Платежный шлюз подтверждает транзакции, биллинговая система рассчитывает комиссии, интернет-банк фиксирует списание, а бухгалтерская система отражает финансовые последствия.

Если все сервисы обмениваются данными без четких границ ответственности, возникают расхождения и дубли.

Нужно назначить источник истины для каждого факта. Например, платежная система подтверждает факт оплаты, CRM рассчитывает бонусы и хранит клиентскую историю, а учетная система получает реестр операций для финансового отражения.

В CRM при этом не следует вручную вводить платежи, которые уже существуют в биллинге. Лучше передавать их через защищенный интерфейс с идентификатором, суммой, валютой, датой и статусом.

• Используйте уникальные идентификаторы платежа и бонусной операции.
• Передавайте статусы, а не только суммы.
• Настройте повторную отправку сообщений при временном сбое.
• Храните журнал обмена между системами.
• Разделяйте тестовые и боевые ключи доступа.
• Проверяйте подпись и источник каждого входящего сообщения.

Обмен лучше строить так, чтобы система могла безопасно повторить запрос. Это называется идемпотентностью: повторная обработка одного события не меняет результат второй раз. В финансовом контуре это не техническая мелочь, а обязательное свойство.

Сбой сети не должен превращать один платеж в двойное начисление.

Раз в день или неделю полезно выполнять сверку. Сравниваются количество подтвержденных платежей, сумма начисленных баллов, число списаний, возвраты и ошибки. Расхождения попадают в отдельный реестр.

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

Контроль мошенничества и операционных ошибок

Бонусная программа становится привлекательной целью для злоумышленников, если баллы имеют заметную ценность.

Риски возникают при создании фиктивных клиентов, подборе промокодов, подмене идентификаторов, повторной отправке платежных уведомлений, сговоре с сотрудником и массовом использовании уязвимого сценария возврата.

CRM должна отслеживать необычные шаблоны поведения.

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

Сам по себе сигнал не доказывает нарушение, но позволяет направить операцию на дополнительную проверку.

Пример простого набора ограничений:

• лимит начисления на клиента в сутки и месяц;
• запрет начисления за отмененные и неподтвержденные операции;
• пауза перед использованием баллов новым клиентом;
• дополнительная проверка при крупном списании;
• запрет сотруднику корректировать собственный профиль;
• обязательное подтверждение руководителем больших списаний;
• автоматическая блокировка подозрительной операции без удаления истории.

Важно не перегнуть палку. Если антифрод будет блокировать обычные операции, клиенты начнут воспринимать программу как ненадежную. Поэтому правила оценивают по двум метрикам: предотвращенный ущерб и доля ложных срабатываний.

Для финансовой компании иногда разумнее временно задержать начисление, чем окончательно отказать клиенту в законном вознаграждении.

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

Если обнаружена ошибка, история не переписывается: создается исправительная запись со ссылкой на исходную.

Отчеты и финансовые показатели программы

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

Количество начислений без связи с выручкой может создавать ложное ощущение успеха. Программа способна активно раздавать баллы и одновременно снижать маржинальность.

К основным показателям относятся:

• Активные участники. Клиенты, у которых были операции за выбранный период.
• Доля использования. Сколько начисленных баллов фактически списано.
• Средний баланс. Оценка потенциального будущего спроса на вознаграждение.
• Стоимость балла. Сколько денег или маржи приходится на единицу списания.
• Повторная активность. Как часто участники возвращаются к продукту.
• Доход на участника. Сравнение клиентов программы с обычными клиентами.
• Доля ручных корректировок. Индикатор качества автоматизации.
• Уровень ошибок и спорных операций. Показатель надежности процесса.

Полезно строить когортный анализ. Клиентов группируют по месяцу подключения, затем сравнивают их активность, начисления, списания и доходность. Допустим, участники, подключенные в январе, совершили в среднем 2,4 операции за первый месяц, а участники февральской кампании - 1,7.

Это может говорить о менее удачном предложении, изменении аудитории или проблеме в коммуникации.

Для управления резервом можно использовать оценку ожидаемого погашения.

Если на счетах клиентов находится 20 миллионов баллов, а исторический коэффициент использования составляет 35 процентов, ориентировочная стоимость будущих списаний рассчитывается не как 20 миллионов, а с учетом вероятности использования и себестоимости вознаграждения.

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

Отчет должен иметь расшифровку до конкретных операций. Сводная цифра без drill-down бесполезна при расследовании расхождений. Руководитель видит показатель, финансовый контролер - сегмент, а оператор при необходимости открывает историю одного клиента.

Экономика бонусной программы и налоговые вопросы

Перед запуском следует посчитать unit-экономику. В нее входят стоимость начисленных и списанных баллов, расходы на разработку и поддержку CRM, комиссии партнеров, коммуникации, стоимость дополнительного обслуживания и возможный рост выручки.

Нельзя оценивать программу только по обороту: часть клиентов могла бы совершить ту же операцию и без бонусов.

Простой пример. Компания начислила клиентам 1 миллион баллов номинальной стоимостью 1 рубль. Из них использовано 300 тысяч, но из-за ограничений средняя фактическая себестоимость составила 60 процентов номинала. Прямой расход равен 180 тысячам рублей. Если программа принесла 500 тысяч рублей дополнительной маржинальной прибыли, ее вклад положительный.

Но если большая часть списаний пришлась на операции, которые клиенты и так совершили бы, эффект будет намного скромнее.

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

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

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

Нельзя переносить в учетную политику универсальное решение из чужого бизнеса.

До запуска финансовый блок должен письменно определить:

• момент признания операции;
• порядок оценки неиспользованных баллов;
• правила отражения сгорания и возврата;
• состав документов для подтверждения начислений и списаний;
• порядок сверки CRM с бухгалтерскими регистрами;
• ответственных за изменение условий программы.

CRM не заменяет бухгалтерскую систему. Она предоставляет детализацию и управленческие данные, а финансовое отражение выполняется по утвержденной методике.

Если правила часто меняются, финансовую модель нужно пересматривать вместе с версиями бонусной политики, иначе отчетность перестает быть сопоставимой.

Как внедрить учет поэтапно

Внедрение лучше начинать не с выбора кнопок в CRM, а с описания процессов. На первом этапе фиксируют все источники начислений и списаний, типы клиентов, спорные случаи, возвраты, сроки действия и нужные отчеты.

Затем составляют карту данных: какое поле где создается, кто его изменяет и какая система считается первичной.

На втором этапе проектируют справочники и статусы. Не стоит сразу создавать десятки разновидностей баллов без необходимости. Обычно достаточно разделить бонусы по назначению: стандартные, акционные, партнерские и заблокированные.

Если у каждого вида свои сроки и правила, это должно быть явно отражено в модели, а не спрятано в комментариях.

Третий этап - настройка интеграций и тестирование. Проверяются успешный платеж, задержка ответа, повторное уведомление, отмена, частичный возврат, нехватка баллов, истечение срока и ручная корректировка.

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

1. Описание бизнес-правил и финансовой модели.
2. Проектирование данных и ролей доступа.
3. Настройка справочников, формул и ограничений.
4. Интеграция с платежными и учетными системами.
5. Тестирование на копии или стенде.
6. Пилот на небольшой группе клиентов.
7. Сверка результатов и исправление ошибок.
8. Промышленный запуск с мониторингом.

Пилот позволяет проверить не только техническую часть, но и реакцию клиентов. На ограниченной группе видно, понятны ли уведомления, хватает ли данных операторам, как часто возникают вопросы и не слишком ли сложна процедура списания.

После пилота правила уточняют, а спорные решения закрепляют в регламенте.

Для поддержки нужно подготовить сценарии ответов. Оператор должен быстро объяснить, почему баллы еще не доступны, почему они сгорели, как рассчитывалась сумма и что произойдет при возврате.

Если у сотрудника нет доступа к деталям, он начинает обещать клиенту ручное восстановление, что создает новые ошибки.

После запуска устанавливают мониторинг: количество операций, задержки интеграций, ошибки, рост ручных корректировок, подозрительные всплески и расхождение с учетными данными. Первые недели контроль должен быть усиленным. Программа лояльности - живой финансовый процесс, а не проект, который однажды настроили и забыли.

Практический пример настройки в CRM

Рассмотрим условную компанию, которая предоставляет платежный сервис для малого бизнеса. Клиент получает 1 балл за каждые 100 рублей комиссии, оплаченной без просрочки. Баллы становятся доступными через три дня после платежа, действуют 180 дней и могут покрыть до 30 процентов следующей комиссии.

Для премиального тарифа действует коэффициент 1,5, но общий месячный лимит составляет 5 000 баллов.

В CRM создаются сущности "Клиент", "Бонусный счет", "Партия баллов" и "Операция". В партии хранится дата начисления, срок действия, количество и источник. При поступлении подтвержденного платежа сервис передает идентификатор, сумму комиссии и тариф.

CRM рассчитывает базовое начисление, применяет коэффициент, округляет вниз и создает операцию со статусом ожидания.

Через три дня фоновая задача проверяет отсутствие возврата и просрочки. Если условия выполнены, статус меняется на "доступно". Если платеж отменен, создается операция отмены.

При использовании баллов CRM подбирает партии с ближайшим сроком истечения, создает резерв и передает в биллинг сумму скидки. После подтверждения биллинга резерв превращается в списание.

В отчетах финансовый контролер видит начисления по тарифам, стоимость фактических списаний, объем сгоревших партий и операции, проведенные вручную. Маркетолог оценивает повторную активность и переход клиентов на премиальный тариф.

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

Если клиент обращается с вопросом "куда пропали баллы", оператор не меняет баланс на глаз. Он видит дату начисления, основание, срок действия, уведомление о сгорании и, при наличии ошибки, создает заявку на корректировку.

После проверки финансовый контролер подтверждает исправление, а CRM добавляет новую запись с комментарием и ссылкой на исходную операцию.

Такой сценарий одновременно поддерживает маркетинг, клиентский сервис и финансовый контроль.

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

Типичные ошибки при ведении баллов

Первая ошибка - хранить только общий баланс. Это выглядит удобно, пока не появляется возврат, спор или массовая ошибка интеграции. Исправить итоговую сумму без журнала можно, но доказать правильность исправления уже нельзя.

В финансовом процессе такой подход быстро становится слабым местом.

Вторая ошибка - разрешать сотрудникам редактировать баланс напрямую. Даже добросовестный оператор может ошибиться в нуле, знаке или количестве разрядов.

Кроме того, прямое изменение скрывает причину операции. Безопаснее использовать заявки и автоматические корректирующие проводки.

Третья ошибка - не учитывать отложенное начисление. Если баллы выдаются сразу после авторизации, а платеж потом отменяется, компания будет вынуждена списывать их обратно. Клиент может уже успеть применить бонус, и тогда возникнет отрицательный баланс либо сложная цепочка возвратов.

Четвертая ошибка - менять правила задним числом. Это ломает доверие и затрудняет расчеты. Старые операции должны оставаться привязанными к версии правил, действовавшей на дату события.

Новая политика применяется только к новым операциям, если иное прямо не предусмотрено условиями.

• Не смешивайте бонусные баллы, деньги и промокоды в одном поле.
• Не скрывайте срок действия от клиента.
• Не запускайте массовое начисление без лимитов и теста на дубль.
• Не стройте отчет только по номиналу баллов.
• Не отключайте аудит ради удобства администраторов.
• Не меняйте финансовую формулу без согласования с бухгалтерией и юристами.

Пятая ошибка - отсутствие владельца процесса. Когда маркетинг считает баллы рекламным инструментом, IT - обычными данными, а финансовый отдел узнает о программе постфактум, проблемы неизбежны.

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

Шестая ошибка - чрезмерная сложность. Десятки уровней, исключений и временных коэффициентов могут повысить привлекательность акции, но снизить управляемость. Если формулу трудно объяснить клиенту и проверить в отчете, ее стоит упростить. Прозрачная программа обычно эффективнее хитрой, но непредсказуемой.

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

Начинать нужно с правил и экономики, затем проектировать данные, интеграции и контроль. Журнал операций, идемпотентность, версионность, сроки действия и разграничение прав - не избыточные функции, а основа надежности.

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

Если CRM отвечает на эти вопросы без ручной магии и разрозненных таблиц, бонусная программа работает не только на лояльность, но и на устойчивость бизнеса.

Об авторе

Редактор

Перейти на сайт Просмотреть все записи