Приёмная статистик

1. Приёмная Статистик

2. Показатели направления

Стабильны последние месяцы
95% - 3,92 сек
Итог с Сентября 47 сек -> 3,7
сек

3. Показатели направления

Доля ошибок снижается
Доля ошибок – 0,19%

4. Инциденты

Июнь(Сообщайте нам о проблемах)
Лучший месяц
Не было критичных падений
Всего 38 минут downtime

5. Новые метрики

Будем ориентироваться в новом полугодии
Метрики
Доля запросов выше 10 сек
Количество запросов выше 10 сек

6. Что сделали в рамках стабилизации

Итог
Support
- Реплицировали CPT и Затраты
При отключении Hahn дашборды будут
отображать историческую информацию
Crowd_dwh
- Реплицировали опер.дашборды

7. SL_Q и SLA

А также интегральный показатель

8. Онлайн-метрики

Четыре блока информации на слайде
SL_Q и AFMD
Поместье администратора
- Раз в 10 минут
- Глубина 7 дней

9. Дашборд SLA

информации на слайде
Четыре блока
Единый показатель
Общий SLA/SL_Q
- В письмах два SLA - один попал в таргет, другой нет. Если выбрать только этот канал =
50%
- В чатах один SL_Q = он попал в таргет. Если выбрать только его - будет 100%
При выборе двух каналов получится 3 кейса, 2 в таргете, один не в таргете = 66,67%
SLA и SL_Q

10. Обновление дашборда SLA

Пересчет на 2 месяца
В прошлое не меняем значения (аналог версионирования)
Обновление стало раньше
Было – в 10 утра (нестабильно). Иногда до 12 часов
Стало – 7 утра

11. Количество обращений

Переезд окончен

12. Что изменилось?

Четыре
блока информации на слайде
Источники и дашборд нагрузки
Заменили источники
- CPT
- Escalation rate
- И другие)
Заменили вкладки
- Новые
- Старые с пометкой (delete)

13. Contact waiting и OCW

Clickhouse и онлайн

14. Что это за метрики

Contacts waiting
Число чатов в очереди (не взяты в обработку, не распределены
на оператора) в моменте (хвост)
Реалтайм метрики!
OCW
Время, которое ожидает в очереди самый старый тикет в
моменте

15. Что реализовали?

Четыре
блока информации на слайде
Поместье администратора

16. Это только MVP

Хотим помочь разработке

17. Новый AHT

Что меняется?

18. Какие боли возникали

Четыре
блока
информации на слайде
Не было части тикетов
Не учитывался ЕШ
Так как у них не было событий, которая предоставляет Сансара
Терялись и люди
Там уже новые события были
Трудно было связать со знанием
Из-за недостатка событий были проблемы с определением знания
в действиях оператора

19. Изменения в событиях

Как поменялась методология?

20. Методология AHT

Четыре блока информации на
слайде
Методология
AHT
Звонки
Методология осталась прежней, были исправлены недочеты и
баги
Было. Чаты и письма
Считались по разному:
Чаты - бековые события
Письма - старые фронтовые события
События
Считаем интервал в рамках событий startConversation (начало
разговора) -> endConversation (конец разговора)
Стало. Чаты и письма (ЕШ)
Для чатов и писем одна методология
Смотрим только на бековые события назначений, а также на
изменение статуса тикета
События
SET_TICKET_ASSIGNEE (назначение тикета)
REMOVE_TICKET_ASSIGNEE (снятие назначения)
TICKET_STATUS_LOG (изменение статуса, где тикет закрылся)

21. Методология AHT

Четыре блока информации на
слайде
Методология
AHT
Чаты и письма (ЕШ)
Описание интервалов из примера выше, в которых оператор:
1-3: Зашел в шаблон, где на него назначался тикет 1
4-5: Был назначен второй тикет
5-6: Переключился с тикета 1 на 2, где дал отбивку и вернулся обратно
6-7: Закончил работу над тикетом 1 (снял назначение или закрыл тикет)
7-10: Оставшееся работа над вторым тикетом

22. Реализация

Как мы поддержали методологию

23. ETL-процесс AHT

Создано
2 таблицы + 2 конечные витрины
Переиспользовано
Более десятка таблиц из DWH

24. ETL-процесс AHT

Время готовности витрин
AHT
AHT со знаниями
до 08:00 по МСК
до 09:00 по МСК
Частота пересчета
Каждые 4 часа

25. Структура дашборда

Какие вкладки появились?

26. Что дальше?

27. Можно ли работать с новыми вкладками?

