Многоуровневая модель — это не догма, а удобный способ разделить труд. В маленькой компании все уровни могут совмещаться в одном человеке, в крупных — это разные отделы.
Что обычно делают на каждом уровне
- Tier 1 — отвечает на простые повторяющиеся обращения по скриптам и базе знаний. KPI — скорость ответа и доля закрытых на первом контакте.
- Tier 2 — разбирает нестандартные случаи, работает с продуктовой документацией глубже, иногда привлекает разработчика.
- Tier 3 — обычно инженерная поддержка: разбор ошибок в коде, сложные интеграции, проблемы в промышленной среде.
Что важно
- Чёткие критерии эскалации: что именно идёт с Tier 1 на Tier 2.
- SLA на эскалацию: не больше N часов на передачу.
- Обратная связь от Tier 2 и Tier 3 на Tier 1: какие случаи можно научиться закрывать уровнем ниже.
- Когда поток обращений уже не помещается в одну команду
- Когда часть обращений требует инженерной экспертизы и не должна забирать всё время разработчиков
- В B2B-поддержке со сложными интеграциями и SLA
- В маленькой команде поддержки до 3–5 человек — там многоуровневая модель добавит больше бюрократии, чем пользы
В SaaS-компании Tier 1 отвечает на 80% запросов: «как пригласить пользователя», «забыл пароль», «как настроить уведомления». На Tier 2 уходят случаи интеграций, нестандартные настройки. На Tier 3 — ошибки, требующие разработчика, и проблемы конкретного клиента в его инфраструктуре. После наладки модели среднее время ответа на простые вопросы упало с 4 часов до 15 минут, а инженеры перестали отвлекаться на пароли.
Самая ценная часть многоуровневой модели — обратная связь снизу вверх. Если на Tier 2 регулярно приходят одинаковые сложные случаи, их разбор должен превращаться в новые статьи базы знаний и обучение Tier 1. Без этого верхние уровни постепенно перегружаются и теряют скорость.