Telegram-миниапп как простой интерфейс над Битрикс24: когда это оправдано

Есть категория сотрудников, для которых полноценный портал — избыточная и враждебная штука. Монтажник на объекте, водитель, замерщик, мастер на выезде. Им не нужны воронки, отчёты и лента новостей — им нужно посмотреть три задания на сегодня, отметить выполнение и приложить фото. Заставлять их осваивать весь интерфейс бессмысленно: они просто не будут им пользоваться. Telegram-миниапп — один из рабочих способов это решить, и разбираю, когда он оправдан, а когда нет.

Проблема: портал избыточен для полевого сотрудника

Когда мы внедряем систему, основной интерфейс проектируется под офис. Там менеджеры, руководители, бухгалтерия — люди за компьютером, которым нужна полнота. А потом выясняется, что в процессе участвуют и те, кто в офис не заходит: смонтировал, отвёз, замерил, сдал. И вот для них тот же самый интерфейс становится препятствием.

Механика сопротивления понятная. Человек открывает приложение с телефона, видит десяток разделов, не находит своё, звонит диспетчеру и спрашивает голосом. Через неделю он перестаёт открывать приложение вовсе, и данные снова собираются по звонкам и в чате. Формально система внедрена, фактически на этом участке её нет.

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

Что такое миниапп простыми словами

Миниапп — это небольшое приложение, которое открывается прямо внутри мессенджера. Ставить ничего не надо, регистрироваться отдельно не надо, авторизация проходит через сам мессенджер. Для сотрудника это выглядит как кнопка в чате: нажал — открылся экран с его заданиями. Никакого нового пароля, никакой инструкции на три страницы.

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

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

Что туда выносят

Первое — список заданий на сегодня. Короткий, отсортированный, без фильтров и настроек. Адрес, время, что сделать, контакт клиента, кнопка позвонить. Всё, что нужно человеку в поле, помещается на один экран, и это главное требование к такому интерфейсу.

Второе — отметка о выполнении с доказательством. Нажал «выполнено», приложил фото, оставил короткий комментарий. Отсюда в портал улетает факт закрытия, время, геометка при необходимости и медиафайл в карточку. Именно этот сценарий чаще всего и окупает всю разработку, потому что закрывает вечный спор «сделано или не сделано».

Третье — простые вводы данных: замеры, расход материалов, отметка о выдаче, подпись клиента. Всё, что раньше писалось в блокнот и переносилось в систему вечером или не переносилось вовсе. И четвёртое — быстрая связь с офисом по конкретному заданию, чтобы вопросы не растворялись в общем чате, как я разбирал в статье о том, почему задачи в чатах теряются.

Чего не стоит туда тащить

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

Не надо тащить настройку процессов, права, редактирование справочников и всё, что связано с изменением конфигурации. Миниапп — это исполнительский интерфейс, а не второй административный. Как только вы начинаете дублировать в нём функциональность портала, вы получаете вторую систему, которую придётся отдельно поддерживать и синхронизировать по смыслу.

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

Что продумать до разработки

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

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

И фотографии. Их бывает много, они тяжёлые, и надо понимать, куда они складываются, сколько хранятся и кто это чистит. Заодно сразу договоритесь, что считается годным доказательством выполнения: снимок объекта целиком, документ с подписью или что-то ещё. Иначе через месяц вы получите папку с размытыми кадрами, по которым ничего не докажешь.

Когда это оправдано, а когда нет

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

Считать выгоду тоже стоит не в экономии кликов, а в том, что перестаёт теряться: невыполненные заявки, несданные материалы, споры об объёме работ с клиентом. Если этих потерь нет, разработка не нужна.

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

Хороший маркер готовности — когда диспетчер или мастер сам жалуется, что устал собирать отметки по телефону. Значит потребность созрела внутри, и людей не придётся уговаривать пользоваться новым интерфейсом: они его ждут.

Если решаете делать, начинайте с минимума: один сценарий, одна группа сотрудников, пара недель на живую обкатку. Дальше расширяйте по фактическому спросу, а не по списку хотелок, собранному на старте. Спроектировать такой контур и связать его с порталом — обычная задача на доработки и сопровождение; главное здесь — не построить вторую систему рядом с первой.