Рекомендации от экспертов. Блог Okdesk

Все о сервисном обслуживании. Help Desk (Service Desk). Отзывы, исследования, экспертные мнения, ответы на самые важные вопросы
Лучшее13 июля 2021

Договор SLA или Service Level Agreement – что это такое?

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

Договор SLA. Как составлять и зачем нужен Service Level Agreement?

SLA — что это такое?

SLA (Service Level Agreement — соглашение об уровне обслуживания) — внешний документ (существующий между заказчиком и исполнителем), описывающий параметры предоставляемой услуги. «Соответствие SLA» эквивалентно тому, что сервис работает так, что реальные параметры не выходят за пределы заявленных в соглашении диапазонов метрик.

Хотя сам термин SLA появился в ИТ, сегодня такие документы используются для описания самых разных услуг, как в ИТ, так и в других сегментах B2B, например в обслуживании коммерческой недвижимости, при ремонте специализированного оборудования и т.п. В SLA определяются сроки устранения определенных неисправностей, скорость реакции на обращения, доступность службы поддержки и другие параметры.

Соглашения SLA активно применяются там, где исполнитель и заказчик услуг автономны по отношению друг к другу. И хотя соглашения внутри компании, которые заключаются для обеспечения SLA, зачастую его напоминают, для них применяется другой термин — OLA.

Что такое OLA

Что должно быть в OLA?

Для исполнения SLA с внешним клиентом сервисной компании необходимо следить за процессом оказания услуги внутри — устанавливать сроки ответа на обращения и т.п. Для этого формируется OLA — Operational Level Agreement — аналогичный SLA внутренний документ компании, определяющий зоны ответственности подразделений.

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

Условия OLA должны соответствовать SLA или быть более жесткими, чтобы выступать гарантией соблюдения последнего, поэтому для формирования SLA сначала лучше продумать OLA, согласовав его с исполнителями. Если инженер физически не сможет добраться на объект быстрее, чем за 2 часа, вы не должны обещать клиенту, что решите его проблему за час.

Разница между SLA и OLA

Основное различие SLA и OLA в том, что первый документ описывает взаимодействие с внешним клиентом, а второй — работу подразделений внутри компании. И если SLA говорит на языке клиента и важных для него параметров сервиса («мы обеспечиваем доступность сервиса 99,8% времени»), то OLA погружается в технические детали и подробности взаимодействия отдельных подразделений и специалистов («диспетчер регистрирует заявку в течение 10 минут, инженер реагирует на нее в течение 2 часов, механик выезжает в течение 5 часов»).

Subscription small
15 000+ подписчиков. Присоединиться к рассылке

Что должно быть в договоре SLA

Аналитическая панель отчетов в Okdesk.

SLA должен содержать описание предлагаемой услуги и определять границы ответственности.

Всем приходится сталкиваться с не типовыми заявками. К примеру, вы договаривались на обслуживание типовой ИТ-инфраструктуры, но уже после заключения договора в ней появляется специфическое оборудование, а вместе с ним — и заявки по его настройке. Кто должен этим заниматься? Соответствующий специалист стоит дорого, а его зарплату вы не закладывали при расчете стоимости услуги. С другой стороны, клиент считает, что это часть инфраструктуры, а значит ваша ответственность. Или вы обслуживаете он-лайн кассу, а у клиента проблемы с 1С, которые он пытается повесить на вас.

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

Также в SLA должно быть прописано, при каких условиях услуга считается оказанной (когда ответственность исполнителя прекращается).

Параметры, от которых зависит SLA

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

К примеру, в соглашении можно прописать, что специалист поддержки имеет право отвечать не мгновенно, а в течение 4-х часов после регистрации заявки. Он имеет право не отвечать в выходные и праздничные дни.

Чтобы SLA не превратилось в головную боль для всех заинтересованных сторон, важно указывать там реально достижимые параметры услуг, которые обе стороны трактуют одинаково.

В сервисном бизнесе самый распространенный параметр — время. Это может быть:

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

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

Мы не рекомендуем указывать в SLA слишком много параметров или использовать какие-то косвенные показатели, слабо коррелирующие с действиями исполнителя. Они только усложняют работу.

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

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

Договор SLA

