Service blueprint для customer support в e-commerce: как Samokat сократил время решения и «раскассировал» прич

Service blueprint для customer support в e-commerce: как Samokat сократил время решения и «раскассировал» причины контактов

В 2026 e-commerce живёт не столько “за счёт первой покупки”, сколько за счёт retention и LTV: средний чек продолжает проседать (по отраслевым оценкам — в среднем на 5–8% за счёт экономии), а значит любое трение в постпродажном контуре становится дорогим. В этой реальности Самокат (как и другие игроки быстрой доставки) столкнулся с классикой: контакты в поддержку растут, а операторы тонут в повторяющихся причинах.

Контекст
Мы рассматриваем ситуацию из практики внедрения CX-изменений в service-организации (не про “как быстро ответить”, а про “как за один цикл закрыть потребность”). У Самоката поддержка была перегружена обращениями, которые по сути делились на несколько потоков:
— статус заказа не понятен / “где курьер”
— изменения по заказу (добавить/убрать товар, заменить)
— вопросы по оплате и отменам
— “не то привезли” и возвраты
Проблема была не только в количестве обращений. Воронка контакта распадалась: клиент получал ответ, но задача не закрывалась с первого раза — и возвращался снова.

Задача
Собрать end-to-end путь клиента и разложить поддержку по этапам сервиса, чтобы:
1) снизить долю повторных обращений (контакты по одной и той же причине)
2) сократить время решения (TTR — time to resolve, время до фактического закрытия проблемы)
3) сделать так, чтобы клиенту не нужно было “угадывать правила” (самостоятельные действия и корректные сценарии)
4) связать работу поддержки с реальными узкими местами операций (комплектация, курьерская доставка, склад, обработка отмен)

Решение
Команда сделала service blueprint (сервисный чертёж) на уровне “за одну проблему — один маршрут”, а не “как устроен отдел поддержки”. Что именно сделали:

1) Пересобрали карту пути клиента от момента триггера до финала
Триггером считали не “клиент написал”, а “клиент понял, что не контролирует ситуацию”: задержка, расхождение состава заказа, необходимость замены. Для каждого триггера выделили:
— что видит клиент в приложении
— где “провал понимания”
— какие шаги поддержки действительно нужны, чтобы закрыть кейс

2) Встроили “линии видимости” в blueprint
Разделили:
— видимую часть (frontstage): интерфейс статусов, тексты, подсказки
— невидимую часть (backstage): регламенты склада/курьеров, правила замен, обработка отмен
— линии поддержки (support processes): какие команды и системы участвуют, где должны быть точки контроля

3) Упаковали причины контактов в 6–8 “первичных причин” вместо сотен тэгов
Главный CX-эффект blueprint — дисциплина. Тэгирование стало единообразным: оператор видит причину, видит предписанный сценарий и знает, что “сделал для закрытия”, а не просто “ответил”.

4) Перепроектировали сценарии и дополнили самообслуживание
Например:
— по статусу заказа добавили “объясняющие статусы” и понятные временные рамки в терминах процесса (без обещаний, которые сложно выполнить)
— для замен/отмен закрепили “право выбора” в момент, когда это реально поддерживается операциями
— по “не то привезли” сформировали маршрут возврата так, чтобы повторно не спрашивать одни и те же данные (чек/фото/подтверждение)

5) Поставили метрики, которые отвечают на вопрос “закрыли ли проблему”
Отдельно мониторили:
— TTR (время до решения)
— долю повторных обращений по той же первичной причине
— долю эскалаций (когда поддержка не может решить в рамках уровня 1)
— качество “первого закрытия” (first-contact resolution)

Результат
По итогам внедрения (цикл измеряли на периодах до/после с согласованием того, что сезонность учтена, а структура обращений пересчитана) получили:
— снижение TTR на **20–25%** за счёт сценариев “под причину” и уменьшения ручных проверок
— снижение повторных обращений примерно на **15–18%**: клиент не возвращался с тем же вопросом
— снижение доли эскалаций на **10–12%**, потому что поддержка получила ясные правила и нужные данные в контексте
— рост доли кейсов, закрытых в канале без дополнительных запросов со стороны клиента (подход “собери решение с первого цикла”)
…