Веб-приложение для скидок: правила купонов и защита

С чего начать: цель скидок и контроль на кассе

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

Дизайн купона важен, но в реальности все решают правила применения. Кассиру нужна простая проверка: «можно или нельзя», и короткое, понятное объяснение отказа. Без четких правил веб-приложение для скидок станет витриной купонов, а не инструментом контроля.

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

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

Пример: купон «-10% на кофе» действует только по будням до 12:00, не суммируется с акциями и ограничен 1 раз в день на номер телефона. Если это не зафиксировать в правилах и логах, вы не отличите ошибку кассы от злоупотребления.

Термины и роли, чтобы не путаться дальше

Перед тем как собирать веб-приложение для скидок, договоритесь о словаре. Иначе маркетинг будет говорить «купон», касса - «код», а безопасность - «инцидент», и отчеты начнут врать.

Купон - это конкретный код (или QR), который покупатель показывает на кассе. Кампания - «контейнер» для группы купонов с одной идеей (например, «-10% по пятницам»), сроками и бюджетом. Правило - условие, при котором купон можно применить (сумма чека, категория товара, тип клиента). Исключение - явный запрет, который перебивает правило (например, «не действует на табак»). Лимит - счетчик, который ограничивает частоту (1 раз на чек, 1 раз на клиента в день, 100 применений на магазин).

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

Дальше договоритесь о событиях, которые вы фиксируете одинаково во всех отчетах. Обычно достаточно четырех:

• выдача (купон создан или отправлен клиенту)
• попытка применения (код введен, проверка началась)
• применение (скидка реально попала в чек)
• отмена (скидка снята, чек скорректирован)

И отдельно зафиксируйте определения. «Злоупотребление» не равно «ошибка кассира». Ошибка - это неверно введенный код, забытая карта клиента, отмена из-за сбоя связи. Злоупотребление - повторные применения сверх лимита, подозрительные отмены сразу после применения, использование «служебных» купонов не в той смене или магазине. Если это закрепить заранее, журнал злоупотреблений купонами будет полезным, а не токсичным.

Правила купонов: из чего они состоят

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

1) Что именно дает купон

Начните с типа выгоды. Это может быть процент от суммы, фиксированная сумма (например, минус 300 рублей) или подарок (товар за 0 рублей при выполнении условий). Сразу решите, применяется ли скидка ко всему чеку или только к части позиций. Иначе кассир увидит одно, а отчет покажет другое.

2) Условия применения: время, товары, сумма

У купона почти всегда есть рамки. Задайте период действия (даты), а если акция привязана к трафику - окна по часу и дням недели. Дальше идут ограничения по корзине: какие товары и категории участвуют, есть ли минимальный чек, учитываются ли сервисные позиции (упаковка, доставка, табак, маркировка).

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

3) Комбинации и математика

Отдельно зафиксируйте, можно ли совмещать купон с другими акциями и бонусными баллами. И главное - порядок расчета и округление. Например: сначала применяем скидку по купону к участвующим позициям, потом списываем баллы, округляем каждую позицию до рубля вниз. Если это не прописать, одна касса «даст» 199 рублей, другая 200, и начнутся жалобы.

Пример: купон «-10% на кофе по будням с 8:00 до 12:00 при чеке от 500» должен явно говорить, что скидка считается только по позициям кофе, не трогает сиропы и не суммируется с акцией «2 по цене 1».

Лимиты и исключения: как остановить дыру в правилах

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

Какие лимиты нужны чаще всего

Сначала определите, что именно вы ограничиваете: купон, клиента или чек. Практичный минимум выглядит так:

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

Важно заранее решить, что считать «клиентом». Телефон удобен, но им делятся. Карта лояльности надежнее, но она есть не у всех. Иногда нужны оба варианта: если нет карты, ограничивать по телефону и фиксировать это как риск.

Возвраты и отмены: где чаще появляется дырка

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

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

Чтобы разбирать спорные случаи, записывайте причину отказа в логах. Достаточно фиксировать:

• какой лимит сработал (на купон/клиента/чек/магазин)
• текущее значение и порог (например, 5 из 5)
• идентификаторы магазина, кассы, кассира, клиента
• тип операции (продажа, отмена, возврат)

Журнал злоупотреблений: что логировать и как искать аномалии

