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