Доработки продукта под потребности клиентов — это нормально и взаимовыгодно

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

Когда-то давно, когда мы только начинали, называли себя «система персонализации для ecommerce». Ну как-то так, точно не помню, тем более, что формулировок сменилось много. Собственно, тогда у нас был только один продукт, товарные рекомендации. Это был 2013.

Сейчас REES46 — это с десятка два инструментов, больших и поменьше. Если разделять их на категории, то можно выделить товарные рекомендации, поиск, триггерные цепочки и триггерные рассылки (email, push, готовим sms и мессенджеры), массовые рассылки (то же), сегментация, настраиваемые попапы, сбор и публикация отзывов. Есть рекламная платформа для брендов REC ONE, через которую те публикуют рекламу на сайтах интернет-магазинов. Везде есть подробные метрики, отчеты, графики. Мы стремимся сделать работу каждого сервиса прозрачной.

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

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

Иногда так появляются целые большие фичи. Собрал несколько примеров из последнего.

Вообще надо понимать, что поиск ищет ровно по тем полям, по которым ему искать разрешили. Например, если обычно это название, артикул, категория и тому подобное, то в книжном ритейле есть своя специфика — например, такие параметры товара, как «автор», «издательство», «ISBN». Именно по этой причине не заточенный под книжные дела поисковый движок для магазина в книжном магазине работать будет только наполовину.

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

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

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

Поиск вообще очень востребованный инструмент, поэтому много предложений и просьб мы получаем именно по нему. Так появилась функция голосового поиска — мы сознательно не внедряли ее изначально, ждали, когда появится спрос.

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

Еще один пример недавних обновлений, которые произошли благодаря клиентам: информация о клиентах в сегментаторе.

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

Такие знания позволяют после точно настраивать таргетинг для всех видов рассылок.

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

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

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

Чтобы такая схема работала (я имею в виду схему «клиент попросил / проблема возникла — мы сделали») и все это происходило в адекватные сроки, мы построили такой процесс:

• Когда приходит новый клиент — за ним закрепляется аккаунт-менеджер. Он следит за тем, чтобы клиент был счастлив: все сервисы были настроены, как надо, а потребности закрыты вовремя. Штука в том, что если такого не делать, всегда будет сохраняться некоторый процент «молчунов»: клиентов, которые вроде как пользуются сервисами, платят вовремя, при этом чем-то недовольны и никогда об этом не скажут. С аккаунтом клиента получается «разговорить» и решить его задачи.
• Мы используем чаты для саппорта вместо email. Здесь клиент может быстро задать любой вопрос и не ждать потом днями, когда до него доберется ответственный за консультации сотрудник.
• У нас есть алерт-бот для Slack. Он сообщает в чат технической поддержки, если у какого-то магазина что-то пошло не так, и быстро решить проблему.

В общем, строим клиент-френдли сервис. Спрашивайте в комментариях, если давно хотели что-то узнать про REES46, отвечу.