11.3. Пріоритети звернень
Потрібно передбачити пріоритети:
- низький;
- звичайний;
- високий;
- критичний;
- аварійний.
Критичні звернення повинні мати окремі правила сповіщення, ескалації та контролю строків виконання.
11.4. SLA та строки виконання
Потрібно передбачити налаштування SLA:
- час першої відповіді;
- час взяття в роботу;
- час виконання;
- час реакції для критичних звернень;
- дедлайни;
- автоматичні нагадування;
- ескалації керівнику;
- контроль прострочених звернень;
- звіти по виконанню SLA.
12. Перетворення звернення на баг-репорт
K2 Chat повинен дозволяти створювати баг-репорт на основі повідомлення або звернення.
Баг-репорт повинен містити:
- номер звернення;
- автора звернення;
- дату створення;
- текст повідомлення;
- прикріплені файли;
- скриншоти;
- голосові повідомлення;
- транскрибації;
- записи дзвінків;
- записи відеоконференцій;
- посилання на чат;
- посилання на ERP-об’єкт;
- модуль K2 ERP;
- опис помилки;
- очікувану поведінку;
- фактичну поведінку;
- пріоритет;
- відповідального розробника;
- статус обробки;
- історію змін;
- відповідь користувачу після виправлення.
12.1. Зворотна відповідь користувачу
Після опрацювання баг-репорту система повинна дозволяти:
- автоматично повідомити користувача;
- написати ручну відповідь;
- повідомити про виправлення;
- повідомити про включення в оновлення;
- повідомити про неможливість відтворення помилки;
- запросити додаткові дані;
- закрити звернення після підтвердження.
13. Інтеграція з ERP-об’єктами
K2 Chat повинен мати можливість передавати в чат інформацію з ERP.
Потрібно передбачити передачу таких об’єктів:
- документ;
- рахунок;
- акт;
- накладна;
- замовлення;
- договір;
- контрагент;
- контакт;
- лід;
- клієнт;
- задача;
- проєкт;
- баг-репорт;
- складська операція;
- платіж;
- заявка;
- звернення;
- курс навчання;
- співробітник;
- підрозділ;
- файл із VDoc;
- запис історії змін;
- відеозапис;
- аудіозапис;
- транскрибація;
- протокол зустрічі.
Приклад: менеджер може надіслати в чат картку ліда, бухгалтер — рахунок, розробник — баг-репорт, керівник — задачу, а служба підтримки — звернення клієнта.
13.1. Формат ERP-картки в чаті
ERP-об’єкт у чаті повинен відображатися як компактна картка.
Картка повинна містити:
- тип об’єкта;
- назву або номер;
- короткий опис;
- статус;
- відповідального;
- дату створення;
- суму, якщо це фінансовий документ;
- контрагента, якщо є;
- кнопку відкриття об’єкта;
- кнопку копіювання посилання;
- службові права доступу.
13.2. Права доступу до ERP-об’єктів
Якщо користувач отримав у чаті посилання на ERP-об’єкт, система повинна перевірити його права.
Потрібно передбачити:
- доступ дозволено;
- доступ заборонено;
- доступ тільки на перегляд;
- доступ тільки до частини даних;
- запит доступу;
- логування спроби доступу;
- повідомлення адміністратору при порушенні політики безпеки.
Важливо: передача посилання на ERP-об’єкт у чаті не повинна автоматично відкривати доступ до цього об’єкта. Доступ визначається ролями та правами K2 ERP.
14. Інтеграція з іншими месенджерами
K2 Chat повинен мати можливість комунікації з іншими месенджерами та каналами.
Потрібно передбачити інтеграції з:
- Telegram;
- Slack;
- Viber;
- WhatsApp;
- Facebook Messenger;
- Instagram Direct;
- Email;
- SMS;
- телефонією;
- зовнішніми Helpdesk-системами;
- зовнішніми CRM;
- webhook-сервісами.
14.1. Принцип інтеграції
Інтеграція повинна працювати через:
- API;
- webhook;
- ботів;
- поштові шлюзи;
- інтеграційні токени;
- черги повідомлень;
- налаштування каналів зв’язку.
14.2. Логіка маршрутизації повідомлень
Система повинна дозволяти налаштовувати правила:
- з якого каналу прийшло повідомлення;
- у який чат його направити;
- якому оператору призначити;
- чи створювати звернення Helpdesk;
- чи створювати лід у CRM;
- чи створювати баг-репорт;
- чи відправляти автоматичну відповідь;
- чи дублювати повідомлення в інший канал;
- чи потрібно зберегти вкладення;
- чи потрібно зробити транскрибацію голосу;
- чи потрібно призначити пріоритет.
Розширення: K2 Chat може стати єдиним центром комунікацій компанії, де повідомлення з сайту, месенджерів, email, CRM, телефонії та ERP збираються в одному інтерфейсі.
15. API модуля K2 Chat
K2 Chat повинен мати відкритий API для інтеграції з іншими системами та створення клієнтських додатків.
API повинен дозволяти:
- авторизувати користувача;
- отримувати список чатів;
- отримувати повідомлення;
- відправляти повідомлення;
- редагувати повідомлення;
- видаляти або позначати повідомлення як видалене;
- створювати групи;
- додавати учасників;
- видаляти учасників;
- створювати канали;
- створювати опитування;
- отримувати список користувачів;
- отримувати статуси користувачів;
- завантажувати файли;
- отримувати файли;
- відправляти голосові повідомлення;
- отримувати транскрибації;
- створювати відеоконференції;
- отримувати записи відеоконференцій;
- створювати звернення Helpdesk;
- створювати баг-репорти;
- передавати ERP-об’єкти;
- працювати з webhook;
- працювати з міжхмарними повідомленнями;
- отримувати службові події.
15.1. API для веб-додатку
Для веб-додатку потрібно передбачити:
- REST API для стандартних операцій;
- WebSocket або аналогічний механізм для повідомлень у реальному часі;
- механізм повторного підключення;
- кешування останніх повідомлень;
- пагінацію історії;
- контроль прав доступу;
- захист від масових запитів;
- логування помилок.
15.2. API для зовнішніх додатків
Для зовнішніх додатків потрібно передбачити:
- токени доступу;
- refresh-токени;
- обмеження прав API-користувача;
- обмеження швидкості запитів;
- журнал API-звернень;
- відкликання токенів;
- окремі права для ботів;
- документацію API;
- тестове середовище.
16. WebSocket та повідомлення в реальному часі
K2 Chat повинен підтримувати доставку повідомлень у реальному часі.
Потрібно передбачити:
- миттєву доставку повідомлень;
- індикатор набору тексту;
- статус доставки;
- статус прочитання;
- оновлення списку чатів;
- оновлення кількості непрочитаних повідомлень;
- push-події для веб-клієнта;
- автоматичне перепідключення при обриві зв’язку;
- чергу недоставлених повідомлень;
- синхронізацію після відновлення з’єднання.
17. Масштабованість
K2 Chat повинен бути розрахований на велику кількість користувачів і переписки.
Потрібно передбачити:
- одночасну роботу великої кількості користувачів;
- велику кількість чатів;
- велику кількість повідомлень;
- зберігання великих історій переписки;
- індексацію повідомлень для пошуку;
- архівацію старих повідомлень;
- оптимізацію завантаження історії;
- пагінацію повідомлень;
- горизонтальне масштабування сервісів;
- розділення сервісу повідомлень і сервісу файлів;
- розділення сервісу повідомлень і сервісу відео;
- моніторинг навантаження;
- обмеження розміру вкладень;
- обмеження частоти повідомлень при потребі.
Важливо для великих клієнтів: модуль повинен стабільно працювати при великій кількості співробітників, клієнтів, каналів, Helpdesk-звернень, файлів, відеозаписів та інтеграцій.
18. Зберігання даних
Усі дані K2 Chat повинні зберігатися на сервері тієї хмари K2 ERP, де встановлений модуль.
Потрібно зберігати:
- повідомлення;
- чати;
- групи;
- канали;
- учасників;
- права доступу;
- файли;
- вкладення;
- голосові повідомлення;
- записи дзвінків;
- записи відеоконференцій;
- записи стрімів;
- транскрибації;
- реакції;
- треди;
- опитування;
- нотатки;
- історію редагування;
- історію видалення;
- Helpdesk-звернення;
- баг-репорти;
- службові події;
- API-журнали;
- міжхмарні повідомлення;
- дані інтеграцій;
- налаштування безпеки;
- ключі інтеграцій, у захищеному вигляді;
- журнали аудиту.
18.1. Історія змін
Потрібно передбачити історію змін для:
- повідомлень;
- груп;
- каналів;
- прав доступу;
- звернень Helpdesk;
- баг-репортів;
- інтеграцій;
- налаштувань безпеки;
- транскрибацій;
- записів;
- опитувань;
- нотаток.
18.2. Видалення повідомлень
Для корпоративної безпеки бажано використовувати логічне видалення.
Потрібно передбачити:
- позначення повідомлення як видаленого;
- збереження службового запису про видалення;
- збереження автора видалення;
- збереження дати видалення;
- можливість приховати повідомлення від звичайних користувачів;
- можливість перегляду аудиту адміністратором із відповідними правами.
19. Файли та вкладення
K2 Chat повинен підтримувати роботу з файлами.
Потрібно передбачити:
- завантаження файлів;
- відправку файлів у чат;
- перегляд файлів;
- завантаження файлів користувачем;
- обмеження розміру файлу;
- обмеження типів файлів;
- антивірусну перевірку, якщо така інтеграція підключена;
- зв’язок файлу з VDoc;
- історію файлів;
- заборону фізичного видалення важливих файлів при відповідних налаштуваннях;
- позначення файлу як неактивного через механізми K2 ERP;
- контроль прав доступу до файлів.
Інтеграція з VDoc: файли, що мають юридичне, технічне або бізнес-значення, можуть зберігатися і контролюватися через механізми VDoc із версіями, історією та обмеженням видалення.
20. Голосові повідомлення, запис голосу та транскрибація
K2 Chat повинен підтримувати не тільки текстову переписку, а й повноцінну голосову комунікацію: голосові повідомлення, голосові дзвінки, запис голосу, транскрибацію та пошук по розшифрованому тексту.
20.1. Голосові повідомлення
K2 Chat повинен підтримувати можливість запису, передачі, зберігання та прослуховування голосових повідомлень.
Потрібно передбачити:
- запис голосового повідомлення з веб-інтерфейсу;
- запис голосового повідомлення з мобільного або зовнішнього додатку через API;
- відправку голосового повідомлення в особистий чат;
- відправку голосового повідомлення в груповий чат;
- відправку голосового повідомлення в канал, якщо це дозволено правами;
- збереження голосового повідомлення на сервері хмари K2 ERP;
- відтворення голосового повідомлення в інтерфейсі чату;
- паузу, перемотування та повторне прослуховування;
- відображення тривалості голосового повідомлення;
- обмеження максимальної тривалості повідомлення;
- обмеження розміру аудіофайлу;
- контроль прав доступу до голосового повідомлення;
- журналювання факту створення, редагування або видалення голосового повідомлення;
- можливість прикріпити голосове повідомлення до Helpdesk-звернення, задачі, баг-репорту, ліда, контакту, документа або іншого ERP-об’єкта.
Важливо: голосові повідомлення повинні зберігатися в тій самій хмарі K2 ERP, де працює модуль K2 Chat, якщо адміністратор явно не налаштував інший захищений сценарій зберігання.
20.2. Транскрибація голосових повідомлень
Потрібно передбачити автоматичну транскрибацію голосових повідомлень у текст.
Транскрибація повинна дозволяти:
- перетворювати голосове повідомлення в текст;
- зберігати текстову розшифровку поруч із голосовим повідомленням;
- виконувати пошук по транскрибованому тексту;
- копіювати текст транскрибації;
- редагувати текст транскрибації користувачем із відповідними правами;
- зберігати історію змін транскрибації;
- визначати мову повідомлення, якщо це підтримується сервісом транскрибації;
- підтримувати українську мову як пріоритетну;
- підтримувати кілька мов для міжнародного використання;
- передавати транскрибацію в Helpdesk-звернення;
- передавати транскрибацію в задачу;
- передавати транскрибацію в баг-репорт;
- передавати транскрибацію в CRM-картку ліда, контакту або контрагента;
- використовувати транскрибацію для подальшого аналізу, пошуку та автоматизації.
Практична цінність: транскрибація дозволяє не втрачати зміст голосових повідомлень, швидко знаходити потрібну інформацію через пошук і перетворювати усні домовленості на задачі, баг-репорти або записи CRM.
20.3. Запис голосових дзвінків
K2 Chat повинен підтримувати можливість голосових дзвінків між користувачами та їх запису, якщо це дозволено налаштуваннями безпеки і правами доступу.
Потрібно передбачити:
- голосовий дзвінок між двома користувачами;
- груповий голосовий дзвінок;
- запис голосового дзвінка;
- збереження запису на сервері хмари K2 ERP;
- прив’язку запису до чату;
- прив’язку запису до Helpdesk-звернення;
- прив’язку запису до CRM-картки клієнта;
- прив’язку запису до задачі або баг-репорту;
- автоматичну транскрибацію запису;
- пошук по транскрибованому тексту;
- контроль доступу до запису;
- журналювання факту початку, завершення та запису дзвінка;
- попередження учасників про запис розмови.
Критична вимога: запис голосового дзвінка повинен виконуватися тільки згідно з налаштуваннями безпеки, правами користувачів і правилами компанії. Учасники повинні бачити, що розмова записується.
21. Відеоконференції, запис зустрічей і стрімінг
21.1. Відеоконференції
K2 Chat повинен підтримувати створення відеоконференцій для користувачів K2 ERP.
Потрібно передбачити:
- створення відеоконференції з особистого чату;
- створення відеоконференції з групового чату;
- створення відеоконференції з каналу;
- створення відеоконференції з Helpdesk-звернення;
- створення відеоконференції з задачі;
- створення відеоконференції з CRM-картки клієнта;
- створення відеоконференції з документа або ERP-об’єкта;
- запрошення учасників;
- підключення за посиланням;
- підключення авторизованих користувачів K2 ERP;
- підключення зовнішніх гостей за дозволом;
- очікувальну кімнату для гостей;
- керування мікрофоном;
- керування камерою;
- демонстрацію екрана;
- демонстрацію вікна або вкладки браузера;
- текстовий чат під час конференції;
- реакції під час конференції;
- список учасників;
- ролі модератора, доповідача та слухача;
- видалення учасника з конференції;
- блокування повторного входу небажаного учасника;
- завершення конференції модератором.
21.2. Запис відеоконференції
Потрібно передбачити запис відеоконференції.
Запис повинен включати:
- відео учасників;
- звук;
- демонстрацію екрана;
- чат конференції;
- службову інформацію про учасників;
- час початку;
- час завершення;
- тривалість;
- автора запису;
- модератора конференції.
Після завершення запису система повинна:
- зберегти запис у хмарі K2 ERP;
- прив’язати запис до чату;
- прив’язати запис до задачі, звернення, документа або CRM-картки, якщо конференція була створена з відповідного об’єкта;
- створити текстову транскрибацію зустрічі;
- дозволити пошук по транскрибації;
- дозволити перегляд запису користувачам із відповідними правами;
- дозволити завантаження запису, якщо це дозволено адміністратором;
- дозволити обмеження строку зберігання запису;
- вести журнал доступу до запису.
Важливо: запис відеоконференції може містити конфіденційну бізнес-інформацію, тому доступ до нього повинен регулюватися правами K2 ERP, політиками безпеки та журналом аудиту.
21.3. Транскрибація відеоконференцій
Потрібно передбачити автоматичну транскрибацію відеоконференцій.
Транскрибація повинна дозволяти:
- перетворювати мову учасників у текст;
- розділяти текст за учасниками, якщо це технічно можливо;
- визначати часові мітки;
- швидко переходити від тексту до відповідного моменту запису;
- шукати по тексту зустрічі;
- формувати короткий підсумок зустрічі;
- формувати список домовленостей;
- формувати список задач;
- формувати список ризиків;
- формувати список питань, які залишились відкритими;
- передавати задачі в K2 Projects або інший модуль задач;
- передавати баги в K2 Mantis або баг-трекінг;
- передавати комерційні домовленості в CRM;
- передавати технічні рішення в VDoc або базу знань.
Розширена можливість: на основі транскрибації відеоконференції система може автоматично готувати протокол зустрічі, список задач, відповідальних і дедлайнів.
21.4. Відеоконференції для великої кількості користувачів
K2 Chat повинен підтримувати окремий режим масштабних відеоконференцій і трансляцій для великої кількості учасників.
Потрібно передбачити два режими:
- інтерактивна відеоконференція — для обмеженої кількості активних учасників із камерою, мікрофоном і демонстрацією екрана;
- стрімінг або вебінар — для великої кількості глядачів, зокрема для сотень або тисяч користувачів.
21.5. Режим стрімінгу
Режим стрімінгу повинен дозволяти проводити онлайн-події з великою кількістю глядачів.
Потрібно передбачити:
- створення стрімінгової події;
- підключення тисяч користувачів у режимі перегляду;
- одного або кількох ведучих;
- модераторів;
- чат глядачів;
- питання від глядачів;
- модерацію питань;
- реакції;
- опитування;
- демонстрацію презентації;
- демонстрацію екрана;
- запис трансляції;
- транскрибацію трансляції;
- збереження запису в хмарі K2 ERP;
- обмеження доступу за ролями;
- доступ за запрошенням;
- публічний або приватний режим;
- статистику переглядів;
- список учасників;
- звіт по активності;
- експорт списку учасників;
- інтеграцію з навчальним модулем K2;
- інтеграцію з CRM;
- інтеграцію з подіями, курсами або презентаціями.
Сценарії використання стрімінгу: навчання користувачів K2 ERP, презентації для клієнтів, вебінари для бухгалтерів, демонстрації оновлень, конференції партнерів, онлайн-курси, внутрішні збори великих компаній.
21.6. Архітектура відео та стрімінгу
Для відеоконференцій і стрімінгу потрібно передбачити окремий технічний контур.
Архітектура повинна підтримувати:
- WebRTC для інтерактивних відеодзвінків і конференцій;
- SFU-сервер для групових відеоконференцій;
- стрімінговий сервер для великої кількості глядачів;
- HLS або аналогічний механізм для масштабного перегляду;
- запис відеопотоку;
- збереження записів у файловому сховищі K2 ERP;
- масштабування відеосерверів;
- розділення активних учасників і глядачів;
- черги обробки записів;
- черги транскрибації;
- моніторинг якості зв’язку;
- контроль навантаження;
- резервування сервісів для критичних подій.
Технічна вимога: інтерактивна відеоконференція і стрімінг на тисячі глядачів мають різну архітектуру. Для великих подій потрібно використовувати режим трансляції, а не намагатися підключати тисячі користувачів як повноцінних відеоучасників.
22. Опитування, обране, нотатки та бокова панель чату
22.1. Опитування в чатах і каналах
Потрібно передбачити можливість створення опитувань у чатах, групах, каналах, проєктних чатах і Helpdesk-діалогах.
Опитування повинні підтримувати:
- створення опитування з чату;
- створення опитування з каналу;
- створення опитування з проєктного чату;
- створення опитування з Helpdesk-діалогу;
- один варіант відповіді;
- кілька варіантів відповіді;
- анонімне опитування;
- публічне опитування;
- завершення опитування автором або адміністратором;
- закріплення опитування в чаті;
- копіювання опитування;
- видалення або архівацію опитування;
- перегляд результатів;
- експорт результатів;
- прив’язку результатів до задачі, проєкту, курсу навчання або CRM-об’єкта.
Практична цінність: опитування дозволяють швидко приймати рішення всередині команди, збирати думку співробітників, клієнтів або учасників навчання без використання зовнішніх сервісів.
22.2. Обрані повідомлення
Користувач повинен мати можливість додавати повідомлення в обране.
Потрібно передбачити:
- додавання повідомлення в обране;
- видалення з обраного;
- перегляд усіх обраних повідомлень у межах чату;
- перегляд усіх обраних повідомлень користувача;
- пошук по обраних повідомленнях;
- фільтр обраного за чатами;
- фільтр обраного за датою;
- фільтр обраного за ERP-об’єктом.
22.3. Нотатки в чаті
Потрібно передбачити нотатки в чаті.
Нотатки можуть використовуватись для:
- фіксації домовленостей;
- коротких висновків після обговорення;
- службових приміток оператора підтримки;
- внутрішніх коментарів команди;
- підготовки відповіді клієнту;
- збереження важливих технічних деталей;
- створення майбутньої задачі або баг-репорту.
Нотатка повинна мати:
- автора;
- дату створення;
- текст;
- прив’язку до чату;
- прив’язку до повідомлення, якщо нотатка створена з повідомлення;
- права доступу;
- історію змін;
- можливість видалення або позначення як неактивної.
Важливо: нотатки можуть бути публічними для учасників чату або приватними для операторів підтримки, менеджерів чи адміністраторів.
22.4. Бокова панель чату
У кожному чаті потрібно передбачити бокову панель швидкого доступу.
Бокова панель повинна містити:
- опис чату;
- список учасників;
- адміністраторів чату;
- закріплені повідомлення;
- обрані повідомлення;
- нотатки;
- усі файли;
- усі зображення;
- усі відео;
- усі голосові повідомлення;
- усі посилання;
- усі ERP-картки;
- усі задачі, створені з чату;
- усі Helpdesk-звернення;
- усі баг-репорти;
- усі записи відеоконференцій;
- усі транскрибації.
23. Автоматичне очищення, архівація та політики зберігання
Потрібно передбачити політики зберігання повідомлень.
Адміністратор повинен мати можливість налаштувати:
- безстрокове зберігання;
- зберігання повідомлень певну кількість днів;
- автоархівацію старих повідомлень;
- автоматичне приховування старих повідомлень;
- автоматичне логічне видалення через Active=false;
- різні політики для різних чатів;
- різні політики для різних каналів;
- різні політики для Helpdesk-звернень;
- різні політики для відеозаписів;
- різні політики для голосових повідомлень;
- винятки для юридично важливих чатів;
- винятки для чатів із клієнтами;
- винятки для повідомлень, прив’язаних до ERP-документів, задач, багів або CRM.
Критична вимога: автоочищення не повинно знищувати важливі юридичні, фінансові, технічні або Helpdesk-дані без політики збереження, архівації та аудиту.
24. Проєктні чати, чати робочих груп і чат задачі
K2 Chat повинен підтримувати автоматичне створення чатів для проєктів, робочих груп, задач, спринтів, Helpdesk-звернень, баг-репортів і CRM-угод.
24.1. Чат робочої групи
Для кожної робочої групи або підрозділу потрібно передбачити окремий чат.
Потрібно передбачити:
- автоматичне створення чату робочої групи;
- автоматичне додавання учасників групи;
- автоматичне виключення користувача з чату при виході з групи;
- синхронізацію прав із робочою групою;
- зв’язок чату з документами, задачами, файлами та подіями групи;
- можливість вимкнути чат для конкретної групи;
- історію змін складу групи;
- журнал доступу до чату.
24.2. Чат проєкту
Для кожного проєкту K2 ERP потрібно передбачити проєктний чат.
Проєктний чат повинен містити:
- учасників проєкту;
- задачі проєкту;
- файли проєкту;
- обговорення проєкту;
- рішення;
- ризики;
- протоколи зустрічей;
- відеоконференції;
- записи зустрічей;
- транскрибації;
- дедлайни;
- повідомлення про зміни статусів задач.
24.3. Чат задачі
Кожна важлива задача може мати власний чат.
Чат задачі повинен дозволяти:
- обговорювати задачу без втрати контексту;
- бачити постановника;
- бачити відповідального;
- бачити спостерігачів;
- бачити дедлайн;
- бачити статус задачі;
- прикріплювати файли;
- проводити дзвінок по задачі;
- створювати підзадачі з повідомлень;
- створювати чекліст із повідомлень;
- фіксувати рішення;
- формувати короткий підсумок обговорення;
- автоматично переносити важливі повідомлення в історію задачі.
Важливо: чат задачі повинен бути не додатковим коментарем, а повноцінним робочим простором: обговорення, файли, дзвінки, рішення, підсумки, відповідальні та дедлайни.
25. Відкриті лінії, контакт-центр і робота з клієнтськими діалогами
K2 Chat повинен мати режим відкритих ліній — єдиного центру обробки повідомлень із сайту, месенджерів, соціальних мереж, email, CRM-форм, телефонії та зовнішніх каналів.
25.1. Єдиний список клієнтських діалогів
Оператор повинен бачити всі клієнтські діалоги в одному інтерфейсі.
Потрібно передбачити:
- нові діалоги;
- діалоги без відповіді;
- діалоги в роботі;
- діалоги, передані іншому оператору;
- діалоги, що очікують відповіді клієнта;
- закриті діалоги;
- прострочені діалоги;
- діалоги з високим пріоритетом;
- діалоги з VIP-клієнтами;
- діалоги з різних каналів комунікації.
25.2. Передача діалогу іншому оператору
Потрібно передбачити можливість передати діалог:
- іншому оператору;
- іншій групі підтримки;
- менеджеру з продажу;
- бухгалтеру;
- розробнику;
- тестувальнику;
- керівнику;
- зовнішньому інтегратору, якщо це дозволено правами.
Передача діалогу повинна зберігати:
- історію переписки;
- файли;
- нотатки;
- статус звернення;
- пріоритет;
- CRM-картку клієнта;
- пов’язані задачі;
- пов’язані баг-репорти;
- попереднього відповідального;
- нового відповідального;
- дату передачі;
- причину передачі.
25.3. Додавання колег у клієнтський діалог
Оператор повинен мати можливість додати колегу до діалогу.
Потрібно передбачити:
- додавання співробітника в діалог;
- згадку співробітника через @;
- внутрішній коментар без показу клієнту;
- запит консультації;
- тимчасове підключення експерта;
- видалення експерта після консультації;
- журнал підключення колег.
25.4. Приватні нотатки оператора
У клієнтському діалозі потрібно передбачити приватні нотатки.
Приватні нотатки повинні бути видимі:
- оператору;
- керівнику підтримки;
- менеджеру;
- адміністратору;
- іншим співробітникам із відповідними правами.
Клієнт не повинен бачити приватні нотатки.
Критична вимога: приватні нотатки оператора не повинні випадково відправлятися клієнту або в зовнішній месенджер.
25.5. Готові відповіді
Потрібно передбачити готові відповіді для операторів.
Готові відповіді можуть використовуватись для:
- привітання;
- уточнення контактних даних;
- запиту скриншоту;
- запиту доступу;
- повідомлення про прийняття в роботу;
- повідомлення про передачу розробнику;
- повідомлення про виправлення;
- повідомлення про оновлення;
- закриття звернення;
- типових бухгалтерських питань;
- типових технічних питань;
- типових комерційних питань.
25.6. CRM-форми в чаті
Оператор повинен мати можливість відправити клієнту CRM-форму прямо в чат.
CRM-форма може використовуватись для:
- збору контактів;
- запиту на впровадження;
- заявки на демонстрацію;
- заявки на навчання;
- реєстрації на вебінар;
- збору технічної інформації;
- оформлення звернення;
- уточнення реквізитів компанії;
- створення ліда;
- створення угоди;
- створення контакту;
- створення контрагента.
25.7. Автоматичне створення CRM-контакту
Якщо користувач звернувся з сайту, месенджера, соціальної мережі або email, система повинна перевірити наявність такого контакту в CRM.
Потрібно передбачити:
- пошук контакту за email;
- пошук контакту за телефоном;
- пошук контакту за зовнішнім ID месенджера;
- пошук контакту за соціальним профілем;
- створення нового контакту;
- створення нового ліда;
- прив’язку діалогу до існуючого контакту;
- прив’язку діалогу до контрагента;
- прив’язку діалогу до угоди;
- захист від дублювання контактів.
25.8. Статистика клієнтських діалогів
Потрібно передбачити статистику відкритих ліній.
Звіти повинні показувати:
- кількість діалогів;
- кількість нових звернень;
- кількість закритих звернень;
- середній час першої відповіді;
- середній час вирішення;
- кількість прострочених звернень;
- навантаження на операторів;
- ефективність операторів;
- популярні канали звернень;
- оцінку задоволеності клієнтів;
- кількість діалогів, що стали лідами;
- кількість діалогів, що стали задачами;
- кількість діалогів, що стали баг-репортами.
26. Зв’язок із CRM
K2 Chat повинен бути інтегрований із CRM.
Потрібно передбачити:
- створення ліда з повідомлення;
- прив’язку переписки до ліда;
- прив’язку переписки до контакту;
- прив’язку переписки до контрагента;
- створення задачі менеджеру;
- передачу історії комунікації в CRM;
- відображення CRM-картки в чаті;
- автоматичне визначення клієнта за email або телефоном;
- створення нагадування;
- передавання звернення у воронку продажів;
- збереження записів дзвінків у CRM;
- збереження транскрибацій у CRM;
- прив’язку відеоконференцій до угод або лідів.
27. Зв’язок із системою задач
З повідомлення або звернення потрібно мати можливість створити задачу.
Задача повинна містити:
- текст повідомлення;
- автора;
- чат;
- дату;
- вкладення;
- посилання на повідомлення;
- відповідального;
- дедлайн;
- пріоритет;
- статус;
- пов’язані ERP-об’єкти;
- транскрибацію, якщо задача створена з голосу або відеозустрічі;
- посилання на запис, якщо задача створена за результатами дзвінка або конференції.
28. Зв’язок із K2 Mantis або баг-трекінгом
K2 Chat повинен мати інтеграцію з баг-трекінгом.
Потрібно передбачити:
- створення багу з повідомлення;
- створення багу зі звернення Helpdesk;
- створення багу з голосового повідомлення;
- створення багу з транскрибації;
- створення багу з відеоконференції;
- прив’язку багу до клієнта;
- прив’язку багу до модуля K2 ERP;
- відправку статусу багу в чат;
- повідомлення користувача про виправлення;
- автоматичне закриття звернення після підтвердження.
29. Зв’язок із VDoc
K2 Chat повинен мати зв’язок із VDoc.
Потрібно передбачити:
- прикріплення файлу з VDoc у чат;
- створення обговорення навколо файлу;
- передавання посилання на версію документа;
- збереження історії обговорення документа;
- контроль прав доступу;
- неможливість фізичного видалення важливих документів;
- збереження протоколів зустрічей;
- збереження транскрибацій;
- збереження важливих записів відеоконференцій;
- використання Active=false для позначення неактивного або видаленого запису згідно логіки K2 ERP.
Технічна примітка: для позначення запису або файлу як неактивного в K2 ERP використовується поле Active=false, а не окреме поле deleted_mark.
30. Зв’язок із навчальним модулем K2
K2 Chat може використовуватись у навчальному модулі.
Потрібно передбачити:
- чат курсу;
- чат групи студентів;
- чат із куратором;
- питання по уроку;
- обговорення завдання;
- повідомлення про дедлайн;
- повідомлення про оцінку;
- повідомлення про сертифікат;
- звернення в підтримку навчального курсу;
- навчальні вебінари;
- стрімінгові лекції;
- запис занять;
- транскрибацію занять;
- опитування студентів;
- автоматичне створення навчальних матеріалів із записів.
31. AI-помічник у K2 Chat
K2 Chat повинен підтримувати AI-помічника для обробки повідомлень, голосу, дзвінків, задач, Helpdesk-звернень, CRM-комунікацій і підготовки відповідей.
31.1. AI-можливості в чаті
AI-помічник повинен допомагати:
- писати відповіді;
- скорочувати довгі повідомлення;
- робити підсумок переписки;
- виділяти ключові домовленості;
- виділяти задачі;
- виділяти ризики;
- виділяти питання без відповіді;
- формувати баг-репорт із переписки;
- формувати Helpdesk-відповідь;
- формувати CRM-коментар;
- формувати протокол зустрічі;
- створювати чекліст;
- перекладати повідомлення;
- покращувати стиль повідомлення;
- визначати тональність клієнта;
- визначати терміновість звернення.
31.2. Голосове розпізнавання для задач
Потрібно передбачити можливість створення задачі голосом.
Користувач може надиктувати:
- назву задачі;
- опис задачі;
- відповідального;
- дедлайн;
- пріоритет;
- чекліст;
- пов’язаний ERP-об’єкт;
- пов’язаний документ;
- пов’язаного клієнта або ліда.
Система повинна перетворити голос у структуровану задачу.
31.3. AI-аналіз дзвінків і відеоконференцій
Після дзвінка або відеоконференції AI-помічник повинен мати можливість сформувати:
- короткий підсумок;
- повну транскрибацію;
- список задач;
- список відповідальних;
- список дедлайнів;
- список домовленостей;
- список ризиків;
- список питань, що залишились відкритими;
- пропозицію тексту відповіді клієнту;
- пропозицію створення задачі;
- пропозицію створення баг-репорту;
- пропозицію створення CRM-активності.
Важливо: AI-помічник не повинен автоматично виконувати критичні дії без підтвердження користувача, якщо це впливає на документи, клієнтів, задачі, фінансові дані або права доступу.
32. Боти та автоматизація
Потрібно передбачити можливість створення ботів.
Боти можуть використовуватись для:
- автоматичних відповідей;
- створення задач;
- створення баг-репортів;
- повідомлень про оновлення K2 ERP;
- повідомлень про нові документи;
- нагадувань;
- повідомлень про дедлайни;
- контролю SLA;
- інтеграцій із зовнішніми системами;
- навчальних сценаріїв;
- збору даних від користувача;
- передачі інформації в CRM;
- запуску опитувань;
- підготовки підсумків;
- створення протоколів зустрічей.
32.1. Системні боти
Потрібно передбачити системних ботів:
- бот технічної підтримки;
- бот повідомлень ERP;
- бот задач;
- бот баг-репортів;
- бот оновлень;
- бот навчання;
- бот SLA;
- бот інтеграцій;
- бот безпеки;
- бот транскрибації;
- бот відеоконференцій;
- AI-бот.
33. Desktop-додаток, мультиакаунти та телефонія
K2 Chat повинен мати можливість роботи не тільки у браузері, а й через окремий додаток або клієнт, який може працювати з кількома хмарами K2 ERP одночасно.
33.1. Desktop-додаток
Потрібно передбачити можливість створення desktop-додатку для:
Desktop-додаток повинен підтримувати:
- особисті чати;
- групові чати;
- канали;
- Helpdesk;
- повідомлення про нові події;
- дзвінки;
- відеоконференції;
- запис дзвінків;
- роботу з файлами;
- відкриття ERP-карток;
- швидкий перехід у веб-інтерфейс K2 ERP;
- роботу у фоновому режимі;
- системні сповіщення операційної системи.
33.2. Мультиакаунти та кілька хмар
Користувач повинен мати можливість працювати з кількома хмарами K2 ERP.
Потрібно передбачити:
- підключення кількох хмар;
- швидке перемикання між хмарами;
- одночасну роботу з кількома хмарами;
- окремі сповіщення по кожній хмарі;
- окремі права доступу по кожній хмарі;
- окреме зберігання переписки в кожній хмарі;
- заборону змішування даних різних хмар;
- маркування повідомлень за хмарою;
- контроль міжхмарної безпеки.
33.3. Телефонія в чаті
Потрібно передбачити інтеграцію телефонії з K2 Chat.
Система повинна дозволяти:
- показувати телефонний дзвінок у Messenger;
- створювати окремий чат для кожного дзвінка;
- створювати єдиний чат для всіх дзвінків із клієнтом;
- не показувати телефонні дзвінки в чаті, якщо так налаштовано;
- записувати телефонний дзвінок;
- транскрибувати телефонний дзвінок;
- створювати задачу з дзвінка;
- створювати CRM-активність із дзвінка;
- створювати Helpdesk-звернення з дзвінка;
- прив’язувати дзвінок до клієнта, ліда, контакту або контрагента;
- показувати історію дзвінків у картці клієнта.
Перевага для бізнесу: телефонні дзвінки, чати, відеоконференції, Helpdesk і CRM повинні працювати як єдина історія комунікації з клієнтом.
34. Сповіщення
K2 Chat повинен мати систему сповіщень.
Потрібно передбачити:
- сповіщення в інтерфейсі K2 ERP;
- звукові сповіщення;
- push-сповіщення для веб-додатку;
- email-сповіщення;
- сповіщення в зовнішні месенджери;
- сповіщення про згадки;
- сповіщення про нові звернення;
- сповіщення про критичні баги;
- сповіщення про прострочені SLA;
- сповіщення про відповідь клієнта;
- сповіщення про зміну статусу задачі;
- сповіщення про новий ERP-об’єкт у чаті;
- сповіщення про початок відеоконференції;
- сповіщення про готовність транскрибації;
- сповіщення про готовність запису.
34.1. Налаштування сповіщень користувачем
Користувач повинен мати можливість налаштувати:
- отримувати всі сповіщення;
- отримувати тільки згадки;
- вимкнути сповіщення на певний час;
- вимкнути звук;
- вимкнути сповіщення конкретного чату;
- налаштувати робочий час;
- налаштувати режим “Не турбувати”.
35. Пошук
Потрібно передбачити потужний пошук.
Пошук повинен працювати по:
- повідомленнях;
- чатах;
- групах;
- каналах;
- користувачах;
- файлах;
- зверненнях;
- баг-репортах;
- ERP-картках;
- лідах;
- контрагентах;
- документах;
- задачах;
- тредах;
- голосових транскрибаціях;
- відеотранскрибаціях;
- нотатках;
- опитуваннях;
- протоколах зустрічей.
Фільтри пошуку:
- дата;
- автор;
- чат;
- канал;
- тип повідомлення;
- наявність файлу;
- статус звернення;
- пріоритет;
- ERP-об’єкт;
- тег;
- хмара;
- інтеграційний канал;
- наявність запису;
- наявність транскрибації;
- тип медіа.
36. Адміністративний інтерфейс
Адміністратор повинен мати можливість:
- створювати чати;
- створювати канали;
- керувати користувачами;
- керувати ролями;
- налаштовувати права;
- налаштовувати Helpdesk;
- налаштовувати SLA;
- налаштовувати інтеграції;
- налаштовувати API-доступ;
- налаштовувати міжхмарні з’єднання;
- переглядати журнали;
- переглядати статистику;
- блокувати користувачів;
- блокувати зовнішні хмари;
- відкликати токени;
- вмикати режим підвищеної безпеки;
- налаштовувати відеосервери;
- налаштовувати політики запису;
- налаштовувати політики транскрибації;
- налаштовувати правила зберігання повідомлень.
37. Безпека
K2 Chat повинен відповідати підвищеним вимогам безпеки корпоративних клієнтів.
Потрібно передбачити:
- авторизацію користувачів через K2 ERP;
- рольову модель доступу;
- контроль прав на чати;
- контроль прав на канали;
- контроль прав на файли;
- контроль прав на ERP-об’єкти;
- контроль прав на записи дзвінків;
- контроль прав на записи відеоконференцій;
- контроль прав на транскрибації;
- журнал входів;
- журнал дій користувачів;
- журнал API-запитів;
- журнал міжхмарних обмінів;
- обмеження доступу за IP, якщо потрібно;
- двофакторну автентифікацію, якщо вона підключена в K2 ERP;
- сесії користувачів;
- примусове завершення сесій;
- політики паролів;
- обмеження спроб входу;
- захист від brute-force;
- захист від XSS;
- захист від CSRF;
- захист від SQL injection;
- захист API від перевантаження.
37.1. Шифрування трафіку
Потрібно передбачити шифрування трафіку між клієнтом і сервером.
Мінімальні вимоги:
- HTTPS;
- TLS;
- захищені WebSocket-з’єднання;
- захищена передача API-запитів;
- захищена передача файлів;
- захищена передача аудіо;
- захищена передача відео;
- захищена міжхмарна комунікація.
37.2. Підвищений рівень безпеки
Для клієнтів із підвищеними вимогами до безпеки потрібно передбачити спеціальний режим.
У цьому режимі можуть використовуватися:
- посилене шифрування трафіку;
- окремі ключі хмари;
- додаткове шифрування повідомлень;
- обмеження міжхмарних повідомлень;
- обмеження інтеграцій із зовнішніми месенджерами;
- заборона передачі файлів назовні;
- заборона передачі записів назовні;
- обов’язкова двофакторна автентифікація;
- журналювання всіх дій;
- зберігання даних тільки в приватній хмарі клієнта;
- відключення зовнішніх webhook;
- контроль пристроїв користувачів.
Критична вимога: у режимі підвищеної безпеки жодна переписка, запис голосу, запис відеоконференції, транскрибація або файл не повинні передаватися у зовнішні сервіси без явного дозволу адміністратора хмари.
38. Права доступу
Потрібно передбачити гнучку систему прав доступу.
Права повинні налаштовуватись для:
- користувача;
- ролі;
- групи;
- підрозділу;
- чату;
- каналу;
- Helpdesk-черги;
- інтеграції;
- API-користувача;
- зовнішньої хмари;
- відеоконференції;
- стрімінгу;
- запису;
- транскрибації.
38.1. Приклади прав
| Право
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
39. Звіти та аналітика
Потрібно передбачити звіти:
- кількість повідомлень;
- активність користувачів;
- активність чатів;
- кількість звернень;
- кількість закритих звернень;
- середній час відповіді;
- середній час закриття звернення;
- прострочені SLA;
- завантаженість операторів;
- кількість баг-репортів;
- кількість задач із чату;
- джерела звернень;
- ефективність каналів підтримки;
- статистика міжхмарних повідомлень;
- статистика інтеграцій;
- кількість відеоконференцій;
- кількість записів;
- кількість транскрибацій;
- активність у стрімах;
- статистика переглядів вебінарів;
- оцінка задоволеності клієнтів.
40. Журнали та аудит
Потрібно вести аудит:
- входів користувачів;
- відправки повідомлень;
- редагування повідомлень;
- видалення повідомлень;
- створення чатів;
- зміни прав;
- створення Helpdesk-звернень;
- зміни статусів звернень;
- створення баг-репортів;
- API-запитів;
- міжхмарної комунікації;
- підключення зовнішніх месенджерів;
- помилок доставки;
- дій адміністраторів;
- початку дзвінків;
- завершення дзвінків;
- увімкнення запису;
- перегляду записів;
- завантаження записів;
- редагування транскрибацій;
- створення стрімінгів;
- підключення зовнішніх гостей.
Аудит є обов’язковим для корпоративного використання, оскільки чат може містити критичну бізнес-інформацію, юридично важливу переписку, записи переговорів, технічні рішення та комерційні домовленості.
41. Структура бази даних
На етапі проєктування потрібно передбачити такі основні сутності:
- chat_users;
- chat_rooms;
- chat_room_users;
- chat_messages;
- chat_message_files;
- chat_message_reactions;
- chat_threads;
- chat_channels;
- chat_channel_subscribers;
- chat_polls;
- chat_poll_answers;
- chat_notes;
- chat_favorites;
- chat_helpdesk_tickets;
- chat_ticket_statuses;
- chat_ticket_priorities;
- chat_ticket_history;
- chat_integrations;
- chat_webhooks;
- chat_api_tokens;
- chat_cloud_links;
- chat_cloud_messages;
- chat_bots;
- chat_notifications;
- chat_voice_messages;
- chat_voice_calls;
- chat_video_meetings;
- chat_video_records;
- chat_streams;
- chat_transcriptions;
- chat_audit_log;
- chat_security_settings.
41.1. Основні поля повідомлення
Повідомлення повинно містити:
- ідентифікатор;
- ідентифікатор чату;
- ідентифікатор автора;
- текст повідомлення;
- тип повідомлення;
- дата створення;
- дата редагування;
- ознака активності;
- ознака прочитання;
- відповідь на повідомлення;
- тред;
- вкладення;
- ERP-об’єкт;
- службові метадані.
42. Типи повідомлень
Потрібно передбачити такі типи повідомлень:
- текст;
- файл;
- зображення;
- голосове повідомлення;
- відеоповідомлення;
- системне повідомлення;
- ERP-картка;
- Helpdesk-звернення;
- баг-репорт;
- задача;
- повідомлення від бота;
- повідомлення з сайту;
- повідомлення з Telegram;
- повідомлення зі Slack;
- email-повідомлення;
- міжхмарне повідомлення;
- службова подія;
- запис дзвінка;
- запис відеоконференції;
- транскрибація;
- опитування;
- нотатка.
43. Інтерфейс користувача
Інтерфейс K2 Chat повинен бути зручним для великої кількості користувачів.
Основні елементи інтерфейсу:
- список чатів;
- список каналів;
- список Helpdesk-звернень;
- область повідомлень;
- поле введення повідомлення;
- кнопка запису голосу;
- кнопка прикріплення файлу;
- кнопка відправки ERP-об’єкта;
- кнопка створення задачі;
- кнопка створення баг-репорту;
- кнопка відеоконференції;
- кнопка стрімінгу;
- пошук;
- фільтри;
- панель інформації про чат;
- панель учасників;
- панель треду;
- панель пов’язаного звернення;
- панель пов’язаного ERP-об’єкта;
- бокова панель файлів, медіа, посилань і нотаток;
- налаштування сповіщень;
- статус користувача.
43.1. Інтерфейс оператора підтримки
Оператор підтримки повинен бачити:
- нові звернення;
- звернення в роботі;
- прострочені звернення;
- критичні звернення;
- історію діалогу;
- дані клієнта;
- пов’язані ERP-об’єкти;
- кнопки створення задачі;
- кнопки створення баг-репорту;
- шаблони відповідей;
- приватні нотатки;
- SLA;
- відповідального;
- статус звернення;
- записи дзвінків;
- транскрибації;
- історію попередніх звернень.
43.2. Інтерфейс адміністратора
Адміністратор повинен бачити:
- користувачів;
- ролі;
- чати;
- канали;
- інтеграції;
- API-токени;
- міжхмарні підключення;
- журнали безпеки;
- статистику;
- налаштування шифрування;
- налаштування Helpdesk;
- налаштування SLA;
- налаштування відео;
- налаштування записів;
- налаштування транскрибацій;
- налаштування стрімінгу.
44. Шаблони відповідей
Для Helpdesk потрібно передбачити шаблони відповідей.
Шаблони можуть використовуватись для:
- першої відповіді;
- запиту додаткової інформації;
- повідомлення про прийняття в роботу;
- повідомлення про передачу розробнику;
- повідомлення про виправлення;
- повідомлення про відмову;
- повідомлення про закриття звернення;
- повідомлення про оновлення системи;
- відповіді після відеозустрічі;
- відповіді після аналізу транскрибації.
45. Автоматичні правила
Потрібно передбачити механізм автоматичних правил.
Приклади правил:
- якщо звернення з сайту має тему “помилка”, створити Helpdesk-звернення;
- якщо повідомлення містить слово “критично”, встановити високий пріоритет;
- якщо клієнт прикріпив скриншот, додати його до звернення;
- якщо звернення не оброблено 30 хвилин, повідомити керівника;
- якщо баг закрито, повідомити автора звернення;
- якщо повідомлення прийшло з Telegram, направити його в потрібну чергу;
- якщо звернення від VIP-клієнта, встановити підвищений пріоритет;
- якщо завершено відеоконференцію, створити транскрибацію;
- якщо транскрибація містить домовленість, запропонувати створити задачу;
- якщо в дзвінку згадується помилка, запропонувати створити баг-репорт.
46. Надійність і відмовостійкість
Потрібно передбачити:
- чергу недоставлених повідомлень;
- повторну доставку;
- захист від дублювання повідомлень;
- резервне копіювання;
- відновлення після збою;
- контроль цілісності повідомлень;
- моніторинг сервісу;
- логування помилок;
- повідомлення адміністратора про збої;
- можливість тимчасового відключення інтеграцій;
- резервування відеосервісів;
- збереження запису конференції при нестабільному з’єднанні;
- відновлення обробки транскрибації після збою.
47. Резервне копіювання
Дані K2 Chat повинні входити в політику резервного копіювання хмари K2 ERP.
Потрібно резервувати:
- повідомлення;
- файли;
- звернення;
- баг-репорти;
- журнали;
- налаштування;
- інтеграції;
- ключі, у захищеному вигляді;
- міжхмарні зв’язки;
- голосові повідомлення;
- записи дзвінків;
- записи відеоконференцій;
- записи стрімів;
- транскрибації;
- нотатки;
- опитування.
48. Вимоги до продуктивності
Модуль повинен забезпечувати:
- швидке відкриття списку чатів;
- швидке завантаження останніх повідомлень;
- миттєву доставку нових повідомлень;
- швидкий пошук;
- стабільну роботу при великій кількості користувачів;
- оптимізовану роботу з файлами;
- стабільну роботу Helpdesk;
- стабільну роботу API;
- контроль навантаження на сервер;
- стабільну роботу голосових повідомлень;
- стабільну роботу відеоконференцій;
- масштабований стрімінг для великої кількості глядачів;
- фонову обробку транскрибацій.
49. Вимоги до сумісності
K2 Chat повинен працювати:
- у сучасних браузерах;
- у хмарі K2 ERP;
- у приватних інсталяціях K2 ERP;
- через API;
- із зовнішніми сайтами;
- із зовнішніми месенджерами через інтеграції;
- із модулями K2 ERP;
- із системою ролей K2 ERP;
- із системою файлів K2 ERP;
- із VDoc;
- із CRM;
- із Helpdesk;
- із баг-трекінгом;
- із K2 Projects;
- із навчальним модулем;
- із телефонією;
- із відеосерверами;
- із сервісами транскрибації.
50. MVP першої версії
У першій версії модуля потрібно реалізувати мінімально необхідний функціонал.
До MVP входить:
- особисті повідомлення;
- групові чати;
- канали;
- відправка файлів;
- WebSocket-повідомлення в реальному часі;
- історія переписки;
- пошук;
- базові ролі;
- базова авторизація через K2 ERP;
- Helpdesk-звернення;
- створення задачі з повідомлення;
- створення баг-репорту з повідомлення;
- віджет звернення з сайту;
- API для відправки та отримання повідомлень;
- передача ERP-картки в чат;
- журнал дій;
- базові сповіщення;
- зберігання даних у хмарі K2 ERP;
- голосові повідомлення;
- базова транскрибація голосових повідомлень;
- базові відеоконференції для невеликих груп;
- запис відеоконференції;
- збереження записів у хмарі K2 ERP;
- готові відповіді для Helpdesk;
- приватні нотатки оператора;
- обране;
- бокова панель файлів і посилань.
MVP повинен дати компанії можливість замінити частину внутрішніх комунікацій, приймати звернення з сайту, створювати задачі та баг-репорти, передавати ERP-об’єкти, записувати голос і проводити базові відеозустрічі без виходу з K2 ERP.
51. Наступні етапи розвитку
Після MVP потрібно передбачити розвиток:
- міжхмарний обмін повідомленнями;
- інтеграція з Telegram;
- інтеграція зі Slack;
- інтеграція з Email;
- інтеграція з телефонією;
- розширені боти;
- розширений Helpdesk;
- SLA;
- треди;
- теми в групах;
- розширена аналітика;
- мобільний додаток;
- десктопний додаток;
- режим підвищеної безпеки;
- шифрування повідомлень;
- інтеграція з навчальним модулем;
- інтеграція з VDoc;
- інтеграція з CRM;
- інтеграція з K2 Projects;
- стрімінг на сотні або тисячі користувачів;
- розширена транскрибація відеозустрічей;
- AI-помічник;
- автоматичні протоколи зустрічей;
- автоматичне створення задач із транскрибацій.
52. Критерії приймання
Модуль вважається прийнятим, якщо:
- Користувач може увійти в K2 Chat через K2 ERP.
- Користувач може створити особистий чат.
- Користувач може створити груповий чат.
- Користувач може створити канал.
- Користувач може відправити повідомлення.
- Користувач може прикріпити файл.
- Повідомлення доставляється в реальному часі.
- Історія повідомлень зберігається на сервері хмари K2 ERP.
- Користувач може знайти повідомлення через пошук.
- Адміністратор може керувати правами.
- Відвідувач сайту може створити звернення через віджет.
- Оператор бачить звернення в Helpdesk.
- Зі звернення можна створити задачу.
- Зі звернення можна створити баг-репорт.
- Користувач отримує відповідь по зверненню.
- У чат можна передати ERP-об’єкт.
- Доступ до ERP-об’єкта перевіряється правами K2 ERP.
- API дозволяє відправляти та отримувати повідомлення.
- Дії користувачів логуються.
- Передача даних відбувається через захищене з’єднання.
- Користувач може записати голосове повідомлення.
- Система може створити транскрибацію голосового повідомлення.
- Користувач може створити відеоконференцію.
- Система може записати відеоконференцію.
- Запис відеоконференції зберігається в хмарі K2 ERP.
- Транскрибація доступна для пошуку.
- Оператор може використати готову відповідь.
- Оператор може створити приватну нотатку.
- Користувач може додати повідомлення в обране.
- Адміністратор може налаштувати політики зберігання.
53. Очікуваний результат
У результаті розробки компанія повинна отримати модуль K2 Chat, який:
- працює всередині K2 ERP;
- підтримує велику кількість користувачів;
- зберігає переписку в хмарі K2 ERP;
- дозволяє створювати чати, групи та канали;
- підтримує Helpdesk;
- приймає звернення з сайту;
- створює задачі та баг-репорти;
- передає інформацію з ERP у чат;
- інтегрується з іншими месенджерами;
- підтримує API;
- підтримує міжхмарну комунікацію;
- забезпечує аудит і контроль;
- підтримує голосові повідомлення;
- підтримує запис і транскрибацію голосу;
- підтримує відеоконференції;
- підтримує запис і транскрибацію відеозустрічей;
- підтримує стрімінг для великої кількості користувачів;
- підтримує відкриті лінії та контакт-центр;
- підтримує AI-помічника;
- підтримує desktop-додаток і мультиакаунти;
- підтримує телефонію;
- може працювати в режимі підвищеної безпеки.
K2 Chat повинен стати єдиним центром комунікацій у K2 ERP: для співробітників, клієнтів, партнерів, підтримки, розробників, бухгалтерів, менеджерів, керівників, студентів, викладачів, інтеграторів та зовнішніх користувачів.
54. Висновок
Модуль K2 Chat є стратегічним компонентом K2 ERP, який об’єднує корпоративний месенджер, Helpdesk, баг-трекінг, CRM-комунікації, інтеграції, міжхмарну комунікацію, голосові повідомлення, відеоконференції, стрімінг, транскрибацію, AI-помічника та передачу ERP-даних у єдиному середовищі.
На відміну від звичайних месенджерів, K2 Chat повинен бути тісно пов’язаний із бізнес-процесами компанії. Повідомлення мають бути не просто текстом, а частиною управління задачами, документами, клієнтами, зверненнями, помилками, навчанням, підтримкою, зустрічами, домовленостями та розвитком підприємства.
Головна перевага K2 Chat: комунікація залишається всередині ERP-системи, під контролем компанії, з історією, правами доступу, аудитом, інтеграціями, записами, транскрибаціями та можливістю масштабування на велику кількість користувачів і хмар.
|
|