Раз уж SLA определяет взаимодействие двух сторон — клиента и исполнителя — разберем, как соглашение работает для каждой из них.

Глазами клиента

SLA соглашение. Уровень SLA.

В рамках SLA заказчик получает метрики предоставления услуги — четкое описание того, за что именно он платит.

Клиенту полезно, что в SLA прописываются сроки исполнения заявок (инцидентных или на обслуживание). Конечно, любой заказчик хочет, чтобы его вопрос решался мгновенно, но соглашение (особенно с несколькими уровнями сервиса) отлично демонстрирует, что «мгновенность» стоит денег, и иногда можно подождать несколько часов, чтобы сделать решение дешевле. Он получает достойный ответ на вопрос: «Почему моя проблема не решена вчера?».

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

Глазами сервисной компании

С точки зрения сервисного отдела или компании SLA — это набор целевых метрик, к которым стремятся исполнители. SLA на самом деле очень полезно, т.к. наводит порядок не только во взаимоотношениях с клиентом, но и (по цепочке) в бизнес-процессах самой сервисной компании.

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

Во взаимодействии с клиентом SLA помогает ограничить зону ответственности.

Хотите попробовать Okdesk бесплатно?
Даём бесплатный доступ на 14 дней с полным функционалом!
Возможности Okdesk:
  • Контроль соблюдения SLA
  • Интеграции с e-mail, Telegram, 30+ АТС и другими сервисами
  • Учёт затрат, оборудования и объектов обслуживания
  • Автоматическое распределение заявок
  • Десятки готовых экспертных отчётов
  • Мобильное приложение

Как написать хороший SLA

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

Пройдемся по основным положениям, которые стоит добавить в SLA.

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

  • Какую услугу предоставляет исполнитель — что, когда и где делает? К примеру, мы говорим об обслуживании сантехники в коммерческой недвижимости. Описываем, что услуга подразумевает ремонт и обслуживание сетей водопровода и водоотведения от вентиля жилищно-коммунальной службы на входе в здание. И указываем, что обслуживание осуществляется на территории заказчика в будние дни с 9 до 18 по Московскому времени.
  • Какие предусмотрены ограничения услуги — географические, временные? Предположим, обслуживание и ремонт не производится в праздники и с 20:00 до 7:00 по Московскому времени.
  • Есть ли какие-то приоритеты? К примеру, если речь про сантехнику и слегка подтекает кран, то это обращение обычного приоритета. А если прорвало стояк и заливает уже 3 этажа здания, то это явно аварийная ситуация. Если в рамках услуги такие ситуации должны обрабатываться по-разному, надо прописать, что такое обычное обращение, а какая ситуация будет рассматриваться, как аварийная.
  • Какое подразделение (или несколько подразделений) исполнителя участвует, в чем его (их) роль?
  • Каковы функции сотрудников подразделения? Если упоминаем диспетчеров, объясняем, что их функции — ответ на звонки, регистрация обращения и передача его профильному специалисту.

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

Важно, чтобы исполнитель полностью определял соответствие услуги этим метрикам (имел на них влияние). Если вы обслуживаете только кассы, нельзя привязываться в SLA простой всей ИТ-инфраструктуры магазина, потому что в нее входят компоненты вне вашей зоны ответственности. Кассу-то, может, вы и запустили, но если при этом в помещении отключено электричество, сделать ничего нельзя. Поэтому лучше сосредоточиться на конкретных метриках, определяющих именно вашу услугу — скорость восстановления работы кассы после остановки.

Метрики должны быть реалистичными. Если в примере с кассой установить в SLA скорость ремонта в 10 минут, скорее всего соглашение просто не будет работать. Более реалистичное, но короткое время, заставит привлекать опытных специалистов, которые в среднем работают с задачами быстрее. А это стоит денег. В этом смысле SLA — это поиск баланса между интересами клиента, который хочет «вчера», и исполнителя, который не может быстрее (или может, но в ущерб другим клиентам).

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

Если в оказании услуги участвует несколько отделов и хочется прописать метрики для каждого, это можно сделать в OLA, задав в SLA только один общий параметр, в который уложится вся последовательность действий. Или задать несколько версий этой метрики в SLA, в зависимости от подключения к решению проблемы новых участников (условно говоря, если проблема уходит на третий уровень поддержки, то допустимое время реакции увеличивается на сутки).

