<div><img src="https://mc.yandex.ru/watch/56654995" style="position:absolute; left:-9999px;" alt="" /></div>
Попробовать бесплатно

Tier 1 / Tier 2 / Tier 3 в поддержке

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

Что обычно делают на каждом уровне

  • Tier 1 — отвечает на простые повторяющиеся обращения по скриптам и базе знаний. KPI — скорость ответа и доля закрытых на первом контакте.
  • Tier 2 — разбирает нестандартные случаи, работает с продуктовой документацией глубже, иногда привлекает разработчика.
  • Tier 3 — обычно инженерная поддержка: разбор ошибок в коде, сложные интеграции, продакшн-проблемы.

Что важно

  • Чёткие критерии эскалации: что именно идёт с Tier 1 на Tier 2.
  • SLA на эскалацию: не больше N часов на передачу.
  • Обратная связь от Tier 2/3 на Tier 1: какие случаи можно научиться закрывать выше уровнем.

Когда применять и когда нет

Применять

  • Когда поток обращений уже не помещается в одну команду
  • Когда часть обращений требует инженерной экспертизы и не должна забирать всё время разработчиков
  • В B2B-поддержке со сложными интеграциями и SLA

Не применять

  • В маленькой команде поддержки до 3–5 человек — там tier-модель добавит больше бюрократии, чем пользы

Примеры применения

В SaaS-компании Tier 1 отвечает на 80% запросов: «как пригласить пользователя», «забыл пароль», «как настроить уведомления». На Tier 2 уходят случаи интеграций, нестандартные настройки. На Tier 3 — баги, требующие разработчика, и проблемы конкретного клиента в его инфраструктуре. После наладки модели среднее время ответа на простые вопросы упало с 4 часов до 15 минут, а инженеры перестали отвлекаться на пароли.

Часто задаваемые вопросы

В основе — да. Tier-модель пришла именно из IT-поддержки. В клиентской поддержке смысл уровней похож: простые обращения внизу, сложные и инженерные — выше. Конкретные обязанности и зарплаты сильно отличаются в зависимости от индустрии.

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

Готовы применить теорию на практике?

Соберите команду в Shtab — единое пространство для проектов, целей и задач. Бесплатно до 5 человек.