Каталог услуг в Telegram Mini App полезен, когда помогает выбрать подходящую задачу и отправить понятную заявку. Одной сетки карточек недостаточно. Клиенту нужно знать, что входит в услугу, какие сведения потребуются и означает ли нажатие немедленное подтверждение или только запрос на согласование.
Ниже рассматривается каталог с приёмом заявок, без автоматической оплаты. Платежи имеют отдельные правила платформы и поставщика, поэтому их не следует добавлять как случайный последний шаг к непроверенной форме. Основной процесс здесь — выбор услуги, сбор необходимых сведений и подтверждённая передача в систему обслуживания.
Одна карточка — одно понятное предложение
Название должно объяснять результат услуги, а описание — границы. Например, настройка одного приложения отличается от комплексной подготовки сервера. Если карточка обещает всё сразу, оператору придётся объяснять ограничения уже после отправленной заявки. Это создаёт лишние ожидания и усложняет согласование.
Укажите, кому подходит услуга и какие исходные условия важны. Не перегружайте карточку всей внутренней документацией, но не прячьте существенное ограничение в конце длинного файла. Человек должен понимать, сможет ли выполнить нужный следующий шаг и какие материалы приготовить.
Если показывается цена или срок, источник должен быть актуальным и соответствовать реальным условиям. Статья не предлагает универсальных тарифов. Лучше ясно обозначить необходимость согласования, чем показывать условное значение как подтверждённое предложение. Данные каталога и окончательная сводка должны опираться на один управляемый источник.
Идентификатор услуги и версия условий
Сохраняйте внутренний идентификатор, а не только отображаемое название. Перевод или редактура текста не должны превращать прежнюю услугу в другую запись. При этом значимое изменение содержания может потребовать версии условий, чтобы команда понимала, что видел клиент при подтверждении.
Старая карточка может остаться открытой, пока каталог обновился. Перед отправкой сервер проверяет доступность и текущие параметры. Если изменилось существенное условие, покажите его пользователю и запросите нужное подтверждение, а не молча применяйте новую версию к старому выбору.
Недоступная услуга должна иметь понятное состояние. Иногда её убирают из выбора, иногда сохраняют описание с объяснением. Но форма не должна принимать заявку как подтверждённую, если ресурс уже закрыт. Видимость карточки и возможность исполнения — разные проверки.
Поля формы по выбранной задаче
Собирайте только сведения, которые нужны для обработки конкретной услуги. Для консультации может хватить темы и времени, для технической работы понадобятся система и описание. Не используйте одну длинную анкету со всеми возможными полями, если большинство из них не относится к выбору клиента.
У каждого обязательного поля есть объяснение и проверка. Если требуется файл, укажите допустимый материал. Если контакт необязателен, предусмотрите пропуск. Пароли и постоянные секреты не должны становиться обычным полем первичной заявки: для необходимых рабочих доступов используют отдельный согласованный процесс.
Сохраняйте черновик согласно обещанному поведению. Человек может вернуться в каталог, уточнить другую услугу и продолжить. Правило смены выбора должно объяснять, какие ответы сохраняются и какие больше не подходят. Не переносите старый технический контекст в новую услугу вслепую.
Условный пример: запрос на настройку
Предположим, сервис предлагает консультацию и техническую настройку. Пользователь открывает вторую карточку, читает условия и сообщает систему, версию и цель работы. Перед отправкой он видит сводку: выбранная услуга, собранные сведения и дальнейший этап согласования.
Приложение создаёт одну заявку и возвращает её номер после подтверждённого сохранения. Если CRM временно недоступна, состояние отражает фактический этап передачи. Пользователь не получает ложного сообщения, что специалист уже начал работу, когда система только сохранила внутреннее событие.
Позже человек возвращается к старой карточке. Сервер показывает существующий результат либо предлагает новую заявку явным действием. Пример условный. Mini App предоставляет интерфейс, а идентификация, версия услуги, очередь и защита от повторов реализуются вашим приложением.
Авторизация и принадлежность заявки
Сервер должен проверять данные запуска и собственную сессию поддерживаемым способом. Номер пользователя, присланный из браузерного поля, не является достаточным подтверждением. После входа также проверяется право на конкретную заявку. Авторизация приложения и доступ к объекту — разные этапы.
Если заявка связывается с внешним кабинетом, используйте отдельную процедуру подтверждения. Похожее имя или указанный телефон не должны автоматически открывать всю историю заказов. Для общей консультации может существовать более простой режим без доступа к закрытым данным, если он предусмотрен продуктом.
При работе команды определите, кто видит новые заявки и вложения. Каталог не должен становиться публичным списком клиентских запросов. Ссылки, сообщения и технические идентификаторы передаются в соответствии с назначением и правами, а не ради удобства одного общего рабочего чата.
Подтверждение и результат
Финальная кнопка объясняет действие: отправить заявку, запросить согласование или подтвердить запись. Эти формулировки не равнозначны. Если нужен ответ администратора, обозначьте ожидание. Клиенту важно знать, существует ли уже договорённость или только зарегистрирован интерес к услуге.
Повторное нажатие относится к той же операции и не создаёт дубликат. Сохраняйте идентификатор экземпляра формы и результат. Если ответ потерялся, приложение сначала проверяет существующую заявку. Новая независимая задача создаётся через понятный новый процесс, а не технический повтор старого запроса.
После отправки покажите, где смотреть состояние и как добавить сведения. Не заставляйте человека сохранять единственный скриншот без возможности вернуться. Если уведомления доступны по выбору, подключайте их отдельным понятным шагом, не смешивая разрешение на сообщения с самой заявкой.
Мобильная приёмка каталога
Проверьте длинные названия, несколько языков, открытие клавиатуры и ошибки полей. Карточка должна вести к нужной форме, а возврат — сохранять согласованное состояние. В светлой и тёмной теме должны читаться условия, вторичный текст и состояние недоступной услуги.
Испытайте изменение каталога, пока форма открыта. Затем повторите отправку, перезапустите приложение и смоделируйте отказ CRM. Для каждой проверки определите ожидаемый результат в серверной системе, а не только внешний текст на экране. Это выявляет расхождения между красивой карточкой и реальной обработкой.
Каталог готов, когда человек понимает услугу, может передать нужные сведения и получает честное состояние результата. Количество карточек само по себе не улучшает процесс. Полезнее небольшой проверенный набор, где условия, форма и работа команды связаны однозначно.
Фильтры и пустой результат
Если услуг много, фильтры должны помогать выбору по реальной задаче, а не повторять внутренние названия отделов. Человек может не знать, какая команда оказывает помощь, но понимает нужный результат. Проверьте формулировки на нескольких обычных вопросах, которые задают до оформления заявки.
Пустой список после фильтра не должен выглядеть как поломка. Покажите активные условия и возможность их сбросить. Если подходящей услуги нет, предусмотрите понятный путь уточнения, когда команда действительно принимает такие запросы. Не подменяйте отсутствие результата случайной карточкой, которая технически доступна, но не соответствует задаче.
При переходе из отфильтрованного списка и обратно сохраняйте согласованное состояние. Пользователь не должен каждый раз заново выбирать все параметры после чтения карточки. Одновременно проверьте обновление доступности: сохранённый фильтр не даёт права показывать снятую услугу как действующую.
На приёмке пройдите выбор с пустым результатом, длинным названием и изменением каталога. Затем сравните выбранный идентификатор с серверной заявкой. Такой тест подтверждает, что навигация помогает реальному оформлению, а не только красиво меняет карточки на экране.
Источники
Интерфейс и данные запуска описаны в Telegram Mini Apps, проверка источника — в Validating data. Каталог и модель заявок реализуются отдельно в вашем приложении.