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

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

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

Аналитика услуги: что такое гарантия в проектах разработки сайта

1) Что обычно покрывает гарантия

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

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

2) Что обычно НЕ является гарантией

Чаще всего не входит в гарантию:

• новые требования, “хотим по-другому”, расширение функционала;
• контентные работы (написание/редактура) и маркетинговые задачи;
• изменения из-за внешних факторов (обновления браузеров/платформ/сервисов), если это не дефект поставки;
• работы по SEO-продвижению и росту трафика как результату;
• инциденты из-за нарушения регламента эксплуатации (не обновляли, дали доступы, отключили бэкапы).

3) Почему гарантия зависит от приемки

Гарантия начинается там, где заканчивается приемка. Если нет критериев “готово” и чек-листа, дефектность становится субъективной, и гарантия превращается в спор. Поэтому для B2B важно принимать сайт по сценариям: формы → CRM, мобильный критический путь, базовая SEO-техничка, доступы и безопасность, корректность админки.

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

Какие сроки гарантии встречаются на практике

Единого стандарта нет, но чаще всего встречаются диапазоны:

• 14–30 дней — минимальная гарантия на устранение дефектов после релиза;
• 2–3 месяца — распространенный срок для проектов среднего объема;
• 6–12 месяцев — встречается, когда подрядчик одновременно ведет сопровождение или есть расширенные обязательства.

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

Кому нужна расширенная гарантия

• компаниям, где сайт — основной канал лидов и любая ошибка = потери продаж;
• проектам со сложными интеграциями (CRM, телефония, аналитика);
• сайтам с регулярными релизами и активной рекламой;
• бизнесам с требованиями комплаенса и безопасности.

География и SLA: что меняется, если лиды приходят из разных часовых поясов

При распределенной аудитории важнее не “длина гарантии”, а скорость реакции на инциденты. Поэтому в договорной модели стоит фиксировать SLA: время реакции, время восстановления, режим поддержки (в рабочие часы или 24/7), каналы связи и приоритеты. Чем выше цена простоя, тем жестче должен быть SLA и тем важнее мониторинг и процессы.

CTA: как оформить гарантию так, чтобы она работала

Чтобы гарантия была реальной, зафиксируйте: состав поставки (ТЗ/прототипы/макеты), критерии приемки по сценариям, что считается дефектом, сроки реакции и порядок исправлений, а также границу между гарантийными работами и развитием.

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

И чтобы гарантия не “сгорела” из-за инцидентов, сразу после релиза внедрите защитный контур: как защитить сайт после запуска.

Практика: как прописать гарантию на сайт так, чтобы не спорить после запуска

Проблемы с гарантией на разработку сайта возникают не из-за “плохой воли”, а из-за разной трактовки понятий: что считать дефектом, что считать новой задачей, и кто отвечает за внешние изменения (плагины, обновления, интеграции сервисов). В B2B, где сайт — канал лидов, спор о гарантии обычно совпадает с моментом, когда бизнесу срочно нужно исправление. Поэтому гарантию надо проектировать как процесс: приемка → классификация дефектов → SLA → регламент релизов.

Сценарии: где чаще всего возникают конфликты по гарантии

Сценарий 1. “Это баг или улучшение?”

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

Сценарий 2. Данные в CRM не такие, как нужны продажам

Если контракт данных не был зафиксирован, после запуска продажи начинают просить дополнительные поля, статусы, маршрутизацию, UTM. Это часто относится к развитию, но воспринимается как “ошибка”. Решение — фиксировать состав данных заранее.

Сценарий 3. После обновления CMS/плагина что-то сломалось

Если в договоре не описано, кто обновляет, как тестируется и кто несет ответственность за совместимость, гарантия становится “минным полем”. В B2B лучше сразу связать гарантию с эксплуатацией: staging, регресс, окно релиза.

Сценарий 4. Инцидент безопасности и “кто виноват”

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

Сравнение: формальная гарантия vs рабочая гарантия

Формальная

