Как выбрать бота для рабочих чатов: проверка одной договорённости

Команда Нити · 11 октября 2026 · 10 минут

Бота для учёта обещаний сотрудников можно проверить на одной договорённости: человек обещает прислать смету, подтверждает запись, согласует новый срок и отправляет результат. Попросите поставщика провести её через весь путь в том рабочем чате, которым пользуется команда.

Для руководителя компании на 10–100 человек демонстрация помогает выяснить, кто будет поддерживать записи, где ожидающий результат увидит изменения и какие действия останутся сотрудникам. Ниже приведены предлагаемые критерии выбора. Их значимость зависит от вашего порядка работы. Ручное создание записи тоже может подходить команде, если сотрудники готовы его выполнять.

Все реплики, имена и ситуации ниже вымышлены. Это сценарий для будущей демонстрации. Испытания конкретных ботов по нему не проводились.

Подготовьте рабочий чат и лист проверки

До встречи назовите поставщику мессенджер и тип переписки: рабочая группа в Telegram, группа в MAX или личный диалог. Попросите показ именно в нужном формате. Поддержку группы следует выяснить отдельно от поддержки личной переписки; условия Telegram следует проверить отдельно от условий MAX.

Уточните, какие права нужны инструменту, какие сообщения ему доступны и кто видит сохранённые договорённости. Если для личного диалога требуется пересылать сообщения, запишите это как действие участника. Если сотрудники договариваются голосом, включите голосовое сообщение в показ и проверьте возможность исправить распознанный текст. Для данных выясните место хранения, порядок удаления и выгрузки.

Демонстрация обработки клиентского обращения оставляет вопрос внутренних обещаний открытым. В предоставленных выдержках материалов Umnico и IntellectDialog описаны клиентские диалоги, поддержка, заявки и продажи. Возможности названы поставщиками; независимой проверки в этих материалах нет. Усечённые фрагменты также не позволяют судить обо всех функциях продуктов. Попросите отдельный показ договорённости между сотрудниками.

Заведите лист проверки и заполняйте его по ходу встречи:

В начале листа укажите дату демонстрации, продукт, версию или режим, тариф, если от него зависят возможности, и условия доступа. Так результат можно будет соотнести с условиями, в которых его получили.

Проследите путь от обещания до записи

Условная дата начала переписки — 11 октября 2026 года. Ира пишет в рабочей группе вымышленную реплику:

Ира: «Пришлю смету завтра».

Пусть поставщик создаст запись тем способом, который предлагается вашей команде: автоматически, через пересылку, команду или ручной ввод. Затем откроет из записи исходное сообщение либо покажет другой способ проверить источник. Посмотрите, как сохранены текст обещания, исполнитель и срок.

Предлагаемый критерий: по записи понятно, что обещала Ира, и можно восстановить контекст без поиска по всему чату. Срок «завтра» отображается как 12 октября 2026 года. Час и часовой пояс в исходной реплике отсутствуют; способ их уточнения должен быть виден участникам.

Зафиксируйте способ создания записи и доступность источника для ожидающего результат. Если инструмент назначает время по умолчанию, отделите эту настройку от согласованного срока. Посчитайте пересылки, команды, поля и переходы между экранами, которые пришлось выполнить человеку.

Сохраняйте одну запись на протяжении показа. Это позволит проверить, как с ней связаны последующие сообщения.

Подтвердите исполнителя и исправьте ошибку

Для продолжения сценария Ира уточняет срок вымышленной репликой:

Ира: «Всё верно. Смету пришлю 12 октября до 16:00 по Москве».

Пусть Ира увидит запись с источником, своим именем и сроком, затем подтвердит её доступным способом. Для проверки исправления попросите временно указать в этой же записи ошибочную дату и вернуть согласованную. Выясните, кто может исправлять запись и что после исправления видят участники.

Предлагаемый критерий: исполнитель проверил содержание обязательства, в учёте осталась согласованная дата. Руководитель понимает, каким действием Ира приняла обещание и как устранила ошибку. Запишите, где происходит подтверждение и кому доступны исправления. Если запись сохраняется до ответа сотрудника, выясните, как обозначается её состояние.

Отдельно проверьте назначение исполнителя на вымышленной реплике руководителя:

Руководитель: «Ира, пришли смету завтра».

Ира в этой проверке пока не отвечает. Попросите показать, различает ли инструмент автора сообщения, адресата поручения и человека, который принял обязательство. Если принятие поручения приходится проверять вручную, запишите ответственного за эту проверку.

Для ложного срабатывания используйте ещё одну вымышленную реплику:

Ира: «Клиент написал: “Пришлю смету завтра”».

Посмотрите, появляется ли обязательство на Ире. Если появляется, попросите удалить ошибочную запись и проверить, что она больше не попадает в списки и напоминания. Способ исправления важен и при автоматическом распознавании, и при ручном вводе. В листе проверки должны остаться действия, которыми участники подтверждают обещание и устраняют ошибку.

Согласуйте перенос и проверьте его видимость

Вернитесь к подтверждённой смете. В тот же условный день Ира и руководитель обмениваются вымышленными репликами:

Ира: «Смету пришлю послезавтра, жду цены».

Руководитель: «Согласовано: жду 13 октября до 16:00 по Москве».

Пусть поставщик свяжет перенос с прежним обязательством и покажет состояние записи до согласования и после него. Проверьте, сохранились ли прежний срок, причина переноса и сообщение с согласованием. Затем откройте запись с позиции человека, который ждёт смету.

