Ръководител екип поддръжка / Диспечер

Отдел: Клиентска поддръжка
Ниво: Старши оперативно
Основна цел: Екипът решава навреме, опашката е чиста, БЗ расте, клиентите са доволни

Какво прави тази роля

Ръководителят на екипа не само решава тикети — той оркестрира екипа. Наблюдава опашката, разпределя тикети към агентите, управлява ескалациите, изгражда базата знания, конфигурира предварително дефинираните отговори и параметризира инструментите на екипа. Той е връзката между агентите и Мениджъра.

Редовно използвани модули

Модул	Където се намира	За какво го използвате
Тикети за поддръжка	Операции → Тикети	Наблюдение на опашката + обработка на ескалации
Предварително дефинирани отговори	Операции → Предвар. отговори	Създаване и актуализиране на библиотеката на екипа
База знания	Знания → База знания	Създаване на статии от решени тикети
Анкети	Операции → Анкети	Наблюдение на CSAT + създаване на анкети
Обявления	Маркетинг → Обявления	Съобщаване на инциденти / поддръжка на клиентите
Спам филтри	Маркетинг → Спам филтри	Управление на имейл филтрите за тикети
Задачи	Операции → Задачи	Follow-up задачи за екипа
Автоматизация на работни потоци	Интеграции → Автоматизация	Конфигуриране на автоматизации за известия
Клиенти	CRM → Клиенти	Разбиране на контекста на ескалирани клиенти

Дневен режим

Сутрин — преглед на опашката (15–20 мин)

Тикети → филтриране на всички отдели → статуси: Нов + В процес + На изчакване
Сортиране по приоритет + последна активност → идентифициране на:
- Спешни тикети без отговор → незабавно разпределяне или поемане
- Тикети без активност > 4 часа → проверка защо → преразпределяне, ако агентът е блокиран
- Тикети На изчакване > 24 часа → проверка дали все още имат смисъл → свързване с агента
Балансиране на обема между агентите — ако един агент има > X активни тикети спрямо средното → преразпределяне

През деня

Отговор на ескалации, получени от L1
Добавяне на нови предварително дефинирани отговори при идентифициране на повтарящи се модели в тикетите
Добавяне на статии в БЗ от наскоро решени тикети
Наблюдение на WhatsApp входяща поща — разговори, невзети от агентите

Седмично — преглед на качеството

Произволно четене на 10–15 отговора от всеки агент → индивидуална обратна връзка
Анализ на тенденции: кои категории тикети растат? Кои проблеми се повтарят?
Изпращане на седмичния отчет с показатели до Мениджъра

Основни работни потоци

Работен поток 1 — Управление на ескалация от L1

Агент L1 ескалира сложен тикет
→ Отваряне на тикета → четене на вътрешните бележки на агента
→ Достъп до файла на клиента → разбиране на пълния контекст
   (фактури, поръчки, други тикети, история на отношенията)
→ Ако може да се реши директно → отговор + вътрешна бележка с обяснение на агента
→ Ако изисква друг отдел:
   ├── Продажби/KAM: възможност за upsell или договорен въпрос → предаване
   ├── Склад: проблем с доставка → предаване + проследяване
   ├── Финанси: спор за фактура → предаване на счетоводителя АС + информиране на клиента
   └── Технически/IT: грешка → пълно документиране + задача за IT екипа
→ Клиентът получава незабавна актуализация: „Поехме вашия случай..."

Работен поток 2 — Създаване на статия в БЗ от решен тикет