• указан срок (например, 30 дней), но нет критериев дефекта;
• нет SLA, неизвестно время реакции;
• нет процесса релизов и регресса;
• конфликты решаются “перепиской”, сроки растут.

Рабочая

• есть критерии приемки по сценариям и чек-лист;
• дефекты классифицированы по приоритетам;
• зафиксированы SLA и порядок исправлений;
• есть регламент релизов (staging/регресс/окно).

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

Стоимость: таблица обязательных пунктов гарантийного регламента

Пункт	Как формулировать	Зачем нужен	Типовая ошибка
Состав поставки	ТЗ/прототипы/макеты/список интеграций	фиксирует, что “должно работать”	размытые формулировки “сайт под ключ”
Критерии приемки	сценарии: формы, CRM, мобильный путь, SEO-минимум	отделяет дефект от пожелания	приемка “на глаз”
Классификация дефектов	критичный/высокий/средний/низкий	управляет очередью исправлений	все задачи считаются “срочными”
SLA	время реакции и восстановления	делает гарантию предсказуемой	нет сроков, исправления “когда сможем”
Исключения	внешние сервисы, изменения требований, вмешательства третьих лиц	снижает конфликтность	гарантия “на всё” без регламента
Регламент релизов	staging, регресс, окно релиза, откат	защищает сайт от поломок	правки напрямую в прод

CTA: чек-лист “гарантия без конфликтов”

1. Зафиксируйте состав поставки и критерии приемки по сценариям.
2. Опишите интеграции как контракт данных (поля, UTM, статусы, ошибки).
3. Разделите дефекты и развитие, определите порядок change request.
4. Пропишите SLA и приоритизацию дефектов.
5. Закрепите регламент релизов и ответственность за обновления.

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

Специфика гарантий в B2B: как отличить “дефект” от “развития” и защитить бизнес

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

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

Как выбрать гарантийную модель: 4 принципа

1) Приемка по сценариям

В B2B сайт принимается не “в целом”, а по ключевым сценариям: форма → CRM → уведомления, мобильный критический путь, админка и публикация, базовая SEO-техничка, безопасность доступа. Если сценарии не зафиксированы, дефектность становится субъективной.

2) Контракт данных по интеграциям

Интеграции — самая частая зона конфликтов: “лиды приходят, но не так”. Контракт данных (поля, источники, UTM, статусы, ошибки, логирование) отделяет гарантийный дефект (не соответствует согласованному) от развития (хотим новые поля и маршрутизацию).

3) SLA и приоритизация дефектов

Для бизнеса важнее скорость реакции, чем “длина гарантии”. Поэтому гарантийная модель должна включать SLA: время реакции и время восстановления по приоритетам (критичный/высокий/средний/низкий). Тогда при падении формы или сбое интеграции вы не спорите, а действуете по регламенту.

4) Граница между гарантией и эксплуатацией

Гарантия исправляет дефекты поставки. Эксплуатация обеспечивает жизнь сайта: обновления, безопасность, мониторинг, бэкапы, контроль скриптов. Если эксплуатации нет, дефекты “производятся” внешней средой, и гарантия не может закрыть риски. Поэтому в B2B гарантию разумно дополнять договором поддержки.

FAQ: 12 вопросов о сроке гарантии и гарантийных условиях

1) Какой срок гарантии считается нормальным для сайта?

На практике встречаются разные сроки: от 14–30 дней (минимальный период устранения дефектов после релиза) до 2–3 месяцев (распространенный стандарт для проектов среднего объема) и 6–12 месяцев (обычно при наличии сопровождения или расширенных обязательств). Но “нормальность” срока зависит от того, что именно покрывается: если гарантия включает только исправление багов по ТЗ, длинный срок не всегда дает больше пользы, чем короткий, но с понятным SLA. Для B2B ключевой показатель — сколько времени потребуется, чтобы восстановить лидогенерацию при критичном дефекте. Поэтому при выборе ориентируйтесь не только на срок, но и на критерии дефекта, процессы релизов и поддержку.

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

Обычно гарантия начинается после приемки результата, потому что приемка фиксирует, что поставка соответствует согласованным материалам. Если приемка неформальная, гарантия становится спорной: заказчик может считать, что “ещё не приняли”, а подрядчик — что “всё сдано”. В B2B лучше закрепить этапность: предварительная приемка на staging, финальная приемка после релиза, и старт гарантийного срока с даты подписания акта/протокола. Тогда все стороны понимают, когда начинаются обязательства и что именно считается принятым. Важно также описать, что делать, если дефект обнаружен в период приемки: он исправляется до старта гарантии или фиксируется отдельным протоколом.

3) Что считается гарантийным дефектом, если ТЗ короткое?

Если ТЗ минимальное, дефектность надо привязать к артефактам, которые реально существуют: прототипы, дизайн-макеты, описание сценариев, список интеграций, чек-лист приемки. В B2B разумно использовать критерии по сценариям: форма отправляет заявку, заявка создается в CRM с нужными полями и UTM, события аналитики фиксируются, мобильный путь работает. Тогда даже при коротком ТЗ вы имеете объективные проверки. Если этого нет, спор неизбежен: заказчик говорит “не так работает”, подрядчик отвечает “так не было описано”. Поэтому при коротком ТЗ важно компенсировать его сильной приемкой и протоколом сценариев. Это дешевле, чем спорить после запуска.

4) Должен ли подрядчик чинить баги бесплатно, если заказчик менял сайт сам?

Обычно гарантия распространяется на поставку в исходном виде. Если заказчик или третьи лица внесли изменения в код, плагины, настройки сервера, это может снять гарантийные обязательства по затронутой части, потому что подрядчик не контролирует среду. В B2B это особенно важно: маркетинг иногда “ставит плагины”, devops меняет сервер, а затем ломается форма. Правильный подход — регламент: какие изменения допустимы без согласования, кто имеет доступ, где staging, как проходят релизы. Тогда вы минимизируете риск “самоисправлений” в продакшене. Если бизнесу нужно менять сайт самостоятельно, лучше иметь сопровождение и правила релизов, чтобы гарантия не превращалась в спор о причинах.

5) Что делать, если дефект связан с внешним сервисом (CRM, телефония, аналитика)?

Нужно разделить ответственность: дефект поставки или внешняя деградация. Если интеграция была реализована правильно, но CRM изменила API, истек ключ, изменились правила безопасности или лимиты, это обычно относится к эксплуатации. В B2B такие ситуации неизбежны, поэтому в договоре полезно прописать, что входит в поддержку интеграций: мониторинг, обновление ключей, адаптация к изменениям API. И важно иметь наблюдаемость: логи запросов и ошибок интеграции, чтобы быстро определить причину. Без логов спор превращается в гадание. Практика: договориться о реакции на инциденты интеграций и закрепить ответственных по сторонам.

6) Может ли гарантия включать SEO-результат (позиции, трафик)?

Обычно нет, потому что позиции зависят от множества факторов: конкуренты, обновления алгоритмов, контент, ссылки, поведение пользователей. Гарантия может включать техническую корректность SEO-основы: редиректы, robots/sitemap, canonical, микроразметку, скорость, отсутствие критичных ошибок. Но обещать “топ-3” как гарантию для разработки — рискованная и часто некорректная формулировка. В B2B правильнее разделять: гарантия на корректность реализации, а SEO-продвижение — отдельная услуга с KPI и оговорками. И после релиза важно вести SEO как процесс — что подробно разобрано в материале о факторах SEO-позиций.

7) Как оформлять изменения, чтобы они не “съедали” гарантию?

Нужен процесс change request: фиксируем новую идею, оцениваем влияние на сроки/бюджет, принимаем решение — включать в текущий релиз или переносить. Изменения должны быть отделены от исправления дефектов. В B2B это особенно важно, потому что после запуска появляется много “хотелок” от продаж и маркетинга. Если все это смешать, гарантия распадется: подрядчик будет считать, что это развитие, заказчик — что это “доделайте как надо”. Поэтому изменение должно иметь документ: что меняем, почему, критерии приемки и стоимость. Тогда гарантия остается чистой: дефекты исправляются, изменения оплачиваются и принимаются отдельно.

