volbor

Шукаєте щось?

↑↓навігаціяEnterвідкритиEscзакрити

Оберіть мову

Почати

Зростаючі компанії: одна черга замість особистих чатів співробітників

Поки відповідала одна людина, листування жило в її телефоні. Під час зростання в зміні вже двоє чи троє, каналів кілька, а клієнт не знає, хто веде його питання. Заявка з віджета, месенджера та пошти розходиться по людях. volbor у цей момент потрібен як спільна черга: діалог видно зміні, у нього є власник, а повторне запитання не починає історію наново.

Має сенс підключати не «всі інтеграції», а правило передачі: хто бере нову заявку, що вважається відповіддю і коли діалог переходить наступному.

ПочатиДокладніше
  1. 01
    Дві відповіді на одну заявку

    клієнт написав у віджет та в месенджер. Два співробітники відповідають різним текстом, тому що не бачать чужого чату.

  2. 02
    Заявка без власника

    повідомлення лежить у спільному каналі. Кожен думає, що візьме інший. Клієнт чекає довше, ніж триває сама відповідь.

  3. 03
    Втрата контексту на стику зміни

    ранкова домовленість не записана. Вечірній співробітник запитує те саме ще раз.

  4. 04
    Термін відповіді не видно

    керівник дізнається про затримку зі скарги, а не з черги. Поки немає спільного списку, «ми швидко відповідаємо» не можна перевірити.

З якими втратами стикається зміна з кількох людей

Зростання ламає схему «власник усе пам'ятає»:

  1. 01

    Дві відповіді на одну заявку

    клієнт написав у віджет та в месенджер. Два співробітники відповідають різним текстом, тому що не бачать чужого чату.

  2. 02

    Заявка без власника

    повідомлення лежить у спільному каналі. Кожен думає, що візьме інший. Клієнт чекає довше, ніж триває сама відповідь.

  3. 03

    Втрата контексту на стику зміни

    ранкова домовленість не записана. Вечірній співробітник запитує те саме ще раз.

  4. 04

    Термін відповіді не видно

    керівник дізнається про затримку зі скарги, а не з черги. Поки немає спільного списку, «ми швидко відповідаємо» не можна перевірити.

Ключові сценарії volbor для зростаючої зміни

Черга, призначення та ескалація — це один контур, а не три проєкти.

  1. 01

    1. Усі входи в одному Inbox

    Єдиний Inbox збирає сайт, месенджери та пошту в одну стрічку. Співробітник відкриває діалог і бачить попередні репліки, а не лише останнє повідомлення у своєму застосунку.

  2. 02

    2. Черга та призначення

    Маршрутизація віддає нову заявку вільній людині або потрібній лінії: продажі, запис, підтримка. Без цього спільний чат залишається дошкою, на якій кожен вибирає зручне.

  3. 03

    3. Термін, після якого діалог не можна ховати

    Таймери SLA показують, яке звернення чекає довше правила. Правило задаєте ви: наприклад, перша відповідь у робочу годину не довше 15 хвилин. Таймер не покращує сервіс сам. Він робить прострочення видимим до скарги клієнта.

  4. 04

    4. Повторний клієнт не заводиться наново

    Профіль клієнта зберігає канал, домовленість і відкрите запитання. Новий співробітник у зміні продовжує діалог, а не просить представитися ще раз.

Економіка на одному прикладі

Це арифметика одного тижня, не дослідження і не середня по ринку. Припустимо, зміна з трьох людей втрачає 10 заявок на тиждень, тому що їх взяли двоє одразу або не взяв ніхто. Якщо 4 з цих 10 стали б замовленням із середнім чеком $120, тиждень коштує близько $480, місяць — близько $1 920 [1]. Спільна черга не гарантує ці замовлення: вона прибирає ситуацію, в якій заявка не має власника. Перевіряти потрібно частку діалогів із призначеною людиною та частку перших відповідей у межах вашого правила, а не «зростання конверсії після впровадження платформи».

Якщо заявки і раніше не втрачалися, а сперечалися лише про текст відповіді, Inbox сам по собі виручки не додасть. Тоді спочатку фіксують скрипт, потім чергу.

Часті запитання

Нам ще зарано для спільної черги?

Якщо відповідає одна людина і канал один, почніть зі сценарію для малого бізнесу. Черга потрібна, коли другий співробітник не бачить листування першого.

Чи потрібно підключати CRM у перший день?

Ні. Спочатку одна стрічка та правило, хто бере нову заявку. Профіль і поля мають сенс, коли діалог живе довше однієї зміни і його потрібно знайти через тиждень.

Як не потонути в налаштуванні всіх каналів?

Підключіть канал із найбільшою кількістю звернень та одну лінію. Інші канали додають, коли в черзі вже є власник і термін.

Що вважати відповіддю?

Першу змістовну репліку людині, а не автовідповідь «ми отримали повідомлення». Інакше таймер закривається, а клієнт усе ще чекає на суть.

Чи можна залишити особисті месенджери співробітників?

Як особистий канал співробітника — ні, якщо цей чат обіцяє клієнту відповідь компанії. Інакше домовленість знову залишиться в одному телефоні. Особистий номер може бути входом, але діалог повинен потрапити до спільної черги.

Корисні посилання та пов'язані рішення

Зростаючій зміні потрібен спільний список справ, а не ще один бот поруч зі старими чатами.

  • Єдиний InboxНавіщо потрібно: бачити сайт і месенджери в одній стрічці зміни.
    Що буде, якщо не впровадити: два співробітники дадуть відповідь на одну заявку по-різному.
  • Маршрутизація командиНавіщо потрібно: у нової заявки з'являється власник, а не спільне «хтось візьме».
    Що буде, якщо не впровадити: звернення чекатиме, поки хтось помітить його у спільному чаті.
  • Таймери SLAНавіщо потрібно: побачити прострочення до того, як клієнт напише повторно.
    Що буде, якщо не впровадити: про швидкість відповіді дізнаються зі скарги.
  • Профіль клієнтаНавіщо потрібно: не запитувати наново те, що вже сказали вчора іншій зміні.
    Що буде, якщо не впровадити: історія залишиться в пам'яті одного співробітника.
  • АналітикаНавіщо потрібно: перевірити частку діалогів із власником та перших відповідей у межах правила.
    Що буде, якщо не впровадити: черга є, а зрозуміти, чи допомагає вона, не можна.
  • Малий бізнесНавіщо потрібно: якщо команда ще відповідає наодинці й спільний Inbox зарано.
    Що буде, якщо не впровадити: налаштування почнеться з ролей, яких у зміні немає.
  • Великі командиНавіщо потрібно: коли черг кілька і доступ до чужих діалогів уже не можна давати всім.
    Що буде, якщо не впровадити: зростання закінчиться однією спільною стрічкою на всі відділи.

Як пораховано

Звідки цифра в прикладі

  1. [1]
    Близько $1 920 на місяць, якщо 4 з 10 втрачених за тиждень заявок стали б замовленням по $120.

    4 замовлення на тиждень × $120 × 4 тижні = $1 920. Умова прикладу задана в абзаці: 10 заявок без власника, 4 з них конвертувалися б. Не замір продукту і не середня по ринку.