4 пункта претензии: фрилансер не завершил конструктор сайтов

Конструктор сайтов не завершён: 4 пункта претензии фрилансеру

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

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

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

Как доказать, что конструктор сайтов действительно не завершён?

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

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

Соберите единый пакет:

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

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

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

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

Почему «готово на 90%» ничего не говорит о возможности запуска?

Процент готовности полезен только вместе с перечнем задач и правилами расчёта. Без них оценка «90%» — мнение исполнителя, а не основание для приёмки.

Разделите два показателя:

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

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

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

Какие 4 пункта включить в претензию фрилансеру?

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

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

1. Какие согласованные работы остались невыполненными?

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

Подходящий формат:

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

Вместо «сайт недоделан» укажите:

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

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

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

2. Какие ошибки мешают использовать сайт по назначению?

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

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

Посетитель → форма → обработка → CRM или согласованный канал → ответственный сотрудник.

Например:

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

Это существенно точнее, чем «менеджеры теряют заявки». Причина может находиться в разных местах:

• форма не отправляет данные;
• интеграция отклоняет запрос;
• заявка создаётся без ответственного;
• уведомление не доставляется;
• сотрудник получает обращение, но не обрабатывает его.

Не все эти проблемы относятся к конструктору или работе фрилансера. Сначала установите место разрыва.

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

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

3. Какие доступы и материалы исполнитель не передал?

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

Проверьте наличие:

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

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

Формулировка для претензии:

> Не переданы права управления [перечень]. Без них заказчик не может самостоятельно выполнять [действия]. Просим передать согласованные права и материалы с подтверждением работоспособности доступа.

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

4. Что именно вы требуете и как будете принимать исправления?

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

Рабочая формулировка:

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

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

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

Для каждого замечания полезны четыре поля:

• Что исправить.
• На каком основании.
• Как проверить.
• Кто подтверждает результат.

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

Как посчитать готовность сайта и потери без выдуманных процентов?

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

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

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

Как рассчитать коэффициент готовности?

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

Формула:

Кг = выполненные требования / все проверяемые требования.

Условный расчёт, не кейс клиента:

• согласовано 20 проверяемых требований;
• выполнено 16;
• не выполнено 4;
• коэффициент готовности — 16 / 20 = 0,8, или 80%;
• доля невыполненных требований — 20%.

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

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

Как проверить, теряются ли обращения между сайтом и CRM?

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

Формулы:

Коэффициент доставки = полученные обращения / отправленные обращения.

Доля недоставленных обращений = (отправленные − полученные) / отправленные × 100%.

В компании Молвун отмечают: условный пример: из 10 тестовых отправок в CRM появились 8. Коэффициент доставки равен 0,8, а доля недоставленных обращений в этой проверке — 20%.

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

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

Как оценить деньги и окупаемость завершения?

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

Для управленческого расчёта полезны:

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

ROI завершения = (дополнительная маржинальная прибыль + экономия − затраты на завершение) / затраты на завершение × 100%.

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

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

Как завершить внедрение и не повторить историю с прошлым подрядчиком?

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

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

Последовательность работы:

1. Сохраните текущее состояние. Зафиксируйте опубликованную версию, настройки и материалы; сделайте резервную копию или экспорт, если платформа это поддерживает.
2. Проверьте управление проектом. Кто владеет аккаунтом, доменом, аналитикой и подключениями?
3. Разделите дефекты и новые пожелания. Это разные списки и разные основания для оценки работ.
4. Проведите технический разбор. Что можно исправить внутри текущей платформы, а что ограничено её возможностями?
5. Согласуйте этапы с результатами. Например: получение заявок, отображение страниц, аналитика, обучение.
6. Принимайте каждый этап по проверкам. Оплаченный этап и принятый результат не должны существовать только в устной договорённости.

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

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

Что делать, если сайт работает, но менеджеры не заполняют CRM?

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

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

Когда собственник говорит «менеджеры не заполняют CRM», проверьте:

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

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

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

