Приём документа в Telegram-боте должен отвечать на простой вопрос: подходит ли этот материал для текущей заявки? Факт получения сообщения ещё не означает, что оператор получил нужный файл. Пользователь может отправить фотографию вместо исходного документа, приложить не ту версию или добавить пояснение отдельной репликой.
Чтобы форма не теряла смысл, проверку строят по этапам: ожидание вложения, определение типа, проверка допустимости и подтверждение связи с заявкой. Хранение в CRM рассматривается отдельно. Здесь основная задача — принять правильный материал и дать человеку исправить ошибку без повторного заполнения всей формы.
Опишите ожидаемый материал обычными словами
Вместо «загрузите файл» укажите, что требуется и для чего. Если нужен исходный документ, объясните, почему фотография страницы не подходит. Если достаточно снимка ошибки, не требуйте сложный архив. Чем точнее назначение вложения, тем меньше лишних материалов получит команда.
Назовите поддерживаемые форматы и ограничения своего приложения. Не копируйте случайное максимальное значение из старой статьи: возможности Telegram, вашей инфраструктуры и внешней CRM могут различаться. Реальный предел определяется всей цепочкой обработки. Укажите его так, чтобы пользователь понял ограничение до отправки большого файла.
Если документ необязателен, предложите пропуск шага. Не заставляйте человека прикладывать случайную картинку ради перехода дальше. Для обязательного материала объясните, можно ли завершить заявку другим способом или обратиться к сотруднику, когда нужного формата под рукой нет.
Различайте фото, документ и ссылку
В Bot API фотография и документ представлены разными объектами. Пользователь может отправить один и тот же снимок разными способами. Поэтому обработчик должен заранее определять допустимые варианты, а не искать только один ожидаемый объект и считать всё остальное отсутствием ответа.
Ссылка на облачное хранилище — отдельный сценарий. Приложение не должно автоматически скачивать любой присланный адрес без предусмотренных ограничений. Если ссылки не поддерживаются, объясните, как приложить файл напрямую. Если поддерживаются, проверьте доступность и правила получения содержимого в своей серверной среде.
Подпись к вложению может содержать важное пояснение. Не теряйте её при передаче материала сотруднику. Если пользователь прислал описание следующей репликой, связь определяют по состоянию формы и контексту. Не следует автоматически относить любое последующее сообщение к последнему файлу без ограничений по сценарию.
Проверка типа и размера
Имя и расширение полезны для интерфейса, но недостаточны для определения допустимого содержимого. Разработчик должен применить предусмотренные проверки на сервере. При этом задача бота — не обещать абсолютную проверку любого файла, а соблюдать ограничения собственного процесса и ясно обозначать результат.
Проверка размера должна происходить настолько рано, насколько позволяет доступная информация. Если файл превышает установленный предел, не заставляйте пользователя ждать неопределённо. Сообщите ограничение и предложите допустимый вариант: уменьшить файл, передать нужную часть или воспользоваться предусмотренным каналом, если он существует.
Не отправляйте полученный документ сразу всем участникам рабочего чата. Сначала определите его связь и доступ. Некоторые материалы требуют ограниченного просмотра. Пользователь может ошибочно приложить лишние сведения, поэтому у команды должен быть порядок обработки неподходящих материалов без бесконтрольного распространения копий.
Условный пример: документ для согласования услуги
Предположим, сервис просит приложить техническое задание к заявке. Поддерживаются определённые форматы, перечисленные рядом с кнопкой отправки. Пользователь присылает фотографию титульного листа. Бот объясняет, что для этого шага нужен сам документ, и сохраняет уже заполненные данные анкеты.
После повторной отправки приложение проверяет допустимость и показывает краткую сводку: название материала, к какой заявке он относится и что будет передано сотруднику. Клиент замечает, что выбрал старую версию, и заменяет файл до финального подтверждения. Прежний объект получает предусмотренное состояние, а не остаётся неразличимым активным вложением.
Если пользователь хочет добавить второй независимый документ, сценарий должен это разрешать явно либо объяснять ограничение. Пример условный: Telegram обеспечивает передачу объектов, а правило версий, сводка и допустимое количество материалов относятся к вашему приложению.
Несколько файлов и альбомы
Люди могут отправить несколько вложений подряд или объединить их доступным способом клиента. Не считайте каждое входящее сообщение отдельной окончательной заявкой. Сначала определите, поддерживает ли форма несколько материалов, как завершается их выбор и что означает удаление одного из них.
Если приложение принимает только один документ, объясните, заменяет ли новый файл предыдущий. Молчаливая замена особенно опасна: пользователь может думать, что отправил комплект. Если принимается несколько объектов, покажите список перед подтверждением, чтобы человек мог заметить пропуск или случайный материал.
При обработке связанных сообщений учитывайте документированные поля Telegram и собственное состояние формы. Не полагайтесь только на близкое время отправки: два разных вопроса могут прийти подряд. Подтверждение комплекта даёт более ясную границу, чем предположение, что пауза между сообщениями означает завершение загрузки.
Ошибки загрузки и продолжение анкеты
После временного сбоя сервер не должен забывать всю заявку. Сохранённые ответы и состояние загрузки помогают предложить повтор именно проблемного шага. При этом нельзя показывать «файл принят», если приложение лишь получило сообщение, но не завершило необходимую проверку и сохранение.
Повторная отправка может создать дубликат. Для корректной обработки учитывайте экземпляр анкеты и назначение вложения. Совпадение имени недостаточно, но и новый технический объект не всегда означает новый смысловой документ. В неоднозначном случае лучше показать пользователю сводку и предложить подтвердить комплект.
Сотрудник должен видеть, если материал ожидает проверки либо требует повторного получения. Не скрывайте такую ситуацию обычным значком вложения, который выглядит как готовый файл. Иначе оператор начнёт разбор обращения и обнаружит отсутствие содержимого только после дополнительных действий.
Проверочный набор
Подготовьте допустимый документ, неподходящий тип, файл сверх предела и два объекта с одинаковым именем. Пройдите замену версии, отмену загрузки и повтор после ошибки. Затем отправьте пояснение отдельным сообщением и проверьте, как оно связано с материалом. Используйте тестовые документы без реальных клиентских сведений.
Отдельно испытайте перезапуск приложения между получением и финальным подтверждением. Состояние должно восстановиться согласно обещанному поведению формы. Если черновик не сохраняется, интерфейс обязан честно объяснить необходимость нового шага, а не показывать пустую сводку как готовую заявку.
Проверьте результат глазами оператора: понятны ли назначение, актуальная версия и ограничения просмотра? Если сотруднику приходится искать подпись в истории Telegram, интеграция теряет важный контекст. Приёмка завершается не появлением файла на сервере, а возможностью корректно использовать нужный материал при обработке конкретного обращения.
Если материал проверяет сотрудник
Не каждый формат можно оценить автоматически по смыслу. Система способна принять файл нужного типа, но только специалист определит, содержит ли он требуемые сведения. В таком случае различайте технический приём и содержательную проверку. Пользователь должен понимать, что загрузка завершена, а пригодность документа ещё рассматривается.
Для отказа сотрудник выбирает понятную причину и следующий шаг. Например, требуется другая версия или отсутствует нужная страница. Не отправляйте клиенту внутреннюю пометку без объяснения. Если приложение допускает замену, сохраните связь нового материала с прежней заявкой, чтобы человеку не пришлось снова вводить все поля. Внутри команды также должен быть виден ответственный за проверку: файл, лежащий в очереди без владельца, не становится обработанным только потому, что сервер успешно принял его несколько дней назад.
Источники
Структуры вложений описаны в Bot API: Document и PhotoSize. Получение содержимого представлено в getFile. Ограничения своей формы фиксируйте отдельно от максимально доступных возможностей платформы.