Пример договора SLA

Ниже представлен пример договора SLA реальной IT-компании.

I. Предоставляемые услуги

В этом разделе мы описываем все работы, которые «IT-консалт» выполняет для Заказчика, и системы, которые находятся у нас на поддержке. По каждому виду работ определяется график и ограничения объема услуг, если они есть. Отдельно оговариваются те работы, которые не входят в нашу зону ответственности.

Исполнитель обязуется оказывать Заказчику услуги по сопровождению программного обеспечения 1С 8 ERP, установленного у Заказчика, на следующих инсталляциях:

  • <Инсталляция 1>
  • <Инсталляция 2>

Период оказания услуг — с «___» _______ ____ г. — «___» _______ ____ г.

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

Услуга Время предоставления* Объем услуг
Консультации пользователей по работе с ПО, помощь в решении проблем в части бизнес-процессов:
— Приемка на склад — Отгрузка готовой продукции
24/7 Не ограничен
Консультации пользователей по работе с ПО, помощь в решении проблем в части прочих бизнес-процессов С 9:00 по 18:00 в рабочие дни Не ограничен
Контроль выполнения регулярных процедур по согласованным регламентам 24/7 Не ограничен
Мониторинг интеграций с системами Меркурий, EDI, восстановление работоспособности интеграций 24/7 Не ограничен
Мониторинг и поддержание работоспособности сервера приложений 24/7 Не ограничен
Ведение пользовательской документации (обновление документации при изменениях в ПО, ведение раздела «FAQ») Ежемесячно Не ограничен
Выдача и изменение пользовательских прав, ролей (по заявкам ключевых пользователей или службы безопасности) С 9:00 по 18:00 в рабочие дни Не ограничен
Эскалация вопросов, не относящихся к области компетенции Исполнителя (администрирование инфраструктуры, администрирование БД) С 9:00 по 18:00 в рабочие дни Не ограничен
Исправление ошибок в программном коде ПО С 9:00 по 18:00 в рабочие дни Не ограничен
Доработка ПО в соответствии с бизнес-требованиями Заказчика С 9:00 по 18:00 в рабочие дни Не более 40 плановых часов в месяц **
Обновление систем на новые версии, поставляемые производителем ПО С 9:00 по 18:00 в рабочие дни Не более 2 раз в год

* Время часового пояса Москвы.

** Плановые часы — часы на выполнение модификации, включая постановку задачи, кодирование, тестирование и перенос модификации на рабочее приложение; плановые часы являются оценкой Исполнителя, в обязательном порядке согласуются с ответственным представителем ИТ-службы Заказчика. Риск превышения фактического времени над плановым находится на стороне Исполнителя. Время на модификации не переносится из периода в период.

В перечень услуг, оказываемых Исполнителем, не входят следующие задачи:

  • Поддержка оборудования и инфраструктуры системы (сервера, каналы связи, системное ПО, включая подсистему печати, сервер базы данных), лицензионные ключи на ПО
  • Администрирование базы данных, в т.ч. обеспечение сохранности данных (резервное копирование).

Способы взаимодействия пользователей Заказчика и Исполнителя:

  • E-mail
  • Телефон
  • Система Service Desk Исполнителя

Конкретные почтовые адреса, телефоны и учетные записи для Service Desk определяются в регламенте взаимодействия.

II. Ответственность Заказчика

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

Заказчик обязуется:

  • Предоставить Исполнителю удаленный доступ к инсталляциям ПО для решения заявок;
  • Предоставить Исполнителю копию рабочего ПО с тестовыми данными, для моделирования и решения проблем пользователей специалистами Исполнителя
  • Предоставить Исполнителю серверные ресурсы, необходимые для разворачивания окружения для выполнения доработок.
  • Обеспечить право Исполнителя на контроль кода рабочего приложения (отсутствие модификаций системы своими силами) с целью переноса ответственности за работоспособность системы на Исполнителя.
  • Назначить и письменно сообщить Исполнителю Координатора, ответственного за взаимодействие в рамках услуг, описанных в настоящем Предложении:
    • Управление соглашением об уровне сервиса (инициация, согласование изменений) и вспомогательных регламентов со стороны Заказчика
    • Представление интересов бизнес-пользователей в согласовании изменений к Соглашению об уровне сервиса, а также вспомогательных регламентов
    • Разрешение конфликта интересов, если запрос одного бизнес-пользователя Заказчика конфликтует с запросом другого: по очередности и/или функционалу
    • Определение необходимости реализации, по каждой задаче на доработку системы
    • Приоритизация задач на доработку