Если у вас есть веб-приложение для скидок, журнал злоупотреблений нужен не для наказаний, а чтобы быстро объяснять спорные случаи и закрывать лазейки в правилах. Чем понятнее лог, тем реже менеджеру приходится разбираться «на словах».

Логируйте не только успешное применение купона, но и попытки. Минимальный набор событий:

• проверка купона (валиден/не валиден, причина отказа)
• применение скидки к чеку (сумма до/после, список позиций)
• отмена/возврат после применения скидки
• ручная правка чека или скидки сотрудником
• подтверждение менеджером (кто подтвердил и почему)

К каждому событию добавляйте связки: магазин, касса, смена, сотрудник, время, идентификатор чека и, по возможности, клиентский идентификатор (телефон/карта лояльности/псевдо-ID). Важно фиксировать и «контекст правила»: какое правило сработало, какой лимит проверяли, какой именно запрет сработал.

Аномалии часто видны по простым сигналам, особенно в первые недели акции:

• много попыток с одного сотрудника или кассы за короткое время
• повтор одного кода в разных магазинах или сменах
• частые отмены сразу после применения скидки
• всплеск скидок на одну и ту же позицию или категорию
• «лесенка» чеков на минимальную сумму для прохождения условия

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

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

Данные и структура: чтобы отчеты не ломались

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

Минимальная база обычно укладывается в несколько сущностей, но каждая должна хранить точные идентификаторы и связь с чеком:

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

Дальше самое важное - идентификаторы. В каждом применении фиксируйте код купона, ID чека, магазин, кассу и смену. Если у вас есть внешний номер операции от кассового ПО, сохраняйте и его. Тогда вы сможете строить отчеты по скидкам в любом разрезе и быстрее находить «двойные» применения.

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

Для аудита предусмотрите экспорт без ручной правки: один формат и одни поля каждый раз. Полезно, если в выгрузке есть период и фильтры, данные чека (ID, магазин, касса, смена), купон и версия правила, результат проверки и причина отказа, а также кто и когда сделал действие.

Интерфейс: купоны, проверки и объяснимые отказы

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

Экран кассира

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

Показывайте результат сразу и человеческими словами:

• скидка применена: сколько процентов/рублей и к каким позициям
• отказ: одна короткая причина и что можно сделать (если можно)
• предупреждение: например, «купон почти исчерпал лимит»
• кнопка «Показать детали»: какие правила сработали
• быстрый переход в историю по купону

Важно: никаких внутренних кодов ошибок. Вместо «RULE_42» пишите «Не подходит для алкоголя» или «Только по карте лояльности».

Экраны для контроля и настроек

Менеджеру нужен экран спорных случаев: список применений, отмен, ручных корректировок и блокировок. В 1-2 клика он должен открыть карточку купона и карточку сотрудника: кто применял, когда, на какую сумму, сколько было отказов подряд, были ли попытки «подбора» кода.

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

Короткий пример: кассир вводит «NEW10», система отвечает «Отказ: только для новых клиентов» и предлагает кнопку «Проверить по телефону». Это снижает конфликт на кассе и не заставляет персонал гадать.

Отчеты по использованию: что считать и как показывать

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

Начните с базовых метрик, которые можно сверить с кассой и бухгалтерией:

• применений купонов (уникальные и всего)
• сумма скидок (по чекам и по позициям, если есть)
• выручка чеков со скидкой и без (для простой оценки эффекта)
• конверсия по магазинам: доля чеков с купоном
• средняя скидка на чек

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

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

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

Чтобы финансы и маркетинг считали одинаково, заранее зафиксируйте определения: что такое «применение» (по чеку или по позиции), как считать «сумму скидки» (до округления или после), и что делать с возвратами. Эти правила лучше держать рядом с отчетами и не менять без версии.

Пример сценария: акция и разбор спорных применений

Представим офлайн-магазин, где запускают купон на скидку 10% по выходным при сумме чека от 1500 руб. Купон одноразовый на номер телефона, а алкоголь и табак из скидки исключены. Это типичный кейс, который быстро выявляет слабые места в правилах и в проверках на кассе.

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

Как это выглядит на кассе в спорных ситуациях:

