П'ять скриньок - це не п'ять каналів - це п'ять місць, де втрачається запит
Кожен канал має власну логіку сповіщень. Форма надсилає e-mail одній людині. Messenger сповіщає в додатку, який працівник перевіряє рідше, ніж пошту. Телефон залишає лише номер на дисплеї, якщо ніхто не відповість. E-mail чекає в скриньці, доки хтось його не відкриє. Жоден з цих каналів не знає про інші. Те саме питання може прийти три рази, а відповідь може не прийти зовсім. Йдеться про автоматизацію обробки запитів, яка збирає ці п'ять входів в одне місце. Кожне звернення там отримує власника та термін відповіді.
- Кожен канал має свого власника
- Статус звернення знає лише той, хто його бачив
- Час реакції ніде не рахується
- Відсутність однієї людини зупиняє канал
- Всі канали потрапляють в одне місце
- Кожне звернення має стан та власника
- Час реакції рахує система
- Відсутність реакції підвищує ескалацію
Чому це не теоретична проблема
Згідно з нашими даними, запит у цих компаніях ніде не записується.
Жодна з них не має власного місця для запиту. Перш ніж компанія додасть ще один канал контакту, варто перевірити, чи має вона хоча б одне місце, в якому запит записується.
Як виглядає черга: тригер → маршрутизація → SLA → ескалація
Звернення з форми, телефону, Messenger або e-mail спочатку потрапляє до тригера. Це правило, яке його ловить та записує в одній системі. Маршрутизація вирішує, хто його отримує - конкретну людину, відділ або змінну чергу, залежно від години та теми. SLA - це термін першої відповіді, який відлічується від надходження звернення, а не від моменту, коли хтось його помітив. Ескалація вмикається, коли термін минає - звернення потрапляє до керівника або до другої людини в черзі. Цей ланцюг працює так само для телефону, як і для повідомлень у WhatsApp. Всі канали потрапляють до того самого пункту входу.
Пороги SLA встановлює фірма. Рисунок показує, що кожен рядок має стан і правило.
Хто і що реально в цьому бере участь
За тригером зазвичай стоїть CRM. Це місце, в якому запит стає записом, а не лише повідомленням. CRM для вашої компанії об'єднує форму, WhatsApp Business API, Messenger та скриньку e-mail в один перегляд звернень. Рецепція або відділ обслуговування бачить чергу з термінами замість п'яти окремих додатків. Власник отримує звіт, скільки звернень чекало довше за встановлений термін. Це завдання звітів AI, а не ще один аркуш для ручного підрахунку. Якщо компанія веде розмови переважно через месенджери, інтеграція з Messenger та WhatsApp стає пунктом входу замість форми.
- Формуляр
- Телефон
- Messenger
- CRM
- Повідомлення власника
- Ескалація
- Звіт
Скільки це коштує
Обсяг і ціна — після розмови про потреби. Основа — сама черга автоматизації запитів: тригер, маршрутизація, SLA. Решта залежить від того, скільки входів треба до неї під'єднати: кожен месенджер, пошта та форма на сайті — окрема робота, бо кожен по-своєму віддає дані. Правила призначення та ескалації в CRM — наступний відрізок: без них черга є, але за неї ніхто не відповідає. Компанія додає лише ті канали, які фактично має, — тому обсяг не можна назвати заздалегідь, до розмови.
Що ламається і хто це ремонтує
Дублікати - найчастіша помилка. Той самий запит потрапляє з форми та з Messenger, бо клієнт написав в двох місцях. Без правила дедуплікації тригер створює два записи, а дві людини дзвонять тому самому клієнтові. WhatsApp Business API має ліміти повідомлень до нових номерів. Після перевищення денного ліміту інтеграція перестає надсилати сповіщення, а помилку видно лише в логах постачальника. Вкладення найчастіше втрачаються при переадресації з e-mail до CRM, якщо інтеграція копіює лише посилання на файл, а не сам файл. Посилання перестає діяти, і вкладення зникає. За ці аварії відповідає той, хто підтримує інтеграцію. Варто заздалегідь визначити, чи це ІТ-відділ клієнта, чи виконавець автоматизації.
Коли цього не робити
Компанія з невеликим обсягом запитів, де одна людина бачить всі звернення, не потребує маршрутизації або ескалації. Вартість такої черги тоді перевищить ефект. Те саме стосується компаній, які обслуговують клієнтів лише одним каналом - там проблема лежить деінде, а не в кількості скриньок. Ми при цьому не обіцяємо конкретну кількість відновлених запитів або конкретне скорочення часу відповіді - цього ніхто чесно не гарантує. Ми гарантуємо структуру: одне місце входу, одного власника звернення та видимий термін відповіді замість здогадки.
FAQ
Чи можна автоматизацією обробки запитів замінити працівника?
Ні. Тригер і маршрутизація переносять звернення до правильної людини, а відповідь все ще пише людина. Автоматизація скорочує час між надходженням запиту та моментом, коли хтось його бачить.
Що, якщо ми маємо лише форму і телефон, без месенджерів?
Черга працює і при двох каналах. Інтеграція з e-mail часто достатня як перший крок, перш ніж додадуться наступні канали.
Чи потрібно міняти CRM, щоб це впровадити?
Не завжди. Тригер і маршрутизацію можна підключити до існуючої системи, якщо вона має API. Заміна CRM - це окреме рішення, не пов'язане з самою чергою звернень.
Як довго триває впровадження?
Залежить від кількості каналів та від того, чи CRM вже існує. Ми не вказуємо тут термін без знання конкретної компанії - це перше питання, яке ми з'ясовуємо в розмові.
Що відбувається із запитом після перевищення SLA?
Ескалація переносить його до керівника або на другу людину в черзі, згідно з правилом маршрутизації. Звернення не зникає - змінює власника і позначається як прострочене.
Поговорімо про автоматизацію обробки запитів для вашої компанії у Варшаві.