WAPP
FinTech10 мин чтения

LIFE PAY: корпоративный сайт платёжной компании с воронкой заявок

Корпоративный сайт платёжной компании: продуктовые страницы, CMS, админка и воронка заявок с интеграцией amoCRM.

LIFE PAY: корпоративный сайт платёжной компании с воронкой заявок
В

Виталий

Разработка

Р

Роман

Разработка

Д

Дмитрий

Разработка

А

Андрей

Разработка

Максим

Максим

Управление проектом

LinkedIn

Маркетинговый сайт life-pay.ru, CMS для блога и маркетплейса, административная панель и лид-хаб с интеграциями. Проект прошёл несколько поколений редизайна без остановки лидогенерации.

Отрасль: FinTech
Период: 2017–2019
Стек: Laravel 5.4, Vue 2, MySQL, Docker

UI-kit проекта: типографика, кнопки, формы и цветовая система

Задача

LIFE PAY продаёт онлайн-кассы, эквайринг и фискальные решения. Сайт для такой компании работает не как витрина, а как основной канал заявок: посетитель приходит по рекламе, выбирает решение, оставляет контакты, и заявка должна дойти до отдела продаж без потерь.

Требовалось закрыть четыре задачи одновременно:

  • собрать публичный сайт с продуктовыми страницами, блогом, новостями и маркетплейсом;
  • построить воронку заявок с нескольких источников: формы сайта, лендинги на Tilda, партнёрский API, Telegram-бот;
  • дать маркетингу инструмент управления контентом без участия разработчиков;
  • не сломать существующие URL и сквозную аналитику при обновлении дизайна.

Дизайн

Главная страница пришла от стороннего подрядчика. Остальной сайт спроектирован в WAPP: 18 макетов в Figma — продуктовые лендинги касс, партнёрская страница, пульт для партнёров, служба поддержки, страницы оплаты, отзывы, новости, блог, контакты, страница 404.

Отдельно собран UI-kit: типографика, кнопки, поля форм, иконки и цветовые переменные. Дальше все новые страницы собирались из этих элементов, а не рисовались с нуля.

Партнёрская страница: условия, шаги подключения и калькулятор дохода

Четыре поколения интерфейса в одной кодовой базе

Самая нетривиальная часть проекта. За время работы сайт пережил несколько редизайнов, и в кодовой базе одновременно жили четыре слоя шаблонов: old, site, new и reboot.

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

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

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

Масштаб: около 150 Blade-шаблонов и 20 Vue-компонентов, ~80 маршрутов, 24 миграции базы данных.

Страница оплаты счёта

Административная панель

Панель управления сделана как SPA на Vue с авторизацией через JWT — около 14 экранов. Формы строятся из схем моделей на бэкенде, поэтому добавление новой сущности не требует отдельной вёрстки.

Что получила команда контента:

  • Блог — полное управление записями, отложенная публикация, загрузка изображений через редактор;
  • Маркетплейс — карточки партнёрских решений с управлением публикацией;
  • Заявки — список с фильтрами по дате, источнику, статусу в CRM и партнёру, выгрузка в XLS;
  • Клиенты — поиск по телефону, имени и email.

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

Служба поддержки: поиск по базе знаний и форма обращения

Воронка заявок

Заявки приходили из четырёх источников, и каждый требовал своей обработки: формы на сайте, лендинги на Tilda, партнёрский API с проверкой ключа, Telegram-бот с деревом диалога.

Путь заявки:

  1. Валидация и нормализация данных, определение источника, партнёра и UTM-меток
  2. Сохранение в базу, создание карточки клиента при новом номере
  3. Подписка на рассылку, если посетитель её выбрал
  4. Передача во внешнее ядро обработки заявок
  5. Уведомление в рабочий чат отдела продаж с полным контекстом: имя, контакты, источник, партнёр, метки

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

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

За период 2017–2018 через воронку прошло около 5900 заявок и 3500 клиентов.

Пульт для партнёров: материалы, инструкции и презентации

Что осталось за границами проекта

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

Логика распределения заявок между менеджерами тоже жила во внешнем ядре. Задача сайта — собрать заявку, обогатить её данными об источнике и доставить без потерь.

Стек

Бэкенд: PHP, Laravel 5.4, MySQL
Фронтенд: Vue 2, Webpack, Gulp
Инфраструктура: Docker, GitLab CI
Интеграции: amoCRM, Telegram Bot API, Mailchimp, Google Analytics, Яндекс.Метрика, GTM, Adspire, CityAds, DaData

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