Все, что вы хотели знать о SLA. Соглашение об Уровне Услуг – SLA

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

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

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

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

• Перечень услуг, которые будет оказывать подрядчик
• Формат и форма предоставления сервиса
• Критерии оценки качества выполнения работ
• График выполнения работ
• Разделение ответственности сторон
• Вопросы обеспечения соответствия требованиям закона
• Механизмы мониторинга деятельности и предоставления отчетности
• Порядок и принципы оплаты
• Процедуры разрешения споров
• Категории конфиденциальных данных, не подлежащих разглашению
• Условия прекращения действия договора.

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

Борьба за эффективность

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

В общем случае существует 4 вида характеристик работ – это объем, качество, оперативность и эффективность. Численное определение данных параметров позволяет создать метрики для оценки уровня обслуживания. Чтобы правильно подобрать критерии оценки работы, мы предлагаем придерживаться пяти основных принципов:

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

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

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

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

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

Построение партнерства

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

Согласно Википедии Соглашение об уровне обслуживания (перевод Service Level Agreement SLA) - термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и согласованный уровень качества предоставления данной услуги. Процесс SLA описан в книге ITIL Проектирование услуг (Service Design).

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

Состав соглашения об уровне оказываемых услуг (SLA)

Типовое соглашение об уровне сервиса (SLA) должно содержать следующие разделы:

• Контактные данные сторон, вовлеченных в соглашение, и срок его действия
• Описание услуги
• Техническая информация об услуге
• Поддерживаемое оператором абонентское оборудование
• Уровень и качество обслуживания
• Средства мониторинга и отчеты SLA
• Центр технической поддержки
• Механизм резервирования и восстановления услуги
• Нарушения обслуживания и компенсации
• Тарифы и выставление счетов
• Процесс улучшения SLA
• Порядок прекращения оказания услуги

Пример SLA

Подробнее показатели и примеры соглашений об уровне сервиса SLA рассмотрены в стандарте ITU-T M.3342 и TM Forum SLA Management Handbook. Вы можете получить шаблон SLA для услуги виртуальной частной сети (VPN), отправив заявку.

На что обратить внимание при составлении договора SLA

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

• Перечень ключевых показателей: типовое SLA должно содержать технологические (KPI) и организационные (KQI) показатели услуги. Каждый показатель должен однозначно трактоваться и иметь согласованную формулу для его расчета.
• Целевые значения показателей: для каждого показателя должно быть определено целевое значение исходя из потребностей бизнеса, предоставления информационных и телекоммуникационных услуг. Например, целевые значения услуги VPN определяются исходя из требований вышележащих сервисов. При использовании дополнительных средств шифрования каналов данная задача становится не тривиальной и требует лабораторных изысканий с использованием специализированных средств или определения данных показателей эмпирическим путем (методом «тыка»).
• Средства контроля и отчетности: Для каждого показателя должна быть определена методика измерения и средства контроля его значений. Согласование является важным моментом при подготовке SLA соглашения об уровне оказываемых услуг. Отчеты SLA должны формироваться в автоматическом режиме .

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

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

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

KPI не равно SLA

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

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

Если в SLA, как в любом договоре, возможно внести санкции за некачественное исполнение, то KPI сам по себе только виртуальная полоса на графике взлетов и падений уровня сервиса. KPI всегда остается безучастным к невыполнению показателей, а только безмолвно фиксирует отклонение. Ну и последнее: хотелось бы отметить, что соблюдение требований, описанных в SLA, используется как основной ключевой показатель эффективности (KPI) ИТ-отдела.

В самом начале

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

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

Но это в идеальной картине книг ITIL. Чаще всего инертность и безразличие «бизнеса», а порой просто непонимание, что же конкретно требовать от ИТ, приводит к тому, что и SLR подготавливается в стенах ИТ-подразделения. А затем вся связка необходимых документов преподносится на обсуждение руководству компании исходя исключительно из цифр выделенного на ИТ бюджета. В ИТ-службе не до конца способны понимать такой параметр для оказываемых ими услуг, как «критичность для бизнеса», «затронутые бизнес-транзакции» и действительно требуемый уровень услуг для поддержания функционирования зависимых подразделений.

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

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

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

Если свести этот документ к некому формуляру, данные из которого можно смело переносить в SLA и использовать для создания KPI, то получится вот такой список (см. таблицу 1).

Таблица 1. Формуляр, данные из которого можно переносить в SLA и использовать для создания KPI

