Цифровая система для онлайн уроков, максимальный контакт с клиентом : Стриминговый сервис + сайт + Битрикс24

Предыстория

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

Первоначальными задачами было:

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

В качестве CRM-системы мы решили выбрать уже проверенный Битрикс24. Для оперативного решения проблем сайта мы заключили расширенный договор техподдержки, по которому мы фиксировали возникающие баги с 07 до 23 часов, без выходных.

Что хотел клиент

Разработать стабильный ресурс-экосистему, объединяющую сайт, CRM-систему и стриминговый сервис с видеоуроками.

Этапы решения

Шаг 1. Стабилизация ситуации:

В самом начале работы с проектом мы приняли оперативную поддержку сайта и провели первичную настройку CRM-системы:

• Подготовили инфраструктуру CRM-системы (воронки, поля, карточки);
• Заявки с сайта интегрировали с Битрикс24.

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

• Регистрация на пробный трехдневный период;
• Переход на страницу тарифов;
• Переход на страницу оплаты;
• И другие сервисы.

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

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

После этого в CRM стало возможным:

1. Уведомление менеджеру отдела продаж о том, что новый клиент (в CRM все новые клиенты автоматически попадают в лиды) не провел оплату в течение 3 дней после регистрации на демо-период;
2. Автоматически конвертировать лид в сделку, если клиент с тестовым периодом переходил на страницу покупки тарифа (это важно, так как регламент работы менеджера очень сильно разнится при работе с лидами и сделками);
3. Фиксировать в таймлайне сделки всю историю просмотров тарифов: дату/время, название тарифа, стоимость тарифа на момент просмотра;

5. Фиксировать неудачные оплаты (отказ в транзакции, недостаток средств, выход со страницы онлайн-оплаты до заполнения данных карты и т.д.), а также уведомлять об этом менеджера;

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

Шаг 2. Исправление чужих ошибок:

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

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

Данная ситуация была связана с несколькими факторами:

• Судя по стилистике кода, до нас над проектом работало как минимум 3 команды, которые не особо увязывали свою работу над сайтом друг с другом;
• Изначально у сайта не было четкой структуры, а наши предыдущие коллеги добавляли функционал, что называется «на ходу»;
• Костыли от экстренно исправленных багов, появлявшихся на этапе становления проекта, остались в нем вплоть до перехода под нашу опеку. Ситуация осложнялась тем, что они не были документированы.

Все это приводило к запутанной архитектуре, проблемам в совместимости модулей и к непредсказуемой реакции сайта на малейшие изменения в коде.

Кроме этого, сайту очень не хватало дополнительного функционала:

• Синхронизации периода доступа к видео между сайтом и стриминговым сервисом;
• Инструментов для генерации учётных записей и продления подписки из CRM-системы;
• Раздела с информацией о ежедневном правильном питании;
• Онлайн-гида, знакомящего пользователя с возможностями сервиса;
• Автоматического переключения между видео;
• Раздела с готовыми курсами;
• Мобильного приложения;
• И ряда других, менее значимых функций.

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

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

Несмотря на предварительную оценку в 5 недель, мы полностью пересобрали сайт в течение 3 недель!

В процессе работы мы подготовили и реализовали:

• Четкую, простую и понятную архитектуру сервиса, включающую в себя все информационные системы клиента;
• Полноценную модульную систему на стороне сайта, позволившую избегать как дублирования кода, так и непредсказуемые реакции системы на его изменения;
• Стандартизированные методы API для полноценного обмена всеми потоками информации;
• Весь дополнительный функционал, необходимый для гармоничного развития сервиса;
• Увеличение скорости загрузки страниц до 96 из 100 пунктов для десктопа и 86 из 100 пунктов для мобильной версии (по данным инструмента PageSpeed Insights от Google);
• Покупку подписки в рассрочку от Тинькофф.

Шаг 3. Развитие:

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

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

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

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

Общая схема взаимодействия сервисов:

Скриншоты: