AlexMorozov
New member
Три года назад я закрыл проект и остался ни с чем: заказчик принял работу, похвалил в переписке, а деньги так и не пришли. Спорить было нечем, потому что договора не было, акта не было, а из доказательств — только дружелюбные сообщения в мессенджере. С тех пор я собрал коллекцию из шести причин, по которым заказчики не платят, и выстроил для себя схему, которая почти убирает этот риск. Делюсь, потому что тема болит у всех, кто работает на фрилансе или держит небольшую студию.
Причина первая: работа формально не сдана. Заказчик говорит, что ждёт финальную версию, версия лежит у него на почте, но акта нет — и платить вроде как не за что. Вторая причина — размытое техническое задание. Если в нём написано сделать красиво и удобно, то в момент приёмки выясняется, что красиво — это совсем другое, и ваш макет вообще не то.
Третья причина: один большой платёж в конце. Весь проект висит на честном слове, и если у заказчика в этот месяц не сложилось с деньгами, платить он будет не вам, а тем, кто важнее. Четвёртая: у него самого кассовый разрыв. Такое бывает не от жадности, человек реально ждёт оплату от своего клиента и тянет с вашей.
Пятая причина — личные отношения. Работали по-дружески, без бумаг, на доверии, а когда начались проблемы, оказалось, что и разговаривать не о чем. Шестая, самая обидная: вкусовщина. Работа сделана по техническому заданию, но заказчику не зашло, а критериев приёмки в договоре нет, поэтому доказать свою правоту невозможно. Заметьте, в пяти случаях из шести виноват не только заказчик, но и я сам.
Теперь о том, как строить заранее. У меня есть короткий рамочный договор на одну-две страницы: предмет, этапы, сумма, сроки, порядок приёмки и ответственность. К нему счёт на предоплату — от тридцати до пятидесяти процентов, в зависимости от проекта. Этапы дроблю так, чтобы каждый закрывался отдельным актом и отдельным платежом: дизайн, вёрстка, интеграция, запуск. Чем меньше шаг, тем меньше потеря, если что-то пойдёт не так.
Обязательно прописываю критерии приёмки и срок на ответ. Например: заказчик рассматривает результат пять рабочих дней, правки присылает одним списком, а если молчит, работа считается принятой. Количество правок ограничено, всё сверх — отдельная смета и отдельная договорённость. Любые изменения обсуждаю только письменно: голосовые сообщения в мессенджере не считаются, потому что потом невозможно вспомнить, кто что обещал.
И про рычаги. Исходники, доступы, админку и домен отдаю после финального платежа — это не шантаж, а нормальный порядок расчётов. Если проект запускается на моём стенде, заказчик видит результат, но продолжает платить за этапы. Когда деньги всё-таки зависают, я не пишу гневных писем: сначала спокойная претензия с расчётом и сроком, потом пауза, потом уже разговор о суде. Чаще всего помогает вежливая бумага, а не эмоции.
Заканчиваю мыслью, к которой шёл несколько лет: договариваться о деньгах нужно до того, как вы открыли редактор кода, а не после. Это не про недоверие, это про уважение к своему труду и к чужому времени. А теперь вопрос к вам: какая причина неоплаты встречалась в вашей практике чаще всего и какой пункт в договоре вы считаете обязательным?
Причина первая: работа формально не сдана. Заказчик говорит, что ждёт финальную версию, версия лежит у него на почте, но акта нет — и платить вроде как не за что. Вторая причина — размытое техническое задание. Если в нём написано сделать красиво и удобно, то в момент приёмки выясняется, что красиво — это совсем другое, и ваш макет вообще не то.
Третья причина: один большой платёж в конце. Весь проект висит на честном слове, и если у заказчика в этот месяц не сложилось с деньгами, платить он будет не вам, а тем, кто важнее. Четвёртая: у него самого кассовый разрыв. Такое бывает не от жадности, человек реально ждёт оплату от своего клиента и тянет с вашей.
Пятая причина — личные отношения. Работали по-дружески, без бумаг, на доверии, а когда начались проблемы, оказалось, что и разговаривать не о чем. Шестая, самая обидная: вкусовщина. Работа сделана по техническому заданию, но заказчику не зашло, а критериев приёмки в договоре нет, поэтому доказать свою правоту невозможно. Заметьте, в пяти случаях из шести виноват не только заказчик, но и я сам.
Теперь о том, как строить заранее. У меня есть короткий рамочный договор на одну-две страницы: предмет, этапы, сумма, сроки, порядок приёмки и ответственность. К нему счёт на предоплату — от тридцати до пятидесяти процентов, в зависимости от проекта. Этапы дроблю так, чтобы каждый закрывался отдельным актом и отдельным платежом: дизайн, вёрстка, интеграция, запуск. Чем меньше шаг, тем меньше потеря, если что-то пойдёт не так.
Обязательно прописываю критерии приёмки и срок на ответ. Например: заказчик рассматривает результат пять рабочих дней, правки присылает одним списком, а если молчит, работа считается принятой. Количество правок ограничено, всё сверх — отдельная смета и отдельная договорённость. Любые изменения обсуждаю только письменно: голосовые сообщения в мессенджере не считаются, потому что потом невозможно вспомнить, кто что обещал.
И про рычаги. Исходники, доступы, админку и домен отдаю после финального платежа — это не шантаж, а нормальный порядок расчётов. Если проект запускается на моём стенде, заказчик видит результат, но продолжает платить за этапы. Когда деньги всё-таки зависают, я не пишу гневных писем: сначала спокойная претензия с расчётом и сроком, потом пауза, потом уже разговор о суде. Чаще всего помогает вежливая бумага, а не эмоции.
Заканчиваю мыслью, к которой шёл несколько лет: договариваться о деньгах нужно до того, как вы открыли редактор кода, а не после. Это не про недоверие, это про уважение к своему труду и к чужому времени. А теперь вопрос к вам: какая причина неоплаты встречалась в вашей практике чаще всего и какой пункт в договоре вы считаете обязательным?