OLA (Operational Level Agreement, Соглашение операционного уровня)

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

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

Словарь ITIL дает определение для OLA как «Соглашение между поставщиком ИТ-услуг и другой частью той же организации». Слова «той же организации» являются ключевыми.

Если, например, речь идет о соглашении по срокам исправления неисправности доступа в сеть интернет или качества самого соединения со стороны провайдера, то это с точки зрения ITIL будет «Внешний договор» (UC, Underpinning Contract).

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

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

Ради чего все эти сложности

Собрав требования бизнеса (SLR) и договорившись с нужными для оказания услуг подразделениями (OLA), можно приступать к написанию итогового документа – «Соглашения об уровне услуг». Все зависимости документов изображены на рис. 1.

На практике чаще всего запускают процесс разработки SLA в моменты внедрения в ИТ- службе Service Desk-системы, даже минуя этап SLR, сначала это не будет видно, но в процессе эксплуатации систем время расставит все на свои места. Разумеется, не надо забывать, что SLA является обязательной частью любых договоров, связанных с аутсорсингом ИТ-услуг. Итоговой целью создания SLA является то, что обе участвующие стороны переходят на единый понятийный уровень в отношении качества услуг.

С точки зрения здравого смысла и теоретических вкладок ITIL разработка SLA происходит на стадии Service Design, т.е. тогда, когда сервис еще не запущен в промышленную эксплуатацию и только готовится к внедрению. Для уже внедренных сервисов происходит пересмотр SLA и остальных параметров, тоже на стадии Service Design. Разработка SLA сама по себе влечет за собой пересмотр архитектуры ИТ- инфраструктуры для появления разрабатываемого сервиса, если по факту текущего состояния обеспечить выполнение условий не представляется возможным. Понятное дело, что также пересматриваются уже текущие бизнес-процессы, и внутрь них накладываются новые.

Само по себе соглашение (SLA) должно содержать четкие ответы на следующие четыре вопроса:

• Какие сервисы?
• Кому конкретно предоставляются?
• Какого именно качества он должен быть?
• В какие сроки должны быть устранены отклонения от описанных параметров в п. 3?

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

По определению в официальной книге ITIL:Service Design в зависимости от разреза услуги SLA делятся на три группы :

• Service-based (От услуги) – все заказчики получают одинаковые условия на один и тот же сервис.
• Customer-based (От потребителя) – условия различаются в зависимости от заказчика (и, разумеется, за разную цену).
• Multi-level (Многоуровневый) – условия описываются для компании, клиентов и служб, при этом каждый раз они различаются.

Для упрощения написания SLA подходят к разработке некого единого общего «соглашения» (Default SLA), включенного в «Каталог услуг», при этом все потребители получают общий набор сервисов с единым уровнем обслуживания и максимальным сроком исполнения поступивших обращений. В случаях, если какое-либо бизнес-подразделение не устраивает общий уровень по группе сервисов или даже по всему списку, тогда разрабатывается отдельный документ, «специально» описывающий особые условия.

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

Как и что писать

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

Главным посылом при разработке документа должно выступать для обеих сторон желание устанавливать реальные нормы качества для SLA, с учетом возможностей подразделения и целевых показателей, описанных в SLR. Ну, конечно, нельзя подходить к процессу с точки зрения «генерации» договора с красивыми, но не отражающими реалии словами.

Собирать информацию для данного документа рекомендуется:

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

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

Важно не забыть и дать описания таких понятий, как «Аварийная ситуация», «Инцидент», «Стандартное время регламентных работ (обслуживания)», «Доступность» и «Система регистрации заявок».

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

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

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

Каждый уровень «деградации» сервиса (см. таблицу 2) описывается в разрезе таких параметров, как «Время реакции на запрос (передача запроса на исполнение ответственному специалисту)», «Время выполнения (информирование заказчика о факте завершения запроса)». Последний столбец такой таблицы – стоимость неустойки за час или каждый просроченный случай.

Таблица 2. Уровни «деградации» сервиса

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

SLA – не обязательно документ с подписями и печатями

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

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

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

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

Как мы выяснили, просто так разбрасываться «умными» терминами не стоит, лучше понимать, что же скрывается за красивыми аббревиатурами.

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

1. Словарь терминов и определений ITIL 2011 на русском языке – http://www.itsmforum.ru/ZAM-test .
2. «ITIL® Service Design 2011edition», London: TSO, ISBN 9780113313051, p.111.