8) Какие дефекты считаются критичными и требуют срочной реакции?

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

9) Почему гарантия без поддержки не защищает сайт после релиза?

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

10) Как договориться о “мелких правках” в гарантийный период?

Есть два рабочих подхода. Первый — строго: гарантия только на дефекты, любые правки — отдельные задачи. Второй — гибрид: в гарантию добавляют небольшой лимит часов на мелкие изменения, чтобы снять напряжение в период адаптации после запуска. В B2B гибрид часто удобнее, потому что после релиза появляются уточнения по текстам, формам и блокам. Главное — зафиксировать лимит и перечень: что считается мелкой правкой (например, до N часов) и что считается развитием. Тогда ожидания прозрачны. И важно не путать “мелкие правки” с крупными изменениями структуры: они должны идти отдельным change request.

11) Как связать гарантию с безопасностью и доступами?

Гарантия предполагает контролируемую среду. Если доступы раздаются хаотично, нет 2FA, подрядчики имеют постоянный доступ, а обновления ставятся “как получится”, инциденты становятся вероятными. После инцидента возникает спор: дефект ли это поставки или нарушение регламента. Поэтому в B2B в гарантийных условиях полезно закрепить минимальные требования эксплуатации: кто имеет доступ, как выдаются доступы, обязательность 2FA, порядок обновлений, наличие бэкапов и мониторинга. И после запуска нужно внедрить защитный контур — как защитить сайт после релиза — чтобы гарантия не “сгорала” из-за управленческих ошибок.

12) Какой формат документов лучше: один договор или гарантийный регламент?

Лучше иметь договор + приложение (регламент), где расписаны детали: критерии приемки, классификация дефектов, SLA, порядок релизов и исключения. В договоре часто слишком мало места для технических нюансов, а регламент позволяет описать всё конкретно. В B2B это снижает конфликтность: при инциденте вы открываете документ и действуете по правилам, а не обсуждаете “как правильно”. Дополнительно можно иметь чек-лист приемки и протокол интеграций как отдельные приложения. Такой пакет документов выглядит профессионально и повышает доверие корпоративных клиентов.

Глоссарий

1) Дефект

Несоответствие согласованным требованиям (ТЗ/макеты/прототипы/критерии приемки). Дефект исправляется по гарантии, если выявлен в гарантийный период и не вызван внешними вмешательствами.

2) Развитие

Любые новые требования, улучшения UX, расширение функционала, изменение структуры и логики. Развитие оформляется как change request и обычно оплачивается отдельно.

3) Приемка

Процедура подтверждения, что сайт соответствует требованиям. В B2B приемка должна быть сценарной: формы, CRM, аналитика, мобильный путь, SEO-минимум.

4) SLA

Соглашение о сроках реакции и восстановления. В B2B SLA критично для защиты лидогенерации при сбоях.

5) Приоритет дефекта

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

6) Change request

Процесс управления изменениями: фиксация новой идеи, оценка, решение о включении. Защищает гарантию от расползания.

7) Контракт данных

Описание полей и логики интеграций: UTM, статусы, ошибки, уведомления, логирование. Ключ к снижению споров о “лиды не такие”.

8) Регламент релизов

Правила публикации изменений: staging, регресс, окно релиза, план отката. Делает сайт устойчивым и снижает риск поломок.

9) Staging

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

10) Регресс

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

11) Эксплуатация

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

12) Откат

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

Заключение

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

CTA

Чтобы гарантия реально защищала бизнес, фиксируйте не только срок, но и критерии дефекта: приемка по сценариям, контракт интеграций, SLA по приоритетам и регламент релизов (staging/регресс/окно). Дополните гарантию обслуживанием — что включает техническая поддержка — и выстройте защитный контур после запуска — как защитить сайт от взлома — чтобы сайт оставался стабильным источником лидов, а изменения не превращались в риск и споры.