Меню

RFI: платформа та розробка чат-бота для Лінії юридичної допомоги

February 27, 2026

Запит на інформацію (Request for Information, RFI).

Мета RFI - зібрати ринкові опції, підходи до міграції та порядок цін. Документ не є запитом фінальної комерційної пропозиції та не створює зобовʼязань сторін.

1. Контекст і коротко про поточний бот

Фонд використовує чат-бот у трьох месенджерах: Telegram, Viber, Facebook (Messenger). Критичний функціонал - база знань та письмові консультації спеціалістів через модуль «Звʼязок з юристом».

Поточна платформа (Pipe.bot) має операційні обмеження: оновлення сценаріїв скидає активні сесії, що особливо проблемно під час консультацій з оператором. Оновлення і збої не комунікуються завчасно.

2. Ціль майбутнього рішення

Отримати стабільну платформу/рішення для чат-бота, яке:

●        збереже весь поточний функціонал для користувачів у 3 месенджерах без «болючого» переходу

●        дасть зручний адмін-інтерфейс для спеціалістів без коду

●        забезпечить операційну надійність

●        налагодить підтримку та сповіщення про збої, забезпечить захист персональних даних та керування доступами

●        дасть можливість розвитку та масштабування чатботу, включно з інтеграцією AI (за потреби).

3. Обсяг RFI (що просимо описати)

Просимо надати інформацію за розділами 4-8 нижче та заповнити матрицю порівняння (Додаток А).

4. Вимоги до каналів і користувацького досвіду (must-have)

●        Підтримка Telegram, Viber, Facebook (Messenger) в одному рішенні або в єдиній керованій архітектурі з одним адмін-кабінетом.

●        Збереження структури меню/кнопок та логіки відповідей. Можливість працювати зі сценаріями та базою текстів у реальному часі.

●        Підтримка файлових вкладень (за потреби), посилань, довгих текстів, мульти-меню.

●        Коректний fallback: якщо користувач пише текстом, система або розуміє намір, або коректно веде в меню без «тупика».

5. Операторський модуль для спеціалістів (must-have)

●        Перехоплення діалогу оператором/спеціалістом з доступом до історії чату.

●        Сповіщення про нові запити та зручна робота в робочі години (поза графіком - авто-відповідь/черга).

●        Можливість передавати кейс між спеціалістами без втрати контексту.

●        Мінімум: статуси кейсу (новий/в роботі/закрито), призначення відповідального, нотатки/теги.

6. Адміністрування, аналітика, інтеграції

●        Інтуїтивний конструктор сценаріїв без програмування (ролі та права доступу).

●        Оновлення текстів/категорій/статей у реальному часі з журналом змін.

●        Аналітика: приріст користувачів по кожному каналу, топ-гілки/теми, конверсії сценаріїв, кількість звернень до спеціалістів.

●        Експорт даних (CSV/Google Sheets) або API. Можливість налаштовувати події/вебхуки.

7. Надійність, підтримка, SLA

●        Опис вашої служби підтримки: канали комунікації, години роботи, середній час реакції (SLA) та шляхи ескалації.

●        Моніторинг і сповіщення: як ви інформуєте замовника про збої, зміни API/політик месенджерів, планові роботи та оновлення.

●        Наявність механізму резервування/відмовостійкості та як саме обробляються інциденти.

8. Безпека та персональні дані

●        Місце хостингу/юрисдикція, варіанти розміщення (за наявності) баз даних, політика зберігання даних.

●        Шифрування даних під час передачі та зберігання (за наявності).

●        Ролі доступу, 2FA (за наявності), журнали доступу (audit logs).

●        Retention: строки зберігання листувань/вкладень, видалення/анонімізація на запит. Відповідність закону України “Про захист персональних даних”.

9. Міграція з поточної платформи (ключовий блок)

Просимо описати варіанти міграції та ризики, зокрема:

●        Перенесення наявного функціоналу в повному обсязі: сценаріїв/дерев рішень, тестів, калькуляторів, меню, push-розсилок.

●        Перенесення історії діалогів і вкладень або варіант архівації.

●        Збереження бази користувачів: що реально можливо з точки зору правил месенджерів, і який план «мʼякого переходу», якщо перенос неможливий.

●        Збереження/заміна поточних посилань на ботів та сценарій редіректів/інформування.

10. Питання до постачальника (обов’язкові питання)

1.       Яка ваша рекомендована архітектура для 3 месенджерів (єдина платформа чи комбінація)?

2.       Які обмеження є саме для Facebook (Messenger) і які легальні технічні підходи ви використовуєте для їх врахування (офіційні інтеграції, політики Meta, вимоги до верифікації тощо?

3.       Як виглядає  модуль адміністратора: черга, призначення, статуси, теги, шаблони?

4.       Як організована аналітика та експорт: що є «з коробки», що доробляється?

5.       Який підхід до ціноутворення: за Active users, Audience, повідомлення, операторів тощо?

6.       Які строки та етапи міграції ви бачите для такого кейсу (оцінка діапазоном)?

7.       Який склад команди з вашого боку та які ролі потрібні з боку Фонду?

11. Очікуваний формат відповіді на RFI

Просимо надати відповідь у форматі:

●        Короткий опис рішення (1-2 стор.).

●        Заповнений Додаток А (матриця порівняння).

●        Діапазон вартості: щомісячний хостинг, міграція, навчання, доопрацювання функціоналу,підтримка.

●        Кейс-референси (за наявності): 1-3 приклади подібних впроваджень.

●        Юридичний формат співпраці та базові умови договору (коротко).

https://zakupivli.pro/commercial/tenders/r-ua-2026-02-26-1000117-k

RFI_Chatbot_Platform_R2P

Завантажити

RFI_Chatbot_Platform_R2P_

Завантажити