Тикет X, решен с ценно решение (честа ли е тоест или нов проблем)
→ Знания → База знания → Добавяне на статия
→ Попълване:
   Заглавие: формулирано като въпрос (напр. „Как да нулирам паролата на акаунта си?")
   Група: подходяща категория (напр. „Акаунт и достъп")
   Съдържание: стъпки за решение, ясни, с изображения, ако е възможно
   Видимост:
     - `staff_article = 0` → видимо за клиентите в портала (препоръчително)
     - `staff_article = 1` → само за вътрешен персонал (вътрешни процедури)
→ Публикуване (`active = 1`)
→ Следващия път, когато се появи същият проблем → агентът изпраща линка, не пише отново

Работен поток 3 — Комуникация при инцидент / поддръжка

Платформата е в поддръжка в събота от 02:00 до 04:00
→ Маркетинг → Обявления → Добавяне
   Заглавие: „Планирана поддръжка — 14 юни, 02:00–04:00"
   Съобщение: „Платформата ще бъде временно недостъпна..." (ясни детайли)
   showtousers = 1 → видимо за клиентите в портала
   showtostaff = 1 → видимо за агентите при вход

→ Обявлението се появява незабавно в клиентския портал
→ Ако е активен проблем → актуализиране на обявлението с текущия статус
→ При решаване → изтриване на обявлението или добавяне на „Проблемът е решен"

Работен поток 4 — Управление на спам филтри

Забелязвате изпращач, заливащ с тикети спам
→ Маркетинг → Спам филтри → Добавяне на филтър:
   Вид: изпращач (имейл адрес)
   Стойност: [email protected]
   Активен: ДА

ИЛИ при множество подобни теми:
   Вид: тема
   Стойност: *промоционален*

→ Оттук нататък съответстващите имейли се игнорират автоматично
→ Внимание: периодично проверявайте дали филтрите не блокират легитимни имейли

Работен поток 5 — Конфигуриране на автоматизация за поддръжка

Препоръчителни автоматизации за конфигуриране:
→ Интеграции → Автоматизация на работни потоци → Добавяне на автоматизация

1. Автоматична ескалация на Спешни:
   Задействане: Нов тикет + Приоритет = Спешен
   Действие: Push известие + имейл → Ръководителя на екипа

2. Сигнал за необслужен тикет:
   Задействане: Тикет В процес + Без отговор от персонал > 4 часа
   Действие: Известие → Ръководителя на екипа + назначения агент

3. Анкета след решаване:
   Задействане: Статус на тикета → Затворен
   Изчакване: 1 час
   Действие: Изпращане на анкета за удовлетвореност → имейла на клиента

4. Автоматично затваряне на неактивни тикети:
   Задействане: Статус на тикет = Отговорен + без активност > 7 дни
   Действие: Статус → Затворен + автоматична бележка: „Затваряме тикета поради неактивност..."

5. Автоматично повторно отваряне при отговор след затваряне:
   Задействане: Клиентът изпраща имейл с [ID на тикет: X] към Затворен тикет
   Действие: Статус → Отворен + известие до агента

Управление на библиотеката с предварително дефинирани отговори

Където: /admin/tickets/predefined_replies

Препоръчителна структура (префикси за визуална организация):

[Общ] Потвърждение за получаване
[Общ] Заявка за допълнителна информация
[Общ] Проблемът е решен — потвърждение от клиента
[Общ] Ескалацията е в процес
[Общ] Затваряне поради 7-дневна неактивност

[Акаунт и достъп] Инструкции за нулиране на парола
[Акаунт и достъп] Активиране на нов акаунт
[Акаунт и достъп] Липсващи разрешения — насочване към администратора

[Фактуриране] Дублирана фактура — разследване
[Фактуриране] Несъответстващо плащане — стъпки за проверка
[Фактуриране] Заявка за кредитно известие — инструкции

[Доставка] Поръчка в процес на обработка — срок
[Доставка] Инструкции за проследяване на AWB
[Доставка] Връщане на стоки — процедура

Показатели за ежедневно/седмично наблюдение

Показател	Извор	Честота на преглед
Общо отворени тикети	Dashboard на тикетите	Ежедневно
Тикети > 24 часа без отговор	Филтриране на тикети	Ежедневно
Разпределение по агент	Филтриране по назначен `admin`	Ежедневно
Средно време на първи отговор	Отчет за тикети	Седмично
Средно време за решаване	Отчет за тикети	Седмично
CSAT от анкети	Анкета → Резултати	Седмично
Прегледи на статии в БЗ	База знания → статистики	Седмично
Тикети по категория услуга	Филтриране по Услуга	Месечно

Практически съвети

Чиста опашка = здрав екип. Тикети, стоящи > 48 часа без активност, сигнализират, че нещо е блокирано — претоварен агент, неясен проблем, пропусната ескалация. Откривайте ги рано.

БЗ расте от ежедневни усилия, а не от специални проекти. Добавяйте по една статия дневно от решени тикети — за 3 месеца ще имате солидна база за самообслужване, намаляваща обема на тикетите повече от всяко ново наемане.

Остарелите предварително дефинирани отговори са по-лоши от липсата на отговори. Предварително дефиниран отговор с остарялата процедура дезинформира клиента. Проверявайте ги тримесечно.

Съобщавайте инцидентите проактивно, не реактивно. Ако знаете, че платформата ще бъде недостъпна, обявете го 48 часа предварително. Ако е недостъпна сега, обявете го в рамките на 15 минути. Мълчанието по време на инцидент генерира десетки ненужни тикети.