договор оферта на создание сайта

Образец договора

Договор-оферта на платные услуги по созданию сайта.

Настоящая оферта представляет собой официальное предложение Индивидуального Предпринимателя Вавилина Анатолия Дмитриевича, ИНН: 526 318 940 733, ОГРНИП: 311 526 304 600 011, именуемый в дальнейшем Исполнитель, по оказанию услуг создания интернет-сайта любому юридическому или физическому лицу, именуемому в дальнейшем Заказчик, и выражает намерение сторон заключить Договор на создание сайта на условиях настоящей Оферты.

1. Предмет договора

Заказчик поручает, а Исполнитель принимает на себя обязанности по созданию интернет-сайта.

2. Права и обязанности сторон

2.1 Права и обязанности Исполнителя:

— Создать интернет-сайт и передать его в собственность Заказчику.

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

— заказать услуги хостинга от ООО ТаймВэб, на имя Заказчика; оплата хостинга осуществляется Заказчиком, в течении 7 дней с момента регистрации.

— передать все необходимые пароли доступа к администрированию Интернет-сайта.

— разместить Интернет-сайт на хостинге от компании ТаймВэб, либо передать Заказчику исходник сайта, для самостоятельного размещения Заказчиком сайта на другом хостинге.

— в обязанности Исполнителя не входит наполнение сайта информацией, но по обоюдной договоренности Исполнитель может на себя взять обязанности по наполнению.

— Исполнитель обязан предоставить инструкции по пользованию сайтом.

— Исполнитель вправе отказаться от выполнения работ, на любом этапе.

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

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

2.2 Права и обязанности Заказчика:

— Оплатить оказанные Исполнителем услуги, в случае, если его устраивает созданный сайт.

— Предоставить необходимые данные для регистрации домена и хостинга.

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

3. Порядок расчетов и выполнения работ

3.1 Оплата за создание сайта осуществляется путем безналичного перевода денежных средств на расчетный счет Исполнителя, либо другим способом, по обоюдной договоренности сторон.

3.2. Оплата услуг Исполнителя производится после выполнения работ по созданию сайта.

3.3 Регистрация доменного имени и передача сайта в собственность Заказчику осуществляется в течении 3 рабочих дней с момента поступления денежных средств на счет Исполнителя, при условии предоставления Заказчиком необходимых данных для регистрации домена, в случае, если данные Заказчиком не были предоставлены, регистрация домена и передача сайта осуществляется в течении 3 дней с момента получения Исполнителем необходимых данных от Заказчика;

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

3.5 После оплаты услуг Исполнителя сайт переходит в собственность Заказчика.

3.6 Фактом выполнения работ Исполнителем, является отсутствие претензии, направленной Исполнителю в течении месяца со дня оплаты, заказным письмом с уведомлением о вручении или курьером по юридическому адресу Исполнителя.

4.1 Стоимость услуг Исполнителя составляет 5000 рублей.

5. Ответственность сторон

5.1 Стороны несут ответственность за несоблюдение условий соглашения в соответствии с действующим гражданским законодательством Российской Федерации.

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

5.3 Исполнитель не несет юридической, материальной или иной ответственности за содержание, качество и соответствие действующему законодательству информации, размещенной Заказчиком на Сайте.

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

5.5 Исполнитель гарантирует, что на момент передачи сайта, сайт свободен от прав на него и доступа к нему у третьих лиц.

Источник

Как составить договор с заказчиком и не попасть в рабство

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

договор оферта на создание сайта. договор оферта на создание сайта фото. картинка договор оферта на создание сайта. смотреть фото договор оферта на создание сайта. смотреть картинку договор оферта на создание сайта.

договор оферта на создание сайта. договор оферта на создание сайта фото. картинка договор оферта на создание сайта. смотреть фото договор оферта на создание сайта. смотреть картинку договор оферта на создание сайта.

договор оферта на создание сайта. договор оферта на создание сайта фото. картинка договор оферта на создание сайта. смотреть фото договор оферта на создание сайта. смотреть картинку договор оферта на создание сайта.

Веб-разработчик, интернет-маркетолог, основатель и директор веб-студии «Облако».
В диджитал-сфере с 2013 года.

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

Девиз по жизни: «Люби, что делаешь. Делай, что любишь».

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

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

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

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

Работа над ошибками

И я начала с формы договора.

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

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

Кстати о бесплатном

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

Через некоторое время я осознала, что любой труд стоит денег, а написание технического задания ещё и неплохо увеличивает средний чек сделки.

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

Это не единственные подводные камни, которые мне встретились.

Изменения гарантийных условий

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

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

Когда мы назвали сроки диагностики сайта и сколько она у нас стоит, телефонный разговор прекратился. А на следующий день мы получили на имейл досудебную претензию с требованием восстановить сайт — бесплатно. В документе ссылались на положение Гражданского кодекса о том, что если гарантийный срок на услугу или выполненную работу не установлен, то заказчик вправе предъявлять претензии в течение двух лет со дня передачи результатов работы. (Об этом говорится в п. 2 ст. 724 ГК РФ.) Не знали об этом?

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

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

Итак, теперь наша гарантия не действует:

Изменения в бизнес-процессах

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

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

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

Согласования при разработке сайта

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

При сотрудничестве никто не застрахован от смены ЛПР (лица, принимающего решения). А новый человек часто смотрит на проект по-новому. У меня как-то был проект, за время которого в компании сменилось ЧЕТЫРЕ! маркетолога. И каждый из них видел будущий сайт совсем не таким, каким хотели его предшественники. Только подписи под каждым этапом согласования позволили нам не переделывать всё бесплатно.

Что согласовывать?

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

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

Источник

Как агентству и фрилансеру защитить свою работу

От бесконечных правочек и доработочек

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

Бесконечные правочки ведут к неприятным для проекта вещам: он становится невыгоден и все менее интересен студии. Теряется время, и другие проекты сложно планировать — а для компании это тоже потерянные деньги. Все участники проекта устают, падает их мотивация, а в итоге — качество проекта.

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

Это стало возможным благодаря двум вещам: жесткой внутренней системе документооборота и грамотно выстроенному общению с клиентами. В этой статье я расскажу о первом — документальном — способе защиты агентства и результатов нашей работы.

Осторожно, бюрократия

Наши правила документооборота достаточно жесткие. Оправдание этой бюрократии простое: мы хотим, чтобы наши права были защищены. При этом мы делаем еще две вещи:

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

Как делают сайты

Когда компания выходит на рынок, вырастает, меняет аудиторию или просто обнаруживает себя в 2019 году, ей становится нужен сайт.

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

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

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

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

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

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

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

Какие есть подходы и проблемы

Есть два подхода к созданию любого веб-проекта.

Первый подход — классическая «водопадная» модель разработки. Она подразумевает, что все части проекта идут последовательно друг за другом. Это значит, что сначала мы согласовываем задание и только потом начинаем рисовать дизайн-концепцию. Концепция будет основана на задании и переданных материалах. После концепции наступит очередь макетов, а когда макеты будут готовы — начнется сборка. Наполнять сайт мы будем только предоставленным контентом. При таком подходе стоимость проекта рассчитывается заранее и не меняется в процессе работы.

Второй подход — это применение так называемых гибких методологий (эджайл, скрам, тайм-энд-матириал и другие красивые слова — отсюда). При таком подходе разработка ведется этапами и не останавливается. Как пример: сначала быстро нарисовали, запрограммировали и выпустили главную страницу сайта и каталог. Потом добавили еще пару страниц. И еще пару страниц. Такой подход подразумевает почасовую оплату работы специалистов: сколько времени потратили на итерацию, столько она и будет стоить.

Работать «по водопаду» уже не так модно, как по эджайлу, но это все еще популярный подход в разработке сайтов.

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

Наш подход

Мы работаем по первой модели — «водопадной». Чтобы избежать проблем, мы фиксируем в документах все стоящее, все полезное и все спорное. Каждый этап работы также обрастает документами.

В итоге на любом проекте у нас есть:

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

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

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

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

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

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

Расскажу о каждом документе подробнее.

Договор

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

Во всех наших договорах мы прописываем важные для нас нюансы.

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

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

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

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

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

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

Приложение

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

В приложении всегда есть предоплата. В зависимости от договоренностей с клиентом и объема работ, она составляет от 20 до 100% стоимости контракта. Мы не работаем без предоплаты, потому что всегда есть шанс расторжения договора и прекращения сотрудничества. Будет обидно, если мы сделаем работу без предоплаты, ее не примут и потребуют расторгнуть договор. Получится, что денег нет, клиента нет, а время, которое потрачено на эту работу, не вернуть.

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

Сначала читать, потом подписывать

Разбивка по этапам выглядит примерно так:

При желании можно разбить проект на большее количество этапов: отдельно показать прототип, адаптацию макетов, верстку, тестирование и что-нибудь еще. Все зависит от проекта.

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

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

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

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

Вот что мы делаем для разработки концепции:

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

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

Задание

Задание — это стандартный первый этап работы над проектом. Мы употребляем именно термин «задание», а не «техническое задание» или «ТЗ», по нескольким причинам.

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

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

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

Источник

7 правил оформления публичной оферты для интернет-стартапа

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

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

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

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

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

В соответствии со статьёй 432 Гражданского кодекса договор заключается посредством направления оферты (предложения заключить договор) одной стороной и её акцепта (принятия предложения) другой стороной.

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

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

Совет №1. Не используйте публичные оферты, заимствованные у сервисов-конкурентов. Каждый бизнес уникален и имеет не только экономические, но и юридические особенности.

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

Совет №2. Если вы можете уйти из-под действия закона о защите прав потребителей, то сделайте это скорее.

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

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

Совет №3. Структурируя оферту, начните с создания матрицы юридических рисков.

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

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

Пунктом 2 статьи 310 Гражданского кодекса установлено, что, если кто-то из участников договора не является субъектом предпринимательской деятельности, право на одностороннее изменение его условий может быть предоставлено лишь стороне, не осуществляющей предпринимательскую деятельность (за исключением случаев, когда законом или иным правовым актом предусмотрена возможность предоставления договором такого права другой стороне).

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

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

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

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

Совет №6. Не называйте публичную оферту несуществующими юридическими терминами.

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

«Договор оферты» — это оксюморон. Надеюсь, вы помните, о чём был юридический ликбез в начале статьи.

При этом допустимо называть документ «договор-оферта», поскольку это определение справедливо отражает его двойственную природу (после акцепта и до него).

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

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

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

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

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

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *