{"id":9454,"title":"\u041a\u0430\u043a \u0441\u0442\u043e\u043b\u044f\u0440\u044b \u0438\u0437 \u0420\u044f\u0437\u0430\u043d\u0438 \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043d\u0430 \u0434\u0435\u0440\u0435\u0432\u044f\u043d\u043d\u044b\u0445 \u0434\u0438\u043d\u043e\u0437\u0430\u0432\u0440\u0430\u0445","url":"\/redirect?component=advertising&id=9454&url=https:\/\/vc.ru\/pochta\/328045-kak-stolyarnaya-masterskaya-iz-ryazani-nachala-prodavat-tovary-po-vsemu-miru&placeBit=1&hash=2a5fe1185750debf6eff79c9510d5a82ba810f16be799f12f89083789a4f685f","isPaidAndBannersEnabled":false}
Сервисы
Itsoft Web-studio

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

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

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

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

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

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

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

Зачем писать регламент и как его писали мы

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

Исполнителю же регламент нужен не затем, чтобы иметь 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 внутри компании;
  • договоров с поставщиками и их обязательств;
  • обширной статистики обращений, сроков, косяков и иных ситуаций.

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

0
8 комментариев
Популярные
По порядку
Написать комментарий...
Мутный корабль

А вот этот ваш регламент проходил реальную "проверку боем"?
Я имею в виду юридические разбирательства, в которых вы тыкали бы недовольного клиента в нос своим регламентом, и его юристы беспомощно разводили руками?
Все вот эти многостраничники же не просто так появляются... Приходит такое чучело и заявляет: "А у вас не написано, что писюн нельзя совать в миксер, потому давайте 100500 денег". И бедолаги добавляют пункт о запрете совать писюн, а равно пальцы, уши и другие выступающие части тела во всё более пухнущий документ.

Ответить
0
Развернуть ветку
Evil Pechenka

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

Есть масса примеров, когда договор длинный, непонятный, запутанный, но в суде это не спасает и компанию натягивают. У меня в жизни был случай: договор составлял отдел — 5 юристов, было очень длинно и невозможно читать, в суде компания проиграла. И какой вывод?

***

Реальность такова — всё не пропишешь и от всего не убережёшься, как не раздувай договор всё равно есть шанс проиграть, Гугл и Фейсбук налетают на миллиардные штрафы, у них что, юристов нет? Договора плохие?

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

Ответить
2
Развернуть ветку
Мутный корабль

У меня одного ссылка на ваш регламент https://itsoft.ru/r/dc/ не работает?

Ответить
1
Развернуть ветку
Itsoft Web-studio

Благодарю Алексей за отклик. Подправили. Просьба проверить.

Ответить
1
Развернуть ветку
Мутный корабль

Всё отлично.

Ответить
–1
Развернуть ветку
Миша Магадан

чего не должно быть в регламенте:...неизмеряемых критериев типа «в кратчайшие сроки»;
а я полез в ваш вариант короткого договора и нашёл там такой пункт -
"Своевременно отвечать на заявки Заказчика."

Ответить
1
Развернуть ветку
Itsoft Web-studio

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

Ответить
0
Развернуть ветку
Миша Магадан

да я верю,  что вы хорошие :) я про договор, что там вроде не очень написано

Ответить
0
Развернуть ветку
Читать все 8 комментариев
Ozon запустил встроенный в маркетплейс онлайн-кошелёк «Ozon Счёт» Статьи редакции

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

Мечтает ли Мастер кампаний «Яндекса» об электроовцах? Алгоритмы «Директа» заменят агентства. Мы станем водителями такси

Испытали новую волшебную таблетку «Яндекс.Директа» — «Мастер кампаний» в e-com, мебели и недвижимости. Дешевые лиды в три клика в сверхконкурентных нишах.

Увлечение самолётами, которое переросло в бизнес

Предприниматель из Волгограда производит и продаёт по всему миру симуляторы дополненной реальности.

Сезон подкаста как эксперимент: научили ведущих бегать и отправили на полумарафон. Кейс Sports.ru и adidas
Какие тренды мобильного банкинга актуальны в 2021 году: главное из отчета Go Banking

7 декабря digital-агентство Go Mobile выпустило ежегодный отчет о мобильном банкинге в России. Эксперты оценили 35 банков и выявили основные тренды, в рамках которых развивались их мобильные приложения.

DiDi впервые показал в России электромобиль для водителей такси

Его представили 7 декабря на форуме «Открытые инновации» в Сколково.

«Газпромбанк» взял семь номинаций на двух премиях

Редко удается получить сразу несколько наград, а ещё реже получается это сделать на двух премиях сразу. Тем не менее, у нас получилось: стали лауреатами Digital Leaders и «Время инноваций»!

Несвободный фриланс: сложности продуктов для проектных исполнителей

Хоть количество фрилансеров в России растет, на рынке все еще сложно создать продукт с F2B или P2P-моделью.

Фото: Unsplash
Как и чем сейчас живут московские рестораны, отмеченные гидом «Мишлен»

Узнали и рассказываем, как повлиял звездный статус на рестораны «Деликатессен» и «Паризьен», и за что их сотрудники получают повышенные чаевые.

Что такое контент-план для соцсетей и как с ним работать

Продолжаем разбираться с контентом для бизнеса. Сегодня обсудим контент-план — что это такое, какие задачи решает и почему работает не всегда. В конце статьи разберёмся, как интегрировать в контент-план непредсказуемые инфоповоды

null