SLA-договор на сопровождение: как мы его написали

Несколько месяцев назад мы разбирали арифметику аутсорса против штатного администратора. Там был один момент, который мы отметили мимоходом: без внятного SLA аутсорс - это просто «звоните, приедем». Сейчас хотим рассказать подробнее, как выглядит этот самый внятный договор на сопровождение и что нам потребовалось, чтобы его написать.

Работа с клиентами без формального соглашения о качестве была нормой - не только у нас, у всех. Договор был: «оказание услуг по техническому обслуживанию, ежемесячный платёж такой-то». Дальше - устные договорённости, которые каждая сторона понимала по-своему. Клиент считал, что мы обязаны приехать через час в любое время суток. Мы считали, что приехать «в разумные сроки» - это наш рабочий день. Когда всё шло хорошо, разночтений не было. Когда что-то ломалось по-настоящему - вылезали.

Мы сели и написали договор. Не с первого раза, версий было несколько, кое-что переписали уже после первых подписантов. Вот что в итоге оказалось существенным.

Приоритеты инцидентов

Без этого раздела весь остальной текст теряет смысл. Мы выделили три уровня.

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

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

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

Эти три категории закрывают почти все ситуации. Сразу стало понятно, о чём мы вообще разговариваем, когда клиент звонит.

Что входит в абонентку

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

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

Что не входит - и это важнее. Закупка оборудования и расходников, работы вне рабочего времени (если не оговорено отдельно), разработка или существенная переработка инфраструктуры, работы по инцидентам выше порогового количества в месяц.

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

Сверхнормативные работы

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

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

Как фиксируется инцидент

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

Это решает ещё одну проблему: когда клиент говорит «вы плохо работаете», у нас есть что показать. А когда мы видим, что одна заявка каждый месяц повторяется - значит, мы не решаем проблему, а затыкаем дыру.

Как это прошло с клиентами

Несколько клиентов подписали договор в таком виде без вопросов - те, с кем мы давно работаем и у кого уже было понимание, что́ мы делаем. С новыми сложнее: часть переспрашивала про «критический инцидент ночью» - мы добавили отдельный пункт про дежурство с повышенным тарифом, и вопрос снялся.

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

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