Поэтапная безопасная сделка на примере сервиса по ремонту

Часто бывает на сервисах заказа услуг типа youdo, Profi.Ru, FL.ru, что сумма оказания услуг достаточно значительна, и клиент не может воспользоваться безопасной сделкой, т.к. не имеет всей суммы контракта для брони. Делюсь идеей, как можно сделать поэтапную оплату, но соблюсти принципы безопасной сделки

Эксперт по маркетплейсам Bright Mobile рассказывает о возможности применения безопасной сделки в проектах с крупным бюджетом

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

Суть нюанса в том, что стоимость ремонта под ключ в Москве плюс минус стартует от 1 млн.р. Ремонт делать примерно 2-3 месяца и большинство клиентов не смогут воспользоваться безопасной сделкой - у них тупо нет этой суммы на старте. Начав разбираться в этом вопросе понял, что он не касается только строительных услуг. Взять любую сферу с большим чеком и сроком реализации в несколько месяцев - проблема та же. Чего далеко ходить, ведь далеко не у всех клиентов есть 400к за приложение на старте (деньги чаще всего берутся из оборотки ежемесячно). Поэтому решил поделиться найденным решением с аудиторией VC? и жду обратной связи о вашем опыте и возможных подводных камнях.

Как всё происходит в обычных условиях

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

  • Мастер и клиент договариваются об объёме, цене работ и этапах
  • Формируется некая смета на каждый этап
  • Клиент вносит оплату за первый этап 50%
  • Бригада выполняет первый этап
  • Клиент оплачивает остаток за этап и авансирует следующий и т.д.
  • По окончании всех этапов работа полностью сдаётся и (в теории) все рады

По факту, рады далеко не всегда - клиент задерживает очередные платежи, мастера косячат при ремонте и разводят на доп работы, ну вы поняли... Собственно, из этого клубка проблем и родилась идея сервиса Мергена - он не просто транслирует заказ клиента, составленный абы как, а помогает клиенту сформировать профессиональное ТЗ на ремонт для мастеров, а за счёт этого снижает стоимость ремонта и снижает количество недоговорённостей и ошибок.

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

  • Стороны привыкли платить поэтапно
  • Клиент не имеет на старте всей суммы для оплаты ремонта
  • Бригада боится выполнять работу с полной постоплатой даже в случае гаранта сделки

Техническая реализация

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

Но, к сожалению, чудес не бывает и сервисы гаранта сделки воспринимают каждую сделку атомарно. То есть вносится полная предоплата, затем исполнитель выполняет работу, а затем исполнителю перечисляется dcz замороженная оплата за исключением комиссии сервиса. В том числе, такой функции нет и в выбранном нами гаранте сделок.

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

  • Заказчик с помощью компании Мергена формирует подробную заявку на ремонт
  • Исполнители заполняют отклик указывая какие они видят этапы работ, с разбивкой стоимости и сроков по этим этапам
  • Заказчик выбирает понравившегося и подтверждает его, как утверждённого исполнителя
  • В системе создаются дочерние сделки - на каждый этап своя дочерняя сделка, где исполнителем уже назначен тот, кого клиент выбрал в родительской сделке
  • Клиент вносит аванс по первому этапу, а исполнителю отправляется уведомление о резерве суммы
  • Исполнитель выполняет этап, уведомляет заказчика, нажав кнопку в системе
  • Заказчик согласовывает работу и принимает этап
  • Система уведомляет сервис гаранта сделки и исполнителю отправляются деньги за выполненный этап
  • Стороны переходят к следующему этапу работ и т.д. до окончательного выполнения

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

Арбитраж и разрешение споров

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

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

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

Что думаете об идее разделённой безопасной сделки? Какие подводные камни?

44
13 комментариев

Не понял, чем дочерняя сделка отличается от мелкого этапа. Только количеством возни по оформлению ? Сделайте шаблон и пользуйтесь любым инструментом оплаты этапа как законченной сделки.

1
Ответить

Клиент по мнению Мергена не будет заморачиваться ручным созданием этапов. Идея в том, что по кнопке все этапы создаются автоматом на основе заполненной мастером анкеты.

Ответить

Комментарий недоступен

Ответить

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

1
Ответить

Можно ещё включить небольшую фичу, если бы это был удаленный заказ, то в промежутке выполнения подзадания, сервис спросит исполнителя типа "Как дела с заказом? Успеваешь? Нажми ОК, если успеешь к сроку, если нет, то нажми НЕТ и обсуждай проблему с заказчиком".

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

Этапность должна предоставлять точно сторона Исполнитель, так как он и компетентен.

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

Качественное ТЗ (максимально подробное), поэтапный прием работ, четкий договор с точки зрения юристов.

Ответить