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