Таймлайн
Если у вас ЕШ
Пользуйтесь текущими вкладками
Если у вас без ЕШ
Пользуйтесь вкладками c пометкой (old)
В мотивации
За Июнь – переходный период
Далее – по новым вкладкам (где применимо)

28. Приоритизация ad-hoc задач

29. Почему мы обновили флоу?

Как было раньше
Проектные задачи как ad-hoc
Не знали о них заранее, приоритизировали по дедлайну и
приоритету. Много блокеров и критов
Ad-hoc задачи — это задачи, которые
возникают спонтанно и требуют
немедленного решения. Не являются частью
заранее запланированных мероприятий
Не разделяли квоту на проекты и adhoc
В спринт могли попадать задачи с меньшим профитом для
бизнеса
Не успевали делать запланированные
проекты
Фокусировались на срочных незапланированных задачах

30. Что изменилось?

Четыре
блока информации на слайде
Меняем подход к приоритизации
• Опираемся на бизнес-ценность, приоритет, дедлайн
Собрали заказ на полугодие
• На этапе планирования уточнили, потребуется ли аналитика в
проектах смежных команд
• Разделяем квоту на проектные и ad-hoc задачи
• Запланировали эти проекты и выделили ресурс
Фокус на проекты и важные ad-hoc
задачи
Процесс работы с отложенными
задачами
• Проектных задач стало больше — уже начали работу по ним
• Несрочное и неважное откладываем
• В спринт берем самые срочные и важные ad-hoc задачи,
которые влияют на бизнес
• Раз в два спринта смотрим, по какому дашборду больше задач
и берем их вместе в работу

31. Что было сделано?

Три фотографии
с текстовыми блоками
Описали критерии важности
ad-hoc задач
Какую задачу можно отложить, а какую нужно
поскорее взять в спринт
Дополнили ФОС
Стало больше вопросов с вариантами ответа
— это поможет в приоритизации
Ввели поле «Бизнесценность»
Начинаем использовать его в работе.
Заполняется в зависимости от ответов в ФОС

32. Итоги

Тамлайн
К чему мы хотим прийти
Распределяем
квоту
Цель — выполнить
заказ на полугодие
Более прозрачная
приоритизация
Описание флоу в
открытом доступе
80% —
запланированные
проекты
20% — ad-hoc задачи
Реализовать все
проектные задачи и
развивать наше
направление
Новый статус
«Отложен», бизнесценность в задачах
Хранится на нашем
портале на Вики

33. Единый UI для дашбордов

34. Причины изменений

Четыре блока
инфо слайде
Отсутствие стандартизации
визуализации данных
Отсутствие прозрачности в актуальных
данных
Существующие дашборды в DataLens разрабатывались разными
командами без единых правил, что привело к неконсистентности в
оформлении, структуре и навигации. Это усложняет анализ
данных и снижает эффективность их использования.
Пользователи не всегда понимают, когда данные последний раз
обновлялись, что может привести к принятию решений на
устаревшей информации. Нет единого механизма индикации
обновлений и ошибок.
Низкая читаемость и удобство
использования текущих дашбордов
Необходимость контроля за
работоспособностью дашбордов
Из-за разнообразия подходов к визуализации пользователи тратят
дополнительное время на изучение каждого дашборда, а
некоторые элементы (селекторы, чарты) могут быть
неочевидными или перегруженными.
Некоторые дашборды могут содержать некорректно работающие
элементы (чарты, селекторы), но пользователи не всегда
замечают или не знают куда об этом сообщить и используют то
что имеют, что ведет к ошибочным выводам.

35. Стандартизация дашбордов – не ограничение, а свобода понимания.

Единый стандарт селекторов
Ранее селекторы могли располагаться хаотично и не
структурировано.
Индикатор данных
Сделали индикатор данных для понимания актуальности данных
Новые элементы для коммуникации
Добавили элементы перехода на приемную в мессенджере,
новостной Telegram-канал, вики, единую форму для задач и
форму для багов.

36. Измененные дашборды

Таймлайн
16.06 – 30.06
30.06 – 14.07
14.07 – 28.07
28.07 – 11.08
Продуктовая нагрузка
SLA онлайн
Количество обращений онлайн
AHT
SLA
CPT
CPT express
Поместье администратора
CSAT
База знаний
OCC/UTZ
Операционная нагрузка
Общие правки на прошлых
дашбордах
Статистика по
автоматизациям
Contact Resolution
Продуктовые метрики
клиентского сервиса
Escalation Rate

37. Визуальные изменения

Таймлайн

38. Спасибо!