Допустим, покупатель оплатил часть покупки баллами, а на следующий день вернул один товар. По правилам этого примера касса возвращает деньги; бонусная система восстанавливает потраченные баллы и отменяет начисление за возвращённую позицию. В приложении покупатель видит новый баланс и причину изменения. Этот короткий сценарий помогает понять, какие работы войдут в разработку.
Мы предлагаем оценивать приложение лояльности через такие операции. Если действующая система уже рассчитывает баллы и умеет обрабатывать возвраты, можно подключить к ней мобильный интерфейс. Если касса и сайт ведут отдельные счета, потребуется связать данные и правила. Ниже покажем, как различить эти составы, сравнить сметы и принять первую версию на одной покупке. Вы сможете собрать исходные данные для оценки без длинного технического задания.
Три состава проекта, которые дают разную стоимость
Первая развилка находится в действующей программе лояльности. Мы выясняем, где хранится счёт участника, кто рассчитывает начисление и как другие системы получают результат. Это определяет, сколько логики нужно разрабатывать заново.
| Состав | Что уже есть | Что оцениваем |
|---|---|---|
| Приложение поверх готовой программы | Один сервис ведёт счёт, правила, покупки и возвраты; доступны нужные операции обмена. | Карта участника, вход, баланс, история, предложения, уведомления и подключение к сервису. |
| Объединение каналов | Касса и сайт работают, но клиенты или бонусные операции не связаны. | Сопоставление профилей, общий источник расчёта, обмен покупками и возвратами, перенос данных, сверка. |
| Собственное бонусное ядро: сервер, который ведёт счёт и правила | Готовая система не покрывает согласованные правила или путь покупки. | Журнал операций, расчёт и срок действия баллов, списание, возврат, права сотрудников, интеграции и эксплуатация. |
Во всех трёх вариантах могут быть похожие экраны. Разница в смете появляется из-за работ на сервере и в системах магазина. Поэтому мы просим оценивать отдельно приложение, бонусный расчёт, каждый обмен и приёмку. Предложения подрядчиков становятся сопоставимыми, когда у этих частей известны включения и границы.
Если ядро уже работает, его замена потребует дополнительного основания: например, правила невозможно реализовать через доступный интерфейс обмена. До решения о замене стоит проверить реальные ограничения, перенос истории и дальнейшую стоимость владения.
Иллюстрация сценария
Одна покупка затрагивает несколько систем
Карта связывает участника с покупкой. Чек и возвращённая позиция дают основание для изменения баллов.
Как мы сделали работу с баллами во Frost Mining
Для Frost Mining, магазина термопаст и термопрокладок, мы разработали собственный интернет-магазин и админ-панель. Добавили оплату баллами, историю начислений и списаний, корректировку баланса, фиксированные и личные промокоды. Сотрудник может посмотреть операции и изменить баланс через панель управления.
При оценке вашей задачи мы предложим пройти такой же путь глазами сотрудника: открыть счёт, найти изменение, понять его причину. Если ручная корректировка входит в первую версию, в состав работ нужно включить права доступа и запись основания. По такой записи поддержка сможет объяснить покупателю изменение баланса.
Реальный проект 13FOX
Баллы и промокоды в своей системе
Сотрудник видит изменения счёта и может настроить предложение для покупателя.
Сначала связываем клиента и владельца баланса
Допустим, у покупателя есть пластиковая карта, аккаунт сайта и вход в приложение по телефону. Для единого баланса эти записи нужно связать с одним внутренним идентификатором участника. Телефон может измениться, а старые карты и покупки должны остаться у правильного человека.
Мы предложим правила связывания до переноса данных: что считается подтверждением владения профилем, кто разбирает совпадения и как сохраняется история. Автоматическое объединение по одному похожему полю может передать чужие баллы. Стоимость миграции зависит от качества исходной базы и числа исключений, которые придётся проверить.
Дальше выбираем одну систему, которая разрешает списание и ведёт бонусные операции. Это может быть существующая платформа лояльности или разработанный сервер. Касса передаёт покупку, сайт и приложение получают результат. Учётная система сохраняет нужные ей данные по согласованному обмену. Запрос на чтение баланса сам по себе ещё не даёт права потратить баллы.
В технической части оценки мы проверим интерфейс обмена, который часто называют API: какие операции он разрешает, как опознаёт клиента, покупку и возвращённую строку. Например, в документации кассовой интеграции Mindbox выделены расчёт покупки, подтверждение и возврат. Для вашей платформы состав и условия нужно проверить отдельно.
Покупка и частичный возврат в бонусном журнале
Бонусный журнал хранит изменения счёта с причиной и связью с покупкой. По нему можно объяснить баланс, найти повторную операцию и восстановить картину после сбоя. Простого поля «сейчас 195 баллов» для этого недостаточно: сотруднику нужна история его появления.
Возьмём условный расчёт. До покупки у участника 250 доступных баллов. Он покупает два товара за 600 и 400 рублей, тратит 100 баллов. В примере один балл уменьшает оплату на рубль; списание распределяется по товарам как 60 и 40 баллов. Начисляем 5% от оплаченной деньгами суммы, активируем сразу. Округление и срок действия в этом примере не меняют результат. До возврата заработанные 45 баллов остаются на счёте.
| Событие | Деньги и баллы | Что сохраняем |
|---|---|---|
| Покупка двух товаров | Товар 600 ₽: 540 ₽ деньгами + 60 баллов. Товар 400 ₽: 360 ₽ деньгами + 40 баллов. Начисление: 27 + 18 = 45 баллов. | Идентификаторы покупки и строк, исходные суммы, распределение списания, применённое правило. |
| Возврат товара за 400 ₽ | Возвращаем 360 ₽ и 40 потраченных баллов. Отменяем 18 начисленных баллов. Доступный баланс становится 217. | Связь с исходной строкой, возвращённое количество, отдельные бонусные операции и их статус. |
| Повтор того же возврата | При повторе с тем же идентификатором возврата баланс дополнительно не меняется. | Уникальный идентификатор операции и результат уже выполненного возврата. |
Здесь видны две разные операции: восстановить потраченное и отменить заработанное. Их нельзя объединять в одну неподписанную поправку. Если начисленные баллы ещё ожидают активации, возврат должен изменить ожидающее начисление. Если клиент уже потратил заработанные баллы на следующую покупку, заранее выбираем правило: например, разрешённый долг по счёту или отдельный порядок урегулирования.
При частичном возврате используем данные исходной строки и количество возвращённого товара. Если в чеке были исключения, скидки или разные ставки начисления, расчёт по доле общей суммы может дать неверный результат. В документации изменения статуса строки Mindbox описана работа с идентификатором строки и количеством. Поэтому сохранение состава покупки входит в интеграцию уже с первого этапа.
Что должно быть выделено в смете
Для сравнения двух предложений полезно отправить подрядчикам одинаковые правила и обезличенную покупку с возвратом. Мы предлагаем зафиксировать результат каждой части работ: клиентский экран, операцию сервера, обмен и способ проверки. Тогда видно, где заканчивается ответственность исполнителя и какие работы остаются на стороне магазина.
| Часть работ | Что меняет оценку | Что получаете и проверяете |
|---|---|---|
| Клиент и история | Дубли профилей, старые карты, перенос балансов, смена телефона. | Правила связывания и протокол сверки перенесённых счетов. |
| Бонусные правила | Исключённые товары, сочетание скидок, активация, срок действия, частичный возврат. | Согласованные примеры расчёта и журнал операций с причинами. |
| Касса, сайт и учёт | Версии систем, доступные API, число разных конфигураций, задержки, работа при сбое. | Карта обмена, обработка повторов и контрольные покупки в каждом канале. |
| Приложение | Платформы, карта участника, баланс, покупки, предложения, уведомления и восстановление входа. | Рабочий клиентский путь и проверка на согласованных устройствах. |
| Панель и поддержка | Роли, ручные корректировки, поиск ошибки, наблюдение за обменом. | Доступы сотрудников, журнал действий и порядок разбора расхождений. |
Попросите отдельно указать разработку, подключение и настройку существующих систем, миграцию, тестирование, выпуск и последующую поддержку. Лицензии платформы лояльности, кассовые модули, серверы, сообщения для входа и сопровождение 1С могут оплачиваться отдельно. Их цену проверяют по вашим условиям и действующим предложениям поставщиков.
Для ограничения первой версии можно выбрать одну кассовую конфигурацию и одну бонусную механику. В неё стоит включить полный путь покупки и возврата, а сложные уровни участника или набор персональных кампаний вынести на следующий этап. Так первая оценка опирается на проверяемый состав.
Повторы и сбои добавляют работу ещё до релиза
Например, касса отправила покупку, сервер записал начисление, но ответ пропал. Касса повторяет запрос. Для этого случая мы предложим передавать стабильный идентификатор операции и сохранять результат обработки. Повтор с тем же идентификатором покупки должен распознаваться как уже обработанная операция.
Такое поведение называют идемпотентностью: повтор операции не создаёт дополнительного изменения. В документации Stripe это объясняется через ключ запроса и сохранённый результат. Здесь важен сам принцип; конкретный механизм вашей кассы и бонусного сервиса мы проверим при проектировании.
Отдельный случай возникает, когда баллы одновременно пытаются списать на сайте и на кассе. Прочитанный баланс уже мог измениться. Решение о списании принимает ядро: оно повторно проверяет доступную сумму и подтверждает операцию. Проверку и запись списания проектируем так, чтобы два запроса не потратили одну и ту же сумму. При необходимости проектируем резерв баллов на время покупки, снятие резерва при отмене и обработку истёкшего ожидания.
При недоступной сети заранее выбираем поведение кассы. Например, временно запрещаем списание, а начисление принимаем после восстановления связи. Если бизнес требует списания без связи, понадобятся лимиты, правила конфликтов и отдельная проверка риска. Этот вариант меняет состав разработки.
После запуска нужен ответственный за ошибки обмена. Мы предложим показывать сотруднику незавершённые операции, проводить сверку и согласовать порядок восстановления. В предложении отдельно определяем работы с резервными копиями и проверкой восстановления, обновления приложения и адаптацию интеграций при изменении внешних систем.
Как выглядит связанный обмен на примере Бакаева
В «Бакаеве» мы помогли перенести локальную 1С в облако и связали её с админ-панелью мобильного магазина по API. Сервер синхронизации передаёт изменения между системами. Сотрудник меняет фотографию в админ-панели, она обновляется в 1С. Покупатель оформляет заказ в приложении, изменение остатка отражается в админ-панели и 1С. Изменения на стороне 1С проходят обратный путь к приложению.
Для вашей программы лояльности мы предложим так же описать направление каждого обмена: откуда приходит покупка, где принимается возврат, кто рассчитывает баллы и какой статус видит покупатель. На этой карте можно оценить работы по каждой границе систем и назначить ответственных.
Реальный проект 13FOX
Админ-панель, приложение и 1С
В Бакаеве мы настроили двусторонний обмен товарами, остатками и изображениями.
Принимаем первую версию на покупке и возврате
До разработки мы предложим согласовать ожидаемые результаты контрольных операций. Их можно провести на тестовом участнике и обезличенных товарах. По итогам пилота сравниваем клиентский экран, бонусный журнал, кассовую операцию и нужные данные учёта.
- Вход и связывание. Старая карта и подтверждённый аккаунт открывают нужный счёт; чужой профиль не объединяется автоматически.
- Покупка. Баллы списаны и начислены по согласованному правилу. История показывает причину, доступную и ожидающую суммы, если предусмотрена отложенная активация.
- Повтор после пропавшего ответа. Повторяем операцию с тем же идентификатором; проверяем отсутствие дополнительного начисления или списания.
- Возврат. Проверяем одну позицию и весь чек. Отдельно видны восстановленные потраченные и отменённые заработанные баллы.
- Конкурирующее списание и сбой связи. Касса и сайт соблюдают выбранное правило доступного баланса. После восстановления сотрудник видит результат сверки.
- Доступ и эксплуатация. Покупатель видит свой счёт; сотрудник действует в рамках роли. Есть порядок корректировки, обращения в поддержку и восстановления данных.
Согласия на участие и коммуникации тоже входят в сценарий: фиксируем их текст и версию, момент получения, источник и отзыв. Для конкретной программы набор документов и требования к данным согласуем с ответственными со стороны бизнеса. Нажатие системного разрешения на уведомления само по себе не описывает все условия рассылок.
Для компании из Москвы, Санкт-Петербурга или другого города России заранее согласуем способ приёмки: удалённую проверку на тестовой кассе или работу на вашей площадке. В предложении укажем условия доступа к тестовой системе и выезда, если он нужен.
Вопросы перед оценкой
Можно ли назвать цену по списку экранов?
По нему можно оценить часть интерфейса. Для полного предложения нужны бонусные правила, системы обмена, состояние клиентской базы и сценарии покупки и возврата. Мы предлагаем разделить эти работы в смете.
Можно сохранить существующую программу лояльности?
Да, если она поддерживает нужные правила и разрешает требуемые операции через доступный интерфейс обмена. Сначала проверим получение баланса, покупку, списание, возврат и повторы на тестовом контуре.
Как получить общий баланс кассы, сайта и приложения?
Нужно выбрать владельца расчёта, связать идентификаторы участников и передавать ему согласованные операции из каналов. Потом проверить задержки, одновременные списания и сверку после сбоя. Объём работ зависит от возможностей каждого подключения.
Что прислать для первого обсуждения?
Правила начисления и списания, названия и версии кассы, сайта и учёта, описание текущей программы, обезличенный чек и пример возврата. Также полезно указать, кто меняет правила и кто разбирает обращения. Пароли и персональные данные покупателей для этого не нужны.
Разберём одну покупку до оценки разработки
Покажите бонусные правила, кассу, сайт и учёт. Мы разберём покупку и возврат, предложим состав первой версии и перечень работ для оценки. Оставьте контакт в форме; исходные материалы можно обсудить после связи с командой.
Состав решения собран на странице разработки приложения программы лояльности.