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

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

• прочитать и понять их почти невозможно;
• непонятно кем, для кого и зачем они пишутся, если можно написать в одном предложении: «Банк, хостер, Исполнитель всегда прав»;
• регламенты не несут пользы клиентам.

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

Кратко о наших принципах:

• Чего не должно быть в регламенте:словаря общеизвестных терминов – не надо определять Интернет, сеть, ЛК и т.п.;неизмеряемых критериев типа «в кратчайшие сроки»;ни на что не влияющих тупых фраз, которые заведомо никто не будет даже читать;страшилок и кабальности, что мы порвём клиента, если он оступится;дублирования императивных норм законов и подзаконных актов – они действуют независимо от того, что написано в договоре и регламенте.

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

Далее – большой лонгрид про написание полезного регламента и примеры, как делать не стоит.

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

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

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

Еще одна причина – у регламента может быть масса других названий. Например, «Соглашение об уровне обслуживания» или «Условия использования…», но все это об одном и том же.

Пришли мы к этому, когда искали и смотрели, как сделано у других.

Схожий опыт уже был – он описан в статье про то, как написать простой и понятный договор.

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

Сразу оговорюсь, для примера взяли наиболее яркие примеры, большая часть которых нашлась на сайте у коллег из reg.ru и selectel, за что им спасибо, так как в отличии от некоторых, на их сайте документы есть и их много :)

Ощущение, что документ(ы) писал фрилансер, которому за количество символов платили.

Вот «Условия использования …» и там всего 8 страниц, но это условия для одной единственной услуги! А таких на сайте > 20.

Больше услуг – больше чтива на ночь, смиритесь!

А вот тут уже 17 страниц – из-за растянутых формулировок и текста ради текста.

Выяснилось, что есть такой прикольный параметр, как «тошнота» текста – измерить его можно, например, тут.

В данном случае он составляет 16.6, что более чем в 2 раза превышает допустимую «норму».

По рейтингам, Россия на втором месте среди «самых читающих стран», не находите взаимосвязи?

Максимально расплывчатые понятия и неизмеримые параметры – это уже не классика, а издевательство!

Например:

«2.6.7. По завершении установки оборудования в Дата-центре, Исполнитель информирует Заказчика через Тикет-систему и/или по электронной почте о подключении» (с).

Там же:

«5. Заказчик не имеет права пользоваться Услугами, если своевременно не устраняет уязвимости, обнаруженные при проверке требований безопасности» (с).

Своевременно – это час? День? Месяц? Год?

Уязвимости какого характера? Microsoft практически в каждом обновлении на своих продуктах уязвимости закрывает – выходит, они там по умолчанию есть и сервером с виндой пользоваться запрещено?

Или тут:

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

Может, но не обязан. А слово «разные» – верх точности и определенности.

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

Примеры:

«Служба поддержки (СП) – команда специалистов Исполнителя, ответственная за оказание услуг клиентской поддержки Пользователей» (с);

«Правила – условия оказания технической поддержки, описанные в настоящем документе» (с);

«Панель управления – веб-интерфейс, представленный Заказчику Исполнителем для управления услугами» (с);

«Стеллаж – конструкция, для размещения оборудования не предназначенного для крепления в Серверной стойке» (с).

Спасибо, что разъяснили…

Обратная ситуация:

«Мягкий грейс период – период оказания услуги после завершения оплаченного периода, в течение которого услуга оказывается Исполнителем Заказчику в полном объеме» (с).

Там же есть еще «Жесткий грейс период»...

При этом существует простое и известное/доступное понятие – льготный период, а судя по отсутствию в википедии понятий как “мягкий” и “жесткий” – это какое-то изобретение, очевидно, велосипеда.

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

Много таких пунктов нашлось у hostkey. Например, в документе «Согласие на обработку персональных данных» (редакция от 30 декабря 2020 года) в пункте 7.6 зачем-то продублированы полные названия законов, постановлений и приказов:

Много бесполезного текста.

Или тут:

«в случае обнаружения информации, выражающей в неприличной форме, которая оскорбляет человеческое достоинство и общественную нравственность, явное неуважение к обществу, государству, официальным государственным символам Российской Федерации, Конституции Российской Федерации или органам, осуществляющим государственную власть в Российской Федерации, Генеральный прокурор Российской Федерации или его заместители обращаются в федеральный орган исполнительной власти, осуществляющий функции по контролю и надзору в сфере средств массовой информации, массовых коммуникаций, информационных технологий и связи» (с).

И такого много…

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

А теперь сиди и разбирайся, где «та мера» и «применимость» законодательства.

«2.2.2. Заказчик обязан оказывать содействие Исполнителю при расследовании причин незапланированных перерывов в обслуживании, нарушения требований безопасности и при подозрении на нарушения условий Соглашения» (с).

Вам не кажется, что тут что-то не так?

Что вам, как клиенту хочется видеть в регламенте?

Какие услуги оказываются?

Какие события могут произойти?

А что, если произойдет авария?

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

Какие объемы услуг и в какие сроки должны быть предоставлены?

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

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

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

Без лишних слов, просто и понятно – написать, как и куда обратиться, как оценить качество, в какие сроки ждут реакции от вас.

Этому тоже мало где уделяют внимание.

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

А почему?

Когда речь заходит про дата-центр, особенно сертифицированный, разве это не накладывает ряд обязательств на исполнителя?

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