• неверное время: «Купон действует только в сб и вс. Сейчас: пт 19:40»
• недобор суммы: «Не хватает 230 руб до 1500 руб»
• в чеке только исключения: «Скидка не применяется к алкоголю и табаку»
• купон уже использован: «Этот номер телефона уже применял купон 12.01, касса 3»

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

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

• попытка применения (успех или отказ) с причиной
• идентификатор кассира и кассы, смена, магазин
• номер телефона в хэшированном виде и ID купона
• сумма чека, сумма товаров-исключений, итоговая скидка
• отмена чека и причина отмены (если есть)

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

Пошаговый план MVP за 1-2 недели

Неделя 1: правила, данные и кассовая проверка

Начните не с базы данных, а с коротких кейсов. Подготовьте 6-10 примеров в формате: «кто», «что покупает», «какой купон», «какой итог», «почему отказ». Эти кейсы сразу показывают дырки в правилах применения купонов и спорные места на кассе.

Дальше зафиксируйте минимальный набор сущностей и статусов купона (создан, активен, истек, заблокирован, использован) и один путь применения. Удобно, если каждое решение системы можно объяснить кассиру одной фразой.

Соберите ядро MVP так, чтобы им реально пользовались на точке:

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

Неделя 2: журнал, отчеты и защита

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

Затем соберите 2-3 отчета, которые проверяются по реальным чекам: использование купонов по дням, топ купонов по сумме скидок, доля отказов по причинам. Это быстро показывает аномалии.

Последний шаг - тест на типовые злоупотребления и права доступа. Проверьте повторное применение, подбор кодов, использование в чужом магазине, ручное изменение суммы. Разделите роли (кассир, менеджер, админ) и убедитесь, что никто «на месте» не может отключить ограничения без следа в журнале.

Частые ошибки и ловушки в купонных системах

Самая частая проблема в том, что правила написаны «по-человечески», а работают «по-разному». На кассе кассир понимает купон как «скидка на все», маркетолог - как «на одну категорию», а в отчетах это превращается в кашу. В веб-приложении для скидок лучше сразу заложить одно место, где правило живет как формальная проверка: условия, исключения и причина отказа.

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

Часто логируют только успешные применения. Тогда вы не видите, что кассиры десять раз пытались «протолкнуть» купон мимо ограничений, или что правило слишком строгое и вызывает вал отказов. Логируйте попытки, отказы и отмены - именно там прячутся злоупотребления и ошибки настройки.

Что обычно забывают в журнале

Журнал «в целом» бесполезен, если нельзя привязать событие к реальной операции. Минимальный набор полей, который спасает в разборе:

• касса (ID устройства) и смена
• кассир/оператор (ID)
• чек/транзакция (ID) и время
• код купона и версия правила
• результат (успех/отказ/отмена/возврат) и причина

Возвраты, отмены и расхождение цифр

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

И не делайте сложные формы для маркетолога. Когда «исключения» спрятаны в трех вкладках, правила начинают править «вручную» через разработчиков. Лучше короткая форма и понятный предпросмотр: почему купон сработает или не сработает.

Короткий чеклист перед запуском и следующие шаги

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

Проверьте по чеклисту:

• Событие применения и событие отказа логируются одинаково подробно: ID купона и кампании, время, магазин, касса, сотрудник, сумма чека, сумма скидки, список товаров (или хотя бы категории) и причина отказа.
• Лимиты и исключения проверены на 5 типовых чеках: маленькая корзина, большой чек, товары-исключения, пограничная сумма для минимального чека, повторная попытка применения.
• Журнал легко фильтруется хотя бы по сотруднику, кассе, магазину и кампании, чтобы за 2 минуты собрать картину по спорному случаю.
• Отчет по скидкам сходится с итогами по чекам: сумма скидок, число применений, число отказов и «непонятные» случаи (например, ручные корректировки).
• Права настроены просто и жестко: кассир не меняет правила, менеджер видит журнал и причины отказов, маркетинг видит отчеты и итоги кампаний.

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

Если нужен быстрый прототип, TakProsto (takprosto.ai) можно использовать как основу: описать правила и сценарии текстом, собрать экраны проверки купона и журнал событий, а дальше спокойно уточнять поля и роли. Для изменений пригодятся planning mode, snapshots и rollback, чтобы обновлять правила и интерфейс без «плавающих» скидок на точках.