Заказчик имеет право:

  • Запрашивать у Исполнителя информация о статусе обработки заявок.
  • Письменно информировать Исполнителя о недостатках в работе или нарушениях и требовать их исправления.
  • Согласовывать с Исполнителем изменения в объемах выполняемых работ, заключать с Исполнителем Дополнительные соглашения об изменении объема услуг и работ для Заказчика, выполняемых Исполнителем.

III. Приоритеты и нормативное время решения заявок

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

Приоритет заявок определяется дежурным специалистом Исполнителя, исходя из бизнес-процесса, по которому поступила заявка от пользователя ПО, и характера заявки. Нормативное среднее время выполнения заявок и максимально допустимая доля заявок, время выполнения которых не уложилось в нормативное время, представлена в таблице:

Приоритет Среднее время решения заявки Доля просроч. заявок Виды заявок
1 Критический Не более 2 рабочих часов Не более 20% Нарушения в работе ПО, которые приводят к неработоспособности одной или нескольких инсталляций в целом.

Мониторинг и поддержание работоспособности сервера приложений

2 Высокий Не более 4 рабочих часов Не более 20% Консультации пользователей по работе с ПО, помощь в решении проблем в части бизнес-процессов высокого приоритета:

— Приемка на склад

— Отгрузка готовой продукции

— Казначейство

Эскалация вопросов, не относящихся к области компетенции Исполнителя (администрирование инфраструктуры, администрирование БД)

Контроль выполнения регулярных процедур по согласованным регламентам

Мониторинг интеграций с системами Меркурий, EDI, восстановление работоспособности интеграций

3 Средний Не более 16 рабочих часов Не более 20% Консультации пользователей по работе с ПО, помощь в решении проблем в части прочих бизнес-процессов

Выдача и изменение пользовательских прав, ролей

4 Низкий Не более 40 рабочих часов Не более 20% Исправление ошибок в программном коде ПО
5 Фоновый По согласованию Доработка ПО в соответствии с бизнес-требованиями Заказчика

Обновление систем на новые версии, поставляемые производителем ПО

Ведение пользовательской документации (обновление документации при изменениях в ПО, ведение раздела «FAQ»)

По взаимному соглашению сторон приоритет заявки может быть изменен как в большую, так и в меньшую стороны.

Время решения заявки рассчитывается как разница между датой/временем решения заявки и датой/временем регистрации заявки в ServiceDesk, за вычетом периодов нерабочего времени (в соответствии с графиком предоставления услуг в разделе I) и за вычетом времени нахождения заявки на стороне пользователя:

  • Уточнение у заказчика
  • Согласование заказчиком
  • Тестирование заказчиком
  • Передано сторонней службе

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

IV. Отчетность по услугам

Раздел определяет формат и частоту предоставления отчетов для Заказчика

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

Отчеты по количественным показателям (раздел III) содержат следующую информацию, в разбивке по приоритетам:

  • Общее количество принятых заявок
  • Среднее время выполнения заявок
  • Доля просроченных заявок
  • Полный перечень заявок, закрытых в течение периода
  • Полный перечень заявок, оставшихся нерешенными на конец периода

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

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

  • Удовлетворенность скоростью решения проблемы
  • Удовлетворенность вежливостью специалистов поддержки
  • Удовлетворенность фактом решения проблем

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

Отчеты по качественным показателям предоставляются Исполнителем дважды в год, до 20 июня и до 20 декабря.

Координатор самостоятельно проводит анализ полученной отчетности. В случае необходимости, Координатор может инициировать проведение совещания рабочей группы с представителями Исполнителя услуг по анализу отчетности.

V. Методика оценки качества сервиса

В этом разделе мы определяем то, как мы измеряем качество сервиса. Мы приводим перечень метрик качества, как количественных, так и качественных, и определяем вес (важность) каждой метрики, исходя из бизнеса клиента