КАК ОПРЕДЕЛИТЬ, ПРОКОНТРОЛИРОВАТЬ И ПОВЫСИТЬ УРОВЕНЬ СЕРВИСА?

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

Определимся с понятиями

SLA расшифровывается как Service Level Agreement, дословно Соглашение об уровне сервиса. Термин SLA пришел из сферы IT, но теперь применяется далеко за ее пределами.

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

Роль Service Level Agreement для бизнеса

Если компания при выполнении процессов обслуживания клиентов опускается ниже установленных показателей, значит, она плохо работает. Таким образом, SLA − это универсальный инструмент оценки уровня сервиса любого бизнеса как в B2C, так и в B2B. Правда, применяется далеко не повсеместно. Почему?

1. Во-первых, в России пока еще не очень развита культура сервисного обслуживания.
2. Во-вторых, мало кто глубоко погружается в этот вопрос, и в итоге большинство работает без регламентированных правил.

На самом деле Service Level Agreement дает значимое конкурентное преимущество тому, кто его заключает.

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

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

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

Структура классического SLA описана в ITIL, при этом она довольно универсальна и может быть применима в абсолютно любом бизнесе. Какие разделы включает Соглашение об уровне сервиса?

Что описывается в договоре?

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

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

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

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

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

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

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

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

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

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

Другой пример: вы заказали замерщика пластиковых окон, он приехал, но вас не оказалось дома. Компания должна определить, сколько еще раз она сможет отправить к вам замерщика бесплатно и с какого момента вам придется за это заплатить.

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

Условия оплаты
Еще в SLA должны быть зафиксированы условия оплаты за предоставляемый сервис − не только стоимость услуг, но и момент ее списания (предоплата или постоплата) и правила возврата при отмене заказа. Скажем, вы бронируете номер в отеле. Цена проживания тут же списывается с вашей карты. Потом вы отменили поездку. Если оповестите отель заранее, он вернет все деньги. А если, скажем, менее чем за сутки до въезда − за вычетом некой удержанной суммы. Эта процедура тоже регулируется SLA.

Правила разрешения споров
Также в Соглашении об уровне сервиса должны быть сформулированы правила разрешения конфликтных и спорных ситуаций. Что делать, если вам привезли ботинки не того цвета, такси не доставило вас вовремя или пицца опоздала к ужину. А может быть, вам обещали восстановить доступ в интернет и сообщили о решении проблемы, а интернета как не было, так и нет. Все эти моменты надо предусмотреть.

Чек-лист по составлению Соглашения об уровне сервиса

Итак, грамотное SLA включает как минимум семь ключевых параметров:

• Список и состав предоставляемых услуг
• Время и география – когда и где обслуживаем клиентов
• Время реакции на заявку – наш первый ответ клиенту
• Время решения заявки – когда клиент получит результат
• Время возврата отложенной заявки
• Порядок оплаты услуг клиентом
• Правила решения спорных ситуаций

Если компания не устанавливает значения этих параметров, значит, у нее нет стандартов обслуживания клиентов.

К примеру, в компании Информатика и Сервис SLA состоит из универсальной части и индивидуальной (в которой могут содержаться не все услуги, а только некоторые из них) и является приложением к договору с каждым конкретным клиентом. В нем расписаны все наши услуги, стоимость и порядок их оказания. Это универсальная формула для всех видов бизнеса. Берите и пользуйтесь.

Автоматизация процессов обслуживания клиентов

Это следующий шаг для тех, кто уже разработал стандарты обслуживания и заинтересован в том, чтобы контролировать их исполнение и улучшать. Для этого существует целый класс программных продуктов − Help Desk или Service Desk. Будем оперировать вторым понятием, которое более функционально.

Каждый шаг сервисного процесса должен быть интегрирован и автоматизирован в системе Service Desk. Как это выглядит?

Все начинается с подачи заявки клиентом – это может быть электронная форма на сайте, письмо или звонок. Новая заявка немедленно регистрируется в журнале учета заявок Service Desk. Кстати, в самом простом виде ею может выступать даже обычный Excel, если все заявки собираются там.

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

После этого система должна помогать выполнять процесс обслуживания клиентов в соответствии с параметрами, которые закреплены в SLA. Для начала − сообщить клиенту, что его заявка получена и будет обработана за конкретное время ответственным исполнителем.

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

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

В идеале, повторим, Service Desk сама должна автоматически реагировать на заявку, назначать компетентного исполнителя и сообщать ему, что он должен решить запрос клиента к определенной дате.

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

