Раз в месяц подрядчик присылает акт «работы выполнены в полном объёме» и просит подписать. Для бухгалтерии этого хватает, для контроля над проектом нет. Нормальный отчёт подрядчика по сайту - документ, из которого видно, что конкретно делали, сколько это заняло и как изменились метрики. Я много раз принимал дела у чужих исполнителей на проектах на Tilda, WordPress и кастомных сервисах и знаю, что скрывается за обтекаемыми формулировками в актах. Ниже - список того, что сам включаю в отчётность клиентам и что советую требовать от любого подрядчика каждый месяц.
Что должно быть в базовом отчёте по сайту
Минимальный набор, без которого отчёт превращается в формальность:
- список задач с датой начала и датой закрытия - не «в течение месяца», а конкретные числа;
- статус по каждой: сделано, в процессе, отложено - и причина, если отложено;
- ссылка на результат - коммит в git, changelog плагина, номер деплоя, скрин из панели администратора;
- часы, потраченные на задачу, если оплата почасовая, с разбивкой хотя бы по крупным блокам работ;
- список страниц или файлов, которые трогали.
Если сайт на WordPress, нормальный отчёт содержит ссылку на коммит или пункт в changelog плагина, а не фразу «доработали функционал корзины». Если правки шли на Tilda через встроенный JS или Zero Block, я прикладываю сам код правки или ссылку на версию в репозитории - заказчик не обязан лезть в код, но у него должна быть возможность это сделать в любой момент.
Отчётность по техподдержке - отдельно от новых доработок
Смешивать в одном отчёте часы на поддержку и часы на разработку новых функций - типичный способ размыть картину. Поддержка и доработки - разные по смыслу работы, и в отчёте они должны идти отдельными блоками:
- время реакции на каждый инцидент - от заявки до первого ответа и до решения;
- список закрытых тикетов с кратким описанием проблемы;
- аптайм за период в процентах, а не фразой «сайт работал стабильно»;
- когда делались резервные копии и проверялись ли они восстановлением на тестовом окружении.
У меня техподдержка сайта начинается от 15 000 ₽ в месяц, и в отчёт по ней всегда попадают конкретные цифры: сколько тикетов закрыто, сколько часов ушло на каждый, был ли простой и в чём причина. Без этого клиент платит за поддержку вслепую и узнаёт о проблемах постфактум, когда уже потерял заявки.
Как проверять отчёт по интеграциям и доработкам
Для типовых интеграций отчёт должен подтверждаться не словами, а проверяемым результатом. Вот что смотрю сам при приёмке работ на разных стеках:
| Тип работ | Что должно быть в отчёте | Как проверить самостоятельно |
|---|---|---|
| Эквайринг T‑Bank на WooCommerce | Лог тестового платежа, статус webhook, обработка ошибок оплаты | Провести тестовую оплату на 1 ₽, проверить, что заказ сменил статус |
| Виджет СДЭК на сайте | Расчёт стоимости на 2-3 разных адресах, скрин настроек тарифов | Открыть корзину, ввести адрес, сверить с калькулятором на сайте СДЭК |
| Кастомные скрипты на Tilda | Что именно изменилось в коде, где искать правку - Zero Block или встроенный JS | Открыть консоль браузера на странице, проверить, что нет ошибок |
| Telegram-бот на aiogram | Версия бота после деплоя, список изменённых команд, лог запуска | Написать боту, пройти ключевые сценарии вручную |
| Автоматизация в n8n | Скрин изменённого workflow, лог выполнений за месяц, список ошибок | Зайти в интерфейс n8n, открыть execution log, проверить статус запусков |
Если подрядчик не может показать лог выполнений или тестовый платёж, а только рассказывает, что «всё настроено и работает», это повод переспросить, где это можно увидеть своими глазами.
Отдельно у меня в блоге есть подборка готовых скриптов для сайтов - по ней удобно свериться, совпадает ли то, что подрядчик описывает в отчёте, с реальной логикой типовых интеграций, или он выдаёт стандартное решение за уникальную разработку.
Метрики, без которых отчёт бесполезен
Отчёт без цифр - это пересказ, а не отчётность. Прошу присылать не общие впечатления, а конкретные значения:
- аптайм за месяц в процентах - например, 99,8% означает 87 минут простоя, и дальше уже видно, укладывается это в договорённости или нет;
- среднее время ответа сервера и динамику по сравнению с прошлым месяцем;
- Core Web Vitals или PageSpeed до и после доработок, если менялась вёрстка или скрипты;
- количество 404 и 500 ошибок в логах - резкий скачок обычно указывает на сломанную интеграцию или битые ссылки после правок;
- число заявок или конверсию, если задача напрямую влияла на воронку.
Без этих цифр отчёт превращается в текст, который можно писать не глядя на сайт.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Красные флаги в отчётах подрядчиков
За несколько лет приёмки чужих проектов я выработал список формулировок и паттернов, которые сразу настораживают:
- общие фразы вроде «работы выполнены в срок» без единой ссылки на результат;
- поддержка и разработка новых функций свалены в один список без разделения по типу и стоимости часа;
- ни слова про бэкапы - ни когда делались, ни где хранятся;
- отчёт за разные месяцы отличается только датой в шапке;
- про инциденты подрядчик не пишет вообще, хотя сайт явно лежал - это видно по логам или жалобам клиентов, которые доходили в обход отчёта.
Если такие признаки повторяются из месяца в месяц, это не разовая небрежность, а способ работы конкретного исполнителя. Стоит менять формат договорённостей или самого подрядчика, пока это не переросло в потерю данных или простой в разгар сезона продаж.
Шаблон отчёта - что фиксировать каждый месяц
Использую таблицу такого вида для любого проекта, независимо от стека:
| Дата | Задача | Статус | Часы | Ссылка на результат |
|---|---|---|---|---|
| 03.07 | Правка расчёта доставки СДЭК | Готово | 2,5 | Коммит #a41f2 |
| 10.07 | Инцидент: сбой оплаты T‑Bank | Закрыт | 1 | Тикет #128, лог webhook |
| 18.07 | Резервная копия базы | Выполнено | - | Хранилище, дата проверки восстановления |
Такой формат занимает у подрядчика 15-20 минут в конце месяца и снимает большую часть споров о том, за что вообще заплачены деньги.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Как часто нужно требовать отчёт, если сайт на постоянной поддержке?
Раз в месяц - это минимум для большинства проектов. Для интернет-магазинов и сервисов с высокой нагрузкой в сезон продаж имеет смысл смещаться на раз в две недели, особенно если были инциденты в прошлом отчётном периоде.
Что делать, если подрядчик отказывается присылать подробный отчёт?
Сначала прописать формат отчётности в договоре или допсоглашении - конкретный список пунктов, а не общее «отчёт о проделанной работе». Если после этого подрядчик всё равно присылает формальные фразы без ссылок и цифр, это сигнал, что стоит подыскивать замену, пока проект не завязан на него критически.
Нужно ли платить отдельно за составление отчёта?
Нет, отчётность - часть добросовестного ведения проекта и входит в стоимость работ или ежемесячной поддержки. Отдельная плата за отчёт - повод насторожиться, а не согласиться.
Как проверить отчёт, если сам не разбираюсь в коде?
Попросите скрины из консоли браузера, панели хостинга или сервиса мониторинга вроде UptimeRobot - это можно сверить визуально без знания кода. Если сомнения серьёзные, разовая консультация стороннего специалиста для проверки отчёта и состояния сайта стоит от 3 000 ₽ и снимает большую часть вопросов.