Цифровые сервисы и IT

Онлайн-платформа или маркетплейс услуг: кто отвечает перед пользователем

Кто отвечает перед пользователем на онлайн-платформе или маркетплейсе услуг: сервис, исполнитель, агрегатор или партнер. Как оформить правила платформы, оплату, возвраты, претензии и ответственность.

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

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

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

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

ZLATA LEGAL помогает IT-проектам, онлайн-платформам, маркетплейсам услуг, агрегаторам, сервисам подбора исполнителей и цифровым продуктам во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России оформить юридическую модель платформы: правила сервиса, оферты, договоры с исполнителями, оплату, возвраты, претензии, персональные данные и распределение ответственности.

Короткий ответ

Ответственность перед пользователем зависит не от того, как платформа себя назвала, а от того, что она реально делает.

Если сайт только размещает объявления исполнителей и пользователь сам связывается с ними, платформа ближе к информационной площадке. Ее основной риск — достоверность размещенной информации, правила модерации, персональные данные и претензии по контенту.

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

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

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

Почему вопрос ответственности важен

Для пользователя разница между платформой, агрегатором и исполнителем часто незаметна.

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

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

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

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

Какие бывают модели платформы

Условно можно выделить несколько моделей.

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

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

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

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

Пятая — смешанная модель. Часть услуг платформа оказывает сама, часть размещает от партнеров, часть продает по подписке, часть через исполнителей. Это самая рискованная история, если в интерфейсе и документах не разделить роли.

Доска объявлений услуг

Если платформа работает как доска объявлений, ее задача — дать исполнителям возможность разместить информацию, а пользователям — найти контакт.

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

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

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

Агрегатор услуг

Агрегатор — более активная модель.

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

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

Ключевой риск агрегатора — недостоверная или неполная информация. Если пользователь заключил договор из-за информации, которую платформа показала неправильно, претензия может прийти к платформе.

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

Когда платформа становится похожа на исполнителя

Платформа становится похожа на исполнителя, когда она слишком активно управляет услугой.

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

В такой ситуации фраза «мы только посредник» может не сработать.

Если бизнес-модель именно такая, это не катастрофа. Просто документы нужно строить честно: платформа оказывает услугу пользователю, а исполнители являются привлеченными партнерами или подрядчиками. Тогда нужно отдельно урегулировать договоры с исполнителями, качество, приемку, ответственность, возвраты, налоги, чеки и претензии.

Опасна не сама модель, а расхождение между фактической ролью платформы и текстом документов.

Кто заключает договор с пользователем

Это главный вопрос для любой платформы услуг.

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

Договор может заключаться между пользователем и платформой. Тогда платформа сама отвечает за оказание услуги, даже если фактически привлекает партнера.

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

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

Информация об исполнителе

Если услугу оказывает не сама платформа, пользователь должен видеть, кто исполнитель.

Для юридического лица — наименование, ОГРН, ИНН, адрес и контакты. Для ИП — ФИО, ОГРНИП, ИНН и контакты. Для самозанятого или физического лица нужно отдельно оценивать, допустима ли такая модель для конкретной услуги и как раскрывать данные без нарушения закона о персональных данных.

Если платформа скрывает исполнителя полностью, но при этом говорит, что сама не отвечает за услугу, возникает противоречие.

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

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

Карточка услуги

Карточка услуги — это не просто маркетинг. Это часть сделки.

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

Если карточка написана плохо, риск переходит на платформу или исполнителя.

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

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

Цена услуги

Цена должна быть понятна до заказа.

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

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

Если на платформе написано «от 1 000 рублей», а пользователь после заказа получает счет на 8 000 рублей, претензия может быть не только к исполнителю, но и к платформе, если она создала неправильное ожидание.

Лучше сразу разделять предварительную цену, фиксированную цену и цену после уточнения задания.

Оплата через платформу

Когда платформа принимает деньги, ответственность становится чувствительнее.

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

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

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

Для маркетплейса услуг платежная модель — это не бухгалтерская деталь, а основа распределения ответственности.

Безопасная сделка

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

Это удобно, но требует четких правил.

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

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

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

Возвраты

Возвраты на платформе услуг зависят от роли платформы.

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

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

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

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

Один универсальный ответ «возврат не производится» для платформы услуг почти всегда слабый.

Претензии пользователя

Пользователь должен понимать, куда писать претензию.

Если платформа принимает претензии только по работе сайта, это нужно указать. Если платформа также принимает претензии к исполнителю и передает их ему, это нужно описать. Если платформа сама рассматривает спор и принимает решение о возврате, нужны правила процедуры.

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

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

Ответственность исполнителя

С исполнителем должен быть отдельный договор или оферта для партнеров.

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

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

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

Проверка исполнителей

Если платформа пишет, что исполнители проверены, нужно понимать, что именно проверено.

Проверка паспорта, ИНН, статуса ИП, лицензии, диплома, портфолио, отзывов, опыта, документов, разрешений, самозанятости, страховки или просто номера телефона — это разные уровни проверки.

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

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

Рейтинги и отзывы

Рейтинги и отзывы влияют на выбор пользователя.

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

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

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

Модерация

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

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

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

Обход платформы

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

Это можно ограничивать правилами, но важно делать это разумно.

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

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

Персональные данные

Платформа услуг почти всегда обрабатывает персональные данные.

Это данные пользователей, исполнителей, сотрудников исполнителей, адреса оказания услуг, телефоны, email, переписка, фотографии, документы, платежные сведения, геолокация, отзывы, данные аккаунтов и история заказов.

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