Допустим, вы подбираете тур в Африку. У хорошей турфирмы сразу есть база всех отелей с ценами и вариантами размещения. Менеджеру не надо тратить время на поиск этой информации, она вся под руками. Подробнее о базе знаний можете почитать .

Следующий эволюционный этап автоматизации сервисного обслуживания − это когда "искусственный интеллект" внутри системы Service Desk, получая запрос от клиента, научится его правильным образом читать, сопоставлять с данными из базы знаний и тут же отправлять в автоматическом режиме ответ клиенту. Это то, к чему должны стремиться все сервисные системы − работать автономно, без менеджеров и исполнителей.

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

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

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

Например, любое мобильное приложение службы такси по окончании поездки предлагает вам оценить водителя и уровень сервиса. Если вы поставите низкую оценку, то приложение поинтересуется причинами. Любая система Service Desk тоже должна предоставлять такую возможность клиенту. Ну и, в идеале, система автоматизации должна быть интегрирована с сервисами оплаты или, по крайней мере, напоминать о формировании счетов или учитывать внесенный пользователем аванс.

Решение для автоматизации процессов обслуживания

9 октября 2017 года компания Информатика и Сервис выпустила новое приложение для Битрикс24 − оно называется Admin24 - Service Desk и помогает бизнес-пользователям Битрикс24 существенно улучшить качество обслуживания клиентов.

В Битрикс24 есть модуль задач (более подробно о нем можно прочитать ), который позволяет создать задачу, назначить исполнителя, указать крайний срок выполнения и пр. Но все это делается в ручном режиме. Когда компания обслуживает большое количество клиентов, важно, чтобы их заявки регистрировались в системе автоматически, чтобы так же автоматически назначались исполнители в соответствии с каталогом услуг и чтобы система следила за исполнением параметров SLA. В штатных возможностях Битрикс24 этого нет. Но благодаря новому приложению Admin24 такой функционал стал доступен.

В нашем приложении можно сформировать простейший каталог услуг. За каждой из них закрепить одного или нескольких ответственных исполнителей. Также в первых версиях приложения Admin24 можно указать три важнейших параметра SLA − время реакции на заявку клиента, время ее выполнения и срок автовозврата заявки (для случаев, когда она по тем или иным причинам была отложена исполнителем). При этом, для расчета всех параметров может применяться только то время, которое вы укажете как рабочее в настройках самого Битрикс24.

Еще в приложении можно указать реквизиты компании, чтобы соблюсти требования федерального закона 152-ФЗ «О персональных данных». Как вы знаете, клиент, отправляя заявку, передает вам свои персональные данные (имя, фамилию, телефон). По закону он должен дать на это согласие.

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

Далее заявка клиента попадает в виде задачи в специально созданную в Битрикс24 группу Admin24 - Service Desk и автоматически назначается тем ответственным исполнителям, которые были определены на этапе формирования каталога услуг при установке и настройке приложения. Настройки можно изменить в любой удобный момент, и это не отразится на ранее полученных заявках.

В задаче для исполнителя сразу указаны контактные данные клиента, текст обращения, а также услуга, по которой поступила заявка. Если этот клиент уже зарегистрирован в CRM Битрикс24, то задача автоматически прикрепляется к его карточке. Получается, что ответственный менеджер отдела продаж увидит, с какими запросами обратился его клиент в сервисный отдел, и сможет подумать, какие еще продукты или услуги продать клиенту дополнительно. В перспективе в Admin24 можно будет автоматически формировать и отправлять счета на оплату из CRM Битрикс24.

В настоящее время реализован минимальный функционал Admin24 - Service Desk , который уже позволяет использовать Битрикс24 как систему автоматизации обслуживания клиентов. Все параметры SLA по каждой заявке фиксируются, и руководитель в специальном отчете видит, сколько заявок не решены в положенный срок, на сколько из них реагировали не вовремя. У руководителя появляется возможность принимать решения на основе этих отчетов, проводить работу над ошибками и повышать качество обслуживания. Этот процесс должен быть непрерывным.

Таким образом, приложение Admin24 - Service Desk позволяет автоматизировать процесс выполнения заявок и обслуживать клиентов на основе SLA. Любая компания, которая использует Битрикс24, может начать обслуживать своих клиентов на основе Соглашения об уровне сервиса. То есть сформировать свои собственные стандарты обслуживания клиентов и постоянно их улучшать.