Автоматизація заявок: від прийому до виконання
Заявка - це не подія, а процес із кількох етапів, і на кожному з них вона може застрягти. Нижче розберемо життєвий цикл заявки послідовно: як вона потрапляє в систему, за якими правилами призначається виконавцю, як рахуються дедлайни і що робить система, коли етап прострочено. Мова піде саме про механіку - правила, таймери, ескалації та автоматичні сповіщення.
Прийом заявок: єдина точка входу і нормалізація даних
Перший етап циклу - прийом заявок. Незалежно від того, звідки прийшов запит, у системі він має стати однаковим обʼєктом із передбачуваним набором полів: хто звернувся, що потрібно, до якого продукту або послуги належить запит, який регіон, який пріоритет. Поки заявки лежать у різних форматах, жодні правила розподілу не спрацюють, бо їм немає за чим орієнтуватися.
Нормалізація - це не тільки зведення полів. Це ще й приведення значень до довідників: телефон у міжнародному форматі, назва міста з єдиного списку, тип запиту з фіксованого переліку. Тоді умова «якщо тип = сервіс і регіон = Захід» працює однозначно, а не залежить від того, як менеджер написав місто в текстовому полі.
Тут же має відпрацювати дедуплікація: якщо клієнт написав двічі за пʼятнадцять хвилин, це одна заявка з двома повідомленнями, а не дві задачі для двох різних людей. Практичне правило - збіг за телефоном або поштою у вікні 24 години обʼєднує звернення в один тред. Те саме стосується повторного звернення по вже відкритому питанню: воно прикріплюється до наявної картки, а не запускає паралельний процес.
Розподіл заявок: правила призначення замість ручного вибору
Коли заявка нормалізована, спрацьовує розподіл заявок за правилами. Базових критеріїв зазвичай чотири: продукт або тип послуги, регіон чи мова клієнта, поточне навантаження виконавця і графік чергування. Правила виконуються по черзі згори вниз, і перше, що збіглося, визначає власника заявки.
Навантаження варто рахувати не за кількістю всіх заявок, а за кількістю активних - тих, що в роботі просто зараз. Якщо у менеджера вісім відкритих заявок, а ліміт десять, він ще в черзі; після ліміту нові запити йдуть наступному. Такий підхід рівномірніший за просту почергову роздачу, бо враховує реальну зайнятість. Графік чергування додає до цього часовий вимір: правило перевіряє, хто саме на зміні в момент надходження заявки, і не призначає запит людині у відпустці чи поза робочими годинами.
Обовʼязково потрібне правило за замовчуванням: якщо жодна умова не збіглася, заявка йде черговому менеджеру або в загальну чергу з окремим сповіщенням. Заявка без власника - найчастіша причина мовчазної втрати, тому стан «нікому не призначено» має бути технічно неможливим довше кількох хвилин.
Статуси і дедлайни: SLA-таймери на кожному етапі
Статуси і дедлайни - це каркас усього процесу. Мінімальний робочий набір статусів: нова, призначена, в роботі, очікує клієнта, виконана, закрита. Кожен статус має власний таймер: наприклад, 15 хвилин на перший контакт, 4 години на оцінку, 2 робочі дні на виконання. Таймер стартує у момент входу в статус і зупиняється при переході далі.
Важлива деталь - таймер має враховувати робочий календар. Заявка, що прийшла о 19:40 у пʼятницю, не повинна вважатися простроченою в суботу вранці, якщо у вас немає нічної зміни. Так само статус «очікує клієнта» має ставити SLA на паузу, інакше метрики покажуть провал там, де команда працювала нормально.
Переходи між статусами варто обмежити: із «нової» можна піти тільки в «призначену», а закрити заявку без етапу «виконана» система не дозволяє. Це прибирає ситуації, коли заявку закривають одним кліком, щоб вона не псувала статистику. Якщо перехід потребує причини - наприклад, відмова клієнта або дубль - причина вибирається зі списку і зберігається разом із заявкою.
Контроль виконання: ескалація прострочених заявок
Контроль виконання будується не на щоденних нарадах, а на автоматичній реакції системи. Схема ескалації зазвичай триступенева: за 20 відсотків часу до дедлайну - нагадування виконавцю, у момент прострочення - сповіщення керівнику групи, через подвійний термін - підняття пріоритету і повідомлення власнику напряму.
Ескалація повинна щось змінювати, а не просто надсилати листи. Корисні дії: автоматичне перепризначення заявки на чергового, підняття її вгору черги, блокування взяття нових заявок виконавцем, у якого висить прострочення. Інакше сповіщення швидко стають фоновим шумом, який усі ігнорують. Практика показує: якщо на ескалацію не підвʼязана жодна автоматична дія, вже за два-три тижні команда перестає її читати.
Окремо варто вести список прострочених заявок як робочу чергу, а не як звіт. Кожен пункт у ньому має закриватися дією: продовжити термін із причиною, перепризначити, повернути клієнту або закрити. Якщо причини прострочень фіксуються структуровано, за місяць видно, який саме етап треба перебудовувати.
Сповіщення клієнта на кожній зміні статусу
Сповіщення клієнта завершує цикл і знімає більшість повторних звернень. Правило просте: кожна зміна статусу, яку клієнт може відчути, супроводжується коротким повідомленням. Прийнято в роботу, призначено виконавця, названо термін, виконано, закрито - пʼять точок, яких достатньо в більшості випадків. Текст сповіщення має вміщатися в два речення і містити відповідь на головне питання клієнта: що відбувається і коли буде результат.
Повідомлення краще надсилати тим каналом, звідки прийшла заявка, і додавати номер звернення - так клієнт відповідає в той самий тред, а відповідь автоматично прикріплюється до заявки. Якщо термін зміщується, сповіщення про це має йти до дедлайну, а не після нього: попереджена затримка сприймається спокійно, виявлена - як зрив.
Зібраний разом, цей цикл дає передбачуваний процес: заявка не губиться на вході, завжди має власника, живе за таймерами і сама сигналить про проблеми. У Devlly ми будуємо такі системи під конкретні процеси компанії - з вашими правилами розподілу, статусами і термінами, а не за універсальним шаблоном.