Отдельно нужно решить, какие данные пользователь видит об исполнителе и какие данные исполнитель видит о пользователе. Например, адрес пользователя может передаваться исполнителю только после оформления заказа, а телефон — только после подтверждения заявки.

Для платформы это вопрос не только закона, но и доверия.

Переписка внутри платформы

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

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

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

Если переписка уходит в мессенджеры, платформа теряет контроль над доказательствами. Это нужно учитывать в правилах: спор по заказу проще рассматривать, если ключевые договоренности зафиксированы внутри сервиса.

Услуги с лицензиями и разрешениями

Некоторые услуги нельзя размещать на платформе без проверки статуса исполнителя.

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

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

Если платформа размещает регулируемые услуги без проверки и при этом активно продвигает исполнителей, риск претензий выше.

Геолокация и выездные услуги

Для сервисов с выездом важны адрес, время, зона обслуживания, опоздание, отмена и безопасность.

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

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

Для Владивостока и Приморья это практично: расстояния, пробки, удаленные районы, выезд в Артем, Уссурийск, Находку, Большой Камень, порты, склады и промзоны могут влиять на цену и срок услуги.

B2B-платформа услуг

Если платформа работает с бизнесом, модель становится сложнее.

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

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

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

Документы для платформы услуг

Для платформы услуг обычно нужны несколько документов.

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

Оферта для пользователей регулирует заказ, оплату, комиссию, возврат, отмену, претензии и роль платформы.

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

Политика обработки персональных данных описывает данные пользователей и исполнителей.

Отдельно могут понадобиться согласия, cookie-документы, правила безопасной сделки, правила модерации, политика отзывов, условия B2B-клиентов и документы для платежного агрегатора.

Что нужно указать в интерфейсе

Юридическая модель должна быть видна не только в документах, но и в интерфейсе.

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

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

Кнопки тоже важны. «Заказать у исполнителя», «Оплатить услугу платформы», «Внести предоплату исполнителю», «Забронировать через сервис» — это разные смыслы.

Частые ошибки

Первая ошибка — назвать проект маркетплейсом, но фактически работать как исполнитель.

Вторая ошибка — написать «платформа не отвечает», но принимать деньги, управлять заказом и обещать качество.

Третья ошибка — не показывать пользователю данные исполнителя.

Четвертая ошибка — не описать возврат предоплаты.

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

Шестая ошибка — использовать слова «проверенный», «гарантия», «лучший», «надежный» без ясных критериев.

Седьмая ошибка — не разделить комиссию платформы и стоимость услуги.

Восьмая ошибка — не оформить персональные данные и передачу данных исполнителям.

Девятая ошибка — не сохранить доказательства заказа, оплаты, переписки и оказания услуги.

Десятая ошибка — копировать документы интернет-магазина для маркетплейса услуг.

Как правильно запустить платформу услуг

Сначала нужно определить роль платформы: информационная площадка, агрегатор, агент, исполнитель или смешанная модель.

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

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

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

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

Локальный аспект: Владивосток, Приморье и Дальний Восток

Во Владивостоке и Приморском крае платформы услуг часто могут быть связаны не только с бытовыми задачами, но и с бизнесом: логистика, складские услуги, перевозки, ремонт оборудования, услуги для ВЭД, поставки из Китая, морская отрасль, мероприятия, аренда техники, подрядчики, сервисные работы, доставка, B2B-заявки и локальные исполнители.

Такие проекты часто начинаются с Telegram-канала, таблицы, сайта или простого личного кабинета. Потом появляется оплата, комиссия, база исполнителей, рейтинг и претензии пользователей.

Именно в этот момент важно не остаться с документами уровня «мы просто информационный сайт». Если платформа уже влияет на сделку, принимает деньги и управляет заказом, ей нужна полноценная юридическая модель.

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

Как ZLATA LEGAL помогает платформам и маркетплейсам услуг

ZLATA LEGAL помогает онлайн-платформам, маркетплейсам услуг, агрегаторам, сервисам подбора исполнителей и B2B-платформам выстроить юридическую модель работы с пользователями и исполнителями.

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

Готовим пользовательское соглашение, публичную оферту для пользователей, договор или оферту для исполнителей, правила платформы, правила оплаты и возвратов, условия безопасной сделки, политику обработки персональных данных, согласия, cookie-документы, правила отзывов, модерации и B2B-договоры.

Работаем с проектами во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России.

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

Частые вопросы

Кто отвечает перед пользователем на маркетплейсе услуг?

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

Можно ли написать, что платформа ни за что не отвечает?

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

Чем агрегатор отличается от доски объявлений?

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

Нужно ли показывать пользователю данные исполнителя?

Если услугу оказывает исполнитель, а не сама платформа, данные исполнителя нужно раскрывать в понятной форме. Пользователь должен понимать, с кем заключает договор и кому предъявлять претензию.

Кто должен возвращать деньги пользователю?

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

Что должно быть в договоре с исполнителем?

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

Можно ли брать комиссию с исполнителя?

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

Что такое безопасная сделка?

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

Что делать с отзывами и рейтингами?

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

Нужна ли политика персональных данных?

Да. Платформа обрабатывает данные пользователей и исполнителей: аккаунты, телефоны, email, адреса, переписку, платежи, отзывы, документы и историю заказов.

Какие документы нужны для запуска маркетплейса услуг?

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

Когда обращаться к юристу?

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

Связанные материалы

Обсудим IT-проект

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