Исходный Telegram-бот агрегировал несколько корпоративных сервисов:
- бронирование переговорных комнат,
- доступ к справочник сотрудников,
- HR-информацию,
- ИТ запросы.
Бизнес-логика уже была реализована в backend-инфраструктуре клиента на базе 1С, SQL Server и внутренних сервисов. Мессенджер выполнял роль интерфейса.
Однако
API Яндекс Мессенджера имеет ограничения по сравнению с Telegram:
- упрощённый Markdown,
- отсутствие полноценной Telegram-inline модели,
- менее гибкий интерактивный UX,
- ограниченные возможности редактирования сообщений.
Это означало, что существующие сценарии нельзя было перенести без изменения архитектуры. При этом сохранение привычного пользовательского опыта было обязательным условием проекта. В такой ситуации перенос требовал изменения архитектурного подхода в виде отдельного оркестратора, который будет компенсировать ограничений и такой системой стал on-prem
n8n.