Предлагаемый критерий: ожидающий результат видит новый срок и понимает, что перенос согласован. В учёте можно восстановить историю изменения и отличить предложение сотрудника от принятой договорённости.

Укажите, кто меняет дату, кто подтверждает перенос и кому он становится виден. Если инструмент создаёт вторую запись, выясните, как участники связывают её с первой и прекращают учёт по старому сроку. Если ожидающий результат узнаёт об изменении только из чата, зафиксируйте этот порядок.

Для проверки напоминания оставьте отдельную копию условного обязательства незавершённой до контрольного срока. Попросите показать, кому и куда приходит уведомление, что видит ожидающий результат и можно ли проверить срок в демонстрационном режиме. Обещание показать уведомление позже запишите как непроверенный пункт.

Проверьте завершение и работу после изменения прав

В условный день завершения Ира прикладывает файл и пишет вымышленную реплику:

Ира: «Смета готова, файл прикрепила».

Пусть сотрудник отметит выполнение предусмотренным способом. Откройте завершённую запись, исходное обещание и сообщение с файлом. Выясните, достаточно ли отправки результата, нужна ли команда или кнопка и требуется ли подтверждение получателя. Проверьте прекращение напоминаний.

Предлагаемый критерий: по записи видно, что сотрудник сообщил о выполнении и где находится результат. Порядок команды определяет, достаточно ли этого для закрытия или получатель должен проверить файл. Эти состояния должны быть понятны участникам.

Укажите способ закрытия, необходимость подтверждения и доступность файла ожидающему результат. Для MAX попросите показать доступные действия отдельно. Поддержку реакций и конкретной отметки выполнения следует установить на демонстрации.

Измените одно согласованное право в тестовой группе MAX

Отдельный показ поможет проверить, что произойдёт при изменении прав бота-администратора. Проводите его в тестовой группе без рабочих данных. Заранее согласуйте с поставщиком операцию и право, которое администратор временно изменит.

Пусть поставщик покажет исходные права, назовёт необходимые для выбранной операции и обработает условную договорённость с вымышленной репликой:

«Пришлю смету завтра к 15:00».

Уточните календарную дату и часовой пояс. Затем администратор меняет одно согласованное право, нужное для показанной операции. Повторите эту операцию и запишите, что именно стало недоступно. Если ограничение не проявилось, зафиксируйте это и попросите поставщика объяснить результат.

Проверьте, как бот обнаружил изменение или ограничение. Запишите время изменения права, обнаружения и уведомления. Отдельно установите, кто получил сообщение и по какому каналу. Посмотрите, доступен ли этот канал после изменения права и какие действия потребовались администратору.

Предлагаемый критерий выбора: поставщик показал обнаружение, ответственный получил понятное сообщение о затронутом чате и операции, порядок восстановления ясен. Получение технического события само по себе ещё не подтверждает уведомление человека.

После возврата права повторите затронутую операцию. Проверьте её выполнение и способ подтверждения восстановления. Запишите, кто повторял действие и потребовались ли дополнительные настройки или обращение в поддержку.

Отдельно проверьте ранее сохранённую договорённость и новую, отправленную во время ограничения. Выясните, что доступно участникам, продолжаются ли напоминания, нужна ли повторная отправка сообщения и возможна ли последующая обработка пропущенного. Непоказанные действия оставьте в листе как непроверенные. Сохранность и обработку пропущенных договорённостей заранее считать подтверждёнными нельзя.

Что уточнить о способе получения событий MAX

В официальном changelog MAX, по наблюдению от 12 октября 2026 года, описано событие bot_admin_permissions_changed в объекте Update. Оно относится к изменению прав бота-администратора в канале или групповом чате. Эти сведения не устанавливают поведение при любых сбоях доступа.

Webhook означает, что платформа отправляет обновления на адрес поставщика. Согласно тому же наблюдению, для получения этого события через Webhook нужна подписка с помощью POST /subscriptions. Попросите поставщика показать подписку и обезличенное свидетельство получения события после согласованного изменения права. Затем отдельно проверьте сообщение ответственному.

При Long Polling бот запрашивает обновления у платформы. На момент наблюдения событие bot_admin_permissions_changed для этого способа было недоступно. Если поставщик использует Long Polling, попросите назвать и продемонстрировать другой способ обнаружения ограничения. Недоступность одного события оставляет открытым вопрос других способов проверки.

Наблюдение не устанавливает гарантии доставки, задержки и поведение конкретного бота. Перед демонстрацией попросите поставщика сверить актуальные условия MAX; результаты относите к показанному режиму и дате.

Подведите итог по показанным действиям

Посчитайте ручные действия за весь путь: создание записи, уточнение срока, подтверждение, исправление, перенос, закрытие и восстановление после изменения права. Разделите их между сотрудником, руководителем и администратором. Учитывайте переходы в личные сообщения, пересылки, повторный ввод даты и поиск исходной переписки. Руководитель решает, сможет ли команда поддерживать такой порядок при своих договорённостях.

Вывод привяжите к увиденному. Например: «Создание записи и перенос показаны. После изменения права бот обнаружил ограничение, но сообщение ответственному не показали. Операцию после возврата права выполнили; обработку сообщений за период ограничения предстоит проверить». Это пример формулировки для листа, результаты такого испытания здесь не приводятся.

Передайте поставщику одну обезличенную внутреннюю договорённость без имён, сумм и сведений о клиентах. Запросите показ её полного пути и, если выбираете бота для группы MAX, согласованного изменения права с уведомлением и восстановлением. По каждому непроверенному пункту укажите, какой показ нужен для решения.