Что должно быть в сопроводительном письме IT-специалиста техподдержки?

Где это письмо читают, а где — нет

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

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

На крупном service desk — корпоративной первой линии, аутсорсинговом колл-центре, в NHS trust или местных органах власти, обрабатывающих сотни заявок в день — заявки обычно сначала проходят через рекрутера или систему отслеживания кандидатов. Эта система и люди, сортирующие заявки, фильтруют по резюме: названия инструментов, годы опыта, сертификаты. Вложение с сопроводительным письмом часто не открывают на этом этапе, а некоторые настройки ATS вообще его не обрабатывают. Если вы откликаетесь на такую вакансию, считайте, что резюме выполняет фильтрацию, а письмо, если его прочитают, появляется позже.

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

Две вещи, на которые оно должно ответить

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

Можете ли вы говорить с нетехническим человеком, не снисходя и не теряя его в жаргоне. Это суть работы, больше, чем устранение неполадок. Пункт в резюме «решал 40+ заявок ежедневно» не говорит им ничего о том, как вы вели звонок. Один короткий пример говорит: пользователь не мог распечатать, уже был расстроен, и что вы сказали, чтобы пройти от «оно сломано» до диагностики, не заставив его почувствовать себя глупо. Это стоит больше, чем любое прилагательное.

Совпадает ли ваш технический охват с тем, что у них развернуто. Не «сильные навыки устранения неполадок» — какая среда, какие инструменты. Первая линия или вторая. Только удаленно или на месте с аппаратной составляющей. Только Windows или вместе с macOS. Если в объявлении названы ServiceNow, Freshservice, Zendesk или Jira Service Management, скажите, какую вы использовали и как, потому что эти инструменты достаточно различаются в том, как они формируют очереди и эскалируют работу, что одно только «опыт работы с системой заявок» не говорит менеджеру по найму ничего.

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

Называть стек, а не просто заявлять о компетентности

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

«У меня отличные навыки устранения неполадок и сильная ориентация на клиента».

против

«Я работал с заявками первой линии в ServiceNow с четырехчасовым SLA для инцидентов P2, обрабатывал блокировки учетных записей AD и сброс паролей, создавал образы и развертывал ноутбуки через Intune для инфраструктуры на 300 пользователей».

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

Если у вас есть CompTIA A+ или Network+, Microsoft MD-100/MD-101 или сертификат ITIL Foundation, и в объявлении упоминается процесс ITIL, управление изменениями или формальная структура SLA, назовите их по имени. Если в объявлении не упоминается ITIL, не начинайте с этого — это сигнализирует, что вы подгоняете письмо под шаблон, а не читаете их объявление.

Где письмо имеет малый вес — и где принимается реальное решение

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

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

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

Что в него включить, в каком порядке

Ограничьтесь тремя короткими абзацами, максимум полстраницы.

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

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

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

Чего не стоит делать

Не пересказывайте резюме хронологически — у читателя есть резюме. Не начинайте с «Я трудолюбивый командный игрок с отличными коммуникативными навыками»; каждое слово этого предложения — утверждение, которое остальная часть письма должна доказывать конкретикой, а не заявлять заранее. Не объясняйте, что такое ITIL или Active Directory — читатель уже знает, и объяснение читается как наполнитель. И не извиняйтесь за пробелы в вашем стеке; если объявление требует поддержки macOS, а вы работали только с Windows, скажите, с чем вы работали, и позвольте остальной части письма нести аргумент, вместо того чтобы привлекать внимание к пробелу в первой строке.

Что делать дальше

Разберите объявление, прежде чем что-то писать: перечислите каждый названный инструмент, ОС, систему заявок и сертификат, которые в нем упоминаются. Сопоставьте каждый с тем, что вы реально использовали, и напишите технический абзац из этого списка, а не по памяти о том, что вы обычно говорите. Затем напишите один пример сложного звонка или заявки, в двух-трех предложениях, не больше. Отправляйте его как PDF, если отправляете напрямую по электронной почте, так как обычный текст, вставленный в тело письма, теряет форматирование и иногда помечается спам-фильтрами как необычный. jobmarket.pro читает объявление на предмет конкретных инструментов, систем и среды, которые оно называет, и составляет письмо из вашего существующего профиля, не выдумывая инструменты или сертификаты, которыми вы фактически не обладаете.