5 ошибок UX, из-за которых B2B-клиенты удаляют мобильное приложение

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

ошибка 1: регистрация раньше пользы

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

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

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

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

ошибка 2: экран загрузки, который не кончается

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

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

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

Чаще всего дело не в самом мобильном приложении, а в том, что оно ждёт ответ от сервера синхронно и целиком, вместо того чтобы сначала показать то, что уже закешировано на телефоне, и подгрузить актуальные остатки в фоне. Второй частый источник задержки — медленный сервер 1С на стороне заказчика: если сама база открывается со скрипом, приложение будет ждать её так же долго, как открывается веб-интерфейс бухгалтерии. На практике разница между «открылось сразу» и «крутится пятнадцать секунд» не в мощности телефона, а в том, сколько данных приложение пытается получить одним запросом перед тем, как показать хоть что-то.

ошибка 3: цифры в приложении не совпадают с 1С

Клиент оформляет через приложение заказ на 40 единиц товара, система принимает его без вопросов. Через час звонит менеджер: на складе осталось 12, остальное давно продано, а выгрузка в приложение обновляется раз в сутки ночью. Второй раз в приложение клиент уже не полезет — проще позвонить и уточнить у живого человека.

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

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

ошибка 4: заявка исчезает при обрыве связи

Торговый представитель заполняет заказ у клиента в подвале склада, где сеть ловит через раз. На середине заполнения связь пропадает, приложение показывает ошибку — и весь заказ, все тридцать позиций, обнуляется. Вводить заново при клиенте неловко, и часть заказов в такой момент просто теряется: представитель говорит «пришлю позже» и в суете забывает.

Цена этой ошибки считается прямо в деньгах: каждая несохранённая заявка — упущенный заказ, а если это повторяется у нескольких торговых представителей регулярно, за месяц набегает заметная сумма недополученной выручки. Считать её точно сложно, потому что событие нигде не фиксируется — в CRM и в 1С просто нет записи о том, что заказ вообще начинали оформлять. Дополнительно теряется доверие самого торгового представителя к инструменту: после двух-трёх таких случаев проще держать блокнот и переносить данные в 1С вручную вечером, а приложением не пользоваться вовсе.

Решение — черновик заказа сохраняется локально на устройстве при каждом изменении и отправляется на сервер, как только связь восстановится, а не только в момент нажатия «отправить». Для B2B-сценариев, где заказ собирают в полевых условиях, это не опция, а обязательное требование к архитектуре. Такую логику мы закладываем в B2B-приложениях с 1С с самого начала проектирования, а не добавляем как заплатку после первых жалоб.

ошибка 5: уведомления, которые никто не просил

Приложение при первом запуске сразу спрашивает разрешение на push-уведомления — ещё до того, как пользователь понял, зачем оно вообще нужно. Часть людей нажимает «запретить» машинально, просто чтобы убрать всплывающее окно, и канал связи с клиентом закрывается навсегда: повторно спросить нельзя, только через настройки телефона, куда почти никто добровольно не полезет. Разработчики иногда запрашивают это разрешение вместе с доступом к геолокации и камере одним общим экраном — у пользователя складывается ощущение, что приложение хочет слишком много сразу, и он отклоняет всё оптом, включая то, что реально нужно.

У тех, кто разрешение дал, вторая проблема — частота и релевантность. Уведомление о статусе заказа полезно, уведомление о том, что «в приложении новый баннер», раздражает и приводит к тому же результату: пользователь отключает пуши в настройках, теперь уже осознанно и навсегда.

когда спрашивать разрешение

Рабочий паттерн — запрашивать доступ к уведомлениям не при установке, а в момент, когда польза очевидна: сразу после оформления первого заказа, с формулировкой вроде «сообщим, когда заказ соберут на складе». Согласие в такой момент дают куда охотнее, чем на пустом экране приветствия, где непонятно, о чём вообще будут уведомлять.

во что каждая ошибка обходится бизнесу

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

как чинить, не переписывая приложение заново

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

Сложнее с тем, что эти пять вещей редко видны на этапе технического задания: они всплывают, когда приложением уже пользуются живые торговые представители и клиенты на слабой сети, а не тестировщики в офисе на Wi-Fi. Поэтому в разработке мобильных приложений мы закладываем отдельный этап проверки в полевых условиях — с реальными данными из 1С, а не на демонстрационном стенде с идеальными числами.

Если приложение уже собрано на 1С:Мобильной платформе, часть этих проблем снимается на уровне платформы — офлайн-режим там встроен изначально, — но момент запроса регистрации и уведомлений платформа за вас не решает, это отдельная задача интерфейса. Разработка мобильного приложения под ключ у нас начинается от 500 000 руб., а точную оценку по вашему проекту и текущей интеграции с 1С можно посмотреть в тарифах. Если сомневаетесь, какие из пяти пунктов актуальны именно для вашего приложения, разумнее сначала провести короткий аудит взаимодействия с 1С и логов реальных сессий, а уже потом решать, что переделывать.

❓ Частые вопросы

Сколько стоит разработка мобильного приложения для бизнеса с интеграцией 1С?

Разработка мобильного приложения под ключ начинается от 500 000 рублей — итоговая цена зависит от числа экранов, глубины интеграции с 1С и того, нужен ли офлайн-режим для полевой работы. Точную оценку под конкретный проект и текущую конфигурацию 1С дают после короткого технического аудита.

Почему пользователи удаляют приложение уже после первого запуска?

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

Как понять, что расхождение данных с 1С — это ошибка UX, а не баг в учёте?

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

Нужно ли переписывать приложение целиком, чтобы исправить такие ошибки UX?

Нет. Регистрация, кеширование данных, черновики заказов и тайминг push-уведомлений — это точечные доработки в существующей архитектуре приложения, а не пересборка с нуля. Полный редизайн нужен редко, чаще хватает нескольких целевых правок после короткого аудита.

Как быстро можно проверить, какие из этих ошибок есть в нашем приложении?

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