Что такое shift-left
Shift-left пришёл из DevOps, где «слева» — это ранние этапы разработки (тесты, статический анализ), а «справа» — продакшн (мониторинг, инциденты). Идея: чем раньше нашли проблему, тем дешевле её решить.
В helpdesk «слева» — пользователь, «справа» — третья линия (разработчики, вендоры). Стандартная цепочка эскалации заявки:
- L0 (self-service) — пользователь нашёл ответ в базе знаний, прошёл шаблон в портале, спросил чат-бота. Заявку даже не создал.
- L1 (первая линия) — простая рутина: сброс пароля, выдача доступа, базовая диагностика.
- L2 (вторая линия) — экспертная диагностика, настройка систем, нестандартные сценарии.
- L3 (третья линия) — разработчики или вендоры; копают код, инфраструктуру, делают патчи.
Цель shift-left — сдвинуть нагрузку влево: то, что сегодня разбирает L2, должно по возможности уметь решать L1; то, что разбирает L1 — пусть пользователь делает сам. Без потери качества.
Экономика shift-left: считаем стоимость заявки
Точные числа сильно зависят от компании, но порядок именно такой:
| Уровень | Стоимость заявки | Откуда складывается |
|---|---|---|
| L0 — self-service | ~50–100 ₽ | Поддержка инфраструктуры портала / БЗ |
| L1 — первая линия | ~300–800 ₽ | 15 мин оператора, ФОТ + накладные |
| L2 — экспертный | ~1500–3000 ₽ | 30–60 мин ведущего инженера |
| L3 — разработка | ~5000–20000 ₽ | Часы разработчиков, потери на context switch |
Если из 1000 заявок в месяц вы переведёте 200 с L1 на L0 — экономия составит порядка 60–140 тыс. ₽ в месяц. Это считая только прямую стоимость операторских часов. Косвенно: операторы перестают сгорать на рутине, у них появляется время на сложные кейсы — это повышает CSAT по тем заявкам, которые остались.
Что переносится на self-service, а что нет
Хорошие кандидаты для shift-left — это заявки с тремя признаками:
- Высокая частотность (повторяются десятки раз в месяц).
- Низкая вариативность (решение по чек-листу, не «зависит от ситуации»).
- Не требуют ручной проверки (либо проверка автоматизируется, либо её нет).
Типовые победители:
- Сброс пароля
- Запрос на доступ к расшаренной папке / Wiki / общему почтовому ящику
- Установка типового ПО из утверждённого каталога
- Заказ оборудования (мышка, клавиатура, монитор) — по шаблону с автоназначением на склад
- Уточнение статуса своей заявки (полностью замещается личным кабинетом)
Плохие кандидаты, которые часто пытаются shift-left, но получается криво:
- Любая диагностика инцидента. Пользователь не должен задавать себе вопросы «обновлены ли драйверы».
- Кросс-системные вопросы. Где конкретно сломалось — узнает только оператор с доступами.
- Что-либо требующее согласования. Сначала автоматизируйте согласование, потом думайте о self-service.
Типовые ошибки shift-left
- «Сделаем портал — пользователи привыкнут». Не привыкнут. Если найти ответ в портале сложнее, чем написать оператору лично, портал останется пустым. Бенчмарк удобства: пользователь должен решить типовую задачу за 2 клика и без логина (если возможно — SSO).
- База знаний без жизненного цикла. Статья опубликована два года назад, инструкция устарела, пользователь следует — ничего не работает, идёт в поддержку с двумя проблемами. База знаний требует владельца и регулярного пересмотра — не реже раз в полгода.
- Чат-бот как «первый эшелон». Если бот не умеет реально решать — он становится барьером. Пользователь говорит «оператор» десять раз — это не shift-left, это деградация UX. Бот имеет смысл только когда он действительно умеет 60+% запросов закрыть до человека.
- Учёт shift-left как KPI операторов. Если операторам в KPI поставить «процент заявок, переадресованных на self-service» — они начнут отфутболивать пользователей со словами «прочитайте инструкцию». Это разрушает доверие.
Как замерять эффективность shift-left
Метрика номер один — deflection rate: процент пользовательских визитов на портал/в БЗ, которые НЕ привели к созданию заявки.
Deflection = 1 − (заявок создано / уникальных визитов на портал)Считается за период (месяц). Здоровый уровень для зрелого портала — 40–60%. Дополнительные метрики:
- Доля self-service от общего объёма заявок. Цель — 25–40% за два года после внедрения портала.
- Top-10 поисковых запросов в БЗ. Если люди ищут «как настроить X», а статьи нет — это бесплатный roadmap для контент-менеджера.
- Время от первого визита до решения. Если в self-service пользователь решает за 5 минут — отлично. Если за 30 минут листает 8 статей — портал нужно перестроить.
Дополняйте этими цифрами свой отчёт по KPI поддержки — без shift-left метрик KPI поддержки выглядит как «больше заявок = больше нагрузки», без понимания, что часть нагрузки можно было даже не создавать.
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Частые вопросы
Что такое shift-left в IT-поддержке?
Перенос рутинных запросов к пользователю или на автоматизацию: портал самообслуживания, база знаний, чат-боты. Цель — снизить нагрузку на операторов первой линии и стоимость заявки.
Какой процент заявок реально перенести на self-service?
Для зрелого портала — 25–40% за два года. Это типовые операции вроде сброса пароля, запросов доступа, заказа оборудования.
Что такое deflection rate?
Метрика shift-left: процент визитов на портал / в базу знаний, которые НЕ закончились созданием заявки. 40–60% — хороший показатель для зрелого портала.
Чат-бот заменяет операторов?
Нет. Чат-бот хорошо работает на FAQ-уровне с типовыми запросами. На реальной диагностике, согласованиях и нестандартных кейсах человек незаменим. Плохо настроенный бот хуже его отсутствия — он становится барьером.
С чего начать внедрение shift-left?
С аналитики топ-20 самых частых заявок. Из них выбрать 3–5 с самым высоким overhead и наименьшей вариативностью. Сделать для них шаблоны в портале + статьи в БЗ. Замерить deflection через 2 месяца.