Качество в поддержке, часть 4: межгалактические требования и международные стандарты
А как там за бугром?
Качество в поддержке, часть 1: проверки тикетов
Качество в поддержке, часть 2: внутреннее и внешнее качество
Качество в поддержке, часть 3: метрики
Качество в поддержке, часть 4: международные стандарты
Качество в поддержке, часть 2: внутреннее и внешнее качество
Качество в поддержке, часть 3: метрики
Качество в поддержке, часть 4: международные стандарты
В первых трёх частях мы разобрали, как поддержку проверяют, как её видит клиент и как всё это пытаются измерить и оценить.
Может показаться, что руководители поддержек созваниваются после обеда и придумывают новые проблемы: то чек-листы для проверки введут, то метрики всех заставляют какие-то выполнять.
Это не так. Все инструменты и понятия, которые используют для оценки и работы с качеством, — это отголоски международных стандартов сертификации, ISO.
Может показаться, что руководители поддержек созваниваются после обеда и придумывают новые проблемы: то чек-листы для проверки введут, то метрики всех заставляют какие-то выполнять.
Это не так. Все инструменты и понятия, которые используют для оценки и работы с качеством, — это отголоски международных стандартов сертификации, ISO.
Проверяем тикеты
Внешнее качество
Сложные метрики
Международные стандарты
International Organization for Standardization собирает экспертов со всего мира, и они договариваются, как лучше всего управлять качеством, безопасностью и другими вещами, чтобы это работало на любом континенте одинаково хорошо. Стандарты едины для всех, независимо от языка и страны.
Попытки буквально «внедрить ISO» приводят к бюрократии и путают всю команду, поэтому сертификация по ISO-талмудам остаётся аутсорс-гигантам, услуги которых лучше продаются при наличии сертификата.
ISO — это бабушка всех процессов в поддержке. Всё, что мы сейчас делаем на работе, — это куски одной большой системы, которую много лет назад пытались описать умные люди. Никто из руководителей поддержек не читал ISO целиком, тем не менее мы все по ним работаем.
Международные стандарты не используют как прямое руководство к действию. Сейчас мы интуитивно понимаем, что у поддержки должна быть база знаний, что на жалобы нужно реагировать, тикеты нужно фиксировать, а за сроками ответов — следить, но это не всегда было таким очевидным.
Эти сотнестраничные документы создавались десятилетиями, опираются на большой накопленный опыт и помогают организовать работу большой службы поддержки, чтобы она не работала на авось. В ISO суперобъёмные тексты, универсальные формулировки для любой области. Эти требования избыточны для команды саппорта из двадцати человек, но всё, с чем мы привыкли работать, появилось благодаря стандартам.
Попытки буквально «внедрить ISO» приводят к бюрократии и путают всю команду, поэтому сертификация по ISO-талмудам остаётся аутсорс-гигантам, услуги которых лучше продаются при наличии сертификата.
ISO — это бабушка всех процессов в поддержке. Всё, что мы сейчас делаем на работе, — это куски одной большой системы, которую много лет назад пытались описать умные люди. Никто из руководителей поддержек не читал ISO целиком, тем не менее мы все по ним работаем.
Международные стандарты не используют как прямое руководство к действию. Сейчас мы интуитивно понимаем, что у поддержки должна быть база знаний, что на жалобы нужно реагировать, тикеты нужно фиксировать, а за сроками ответов — следить, но это не всегда было таким очевидным.
Эти сотнестраничные документы создавались десятилетиями, опираются на большой накопленный опыт и помогают организовать работу большой службы поддержки, чтобы она не работала на авось. В ISO суперобъёмные тексты, универсальные формулировки для любой области. Эти требования избыточны для команды саппорта из двадцати человек, но всё, с чем мы привыкли работать, появилось благодаря стандартам.
ISO 9001. Управление качеством работы любой организации
Стандарт не про работу поддержку, а про качество чего угодно. Вы уже живёте внутри ISO 9001, если ваш работодатель пытается работать не на авось, а стабильно.
Стандарт про «опиши, как ты работаешь → замерь, что у тебя получается → если получается плохо, перепиши и поработай по-новому».
Стандарт не про работу поддержку, а про качество чего угодно. Вы уже живёте внутри ISO 9001, если ваш работодатель пытается работать не на авось, а стабильно.
Стандарт про «опиши, как ты работаешь → замерь, что у тебя получается → если получается плохо, перепиши и поработай по-новому».
❌ Без ISO 9001
- Каждый отвечает, как умеет и считает нужным
- Один просит скриншоты, другой — нет
- Срок ответа может быть любым
- «У нас всё нормально. Вроде»
✅ В духе ISO 9001
- Есть база знаний
- Есть чек-листы и проверки тикетов
- Есть метрики
- Мы пытаемся всё это улучшать
ISO 10 002. Система управления жалобами клиентов
Стандарт, который говорит нам, что жалобы нужно не просто принимать, а как-то управлять ими: фиксировать, уметь считать, устранять и не давать им повторяться. Даже если вам кажется, что баги вообще не чинятся, на самом деле вы уже внутри ISO 10 002.
Стандарт про «жалоба — это не раздражитель, а сигнал, что мы могли бы зарабатывать больше».
Предположим, мы столкнулись с тикетом:
😠 У меня списались деньги дважды!
💬 Вернул, хорошего дня
Стандарт, который говорит нам, что жалобы нужно не просто принимать, а как-то управлять ими: фиксировать, уметь считать, устранять и не давать им повторяться. Даже если вам кажется, что баги вообще не чинятся, на самом деле вы уже внутри ISO 10 002.
Стандарт про «жалоба — это не раздражитель, а сигнал, что мы могли бы зарабатывать больше».
Предположим, мы столкнулись с тикетом:
😠 У меня списались деньги дважды!
💬 Вернул, хорошего дня
❌ Без ISO 10 002
Дальше ничего не происходит. Тикета не было, закрывать его не нужно. Вопрос, в принципе, решён, но нет никакой системной картины, посчитать, сколько раз встречалась проблема, невозможно
Дальше ничего не происходит. Тикета не было, закрывать его не нужно. Вопрос, в принципе, решён, но нет никакой системной картины, посчитать, сколько раз встречалась проблема, невозможно
✅ В духе ISO 10 002
Выясняем, это баг или пользователь сам нажал. Если баг, записываем в таск и передаём разработчику, считаем, сколько обращений было с этим багом. Если сам нажал, записываем, сколько было таких случаев, и передаём дизайнерам интерфейса
Выясняем, это баг или пользователь сам нажал. Если баг, записываем в таск и передаём разработчику, считаем, сколько обращений было с этим багом. Если сам нажал, записываем, сколько было таких случаев, и передаём дизайнерам интерфейса
ISO 18 295. Стандарты качества контакт-центров
Наконец стандарт прямо про нас! Благодаря ISO 18 295 у нас вообще есть работа, потому что он предписывает компаниям иметь контакт-центры для ответов, а не отправлять разработчиков писать тикеты.
Наконец стандарт прямо про нас! Благодаря ISO 18 295 у нас вообще есть работа, потому что он предписывает компаниям иметь контакт-центры для ответов, а не отправлять разработчиков писать тикеты.
❌ Без ISO 18 295
- «Ну напишите нам куда-нибудь»
- Отвечает тот сотрудник, который ближе — директор, уборщица, разработчик
- Можно, в принципе, вообще не отвечать, если вопрос тупой
✅ В духе ISO 18 295
- У нас есть разные каналы связи: вот почта поддержки, здесь чат, вот номер телефона
- Есть команда, которая разговаривает с пользователями, мы обучаем их именно этому
- Мы отвечаем на вопросы согласно регламентам, и все стремимся быть одинаково хорошими
ITSM, ITIL и ISO/IEC 20 000. Стандарт управления айти-услугами
До 1980-х годов айтишники были сугубо техническими структурами, они обеспечить работоспособность ЭВМ и сетей между ними. Пользователей и продуктов было так мало, что никому в голову не приходило как-то специально их поддерживать.
С распространением персональных компьютеров и клиент-серверной архитектуры люди за компьютерами перестали носить белые халаты. Компьютеры появились на столах у бухгалтеров, логистов, маркетологов и учеников начальных классов. Появилась идея о том, что недостаточно просто производить компы и продавать программы. Пользователи захотели звонить и спрашивать, почему не работает.
В ответ появилась концепция IT Service Management (ITSM) — подход, при котором айти-отдел оказывает услуги бизнесу, а бизнес является заказчиком и потребителем.
В конце 1980-х британское правительство столкнулось с проблемой: разные ведомства управляли ИТ по-разному, качество услуг плавало, бюджеты раздувались. Британское Central Computer and Telecommunications Agency получило задачу — унифицировать подходы, чтобы обеспечить предсказуемость и сократить расходы.
CCTA собрало и обобщило лучшие практики коммерческих компаний и госструктур. Результатом стала библиотека документов — IT Infrastructure Library (ITIL). Библиотека документов — это буквально собрание книг, каждая из которых описывает работу со своей сферой сервиса.
До 1980-х годов айтишники были сугубо техническими структурами, они обеспечить работоспособность ЭВМ и сетей между ними. Пользователей и продуктов было так мало, что никому в голову не приходило как-то специально их поддерживать.
С распространением персональных компьютеров и клиент-серверной архитектуры люди за компьютерами перестали носить белые халаты. Компьютеры появились на столах у бухгалтеров, логистов, маркетологов и учеников начальных классов. Появилась идея о том, что недостаточно просто производить компы и продавать программы. Пользователи захотели звонить и спрашивать, почему не работает.
В ответ появилась концепция IT Service Management (ITSM) — подход, при котором айти-отдел оказывает услуги бизнесу, а бизнес является заказчиком и потребителем.
В конце 1980-х британское правительство столкнулось с проблемой: разные ведомства управляли ИТ по-разному, качество услуг плавало, бюджеты раздувались. Британское Central Computer and Telecommunications Agency получило задачу — унифицировать подходы, чтобы обеспечить предсказуемость и сократить расходы.
CCTA собрало и обобщило лучшие практики коммерческих компаний и госструктур. Результатом стала библиотека документов — IT Infrastructure Library (ITIL). Библиотека документов — это буквально собрание книг, каждая из которых описывает работу со своей сферой сервиса.
- Первая версия (конец 1980-х) состояла из 30 книг, детально описывающих процессы: управление инцидентами, проблемами, изменениями, конфигурациями, Service Desk и т. д. Это был набор руководств, как воплощать философию ITSM на практике.
- Вторая версия (ITIL v2, конец 1990-х) структурировала знания в две ключевые книги: Service Support и Service Delivery. Эта версия получила мировое распространение.
- Сейчас, в 2026 году, мы живём в мире пятого ITIL. Если вы работаете в поддержке, вы уже в мире айтил, даже если впервые увидели это слово.
ITSM
концепция
Что мы должны делать вообще?
ITIL
методология
Как мы можем это сделать?
ISO/IEC 20000
стандарт
Что именно мы должны сделать, а что необязательно?
ISO/IEC 20 000 основан на процессах, описанных в айтиле. Он не повторяет айтил дословно, но добавляет минимальные обязательные требования (shall — «должен»), в то время как айтил остаётся набором рекомендаций (should — «следует»). Например:
ITIL: «Можете классифицировать инциденты по приоритетам, это хорошая тема и будет круто».
ISO 20 000: «У вас должен быть задокументированный процесс управления инцидентами с критериями приоритезации».
Если упростить, стандарт требует, чтобы у вас были процессы:
ITIL: «Можете классифицировать инциденты по приоритетам, это хорошая тема и будет круто».
ISO 20 000: «У вас должен быть задокументированный процесс управления инцидентами с критериями приоритезации».
Если упростить, стандарт требует, чтобы у вас были процессы:
- Управление инцидентами (Incident Management): быстро зафиксировать, понять приоритет, починить, регулярно давать статус пользователю.
- Управление проблемами (Problem Management): искать корень проблем и исправлять причину, а не следствие.
- Управление SLA: знать время ответа, решения и расставлять приоритеты.
- Управление изменениями (Change Management): фиксируйте, тестируйте и контролируйте изменения, а не катите с божьей помощью.
- Связь поддержки и разработки: саппорт не просто передаёт туда-сюда жалобы, а действует в процессе, в котором тикеты влияют на приоритеты разработки.
❌ Без ISO 20 000
- Каждый раз одна и та же проблема разбирается с нуля
- Никто не следит за сроками и не держит пользователя в курсе
- Саппорт закрыл тикет — дальше хоть трава не расти
✅ В духе ISO 20 000
- У нас есть понятные статусы: что-то сломалось → завели инцидент → чиним → закрыли
- Мы называем сроки или хотя бы ориентиры и возвращаемся с обновлениями
- Если проблема повторяется — заводим отдельную задачу, чтобы найти причину
- Саппорт остаётся ответственным за ответ пользователю, даже если чинит другая команда
Чему нас учат международные стандарты
💌 Специалистов: если ваш руководитель каждый день вводит по новой целевой метрике или другой глупости, он необязательно самодур, который спит и видит, как бы усложнить вашу работу. Возможно, это части общей системы, без которой всё развалится, но вы не видите полной картины.
👑 Руководителей: нельзя ввести что-то одно — только чек-листы проверок, только одну метрику — и надеяться, что это магическим образом ✨исправит✨ работу команды. Все отличные идеи, которые вы можете подсмотреть у коллег и захотеть ввести у себя, на самом деле — части огромных стандартов и методологий и не помогут, если их натыкать, как редиску на грядку.
Всё, что мы сейчас воспринимаем как очевидное — базы знаний, чек-листы и инструкции, метрики, — пришло к нам из многостраничных стандартов и методологий, а не было придумано руководителями поддержек, чтобы специалистам жизнь мёдом не казалась. Стандарты помогают отвечать на три вопроса:
💌 Специалистов: если ваш руководитель каждый день вводит по новой целевой метрике или другой глупости, он необязательно самодур, который спит и видит, как бы усложнить вашу работу. Возможно, это части общей системы, без которой всё развалится, но вы не видите полной картины.
👑 Руководителей: нельзя ввести что-то одно — только чек-листы проверок, только одну метрику — и надеяться, что это магическим образом ✨исправит✨ работу команды. Все отличные идеи, которые вы можете подсмотреть у коллег и захотеть ввести у себя, на самом деле — части огромных стандартов и методологий и не помогут, если их натыкать, как редиску на грядку.
Всё, что мы сейчас воспринимаем как очевидное — базы знаний, чек-листы и инструкции, метрики, — пришло к нам из многостраничных стандартов и методологий, а не было придумано руководителями поддержек, чтобы специалистам жизнь мёдом не казалась. Стандарты помогают отвечать на три вопроса:
- Мы вообще знаем, как работаем?Стандарты требуют описать процессы. Не «ну мы вроде отвечаем, и пока никто не жаловался», а «вот регламент по качеству ответов, вот матрица эскалаций, вот такие приоритеты ставим». Без этого невозможно ни улучшаться, ни управлять командой.
- Мы измеряем то, что наработали?Если процесс описан, его можно замерить и оцифровать: время ответа, доля повторных обращений, количество тикетов с одной причиной. Стандарты превращают «вроде нормально» в цифры, на которые мы можем внятно влиять.
- Мы зацикливаем улучшения?Это главный принцип ISO 9001, прошитый во все остальные стандарты: описали → замерили → поняли, где тонко → зашили и снова замерили. Без этого цикла саппорт держится на героизме отдельных сотрудников до их выгорания.
Делайте так, и будет у вас международное качество без международных стандартов.
Есть вопросы? Я помогаю бизнесу развивать саппорт, а людям — разобраться с работой в поддержке.
Главред медиа и автор статьи — Юля Бессмертная @murmurderer
📚 Эти ссылки подобрали для вас вручную:
«Ой, мы не хотели»: кризисные ситуации в работе поддержки
«Ой, это было не вам» — фраза, которая хотя бы раз заставляла кровь стынуть в жилах любого саппорта. Ещё не отправляли клиенту скриншот своего чата с подругой вместо ответа по тикету? Ваш час придёт. Встретьте его во всеоружии.
Как получать повышения легко и приятно
Парадокс: одни годами отвечают на тикеты, а другие стремительно растут в карьере. Ну и почему так несправедливо?
Дизайн тикета: как поддержке писать так, чтобы письма и чаты читали
Вы вложили душу в подробный ответ, разобрали проблему по косточкам, дали четкие шаги, а ответа нет. Почему?
Дизайн тикета: доброе слово и пользователю приятно
Вроде пишешь пользователям быстро, а они всё равно злятся. Пишешь по шаблону — не слышат. Добавляете вежливости — звучишь как робот. Что делать?