Initial situation: the company’s internal IT service receives requests from employees via general chat and email. Because of this, details are lost, applications are duplicated and there is no uniform statistics. There is Jira Service Management (Cloud) as a Service Desk, employee authentication through corporate SSO (Azure AD). We want employees to create requests via a Telegram bot, and requests will automatically be included in JSM with the correct category, priority and routing. Technical environment and limitations: Telegram Bot API. Jira Service Management Cloud REST API. Azure AD to verify user domain membership. Deployment in Docker in our infrastructure (Linux VM). Restriction: the bot should not have permanent storage of personal data; it is allowed to store a minimum set (Telegram user id, employee hash ID, tokens only in encrypted form or not at all). Logs must contain no request content (only technical events and identifiers). The bot's communication language is RU. What the bot should do: 1) Authorization - the user links Telegram to a corporate account through a secure flow: the bot issues a link to a short-lived token, the user logs in to Azure AD, after which the bot receives confirmation and allows work. 2) Creating a request - the dialog collects the required fields: type of request (incident, access, equipment, software), brief description, details, criticality, affected service from the list, attachments (screenshots). 3) Automatic classification - based on keywords/templates (customizable table of rules) suggests a category/component and a queue (request type) in JSM, the user confirms or changes. 4) Creating a ticket in JSM - creates a request with the necessary custom fields, attaches files, returns a number and a link. 5) Status and comments - on command shows the last 5 user requests, current stat us, can send a comment to a ticket and receive notifications about status changes/comments in Telegram (webhook from JSM or periodic polling with deduplication). 6) Anti-duplicates - before creating a ticket, the bot does a quick search for similar open user requests for the last 7 days (by keywords/service) and offers to link to an existing one. Expected result: a repository with source code (preferably Python 3.11+ or Node.js 20+), Dockerfile and docker-compose for launch, configuration through environment variables, migration/initialization of classification rules, installation and operating instructions (RU), a minimum set of autotests for key scenarios, configured webhook Telegram mode. Acceptance criteria (measurable): 1) A new user without a link cannot create applications, but after successful authorization he can. 2) Creating an incident with an attachment results in a request appearing in JSM with filled fields and an attached file, the bot returns the correct request key. 3) Notification of a status change in JSM arrives in Telegram no later than 2 minutes (in a test environment). 4) The logs do not contain the text of requests and personal data except technical identifiers. 5) Restarting the container does not break the bot’s operation and does not require manual actions to restore the webhook/subscriptions. Step by step: first a prototype of the dialogue and creation of a ticket, then SSO binding, then notifications and comments, then anti-duplicates and classification rules, then packaging in Docker and documentation. Access: we will provide a test JSM project, a test Azure AD app registration, a Telegram bot token and a list of JSM fields/queues.