Telegram-бот для внутренних заявок — это интерфейс, через который сотрудник отправляет обращение в нужный отдел, а отдел получает его уже заполненным: с автором, обязательными полями, назначенным маршрутом и статусом. Заявка перестаёт теряться в личных сообщениях и рабочих чатах, потому что у неё появляется структура и адресат.
Главная ценность здесь не в самом боте, а в настроенном процессе. Работающей считается схема, где закрыты пять вещей: идентификация заявителя, обязательные поля, маршрут по отделам, видимый статус и правило передачи исключения живому диспетчеру. Всё остальное — оформление диалога.
Когда нужен Telegram-бот для внутренних заявок
Задача подходит, если обращения между подразделениями повторяются: заявки на доступы и технику, хозяйственные поручения, правки в учётных системах, кадровые и бухгалтерские запросы. Характерный признак — сотрудник не знает, кому писать, и отправляет сообщение «кому-нибудь из отдела», а через неделю выясняет, что заявку никто не принял.
Второй признак — руководитель не видит нагрузки. Обращения распределены по чатам и личным сообщениям, часть из них не имеет описания, статус неизвестен, а спорные случаи пересылаются между сотрудниками без контекста.
Третий признак — отдел тратит время на уточнения. Если типовая заявка требует трёх уточняющих сообщений перед тем, как её можно выполнить, это работа для бота с обязательными полями.
Задача не подходит, когда обращения разовые или процесс до конца не описан. Сначала фиксируют, кто выполняет работу и какие данные нужны для результата. Если задача скорее про ответы на вопросы по регламентам, чем про приём заявок, нужен другой инструмент: бот отдела, отвечающий по документам и базе знаний, — о таких сценариях рассказано в разделе чат-боты для бизнеса в Telegram.
Как устроен процесс: пять обязательных элементов
Идентификация. Бот связывает аккаунт Telegram с записью в справочнике сотрудников: подразделение, руководитель, права на типы заявок. Привязка делается по корпоративной почте, коду подтверждения или приглашению в рабочую группу. Без подтверждённой идентификации заявка от чужого имени не создаётся.
Обязательные поля. Для каждого типа заявки задаётся минимум данных: тип обращения, описание, точка или подразделение, срочность, вложения. Бот проверяет формат, не принимает пустые поля и перед отправкой показывает сотруднику итоговый вид заявки — это снижает количество возвратов на уточнение.
Маршрут отдела. Правила маршрутизации определяют, в какую очередь попадает заявка: ИТ, АХО, кадры, бухгалтерия, производственный участок. Заявка уходит в ответственный отдел, а не в общую переписку, и система отсекает очевидный дубль, если сотрудник отправил то же обращение повторно.
Статус. Сотрудник видит движение заявки: принята, в работе, ожидает данные, выполнена, отклонена. Руководитель видит очередь целиком. Закрытый статус убирает вечный вопрос «а где моя заявка» и разгружает переписку.
Исключение. Всё, что не подходит под правило, бот не угадывает и не распределяет наугад. Такая заявка уходит диспетчеру вместе со сводкой диалога: кто обращался, какие поля собраны, на каком шаге правило не сработало. Диспетчер назначает отдел вручную, а случай добавляется в правила.
Пример сценария: заявка сотрудника в ИТ-отдел
Ниже — рабочий пример, а не опубликованный кейс клиента. Сотрудник производства пишет боту: «Нужен доступ к 1С:УТ для нового мастера участка». Бот идентифицирует сотрудника, определяет его подразделение и предлагает тип заявки «Доступ к учётной системе».
Дальше бот собирает обязательные поля: кому нужен доступ, какая система, какой объём прав, на какой срок, есть ли согласование руководителя. Проверяет формат и показывает итог. После подтверждения заявка создаётся в задачах или в CRM, ей присваивается номер и статус «принята», а мастеру участка приходит уведомление.
Заявка уходит в очередь ИТ и двигается по статусам. Когда специалисту не хватает согласования, статус меняется на «ожидает данные», сотрудник получает запрос прямо в диалоге. Когда доступ открыт — статус «выполнена».
Отдельный случай: пользователь просит доступ к данным нового типа, которого нет в каталоге заявок. Правило маршрута не срабатывает, и диалог целиком уходит диспетчеру с пометкой «вне сценария». Диспетчер разбирает обращение вручную, а тип заявки позже добавляется в бота.
Какие данные и доступы нужны
Для работы бота нужны справочники, а не выгрузки «как есть». Минимальный набор: сотрудники и подразделения, каталог типов заявок, правила маршрутов, статусы и список диспетчеров. Заявка должна записываться туда, где отдел реально работает: задачи CRM, документы 1С, очередь в корпоративной системе.
Доступы выдаются по принципу минимальных прав. Бот получает отдельную учётную запись в каждой системе, чтение по умолчанию, а операции записи включаются отдельно и только для согласованных действий. Токены и ключи хранятся отдельно от кода и не попадают в репозиторий.
До старта с ИТ-службой и ИБ согласуются три вещи: где работает система, какие данные видит модель и какие операции бот выполняет сам, а какие ждут подтверждения человека. Что касается каналов связи с учётными системами — 1С по OData и HTTP-сервисам, CRM по REST API, при их отсутствии файловый обмен или промежуточный модуль, — это разобрано в материале интеграция ИИ с 1С и CRM.
Этапы внедрения
Работа идёт шагами, и каждый заканчивается проверяемым результатом. Описание задачи: кто подаёт заявки, что делается вручную, где лежат данные. Техническое задание на этом шаге не требуется. Оценка: проверяется, доступны ли интерфейсы систем и подходит ли задача для автоматизации, называется диапазон часов и лимит бюджета.
Далее — договор и доступы, сборка сценария и интеграций, проверка на типовых, ошибочных и рискованных сценариях. Перед выпуском в отдел бот работает в стендовой группе с руководителем и несколькими сотрудниками: они отмечают ошибки, правила и источники данных правятся.
Запуск включает инструкции для сотрудников и сопровождение: новые типы заявок, разбор журнала, доработки. Каждый час работ записывается в журнал, из него собираются отчёт и акт, поэтому оплачивается только принятая работа. Полный порядок работ и этапы внедрения описан отдельно.
Контроль человека и риски
Бот не получает широкие права по умолчанию. Там, где заявка меняет данные в системе или уходит наружу, последнее слово остаётся за сотрудником: операция выполняется после подтверждения, а объём подтверждений руководитель задаёт сам.
Основные риски и как они закрываются. Ошибочные ответы и неверный маршрут — стендовая группа, прогон на реальных заявках и журнал диалогов для разбора. Дубли при повторной доставке события — проверка на существующую заявку перед созданием. Недоступность CRM или 1С — заявка сохраняется, сотрудник видит понятное сообщение, обращение уходит диспетчеру. Устаревший справочник сотрудников — заявки без подтверждённой идентификации не создаются. Компрометация токена — секреты отдельно от кода, доступ отзывается, бот принадлежит компании и регистрируется на её ресурс.
Как проверить результат и с чего начать
Проверка строится на журнале бота, а не на впечатлениях. Смотрят четыре вещи: сколько заявок пришло с полным набором обязательных полей без уточнений, сколько времени проходит от обращения до назначения ответственного, какая доля заявок ушла диспетчеру как исключение и сколько обращений вернулось в переписку вне бота.
Отдельно отсматриваются дубли и возвраты на доработку. Если доля исключений растёт, значит, каталог типов заявок или правила маршрутов отстают от реальной работы отдела. Если заявки уходят в переписку — причина обычно в неудобных обязательных полях или отсутствии нужного типа обращения.
Начинать стоит с одного процесса: описать, кто подаёт заявки, какие данные нужны для результата и какой отдел их выполняет. На этом шаге становится ясно, нужен ли бот и каков диапазон часов на первый контур. Актуальные ставки закрывает открытый прайс, а обезличенные примеры запуска ботов в отделе собраны в разделе внедрение и результаты.
Подводя итог: Telegram-бот для внутренних заявок окупает себя там, где обращения повторяются, а их обработка сейчас держится на переписке. Идентификация, обязательные поля, маршрут, статус и исключение для диспетчера — тот минимум, после которого заявка становится управляемой, а нагрузка отдела — видимой.
Оценку первого контура по вашему процессу и диапазон часов на стендовую версию можно получить через описание задачи и порядок работы — достаточно одного типа заявок и одного отдела.
Частые вопросы
Чем внутренний бот заявок отличается от портала или 1С:Документооборота?
Портал требует отдельного входа и обучения, а бот работает там, где сотрудник уже общается. Заявка при этом попадает не в переписку, а в учётную систему: с полями, маршрутом и статусом. Бот не заменяет учётную систему, он становится удобным интерфейсом к ней.
Как бот понимает, что пишет сотрудник, а не посторонний человек?
Пользователь Telegram сопоставляется с записью в справочнике сотрудников по согласованному правилу: корпоративная почта, код подтверждения или приглашение в рабочую группу. Если сопоставить не удалось, заявка не создаётся, а диалог передаётся диспетчеру.
Что происходит, если заявка не подходит ни под одно правило маршрута?
Бот не угадывает адресата. Такая заявка уходит диспетчеру вместе со сводкой диалога: кто обращался, что собрал бот и где правило дало сбой. Диспетчер назначает отдел вручную, а случай потом добавляется в правила маршрутизации.
Нужно ли дорабатывать конфигурацию 1С или CRM, чтобы бот создавал заявки?
Обычно нет: используются OData, HTTP-сервисы, REST API и другие штатные интерфейсы. Если безопасного интерфейса нет, остаются файловый обмен или промежуточный модуль вне системы. Решение принимается на проверке интерфейса, до начала разработки.
Сколько времени занимает внедрение и как считается стоимость?
Зависит от числа типов заявок, маршрутов и подключаемых систем. Диапазон часов и лимит бюджета называются после разбора сценария и не превышаются без письменного подтверждения; учёт времени идёт с шагом 0,5 часа. Актуальные ставки — в открытом прайсе.
Официальные материалы по теме
Для терминов, возможностей интерфейсов и требований безопасности используем первичные материалы разработчиков и профильных организаций.