Исполнитель обязуется ежемесячно рассчитывать итоговый показатель качества сервиса (QoS), на основании следующего расчета:

Метрика Вес метрики
Среднее время выполнения заявок 1 приоритета меньше нормативного 0,1
Доля просроченных заявок 1 приоритета меньше нормативной 0,1
Среднее время выполнения заявок 2 приоритета меньше нормативного 0,15
Доля просроченных заявок 2 приоритета меньше нормативной 0,15
Среднее время выполнения заявок 3 приоритета меньше нормативного 0,05
Доля просроченных заявок 3 приоритета меньше нормативной 0,05
Среднее время выполнения заявок 4 приоритета меньше нормативного 0,05
Доля просроченных заявок 4 приоритета меньше нормативной 0,05
Доля ответов «Быстрее, чем рассчитывал», «Как и рассчитывал» на вопрос анкеты «Насколько быстро, по Вашему мнению, решаются Ваши проблемы» больше 70% * 0,1
Доля ответов «Да», «Чаще да» на вопрос анкеты «Снимаются ли Ваши проблемы в работе с системой службой поддержки?» больше 80% * 0,1
Доля ответов «Да», «Чаще да» на вопрос анкеты «Было ли обращение сотрудников службы поддержки с Вами вежливым?» больше 90% * 0,1

* По данным последнего проведенного опроса пользователей

Итоговый показатель качества (QoS) рассчитывается как сумма весов по тем метрикам, которые были выполнены в периоде.

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

VI. Стоимость услуг, штрафные санкции и условия оплаты

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

Стоимость услуг Исполнителя составляет ________ (___________) рублей в месяц, без учета НДС.

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

QoS от QoS до Штрафные санкции, в % от стоимости услуг
0,8 1 0%
0,6 0,79 5%
0,4 0,59 10%
0 0,39 20%

Штрафные санкции могут быть начислены начиная с 3-го месяца оказания услуг. Первые два месяца являются ознакомительным периодом, в котором Исполнитель нарабатывает компетенцию в приложении Заказчика.

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

Стоимость дополнительного сервиса, оказываемого по требованию Заказчика:

  • При превышении указанного в разделе I объема заявок, стоимость каждой заявки сверх указанного объема, составит ______ (_______) руб, без учета НДС, за одну заявку.
  • При необходимости выполнения доработок сверх указанного в разделе I объема, стоимость одного человеко-часа будет составлять ______ (_______) руб, без учета НДС. Подписание Сторонами Акта приема-передачи услуг по результатам выполненных доработок осуществляется по факту завершения пользовательского тестирования.
  • Стоимость работы поддержки в выходные и праздничные дни — ______ (_______) руб./день, без учета НДС, вне зависимости от количества специалистов поддержки. Основанием для начисления стоимости является запрос на услуги поддержки в выходной день, направленный Исполнителю по электронной почте Координатором.

Стоимость дополнительного сервиса будет включаться в месячный акт отдельными строками.

Оплата услуг производится Заказчиком путем перечисления денежных средств на расчетный счет Исполнителя в течение 10 (десяти) рабочих дней, исчисляемых с первого числа месяца, следующего за месяцем, в котором Сторонами был подписан без замечаний Акт приема-передачи услуг.

Источник: Компания «ФТО».

Как работать по SLA?

Схема работы по готовому соглашению предельно понятна:

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

Отметим, что соблюдать SLA проще, если процессы в сервисной компании отлажены. Помогают этому различные инструменты автоматизации, в частности, Help Desk.

Попробуйте Okdesk бесплатно
Бесплатный доступ ко всем возможностям сервиса на 14 дней
Возможности нашего Help Desk:
  • Десятки готовых интеграций: телефония, мессенджеры, сервисы телематики
  • Учёт затрат, оборудования и объектов обслуживания
  • Автоматическое распределение заявок
  • Десятки готовых экспертных отчётов
  • Мобильное приложение для Android и iOS

Subscription small
15 000+ подписчиков. Присоединиться к рассылке
 
Время Uptime за последние
12 месяцев – 99,98
250 тыс
Количество клиентов, которых
поддерживают с помощью Okdesk
 
Активное развитие. Крупный
релиз раз в месяц