Многие и этого избегают, но если нет гарантий – за что ответственность? Удобно.

Если вы уже «обжигались», то будете требовать регламент.

Вот пример статьи в которой автор (со стороны клиента) сам писал SLA при заключении договора. Очевидно, в этом была необходимость и именно так он решил «мотивировать» своего поставщика. Но имеет ли это смысл?

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

Чтобы разобраться в этом, стоит обратить внимание на то, как и зачем пишется должен писаться регламент.

Тут мы повторимся, так как отталкивались от того, что должно быть в регламенте:

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

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

Разберем наш регламент оказания услуг дата-центра и шаги, которые были предприняты для его написания.

Составляем каркас, в нашем случае это 11 пунктов:

• Состав услуг.
• Классификация заявок.
• Время реакции и режим работы.
• Оценка качества услуг.
• Характеристики дата-центра.
• Гарантии.
• Порядок посещения дата-центра.
• Порядок приемки-передачи оборудования.
• Доставка.
• Методы и порядок коммуникаций.
• Ответственность.

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

Наполняем каркас контентом.

Состав услуг

Тут все очевидно: главное, не забыть про дополнительные услуги.

Классификация заявок

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

Время реакции, срок выполнения заявок и режим работы

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

Со временем реакции уже сложнее.

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

Например, время реакции с нашей стороны мы указали 30 минут, однако статистика на данный момент говорит о том, что средний максимум –17 минут. Запас оставляем, но можно и снизить показатель, для красивых цифр.

Расписывать детально по всем типам не стали, выделили лишь типовое обращение, нестандартное обращение, инцидент, аварию и исходящее обращение.

Срок выполнения заявки – тут тоже нужна статистика, которая показывает, в какие сроки и какие обращения были закрыты, на что и стоит ориентироваться.

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

Например, выделение IP-адреса или консультация – типовые обращения, среднее время закрытия подобных заявок составляет 63 и 86 минут соответственно.

Срок выполнения типовых обращений мы прописали 2 часа, так что укладываемся.

Оценка качества услуг

Тут ничего сложного – перечисляем, как клиент может оценить качество.

В нашем случае – это:

• Поставить оценку в переписке по электронной почте, в тикет-системе, в чате Telegram.
• Позвонить техническому или исполнительному директору (контакты есть на сайте).

Вот так может выглядеть статистика у инженеров, чьи показатели выше 97%:

Все минусы и недочеты учитываются и тщательно подсчитываются.

Характеристики дата-центра

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

Сертификатов должно быть три:

Если же их нет, то можно отталкиваться от параметров резервирования по нашей таблице.

Гарантии

Часть гарантий перекрывается параметрами дата-центра и сроками реакции/закрытия инцидента, поэтому, в нашем случае описывать все в этом пункте не стали.

Закрыли частый (и очень важный) вопрос: в какие сроки мы можем подготовить сервер?

Опять же, отталкиваясь от статистики, пишем реальные сроки.

Например, изрядно выбились по срокам подготовки сервера –подарили месяц бесплатной аренды, сами виноваты. Хоть и без пофигизма поставщиков не обошлось, за что им отдельное спасибо… Нужно ли здесь многоточие?

Порядок посещения дата-центра

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

Порядок приемки-передачи оборудования

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

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

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

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

Или еще один важный пункт в том же разделе:

«8.6. Датой прекращения оказания услуги размещения оборудования считается дата выдачи оборудования Заказчику».

Почему так? А потому что написал клиент заявку – отключите, снимите, съезжать буду. Ок, но зачастую это “съезжать буду” может затянуться на неделю, две, месяц… Да, сервер не в стойке, да, не кушает электричество, но хранить-то его тоже нужно. Один – ладно, но если таких 10? 100?

Доставка

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

Методы и порядок коммуникаций

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

Ответственность

Безусловно, самый интересный пункт!

Пункт про деньги – и да, мы тоже считаем что 1/720 это смешно, потому что не брать денег за время, которое услуга не предоставлялась,– логично, но ответственностью и не пахнет.

Так что у нас иные цифры:

100 часов не работал по нашей вине – месяц не оплачиваешь.

Туда же занесли и возмещение за факт нарушения регламента.

И эти цифры тоже не из головы – тут снова статистика, подсчеты «сколько это в рублях» и выводы: готовы ли мы?

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

Например, в конце января по нашему недосмотру в дата-центре Тушино ночью у клиента отключился один из двух серверов. Не авария, но инцидент, по нашему регламенту время на его устранение – 2 часа.

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

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

Как итог, весь февраль клиент размещался у нас бесплатно, все еще с нами и больше жалоб не поступало.

Еще пример: накосячили при настройке VLAN (позиционировали как аварию), клиент получил простой 68 минут, что опять же, вышло за рамки регламента. Компенсация – неделя бесплатно.

Проводим этап согласований и правок на их основе.

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

Именно на этом шаге можно обнаружить полный спектр несоответствия реальности и ожиданиям.

Регламент – это зеркало того, как ваша компания готова/хочет/может работать (нужное подчеркнуть), а не пустая бумага. Это нужно транслировать клиенту на понятном ему языке.

А еще – это самоконтроль и понимание к чему нужно стремиться.

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

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

А значит, если регламента у компании нет, то стоит задуматься: отсутствие какого из вышеперечисленных пунктов мешает его написать?

#дата_центр #цод #регламенты