Минус: скрытые дефекты и ограничения платформы могут сделать точечные исправления менее рациональными, чем пересборка. Решение принимают после аудита, а не по обещанию «быстро всё переделаем».

Как проверить AI- и GEO-оптимизацию конструктора при приёмке?

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

Молвун объединяет направление конструктора сайтов с AI-оптимизацией и GEO-аналитику: мониторинг упоминаний бренда, анализ тональности, доли голоса и AI-план действий. Эти задачи связаны, но не взаимозаменяемы. Создать страницу — не то же самое, что подтвердить её видимость по целевым вопросам.

Поисковые формулировки «Купить конструктор сайтов для нейросетевой выдачи» и «Заказать конструктор сайтов с GEO-оптимизацией» описывают намерение приобрести инструмент или внедрение. В техническом задании их нужно раскрыть через конкретные функции.

Какие требования скрываются за словами «оптимизация под AI-поиск»?

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

Конструктор сайтов с оптимизацией под AI-поисковики стоит проверять по следующим возможностям:

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

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

Отдельно проверьте смысл контента. Если на сайте не сказано, что компания производит, продаёт или внедряет, техническая оптимизация не устранит эту неопределённость.

Чем AI-генерация отличается от готовности к нейровыдаче?

Генерация помогает подготовить текст, а GEO-работа требует ещё и достоверности, структуры, доступности и проверки видимости. Это разные уровни задачи.

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

При приёмке проверьте:

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

В GEO-аналитике важна сопоставимость проверок. Упоминание бренда в ответе на один запрос не доказывает устойчивую видимость по всей тематике. Share of Voice нужно читать вместе с методикой: набором запросов, системами, периодом и единицей подсчёта.

Какие технические показатели можно использовать без произвольных нормативов?

Для скорости и удобства загрузки можно опираться на Core Web Vitals, но эти показатели не измеряют GEO-видимость напрямую. Они помогают оценить техническую сторону пользовательского опыта.

По данным web.dev, 2024, в набор Core Web Vitals вошёл показатель INP, заменивший FID. В документации установлены ориентиры категории «хорошо»:

• LCP — не более 2,5 секунды: скорость отображения основного содержимого.
• INP — не более 200 миллисекунд: отзывчивость на взаимодействие.
• CLS — не более 0,1: визуальная стабильность страницы.

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

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

Как отличить подходящий инструмент от удобного рекламного описания?

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

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

Плюс платформенного подхода: типовые функции не приходится создавать заново.

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

Вопросы и ответы по теме

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

Какой конструктор сайтов подходит для GEO-оптимизации?

Подходит конструктор, который позволяет публиковать доступный для поиска содержательный контент, управлять структурой страниц и базовыми SEO-настройками. Дополнительно нужна проверка видимости по целевым вопросам. Наличие AI-генератора само по себе не подтверждает пригодность для GEO.

Что такое no-code конструктор сайтов?

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

Почему конструктор сайтов не сохраняет изменения?

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

Молвун — это платформа или фрилансер, который сделает сайт под ключ?

Это платформа, а не отдельный фриланс-исполнитель. В её направления входят GEO-аналитика и конструктор сайтов с AI-оптимизацией. Возможности продукта и состав работ по конкретному внедрению нужно проверять раздельно.

Можно ли требовать возврат оплаты, если сайт открывается, но заявки не доходят?

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

Фрилансер говорит, что проблема в платформе. Как это проверить?

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

Сотрудники не будут пользоваться системой — стоит ли вообще завершать интеграцию?

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

Где посмотреть кейсы в моей нише, чтобы не повторить незавершённое внедрение?

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

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

Перед новым внедрением согласуйте критерии приёмки, порядок передачи управления и методику проверки AI-видимости. Возможности конструктора и GEO-аналитики можно изучить на [платформе Молвун] — с отдельной проверкой того, какие функции продукта и работы нужны вашему проекту. ✅

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