Великі команди: доступ за роллю, а не одна стрічка на всю компанію

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

Сторінка не обіцяє окремий кластер, сертифікат або відсоток доступності. Це питання договору та контуру, їх підтверджують окремо. Тут — як влаштований доступ та обмін подіями, коли команд уже кілька.

ПочатиДокладніше
  1. 01
    Зайві очі на чужому діалозі

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

  2. 02
    Немає сліду, хто змінив правило

    сценарій або права змінили, а через тиждень ніхто не може сказати, навіщо. Помилку шукають по пам'яті.

  3. 03
    Подія не доходить до системи обліку

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

  4. 04
    Один ключ на всіх

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

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

Спільна стрічка, яка допомагала одній зміні, на кількох відділах починає заважати:

  1. 01

    Зайві очі на чужому діалозі

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

  2. 02

    Немає сліду, хто змінив правило

    сценарій або права змінили, а через тиждень ніхто не може сказати, навіщо. Помилку шукають по пам'яті.

  3. 03

    Подія не доходить до системи обліку

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

  4. 04

    Один ключ на всіх

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

Ключові сценарії volbor для кількох команд

Межа проводиться до того, як у продукт пускають другий відділ.

  1. 01

    1. Роль бачить лише свою чергу

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

  2. 02

    2. Папки відокремлюють лінії, не ховають діалог

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

  3. 03

    3. Подія надходить у вашу систему

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

  4. 04

    4. Підрядник працює у своєму контурі

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

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

Знову арифметика, не аудит і не бенчмарк. Припустимо, в компанії 8 осіб мають повний доступ до діалогів, хоча відповідають лише 3 лінії. Один зайвий експорт або пересланий фрагмент листування — це не «відсоток ризику з дослідження», а конкретний діалог, який побачили поза чергою. Якщо на розбір такого випадку в керівника йде 3 години, а його година коштує $70, один інцидент коштує близько $210 тільки часу розбору, без наслідків для клієнта [1]. Ролі не обнуляють цей ризик. Вони прибирають причину, через яку повний доступ стоїть за замовчуванням у тих, кому він не потрібен для відповіді.

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

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

Це окреме встановлення продукту?

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

Чим це відрізняється від сторінки для зростаючої команди?

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

Чи можна віддати інтеграцію своїй команді розробки?

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

Що робити з людиною, яка пішла з компанії?

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

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

Ні. Перша межа — одна лінія, яка вже відповідає клієнтам, і одна система, яка має отримати подію. Другий відділ додають, коли в першого ролі вже не дорівнюють «доступ до всього».

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

Великій команді важлива межа доступу та підтвердження, що подія дійшла до обліку.

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

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

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

  1. [1]
    Близько $210 часу керівника на розбір одного випадку зайвого доступу.

    3 години × $70 за годину = $210. Це вартість часу в прикладі, без оцінки збитків клієнту і без вибірки інцидентів.