План технической поддержки: образец

Кратко

План технической поддержки — документ, который отвечает не «как мы работаем» (это регламент) и не «что было в прошлом месяце» (это отчёт), а «что мы построим и к какому сроку»: цели, охват, штат, показатели, этапы и деньги на период вперёд. Его утверждают перед запуском службы, перед годовым бюджетом или перед пересборкой существующей поддержки. Ниже — готовый текст на одну-две страницы: подставьте свои значения в угловых скобках и согласуйте с руководителем, которому нужен бюджет и срок, а не описание процесса.

Актуально на 23 сентября 2026 года.

Чем план отличается от соседних документов

Три документа этого же семейства путают чаще всего, а решают они разные вопросы:

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

Готовый образец

ПЛАН РАЗВИТИЯ СЛУЖБЫ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ НА <ПЕРИОД>

Утверждён: <должность, ФИО>

Дата составления: <ДД.ММ.ГГГГ>

Период действия: <с ДД.ММ.ГГГГ по ДД.ММ.ГГГГ>

1. Цель и область действия

1.1. Цель: <например, снизить долю просроченных обращений с текущих N % до 5 % и перейти на круглосуточный приём критических обращений>.

1.2. Область действия: <какие продукты, подразделения или категории пользователей обслуживает поддержка>.

1.3. Вне области: <что поддержка намеренно не берёт на себя — доработки, обучение, закупки>.

2. Каналы и охват

3. Организация и штат

3.1. Текущий штат: <N> человек. Целевой штат к концу периода: <N> человек.

3.2. Расчёт основан на нагрузке пикового часа и доле полезного времени — методика и пример счёта в статье Сколько операторов нужно поддержке: как посчитать нагрузку.

3.3. Роли и уровни: <первая линия, вторая линия, руководитель> — распределение обязанностей фиксируется отдельно в Положении о службе технической поддержки.

4. Целевые показатели

4.1. Значения «на начало периода» берутся из журнала обращений за последние 30 дней, а не оцениваются на глаз — как их посчитать, разобрано в статье Как проверить, что техподдержка работает: семь замеров.

5. Этапы внедрения

6. Бюджет

7. Риски

8. Точки контроля

8.1. Прогресс по этапам сверяется <еженедельно / ежемесячно> на встрече <кто>.

8.2. Показатели раздела 4 считаются по данным системы, а не по отчётам исполнителей — метод в статье, указанной в п. 4.1.

8.3. По итогам каждого этапа — короткая запись: выполнено / не выполнено / перенесено, с причиной.

Как проверить, что план не остался на бумаге

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

Второй признак — раздел 4 на контрольной точке. Если текущие значения показателей не обновлялись с даты составления плана, контроль существует только в разделе 8, а не на практике.

Частые ошибки

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

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

Штат, взятый круглым числом. «Возьмём ещё двоих» вместо расчёта по нагрузке пикового часа — часто либо избыточно, либо не покрывает пик; методика расчёта — по ссылке в разделе 3.

Этапы без результата, только с датой. «Неделя 3 — настройка» не проверяется. У каждого этапа должен быть результат, который можно увидеть: очередь одна, регламент подписан, SLA не нарушается.

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

Частые вопросы

Чем план технической поддержки отличается от регламента?

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

На какой срок составлять план технической поддержки?

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

Нужен ли план, если поддержка уже работает и регламент есть?

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

С чего начать план технической поддержки с нуля?

С раздела 4: зафиксировать текущие значения показателей (или их отсутствие) и назвать целевые. Пошаговый порядок первых недель для полностью новой поддержки — в отдельной статье о запуске с нуля, ссылка в разделе «Чем план отличается».

Кто утверждает план технической поддержки?

Руководитель, которому подчиняется служба поддержки, и тот, кто распоряжается бюджетом раздела 6, если это разные люди. Без подписи бюджетодержателя раздел 6 остаётся пожеланием, а не планом.