Проблема
Marketplace Комбинатор — платформа-агрегатор, которая помогает малому и среднему бизнесу выходить на маркетплейсы: Wildberries, Ozon, Яндекс Маркет. К моменту, когда ко мне обратились, компания работала уже два года, но росла заметно медленнее рынка.
На поверхности всё выглядело нормально: входящих заявок хватало, команда была укомплектована, CRM велась. Но генеральный директор чувствовал, что что-то постоянно «скрипит»: клиенты жаловались, часть уходила до завершения первого листинга, а менеджеры по сопровождению были хронически перегружены.
Внутри компании каждый отдел — обработка заявок, сопровождение и разработка — работал в своём ритме и по своим правилам. Передача клиента между отделами происходила хаотично, на ответственность никто не претендовал.
Диагностика
Я начал с того, что провёл 47 глубинных интервью с действующими и бывшими клиентами — селлерами на разных стадиях работы с платформой. Это заняло три недели. Разговаривал минимум по 40 минут, без скриптов, просто слушал, что происходит с их точки зрения.
Параллельно изучил внутренние данные: сколько времени проходит от заявки до первого листинга, как распределены тикеты, кто за что отвечает, где клиент «зависает» дольше всего.
«Я отправлял документы трём разным людям и каждый раз получал разные ответы. Непонятно, кто за меня отвечает» — типичный отзыв из интервью.
По итогу диагностики картина стала ясной: между отделами обработки, сопровождения и разработки не было единой точки ответственности. Клиент передавался как эстафетная палочка — без истории, без контекста. Разработка не знала, что пообещало сопровождение; сопровождение не понимало, что уже сделала обработка.
Что сделал
Ввёл роль Project Manager. Один человек стал персональным куратором клиента от заявки до первых продаж на маркетплейсе. Он ведёт весь путь, координирует отделы и несёт ответственность за результат.
Перестроил процессы передачи. Сделал единый чеклист передачи клиента между отделами — 14 обязательных пунктов, без которых переход невозможен. Настроил уведомления в CRM так, чтобы следующий отдел получал задачу автоматически, как только предыдущий закрывал свою.
Провёл серию рабочих сессий. Три совместных воркшопа с руководителями всех трёх отделов — разобрали конкретные кейсы, где клиент терялся, и договорились о правилах взаимодействия.
Выстроил систему обратной связи. После каждого закрытого тикета — автоматический короткий опрос клиента (три вопроса). Данные агрегируются в дашборде раз в неделю.
Пересмотрел приоритизацию в разработке. До этого разработчики брали задачи по порядку поступления. Ввели матрицу приоритетов: срочность × влияние на листинг. Это сняло 30% нагрузки с сопровождения, которое раньше «продавливало» задачи вручную.
Результат
Через 11 месяцев после старта изменений GMV платформы вырос на 84%. Конверсия из заявки в успешный первый листинг поднялась с 31% до 84% — в 2,7 раза. Среднее время закрытия тикета сократилось с 6,4 до 2,5 дней — минус 61%.
Отдел сопровождения перестал быть «узким местом»: нагрузка на одного менеджера снизилась, при этом количество клиентов выросло. NPS по итогам квартала вырос с 34 до 61.
Вывод
Проблема была не в маркетинге и не в продукте — платформа работала нормально. Проблема была в том, что три отдела существовали как три отдельных компании. Как только появился человек, который видит весь путь клиента целиком, и процессы, которые этот путь структурируют, — цифры пошли вверх.
Инструменты здесь вторичны. Первично — кто отвечает за клиента от начала до конца.