Привет, Хабр! Я Саша Яничкина, продакт-менеджер в Ситидрайве. Долгое время нас знали как сервис поминутного каршеринга с яркими тачками. Всё, конечно же, автоматизировано: арендовать, заправить или поставить машину на парковку можно прямо через приложение.
Со временем вокруг каршеринга начали появляться новые продуктовые направления, и Ситидрайв превратился в платформу для автомобилистов с разными сценариями использования. Я отвечаю за два из них:
прокат авто без оклейки от 1 дня — Ситидрайв Рент,
аренду от 1 месяца с возможностью выкупа — Ситидрайв Надолго.
В новых сервисах процессы оставались ручными: таблицы, звонки, переписки, бумажные договоры. По сути, мы масштабировали оффлайн-услугу, спрятанную за кнопкой «оставить заявку», и быстро уткнулись в потолок.
В этой статье расскажу, как мы:
вытащили бронирование из ручных процессов и перенесли его в приложение,
пересобрали клиентский путь и внутренние процессы без остановки продукта,
запустили автоматизацию, которая теперь обрабатывает большую часть заявок без участия людей.
Если вы в той самой точке, где всё держится на костылях, а хочется собрать нормальную систему — будет полезно.
MVP, который приносил деньги, но не масштабировался
Сценарии у «Рента» и «Надолго» — совершенно разные
В Ренте пользователь хочет быстро выбрать машину, оплатить онлайн, забрать, когда удобно — и всё без лишнего общения. Это ближе к e-commerce: важна скорость и предсказуемость.
В Надолго ожидания другие: клиент готов вникать, задавать вопросы, сравнивать, спрашивать про выкуп и страховку. Это уже ближе к покупке машины или оформлению лизинга — нужна уверенность, что всё понятно и прозрачно.
Несмотря на разницу в мотивации, сам процесс оформления одинаковый:
выбор машины,
проверка документов,
договор,
оплата,
подготовка авто,
подписание акта.
И всё это — в формате «полуоффлайн»: заявка на звонок → таблица → звонок менеджера → ручной договор → вручную сгенерированная ссылка на оплату.
В MVP это работало. Но чем больше становилось заявок, тем заметнее было: так не масштабируется. Один менеджер обрабатывал по 30–40 заявок в день, и при этом клиенты ждали, переспрашивали. Мы упёрлись в потолок, и стало понятно: так не полетит.
Как это выглядело на практике
На сайте висели просто карточки автомобилей без актуализации и проверки доступности. Машина могла уже быть в аренде на несколько месяцев вперёд или даже выбыть из парка, но карточка всё равно оставалась активной.
Чтобы обновить карточки, нужно было ставить задачу на команду разработки. Разработка тратила время на ручную синхронизацию витрины, вместо того чтобы развивать продукт. Очевидно, что это нецелесообразно.
У клиента на сайте была единственная точка входа — «Заказать звонок». А дальше запускался длинный ручной процесс:
Колл-центр в рабочее время связывался с клиентом и квалифицировал заявку. Если всё подходило — передавал менеджеру.
Менеджер подбирал авто под запрос клиента, обсуждал условия, предлагал доп. услуги: КАСКО или дополнительный пробег.
Документы клиент отправлял по почте. Менеджер проверял их вручную. Это занимало время и было рискованно — легко допустить ошибку при переносе данных в договор.
После проверки данные передавались специалистам документооборота. Они готовили печатную версию договора, а электронную отправляли клиенту на почту для ознакомления.
Специалисты документооборота через интерфейс сервиса-подрядчика формировали ссылку на оплату. Она действительна 1 час, поэтому, если клиент не успевал — генерировали новую.
Менеджеры операций получали номера авто из оплаченных заказов и начинали подготовку.
В день выдачи перегонщик забирал бумажный договор и акт приёма-передачи, выезжал к клиенту. На месте фиксировали состояние авто и подписывали документы от руки.
В конце смены перегонщик возвращал документы на СТО, где они складывались в архив. Через год таких бумаг накопилось несколько шкафов.
Процесс мог занимать от нескольких часов до нескольких дней. Перегонщикам приходилось ездить с документами туда-обратно, легко было что-то потерять, забыть или допустить ошибку. Автоматизации практически не было — и это буквально тормозило масштабирование, потому что человеческий ресурс переставал справляться с объёмами.
Путь от ручного хаоса к автоматизированной системе
Шаг 1: Зафиксировали, как работает сейчас
Первым шагом я собрала полный CJM со стороны клиента и с точки зрения всех внутренних участников процесса: колл-центра, менеджеров, специалистов документооборота, операционного отдела, перегонщиков.
Это была подробная схема со всеми кейсами и развилками, которые могли возникнуть на пути клиента. Оказалось, что при аренде 1 машины могло быть задействовано до 25 человек.
Также в схеме отразили:
все системы, в которых работали сотрудники,
зоны ответственности и места, где они пересекались,
дублирующиеся задачи,
моменты, где нет утверждённого процесса и непонятна зона ответственности.
Карта оказалась отличным рабочим инструментом: на её основе мы встречались с разными отделами, обсуждали слабые места, генерировали идеи по улучшению и набрасывали, как мог бы выглядеть целевой процесс.
Шаг 2: Сформулировали, как должно быть
На базе CJM и идей, собранных от команд, описала идеальный целевой процесс — «to be».
Получился почти утопический сценарий. Там было автоматическое назначение конкретного авто, постановка задач на подготовку в зависимости от состояния авто, полностью бесконтактная выдача и многое другое.
Именно такое описание и было нужно, чтобы выйти за рамки текущих ограничений и посмотреть на процесс в идеале. Это стало ориентиром, к которому мы стремимся, двигаясь поэтапно.
Шаг 3: Выделили главное
Мы отрезали максимум фантазий и зафиксировали, что должно войти в первую версию. Главная цель — закрыть базовые потребности клиентов, сократить ручной труд на каждом этапе и заложить фундамент под масштабирование.
Вот что вошло в первую версию пути клиента:
Сайт с актуальной доступностью авто по городам. Без «фантомных» карточек — клиент видит только те машины, которые реально доступны.
Автоматическая проверка документов. Мы не стали изобретать велосипед — переиспользовали надёжный процесс, который уже работает в каршеринге.
Назначение конкретной машины — пока вручную. Мы сознательно оставили это менеджеру: нужно обсудить с клиентом нюансы, если они есть, перед тем, как финализировать бронирование.
Автоматическое формирование договора. Данные из документов сами подставляются в шаблон.
Электронное подписание договора и акта приёма-передачи. Клиент получает уникальную ссылку по SMS, вводит код — это приравнивается к простой электронной подписи.
Онлайн-оплата. Деньги списываются с карты, привязанной в приложении или на сайте Ситидрайва через внутренний эквайринг.
Сохранили кнопку «Заказать звонок». Она важна для части клиентов.
А вот, что во внутренних процессах:
Объединили всё в одну систему — 1С. Теперь менеджеры, отдел операций и другие участники видят статусы заявок и информацию по авто в одном окне.
Онлайн-оформление актов — перегонщики заполняют их через специального бота прямо во время выдачи без бумажной волокиты.
Оставили процесс работы с заявками на звонок. Звонки обрабатываются колл-центром в CRM-системе — там удобно фиксировать обращения и автоматически передавать квалифицированные заявки менеджерам.
Шаг 4: Разработка — собрали всё вместе
Когда состав первой версии был утверждён, мы перешли к самому сложному этапу — разработке.
Нужно было спроектировать процессы и интеграции в 1С, выстроить взаимодействие между сайтом и внутренними системами, продумать логику работы с внешними сервисами, создать дизайн всех пользовательских экранов — и всё это реализовать.
Ожидаемо, не всё пошло по плану. В процессе всплывали ограничения, которые сложно было предугадать заранее: технические нюансы, особенности старой архитектуры, несовместимость некоторых сервисов.
Часть решений пришлось упростить или переосмыслить. Где-то — отказаться от идеального дизайна в пользу скорости запуска. Где-то — использовать временные решения вместо полноценных автоматизаций. Например, для ускорения запуска мы подключили сторонний сервис для подписания документов, упростили систему промокодов.
Мы сознательно сделали ставку на «достаточно хорошо», чтобы не тормозить запуск и собрать реальные данные. Всё, что сейчас работает вручную или с костылями, мы держим на контроле и постепенно переводим в автоматический режим.
Но в целом разработка шла стабильно, и всё, что мы получали на выходе, выглядело и работало здорово.
Когда продукт начал складываться в рабочую систему, встал следующий важный вопрос: Как запускать новый процесс? Мы не могли просто нажать кнопку «ЗАПУСК» — бизнес продолжал работать, а команды не могли перестроиться за один день.
Шаг 5: Запустились — поэтапно и с поддержкой
Мы приняли важное стратегическое решение — выкатываться поэтапно.
Так, у отделов было время адаптироваться к изменениям, а у команды разработки — возможность исправлять ошибки на каждом конкретном этапе и только потом двигаться дальше. Это решение оказалось очень правильным: мы не пытались автоматизировать всё и сразу, а шли поэтапно, оттачивая ключевые элементы продукта.
Сначала запустили электронное подписание документов — это позволило быстро упростить онбординг пользователей. Затем внедрили автоматическую проверку документов, чтобы снять нагрузку с поддержки. Параллельно наладили стабильную работу оплат, а потом полностью обновили карточку автомобиля в активном заказе.
Поэтапный подход помог не захлебнуться в техническом долге и не потерять фокус на качестве пользовательского опыта. Никаких «давайте отполируем всё до блеска» — только жёсткая приоритизация.
На этом этапе пришло важное осознание: менеджер продукта — это не только про придумать, описать и реализовать идею. Это ещё и про экологичное внедрение. Чтобы изменения действительно заработали, важно выстроить доверие, прозрачную коммуникацию и дать понятное объяснение.
Чтобы запуск прошёл гладко, я стала связующим звеном между разработкой и другими отделами. Для каждого этапа и для каждой команды я готовила отдельные инструкции, проводила демо и презентации, объясняла, как изменится процесс с их стороны и что увидит клиент.
Мы завели отдельные чаты с командами, куда они присылали всё: от ошибок, с которыми сталкиваются пользователи до вопросов «куда нажать» и «что сказать клиенту».
Три дня по 12 часов я провела на СТО вместе с менеджерами — заводила заявки. Это было как на уроке информатики: один человек нажимает, остальные следят и смотрят.
Каждый день в 18:00 на протяжении двух месяцев мы собирались всей проектной командой — разбирали ошибки, баги, непонятные кейсы. Я сразу же заводила задачки на улучшения, чтобы не копить фидбэк, а внедрять правки по ходу.
Это помогло удержать фокус. Ну и, честно говоря, такая коммуникация стала психологической поддержкой в непростой момент перестройки. Все знали, что не останутся один на один с новым процессом — всегда есть кому задать вопрос и где получить помощь.
Из хаоса — в поток: результаты запуска
Проект по автоматизации бронирования в Ренте и Надолго был непростым: масштабный, многоэтапный, с глубокой перестройкой процессов. Но оно того стоило.
Мы по максимуму убрали ручной труд, и это дало нам главное — возможность расти без перегрузки команд.
~90% трафика теперь проходит через онлайн-бронирование,
~70% заявок обрабатываются без звонков,
1-2 часа нужно на оформление от заявки до оплаты.
Для клиента всё тоже стало проще и прозрачнее: он выбирает подходящую модель авто из доступных, загружает документы онлайн — и в течение часа в рабочее время получает назначение конкретной машины от менеджера. Остаётся подписать договор и оплатить аренду.
Результат: мы сняли узкое горлышко, перестали масштабировать хаос и получили систему, которая не только выдержит рост, но и ускорит его.