T&M или фикс: какая модель поддержки сайта выгоднее бизнесу в 2026 году

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

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

Спор «T&M против фикса» обычно ведут как спор о деньгах. По сути, это спор о другом — кто несёт риск неопределённости. Если объём работ известен заранее, риск небольшой, и его можно зафиксировать в цене. Если объём заранее неизвестен, риск кто-то оплачивает: либо подрядчик закладывает его в сумму, либо заказчик платит по факту.

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

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

Time & Materials — оплата за фактически отработанное время. Заказчик покупает пакет часов на месяц, каждая задача оценивается в часах до начала работ, а в отчёт попадает то, что реально сделано. Ставка зафиксирована, объём — переменная величина.

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

Отсюда следует главное практическое различие. В фиксе любое изменение задачи требует пересогласования: новое ТЗ, новая оценка, новый срок. В T&M изменение приоритетов не ломает договор — меняется только порядок задач внутри пакета часов.

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

Таблица 1. Что различает модели на практике

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

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

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

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

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

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

Вторая сильная сторона модели — оплата по факту. Заказчик оплачивает то, что реально сделано, и видит, на что ушло время.

Третья причина выбрать T&M — доступ к команде вместо доступа к исполнителю. Задачи поддержки редко укладываются в одну специальность: часть требует бэкенда, часть — вёрстки, часть — DevOps, часть — аналитики или дизайна. Модель почасовой оплаты позволяет подключать нужную экспертизу под конкретную задачу, не оплачивая содержание всей команды постоянно.

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

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

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

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

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

Таблица 2. Факторы, которых обычно нет в коммерческом предложении

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

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

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

Таблица 3. Какая модель подходит под какой профиль проекта

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

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

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

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

Таблица 4. Показатели, по которым сравнивают модели поддержки

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

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

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

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