Городские платежи: записки продакта в стартапе (часть I)

Последние 2 года я занимаюсь продуктом Citycard. Это такой сервис, где можно оплачивать разнообразные квитанции онлайн: ЖКХ, детский сад, штрафы там или налоги. Все это мы называем городскими платежами. Я хочу рассказать о том пути, который мы прошли за последние два года: возможно, этот опыт будет кому-нибудь полезен. Ну и критика тоже приветствуется: буду рад понять, в каком месте я делал что-то не так.

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

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

С конкурентами Citycard не очень повезло: прямые конкуренты в виде платежных онлайн-сервисов, косвенные в лице банковских приложений, для которых такие платежи - лишь небольшая часть сервиса. Но рынок представлялся довольно большим, а очереди в отделениях Почты России наводили на мысль, что есть еще аудитория, до которой конкуренты не дотянулись. Да и нет предела совершенству.

Команда разработки небольшая: 3 разработчика (сейчас это Артем, Андрей и Кирилл), тестировщик (Юра), дизайнер (сейчас это Катя). Я отвечаю за управление продуктом\проектом и интернет-маркетинг. Еще нам помогает другая Катя - она отвечает пользователям и заботится о них.

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

Предстоящую работу я грубо поделил на такие этапы:

• критичные вещи, мешающие нормальной работе;

• сценарии для новых пользователей;

• возвращение пользователей и средний чек;

• привлечение пользователей;

• все остальное, чего я пока не понимаю.

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

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

Мы решительно переехали с отсталого OTRS (с точки зрения UX) на zendesk, настроили интеграцию с ним, подключили онлайн-чат и нашли нашу бессменную сотрудницу Катю.

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

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

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

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

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

Таким образом мы добавили уже несколько тысяч поставщиков, и ежедневно добавляем по 5-10.

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

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

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

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

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

UX этих страниц впоследствии унаследовала кнопка “Новый платеж” для авторизованных пользователей.

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

Следующим шагом нашего user-flow стала платежная форма. Если кратко: она нас не устраивала. Мы сделали ее лучше: адаптивной, понятной, стилизованной под гайды сервиса. Ну и конверсия заодно подросла ;).

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

Мы переработали форму авторизации: она начала запоминать пользователя по умолчанию. Время жизни авторизации мы тоже заметно увеличили. Чекбокс “Запомнить меня” превратился в “Чужой компьютер”.

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

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

Буду рад любым комментариям, а особенно - критике.