Техническая поддержка сайта: как учитывать часы, задачи и оплату

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

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

Откуда берётся дебиторка на технической поддержке

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

Обычно проблема складывается из нескольких причин:

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

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

Сначала выберите модель оплаты

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

Пакет часов

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

В KorDevTeam минимальный пакет технической поддержки — 20 часов в месяц по ставке 1 900 ₽ за час, то есть от 38 000 ₽ в месяц. Это не «плата за присутствие». Все работы связываются с задачами, а клиент видит движение и расход времени на публичной доске.

До старта необходимо определить:

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

Почасовая оплата без пакета

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

Фиксированная абонентская плата

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

Отдельный проект с фиксированной стоимостью

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

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

Что считать рабочим временем

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

Состав оплачиваемого времени нужно описать заранее. Обычно в него могут входить:

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

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

Одна задача — одна история решений и часов

У каждой работы должна быть карточка в единой системе. Чат можно использовать для быстрой связи, но итоговые вводные и решения нужно переносить в задачу. Иначе через месяц невозможно доказать, что именно согласовали.

Минимальная карточка задачи содержит:

1. Проблему или ожидаемый результат. Не «поправить сайт», а «восстановить передачу заявки из формы в CRM».
2. Контекст. Где проявляется проблема, кого затрагивает, насколько она срочная.
3. Критерии приёмки. Как клиент и команда поймут, что работа завершена.
4. Предварительную оценку или лимит. Например, до четырёх часов на диагностику и исправление.
5. Согласование. Кто подтвердил работу и допустимый объём.
6. Фактические записи времени. Дата, специалист, длительность и выполненное действие.
7. Результат. Ссылка, скриншот, commit, журнал проверки или короткое описание изменения.
8. Решение клиента. Принято, нужны уточнения, обнаружен баг или задача отменена.

Запись «разработка — 5 часов» ничего не объясняет. Лучше написать: «воспроизвели потерю заявки, нашли ошибку в обработчике, исправили повторную отправку, проверили три сценария и выпуск на рабочем сайте — 5 часов». Такой комментарий связывает время с ценностью и проверяемым результатом.

Как устроена публичная Kanban-доска KorDevTeam

Мы не прячем поддержку в переписке с менеджером. У каждого клиента есть публичная Kanban-доска, на которой видны задачи, статусы, вопросы, история движения и выполненная работа.

Базовый поток выглядит так:

1. Новая задача. Клиент или команда фиксирует запрос и исходные данные.
2. Нужно уточнение. Не хватает доступа, примера ошибки, бизнес-правила или решения клиента.
3. К согласованию. Добавлены оценка, приоритет и предлагаемый результат.
4. В работе. Назначен исполнитель, работа началась.
5. Проверка. Результат готов и ожидает проверки команды или клиента.
6. Готово. Критерии приёмки выполнены, итог зафиксирован.

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

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

Ежедневный статус и отчёт по понедельникам

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

В нашей работе действует два ритма.

Ежедневное обновление активных задач

По каждой активной задаче мы фиксируем:

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

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

Отчёт и план по понедельникам

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

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

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

Оценка — это диапазон и точка следующего решения

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

Рабочая формулировка выглядит так:

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

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

Для каждой задачи полезно определить порог, после которого работа останавливается. Например: без дополнительного согласования нельзя превысить оценку более чем на один час или на 20%. Конкретное правило зависит от договора и характера поддержки, но оно должно быть одинаково понятно обеим сторонам.

Что делать, если возникает перерасход

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

1. что уже проверено и сколько времени потрачено;
2. почему оценка изменилась;
3. что осталось сделать;
4. сколько времени потребуется дальше;
5. какие есть альтернативы;
6. что произойдёт, если остановиться сейчас.

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

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

Как связать отчёт, документы и оплату

Отчёт отвечает на вопрос «что сделано», а финансовые документы — «на каком основании и когда оплачивается период». Если эти процессы не синхронизированы, подробный тайм-трекинг сам по себе не защищает от дебиторки.

До начала поддержки зафиксируйте в договоре и рабочем регламенте:

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

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

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

Не смешивайте спорную и подтверждённую сумму

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

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

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

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

Минимальный реестр дебиторской задолженности

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

Для каждого расчётного периода достаточно фиксировать:

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

Полезно разделять задолженность по возрасту: срок ещё не наступил, просрочка до 7 дней, 8–30 дней и более 30 дней. Границы можно настроить под собственный платёжный цикл. Задача такого отчёта — не нарисовать красивую диаграмму, а не потерять следующий шаг.

Правило приостановки работ

Если работа продолжается при растущей задолженности, проблема становится дороже каждую неделю. Поэтому заранее нужен порядок приостановки:

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

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

MCP-доступ: быстрый ответ без отдельного отчёта менеджера

У клиента KorDevTeam есть не только веб-доска, но и MCP-доступ к её публичной части. Доску можно подключить к совместимому AI-инструменту, например ChatGPT, и задавать вопросы обычным языком:

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

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

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

Пример: срочно перестали приходить заявки

Представим, что клиент пишет: «Форма работает, но заявки нет в CRM».

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

Управляемый сценарий:

1. Создаём карточку с примером заявки, временем отправки и ожидаемым результатом.
2. Помечаем задачу как критичную, потому что бизнес теряет обращения.
3. Согласуем до двух часов на диагностику.
4. Проверяем форму, очередь отправки и API CRM.
5. В ежедневном статусе фиксируем: проблема в истёкшем токене, на диагностику ушло 1,5 часа.
6. Предлагаем ещё до двух часов на обновление авторизации, повторную отправку зависших заявок и проверку мониторинга.
7. После согласования выполняем работу и прикладываем результаты тестовых заявок.
8. Клиент проверяет получение обращения, задача переходит в «Готово».
9. Часы автоматически попадают в недельный отчёт и остаток пакета.

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

Чек-лист закрытия месяца

Перед формированием итоговых документов проверьте:

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

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

Когда почасовая модель не подходит

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

Вместо пакета часов лучше выбрать другой формат, если:

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

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

Как запустить прозрачную поддержку за одну неделю

Не нужно сначала внедрять сложную систему. Начните с минимального контура:

1. Соберите все активные запросы в одну доску.
2. Назначьте человека, который со стороны клиента определяет приоритет.
3. Опишите статусы и правило перехода между ними.
4. Зафиксируйте, что входит в оплачиваемое время.
5. Для каждой новой задачи добавляйте результат, критерии приёмки и лимит.
6. Установите порог согласования перерасхода.
7. Обновляйте активные карточки ежедневно.
8. По понедельникам сверяйте выполненное, часы, остаток и следующий план.
9. Свяжите отчёт с календарём документов и оплаты.
10. Через месяц разберите причины отклонений и упростите регламент.

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

Главное

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

В KorDevTeam этот процесс построен вокруг публичной доски, ежедневных статусов, отчёта и плана по понедельникам и MCP-доступа для быстрых вопросов через ChatGPT. Минимальный формат — 20 часов в месяц по ставке 1 900 ₽ за час. Подробнее о составе работ и подходе — на странице технической поддержки и развития сайтов и веб-сервисов.

---

Источник первоначального материала: Telegram-канал Геннадия Короткова

Теги: Техническая поддержка, Поддержка сайта, Учет времени, Kanban, Дебиторская задолженность, Управление проектами Дата публикации: 31 августа 2026