Проект сдали. Что входит в поддержку
Как договориться об исправлениях, помощи и новых задачах после сдачи проекта. Пять типичных обращений, сроки ответа и решения, состав поддержки и пример итогового сообщения.
«Проект приняли. Если что-то понадобится, напишем».
В этот момент полезно договориться, что произойдёт после такого сообщения. Кто его увидит? Когда ответит? Как поймёт, что случилось? И когда предупредит, что понадобится дополнительная работа?
Под словом «поддержка» могут скрываться очень разные ожидания. Один человек имеет в виду исправление ошибок. Другой — помощь сотрудникам. Третий рассчитывает, что система будет меняться вслед за бизнесом. Пока обращений нет, эта разница незаметна.
Мой подход — описать поддержку через конкретные ситуации и действия. Тогда клиент понимает, на какую помощь рассчитывать, а исполнитель может организовать её без обещания бесконечной доступности.
Сначала определяю, что именно мы поддерживаем
В статье о сдаче результата я разбирал, как зафиксировать готовую версию, проверки и передачу материалов. Для поддержки это отправная точка.
Я предлагаю перечислить, что входит в работающий контур: сайт, конкретная интеграция, отчёт, сценарий автоматизации или AI-помощник. Рядом — какие задачи он выполняет, где находится инструкция и кто со стороны клиента принимает решения.
Возьмём условный пример. Настроена передача заявок с сайта в CRM: система сохраняет источник обращения, создаёт карточку и назначает ответственного по согласованным правилам. Клиент проверил этот сценарий и начал им пользоваться.
У такого решения есть понятная исходная версия. Можно воспроизвести контрольную заявку, проверить поля и посмотреть, кому она назначилась. Если позже появляется вопрос, у нас уже есть с чем сравнивать поведение.
Отдельно фиксирую зависимости: кто управляет CRM, оплачивает внешние сервисы, выдаёт доступы и сообщает об изменениях формы. Если у интеграции перестал работать доступ, нужен человек, который может его восстановить. Одной переписки с разработчиком для этого может быть недостаточно.
Разбираю обращение до оценки работ
Сообщение «заявки не приходят» описывает последствие. Причину ещё предстоит установить: ошибка в нашем сценарии, изменившееся поле формы, недоступная CRM или обращение, которое вообще не было отправлено.
Поэтому сначала мне нужен короткий разбор. Что ожидали увидеть, что произошло, когда это началось и какой пример можно проверить? Если информация ещё не собрана, я помогаю сформулировать обращение.
В условной системе с заявками разговор может выглядеть так:
| Обращение | Что проверяю | Как определяю дальнейшую работу |
|---|---|---|
| Заявка теряется в согласованном сценарии | Повторяется ли ошибка на контрольном примере и где прерывается передача | Фиксируем дефект и порядок исправления |
| Новый сотрудник не знает, где искать заявки | Достаточны ли доступы и понятна ли инструкция | Помощь в использовании или отдельное обучение |
| После изменения формы перестало приходить поле | Что изменилось и учитывает ли это текущая интеграция | Восстановление совместимости в согласованном объёме либо оценка изменения |
| Нужна передача заявок ещё в одну систему | Какого результата ждут и какие данные понадобятся | Новая задача с оценкой и подтверждением |
| Внешняя CRM недоступна | Масштаб сбоя, состояние заявок и доступный ручной порядок | Восстановительные действия и связь с ответственным за сервис |
Такая классификация помогает выбрать действие. Она сама по себе не определяет, кто и сколько платит. Ошибка может обнаружиться после приёмки; дата обнаружения ещё не делает исправление новой функцией. А работа после изменения внешнего сервиса может уже входить в согласованное сопровождение.
В описании управления обращениями Atlassian тоже различаются запросы пользователей и незапланированные нарушения работы сервиса. Мне здесь полезна сама идея: сначала понять характер обращения, затем выбирать порядок работы.
Если система мешает ежедневной работе, отдельно обсуждаю временный выход. Например, как безопасно сохранить входящие обращения до восстановления передачи. После этого можно спокойно уточнять причину и постоянное решение.
Договариваюсь о первом ответе и следующем сообщении
Фраза «быстро реагируем» оставляет слишком много вопросов. Получение сообщения, начало диагностики, временное восстановление и окончательное исправление — разные события.
Я предлагаю заранее определить:
- куда отправлять обращения, чтобы они попадали в общую очередь;
- в какие дни, часы и по какому часовому поясу действует поддержка;
- когда клиент получит первый содержательный ответ;
- как сообщать о ситуации, которая остановила рабочий процесс;
- когда будет следующее обновление, если вопрос ещё не решён.
Содержательный первый ответ для меня означает: обращение принято, влияние на работу понятно, назначен ответственный и обозначен следующий шаг. Автоматическое «мы получили ваше сообщение» полезно как уведомление, но клиенту ещё нужен план действий.
Приоритет я предлагаю определять по последствиям. Потеря входящих заявок и неудобное название поля требуют разной срочности. При этом отсутствие запасного способа работы может сделать локальную проблему особенно важной для конкретной команды.
В документации Atlassian по SLA время ответа и время решения учитываются отдельно; также задаются рабочий календарь и условия отсчёта. SLA здесь — согласованные условия обслуживания. Конкретные сроки я обсуждаю под задачи проекта и доступность людей.
Если для продолжения нужен доступ или ответ клиента, это отражается в статусе обращения. Вместе со статусом остаются причина ожидания, ответственный за следующий шаг и момент следующей связи. Клиенту должно быть понятно, что именно сейчас мешает продвинуться.
Отделяю исправление, помощь и развитие
Для разговора о составе поддержки мне удобно выделять три направления.
Исправление — вернуть согласованное поведение. В нашем примере заявка должна создавать карточку с источником и ответственным. Если сценарий не выполняется, нужно найти причину и проверить восстановление на конкретном случае.
Помощь в использовании — дать человеку возможность выполнить свою задачу в готовой системе. Объяснить действие, найти нужную настройку, уточнить инструкцию. Обучение всей новой команды может потребовать отдельного времени, даже если вопросы касаются знакомой функции.
Развитие — согласовать новое поведение. Добавить канал заявок, изменить правила распределения, подключить другую систему. Оценивать такой запрос стоит по содержанию, зависимостям и проверкам. Слово «маленькая» в сообщении не показывает объём работы.
На практике одно обращение может включать несколько направлений. Сначала мы восстанавливаем передачу заявок, потом обновляем инструкцию, а предложение подключить ещё один канал выносим в отдельную задачу.
Это продолжение подхода из статьи о дополнительных задачах: новое пожелание полезно сделать видимым, описать результат и согласовать его влияние на работу.
Есть и регулярное обслуживание: проверка интеграций, обновления, контроль ошибок. Его состав нужно перечислить отдельно. Если договорились только отвечать на сообщения, постоянное наблюдение за системой из этого автоматически не следует.
Для AI-помощника я также уточняю, кто обновляет материалы, кто проверяет ответы после изменений и кто может остановить неверно работающий сценарий. Подробнее про источники — в статье об актуальности базы знаний. Сам факт запуска помощника не задаёт порядок дальнейшего обслуживания.
Фиксирую объём, оплату и границы ответственности
После примеров можно обсуждать формат поддержки. Я предлагаю описывать его обычным языком, чтобы по документу можно было принять решение в реальной ситуации.
Что входит. Конкретные системы, виды обращений и регулярные действия. Если в сопровождение включены небольшие изменения, для них нужен понятный предел и правило оценки.
Как учитывается работа. Фиксированный состав услуг, согласованный объём времени или оценка отдельных обращений. Клиенту заранее понятно, как увидеть расход и что произойдёт при приближении к пределу.
Когда требуется дополнительное решение. Если работа выходит за договорённый объём, я сначала описываю её, стоимость и влияние на сроки. Начало платного расширения требует подтверждения уполномоченного человека. Для срочного восстановления можно заранее согласовать отдельные полномочия и предел действий.
Что зависит от клиента и внешних сервисов. Оплата подписок, доступы, достоверность данных, изменения со стороны других подрядчиков. При внешнем сбое стоит определить, кто ведёт переписку с поставщиком и кто сообщает команде рабочий порядок на время остановки.
Как заканчивается сопровождение. Дата или условие окончания, порядок продления и передача открытых вопросов. Если меняется исполнитель, ему понадобятся актуальные инструкции, история существенных изменений и согласованные доступы.
Мне важно, чтобы границы поддержки помогали организовать работу. Неясные места лучше разобрать на нескольких примерах до первого срочного обращения.
Закрываю обращение с понятным итогом
«Исправлено» — слишком короткий отчёт, если по нему нельзя понять, что проверили и можно ли возвращаться к обычной работе.
Для условной интеграции итоговое сообщение после проверки могло бы выглядеть так:
Передача заявок восстановлена. Причина — ошибка обработки согласованного поля источника; исправление выполнено в рамках поддержки. Проверили создание карточки, сохранение источника и назначение ответственного на контрольном примере. Пропущенные обращения сверены; повторная передача не создала дубликатов. Пожалуйста, проверьте карточку со своей ролью доступа. Предложение добавить ещё один канал записали отдельно — пришлю оценку до начала работ.
Такое сообщение можно отправлять только после перечисленных проверок. Если часть заявок ещё сверяют, это остаётся открытым пунктом с ответственным и следующим сроком связи.
В журнале обращения я сохраняю причину, выполненное действие, способ проверки и оставшиеся вопросы. Если ситуация повторяется, эта история помогает увидеть, что нужно изменить в самой системе или инструкции.
AI можно использовать для предварительной сортировки обращений, поиска похожих случаев и подготовки ответа. При этом обещание срока, решение о дополнительной оплате и разрешение на изменение работающей системы должны оставаться в пределах заранее согласованных полномочий.
Хорошо организованная поддержка даёт клиенту ясность: куда обратиться, какой помощи ждать и как узнать результат. Для меня именно с этих договорённостей начинается жизнь проекта после сдачи.