Оптимизация пути создания задания

Если сервис берёт процент со сделки, он может участвовать в оплате, приёмке и разрешении споров. Если зарабатывает на доступе исполнителей к заказам, то обычно не участвует в самой сделке. Altprof работает по второй модели.

Исполнитель платит за отправку отклика, а не за полученный заказ. Поэтому ему важно быстро понять объём работы и посчитать стоимость. Если в задании не хватает данных, отклик становится либо слишком общим, либо исполнитель просто проходит мимо.

Документы, ИНН, лицензии, фотографии выполненных работ и отзывы по конкретным заказам дают заказчику больше информации, чем общие формулировки вроде «проверенные мастера».

Не просто «быстро» или «удобно», а «отклики за 30 минут», «заявка за 3–4 минуты», «более 3 000 000 специалистов».

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

Заказчик видит, что предложений нет, но не понимает почему и что можно изменить в задании, чтобы получить отклики.

Заказчик не всегда знает названия работ и нужные параметры. Исполнителю, наоборот, без них сложно оценить объём и стоимость. Поэтому форму нельзя было ни превращать в анкету для специалиста, ни оставлять полностью свободной.

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

Для исполнителя прямой контакт ускоряет обсуждение задачи. Для заказчика ранняя передача телефона означает риск нежелательных звонков. Поэтому момент открытия контактов нельзя было определять только интересами одной стороны.

• Основной вход был через поиск. Но поиск работает, когда человек уже знает, что именно ему нужно.
• Одновременно на странице находился каталог товаров, который уводил пользователя в отдельный сценарий.
• «Более 3179 исполнителей» показывало размер площадки, но ничего не говорило о том, как она поможет решить конкретную задачу.
• Главная не отвечала на два частых вопроса из интервью: сколько это примерно стоит и что произойдёт с контактами после публикации.

На следующей версии я проверял два возможных входа в продукт.

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

В третьей версии главная полностью строится вокруг задачи заказчика.

• Первый экран сразу предлагает описать задачу и получить цены и сроки от исполнителей.
• Вместо количества зарегистрированных компаний показываются реальные выполненные задания с ценой и сроком.
• До начала формы появился блок с диапазонами цен на основе количества выполненных заказов.
• Отдельно объясняется, кто получит контакты заказчика и когда.
• Для разных категорий появились отдельные страницы, чтобы показывать релевантные примеры работ, цены и контент, не перегружая общую главную.

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

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

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

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

В первой версии заказчик последовательно проходил пять шагов.

После этого задание отправлялось на модерацию.

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

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

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

Форма стала короче визуально, но сама задача для пользователя почти не изменилась. Те же вопросы остались, просто теперь находились на одном экране. Гипотеза не дала ожидаемого роста конверсии.

Это показало, что проблема была не в количестве шагов как таковом.

Делать отдельную форму для каждой категории было слишком дорого. Поэтому для основных направлений я собрал отдельные сценарии и сделал ТЗ программистам на интеграцию с Marquiz.

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

Я ориентировался на подход конкурентов Профи.ру и Юду, но сознательно сделал опрос короче. Цель была не собрать максимум информации, а получить только те данные, которые действительно нужны исполнителю для первичной оценки стоимости.

Так мы перестали заставлять заказчика самому понимать структуру работ и начали задавать ему более простые вопросы по ходу формы.

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

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

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

Заказчик описывает проблему так, как понимает её сам. Задача продукта — незаметно собрать из этого достаточно структурированных данных, чтобы исполнитель мог оценить работу.

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

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

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

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