Агрегатор услуг - выбор нескольких исполнителей

Денис Гордиенко, генеральный директор Bright Mobile, о возможности выбора нескольких исполнителей в агрегаторе услуг.

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

Для начала – небольшое отступление о работе стандартного агрегатора

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

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

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

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

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

Подобное решение предполагает наличие некоторых нюансов. Первый – общение с исполнителями.

Тривиальное решение с биржей, где выбирается только один мастер – это простой и однозначный чат между заказчиком и исполнителем. В случае мультивыбора, чтобы не писать каждому одно и то же, чаще всего создаётся групповой чат, в котором каждый (в нашем случае – заказчик и два исполнителя-поклейщика) могут что-то написать.

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

Таким образом, личная переписка типового решения меняется на групповую переписку по заявке. Меняется и сущность переписки: если в RTPlatform она привязана не к заявке, а к двум пользователям (заказчик-исполнитель), то в случае мультивыбора исполнителя чат привязывается к заявке. В любой момент времени заказчик может выгнать из чата одного мастера, добавить другого: сущность чата остаётся прежней, какими бы ни были исполнители. Все сообщения сохраняются, регламентируется только уровень доступа к переписке. В первом случае при удалении пользователя чат остаётся только в базе, в нашем – существует до тех пор, пока есть заявка.

При типовом решении оплаты доступа к сервису (подписка) всё остаётся на своих местах. Но если мы говорим про отклики, логично, что поменяется процентовка: из энного числа откликов выбран будет не один, а несколько. Шанс, что исполнителя выберут, будет выше, а значит, с него можно брать больше денег – не 50 рублей, например, а 150.

При стандартном варианте после того, как заказчик жмёт, что задание выполнено, он может написать отзыв. У нас на RTPlatform кнопки «принять работу» нет – зачем? Раз пишешь отзыв, значит, ты и так закончил сотрудничество с исполнителем, по-хорошему или по-плохому. А в случае решения с несколькими исполнителей и отзывов должно быть несколько, ведь работать все они могли по-разному. Значит, отзыв привязывается не к заявке, а напрямую к каждому мастеру в отдельности.

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

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

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

Например, нужно разработать сайт. По стандарту в формате групповой заявки мы чаще всего ищем дизайнера, верстальщика и программиста, который натягивает всё на cms. Допустим, дизайнер нарисовал какую-то суперкрутую графику, и верстальщик понимает, что html-вёрстку он сможет сделать, а для сложной анимации ему нужен js-программист уровнем повыше. Тогда верстальщик сможет из основного задания скопировать общее ТЗ и, нажав кнопку, создать новое задание по поиску программиста на базе старого, просмотреть отклики и поделиться частью бюджета с найденным специалистом.

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

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

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