Вне регламента как правильно писать
Обновлено: 30.06.2024
Мы уже разбирали, как написать одностраничный Устав единственного учредителя, короткий договор, а теперь поговорим про регламент оказания услуг. С регламентами сложилась ужасная ситуация:
Регламент – это стандарт качества обслуживания, по сути, аналог ГОСТа, который должен защищать интересы клиента. А на деле же часто написан нечитабельным юридическим языком в интересах Исполнителя. Обычно пользователи подписывают не читая договор и все приложения к нему, а потом не могут защитить свои права. Они уже не хотят перемен, смирились. А мы хотим, поэтому создаем документы простыми и работающими, а вас призываем выбирать компании с ясными документами.
Кратко о наших принципах:
- Что должно быть в регламенте:классификация и перечень объектов предметной области: типы услуг, типы событий, виды аварий, способы коммуникаций, перечень юридически значимых действий и т.д.;измеряемые критерии: объёмы, минуты, скорость, оценки и т.д.;алгоритмы, процедуры, которые реально важны;гарантии качества;ответственность за нарушение.
Далее – большой лонгрид про написание полезного регламента и примеры, как делать не стоит.
Заказчику регламент нужен, чтобы получить качественную услугу и отстаивать свои права, если исполнитель косячит.
Исполнителю же регламент нужен не затем, чтобы иметь 100500 поводов нагнуть требовательного и придирчивого клиента, а чтобы сотрудники не халявили, оказывали услуги качественно и в компанию шли клиенты по сарафанному радио.
Причина такого заголовка сводится к тому, что как показала практика, встретить простой и/или понятный регламент практически невозможно, а порой в открытом доступе на сайте его вообще может не быть.
Пришли мы к этому, когда искали и смотрели, как сделано у других.
Схожий опыт уже был – он описан в статье про то, как написать простой и понятный договор.
Как и в прошлый раз, изучение чужих регламентов показало, что у других написано сложно, скучно, непонятно, о чем мы уже сказали в начале статьи, но давайте подробнее разберем, чего же не должно быть в регламенте.
Ощущение, что документ(ы) писал фрилансер, которому за количество символов платили.
Больше услуг – больше чтива на ночь, смиритесь!
А вот тут уже 17 страниц – из-за растянутых формулировок и текста ради текста.
Максимально расплывчатые понятия и неизмеримые параметры – это уже не классика, а издевательство!
Своевременно – это час? День? Месяц? Год?
Уязвимости какого характера? Microsoft практически в каждом обновлении на своих продуктах уязвимости закрывает – выходит, они там по умолчанию есть и сервером с виндой пользоваться запрещено?
Списка литературы в конце не хватает, но не будем подкидывать плохих идей. Большая часть определений - очевидные и общедоступные понятия, а если наоборот, то зачем их использовать?
Спасибо, что разъяснили…
При этом существует простое и известное/доступное понятие – льготный период, а судя по отсутствию в википедии понятий как “мягкий” и “жесткий” – это какое-то изобретение, очевидно, велосипеда.
В ряде случаев предполагается, что документы должны изучить юристы, но какое это отношение имеет к клиенту, который не имеет юридического образования или юриста в штате?
Много бесполезного текста.
Вам не кажется, что тут что-то не так?
Что вам, как клиенту хочется видеть в регламенте?
Какие услуги оказываются?
Какие события могут произойти?
А что, если произойдет авария?
Если с услугами в большинстве случаев проблемы возникают редко, то возможные события и тем более аварийные ситуации никак не прописаны.
Какие объемы услуг и в какие сроки должны быть предоставлены?
Сколько минут / часов / дней требуется для того или иного события?
С какой скоростью должна отвечать техническая поддержка?
Точных значений и того, что действительно можно измерить, многие избегают по понятным причинам.
Без лишних слов, просто и понятно – написать, как и куда обратиться, как оценить качество, в какие сроки ждут реакции от вас.
Этому тоже мало где уделяют внимание.
Это важнейший момент, который либо не прописан, либо прописывается с большим количеством сносок и оговорок.
Когда речь заходит про дата-центр, особенно сертифицированный, разве это не накладывает ряд обязательств на исполнителя?
Этот пункт связан с предыдущим, так как в случае нарушения гарантий должна наступить ответственность, прописанная в документах.
Многие и этого избегают, но если нет гарантий – за что ответственность? Удобно.
Предположим, регламент у поставщика уже есть, но вам он не нравится.Тут стоит задаться вопросом: станет ли поставщик менять его ради одного клиента? Подписать-то могут любую редакцию, но найдет ли это отражение в реальных рабочих процессах?
Чтобы разобраться в этом, стоит обратить внимание на то, как и зачем пишется должен писаться регламент.
Тут мы повторимся, так как отталкивались от того, что должно быть в регламенте:
- классификация и перечень объектов предметной области: типы услуг, типы событий, виды аварий, способы коммуникаций, перечень юридически значимых действий, …;
- измеряемые критерии: объёмы, минуты, скорость, оценки, …;
- алгоритмы, процедуры, которые реально важны;
- гарантии качества;
- ответственность за нарушение.
Важно отметить, что типовой документ тут не подойдет, необходимо понимать реальное положение дел в конкретной ситуации.
Разберем наш регламент оказания услуг дата-центра и шаги, которые были предприняты для его написания.
Составляем каркас, в нашем случае это 11 пунктов:
- Состав услуг.
- Классификация заявок.
- Время реакции и режим работы.
- Оценка качества услуг.
- Характеристики дата-центра.
- Гарантии.
- Порядок посещения дата-центра.
- Порядок приемки-передачи оборудования.
- Доставка.
- Методы и порядок коммуникаций.
- Ответственность.
Каркас получился типовой + мы не стали дублировать то, что и так определено в договоре – зачем лишние пункты.
Наполняем каркас контентом.
Тут все очевидно: главное, не забыть про дополнительные услуги.
Требуется понять, по каким вопросам обращаются клиенты, сгруппировать ряд обращений, выписать все необходимые. Нам помогло то, что ранее мы уже писали SLA и KPI для инженеров дата-центра, в рамках чего эта работа и была проделана.
Время реакции, срок выполнения заявок и режим работы
Режим работы – очевидный параметр, не будем на нем останавливаться.
Со временем реакции уже сложнее.
У нас есть время реакции, которое мы прописываем в инструкции для инженеров, есть статистика, которая говорит о том, что они в это время укладываются. А значит, можем смело ставить эту цифру в регламент.
Например, время реакции с нашей стороны мы указали 30 минут, однако статистика на данный момент говорит о том, что средний максимум –17 минут. Запас оставляем, но можно и снизить показатель, для красивых цифр.
Расписывать детально по всем типам не стали, выделили лишь типовое обращение, нестандартное обращение, инцидент, аварию и исходящее обращение.
Срок выполнения заявки – тут тоже нужна статистика, которая показывает, в какие сроки и какие обращения были закрыты, на что и стоит ориентироваться.
Тут важно отметить, что мы не забыли и про пункт, который регламентирует сроки получения обратной связи от клиента, так как в ряде ситуаций, молчание клиента стопорит выполнение задачи.
Например, выделение IP-адреса или консультация – типовые обращения, среднее время закрытия подобных заявок составляет 63 и 86 минут соответственно.
Срок выполнения типовых обращений мы прописали 2 часа, так что укладываемся.
Оценка качества услуг
Тут ничего сложного – перечисляем, как клиент может оценить качество.
В нашем случае – это:
- Поставить оценку в переписке по электронной почте, в тикет-системе, в чате Telegram.
- Позвонить техническому или исполнительному директору (контакты есть на сайте).
Вот так может выглядеть статистика у инженеров, чьи показатели выше 97%:
Все минусы и недочеты учитываются и тщательно подсчитываются.
Ничего сложного, особенно когда он сертифицирован, а значит, можно смело ссылаться на параметры, актуальные для сертификации.
Сертификатов должно быть три:
Если же их нет, то можно отталкиваться от параметров резервирования по нашей таблице.
Часть гарантий перекрывается параметрами дата-центра и сроками реакции/закрытия инцидента, поэтому, в нашем случае описывать все в этом пункте не стали.
Закрыли частый (и очень важный) вопрос: в какие сроки мы можем подготовить сервер?
Опять же, отталкиваясь от статистики, пишем реальные сроки.
Например, изрядно выбились по срокам подготовки сервера –подарили месяц бесплатной аренды, сами виноваты. Хоть и без пофигизма поставщиков не обошлось, за что им отдельное спасибо… Нужно ли здесь многоточие?
Порядок посещения дата-центра
Как ни странно, но с этим регулярно возникают вопросы и даже курьезные ситуации – так что, вынесли в отдельный пункт и описали все требования, но тут стоит отталкиваться от вашей локации.
Порядок приемки-передачи оборудования
Очень важный пункт, в котором стоит в очередной раз вспомнить, какие косяки имели место быть и все их описать. Причем обратите внимание: требования тут идут именно к клиенту.
После подобных ситуаций мы добавили в регламент пункт 8.3., в котором явным образом прописали, кому мы выдаем сервер – само собой, курьерам без оригинала доверенности не выдавали и выдавать не будем.
Или еще один важный пункт в том же разделе:
Почему так? А потому что написал клиент заявку – отключите, снимите, съезжать буду. Ок, но зачастую это “съезжать буду” может затянуться на неделю, две, месяц… Да, сервер не в стойке, да, не кушает электричество, но хранить-то его тоже нужно. Один – ладно, но если таких 10? 100?
Тоже пункт, который был специально вынесен отдельно, чтобы избежать недоразумений, которые периодически возникают и мы с ними сталкиваемся.
Методы и порядок коммуникаций
Пункт немного сложнее, чем может показаться. Да, тут мы перечисляем все способы с нами связаться, но при этом уделяем внимание и вопросу идентификации клиента, что бывает камнем преткновения во многих конфликтах.
Безусловно, самый интересный пункт!
Пункт про деньги – и да, мы тоже считаем что 1/720 это смешно, потому что не брать денег за время, которое услуга не предоставлялась,– логично, но ответственностью и не пахнет.
Так что у нас иные цифры:
100 часов не работал по нашей вине – месяц не оплачиваешь.
Туда же занесли и возмещение за факт нарушения регламента.
Мы не рассчитываем брать эти деньги из воздуха, потому что регламент – это зеркальное отражение KPI и SLA сотрудников, договоров и оговоренных уровней качества услуг с поставщиками. Как говорится, бизнес никогда не перекладывает на себя новые расходы – тут ситуация немного схожая, вот только клиента эти внутренние разбирательства беспокоить не должны.
Например, в конце января по нашему недосмотру в дата-центре Тушино ночью у клиента отключился один из двух серверов. Не авария, но инцидент, по нашему регламенту время на его устранение – 2 часа.
Усугублялась ситуация еще и тем, что на тот момент круглосуточных инженеров в дата-центре не было (с марта ситуация исправлена, теперь работаем круглосуточно).
Запустить оборудование удалось в районе двух часов дня, что даже при учете рабочего времени – сильно за рамками.
Как итог, весь февраль клиент размещался у нас бесплатно, все еще с нами и больше жалоб не поступало.
Еще пример: накосячили при настройке VLAN (позиционировали как аварию), клиент получил простой 68 минут, что опять же, вышло за рамки регламента. Компенсация – неделя бесплатно.
Проводим этап согласований и правок на их основе.
- тем, кто должен его соблюдать;
- тем, кто должен следить за его соблюдением;
- тем, кто будет его подписывать с другой стороны (некоторым клиентам, например).
- Тут важно понимать, что регламент обязательно нужно показать:
Именно на этом шаге можно обнаружить полный спектр несоответствия реальности и ожиданиям.
Регламент – это зеркало того, как ваша компания готова/хочет/может работать (нужное подчеркнуть), а не пустая бумага. Это нужно транслировать клиенту на понятном ему языке.
А еще – это самоконтроль и понимание к чему нужно стремиться.
Как следствие, регламент не должен и не может быть шаблонным документом, потому что всегда пишется индивидуально, на основании:
- понимания своих же бизнес-процессов и услуг;
- не из головы взятых и прописанных SLA / KPI внутри компании;
- договоров с поставщиками и их обязательств;
- обширной статистики обращений, сроков, косяков и иных ситуаций.
А значит, если регламента у компании нет, то стоит задуматься: отсутствие какого из вышеперечисленных пунктов мешает его написать?
А вот этот ваш регламент проходил реальную "проверку боем"?
Я имею в виду юридические разбирательства, в которых вы тыкали бы недовольного клиента в нос своим регламентом, и его юристы беспомощно разводили руками?
Все вот эти многостраничники же не просто так появляются. Приходит такое чучело и заявляет: "А у вас не написано, что писюн нельзя совать в миксер, потому давайте 100500 денег". И бедолаги добавляют пункт о запрете совать писюн, а равно пальцы, уши и другие выступающие части тела во всё более пухнущий документ.
В данном случае Вы немного подменяете понятия, короткий и понятный документ может быть и хорошим, и плохим, это просто разные вещи. В целом, в длинном и запутанном договоре легче наделать косяков.
Есть масса примеров, когда договор длинный, непонятный, запутанный, но в суде это не спасает и компанию натягивают. У меня в жизни был случай: договор составлял отдел — 5 юристов, было очень длинно и невозможно читать, в суде компания проиграла. И какой вывод?
Реальность такова — всё не пропишешь и от всего не убережёшься, как не раздувай договор всё равно есть шанс проиграть, Гугл и Фейсбук налетают на миллиардные штрафы, у них что, юристов нет? Договора плохие?
Я тоже поддерживаю тренд на короткие и понятные договора написанные человеческим языком, сам такими пользуюсь. Необходимое в них есть, пользоваться ими приятно, а остальное закрывается действующим законодательством.
Читайте также: