Предприниматель заказывает приложение.
Обсуждают каталог, заявки, оплату, личный кабинет, админку.
Всё вроде понятно.
И в какой-то момент звучит фраза:
“А давайте ещё просто добавим чат между пользователями”.
На словах это выглядит мелочью.
Клиент написал. Исполнитель ответил. Сообщения появились в приложении.
Но в разработке слово “просто” часто оказывается самым дорогим.
Потому что чат — это не маленькое окно с сообщениями.
Это отдельная система внутри приложения.
И если не разобрать её заранее, чат может увеличить бюджет, сроки и сложность поддержки.
Типовая ситуация
Предприниматель делает маркетплейс услуг.
Например, приложение, где клиент оставляет заявку, а исполнитель берёт её в работу.
На первом обсуждении всё выглядит логично:
- клиент описал задачу;
- исполнитель уточнил детали;
- стороны договорились;
- заказ выполнен.
Значит, нужен чат.
На первый взгляд — да.
Но дальше начинаются вопросы, которые напрямую влияют на деньги.
Когда клиент может написать исполнителю?
До заявки или только после её создания?
Можно ли писать до оплаты?
Можно ли отправлять номер телефона?
Может ли исполнитель увести клиента из платформы?
Должен ли администратор видеть переписку?
Что делать, если в чате спор?
Кто разбирает жалобы?
Что делать со спамом, матом, мошенниками, запрещённым контентом?
И вот “простой чат” уже перестаёт быть простой функцией.
Ошибка: обсуждать чат как кнопку
Главная ошибка — считать чат одним экраном.
Предприниматель видит:
- список сообщений;
- поле ввода;
- кнопку “отправить”;
- уведомление о новом сообщении.
Но пользователь видит только верхушку.
Внутри чата есть другая часть:
- хранение сообщений;
- серверная логика;
- push-уведомления;
- роли пользователей;
- ограничения;
- статусы доставки;
- обработка ошибок;
- защита данных;
- админка;
- жалобы;
- модерация;
- история переписки;
- работа при плохом интернете.
Каждый пункт — это не просто “добавить”.
Это дизайн, разработка, тестирование и поддержка.
Почему проблема не только в разработке
Чат влияет не только на смету.
Он влияет на бизнес-модель.
Например, если у вас маркетплейс услуг, чат может быть полезным.
Но он же может создать риск.
Клиент и исполнитель начали общаться напрямую.
Обменялись телефонами.
Договорились без платформы.
В итоге приложение оплатило привлечение клиента, но не заработало на сделке.
Другой пример.
Клиент пишет исполнителю в чате. Исполнитель грубит, пропадает или обещает одно, а делает другое.
Появляется спор.
Если администратор не видит переписку, разбирать ситуацию сложно.
Если переписка удаляется, доказательств нет.
Если жалоб нет, контроль слабый.
Если модерации нет, в приложении могут появиться спам, мошенники и токсичное общение.
То есть чат — это уже не функция общения.
Это часть контроля сделок, качества сервиса и защиты бизнеса.
Что надо проверить до старта
Перед тем как закладывать чат в приложение, нужно ответить на несколько вопросов.
Первое. Кто с кем общается?
Клиент с исполнителем?
Покупатель с продавцом?
Администратор с клиентом?
Любой пользователь с любым?
Это разные сценарии.
И у них разная стоимость.
Второе. В какой момент создаётся чат?
До заявки?
После заявки?
После оплаты?
После назначения исполнителя?
После подтверждения заказа?
Если этот момент не определить, потом появляются переделки.
Третье. Что можно отправлять?
Только текст?
Фото?
Файлы?
Голосовые сообщения?
Видео?
Геолокацию?
Каждый новый тип сообщения увеличивает сложность.
Фото нужно хранить.
Файлы нужно ограничивать.
Видео может быстро раздувать серверные расходы.
Голосовые сообщения требуют отдельной логики интерфейса.
Четвёртое. Нужна ли модерация?
Можно ли жаловаться на сообщения?
Может ли администратор видеть переписку?
Можно ли заблокировать пользователя?
Можно ли скрыть запрещённый контент?
Если чат связан с деньгами и заказами, эти вопросы нельзя игнорировать.
Пятое. Что должно быть в админке?
Просто список чатов?
Поиск по переписке?
Фильтр по пользователям?
Жалобы?
Блокировки?
История споров?
Чем больше контроля нужно бизнесу, тем дороже становится функция.
Какой MVP логичен в первой версии
В первой версии приложения редко нужен полноценный мессенджер.
Особенно если продукт ещё не проверен рынком.
Для MVP часто достаточно более простых решений.
1. Комментарий к заявке
Пользователь создаёт заявку и пишет детали.
Например:
“Нужно доставить к 18:00”
“Позвоните перед приездом”
“Нужен мастер с опытом по холодильникам”
Это дешевле, чем полноценный чат.
И часто закрывает 80% задачи.
2. Статусы заказа
Вместо переписки можно сделать понятные статусы:
- заявка создана;
- заявка принята;
- исполнитель назначен;
- заказ в работе;
- заказ завершён.
Для доставки, записи и простых услуг этого может быть достаточно.
3. Шаблоны сообщений
Например:
- “Я выехал”;
- “Буду через 15 минут”;
- “Нужно уточнение”;
- “Заказ выполнен”;
- “Перенесите время”.
Это проще контролировать.
И дешевле разрабатывать.
4. Связь через администратора
Если бизнесу важно не допустить ухода клиента и исполнителя в обход платформы, на старте можно сделать коммуникацию через администратора.
Это не всегда удобно.
Зато безопаснее для первой версии.
5. Внешний мессенджер
Иногда дешевле связать процесс с Telegram, WhatsApp или другим каналом.
Минус: часть коммуникации уходит из вашей системы.
Плюс: не нужно сразу строить свой чат.
Для MVP это может быть нормальным компромиссом.
Что лучше отложить
В первую версию обычно не стоит добавлять всё сразу:
- голосовые сообщения;
- видео;
- отправку больших файлов;
- реакции;
- пересылку сообщений;
- удаление у всех;
- сложные статусы прочтения;
- поиск по переписке;
- автоматическую модерацию;
- полноценную систему жалоб;
- вложенные групповые чаты.
Это может быть нужно позже.
Но на старте такие функции часто не проверяют гипотезу, а просто съедают бюджет.
Главный вопрос простой:
без этой функции приложение не сможет работать или нам просто хочется “как в Telegram”?
Если второе — лучше отложить.
Где обычно растёт бюджет
Бюджет растёт не из-за самого экрана чата.
Он растёт из-за деталей.
Например:
нужно хранить фото и документы;
нужно доставлять push-уведомления;
нужно показывать прочитано/не прочитано;
нужно синхронизировать переписку на разных устройствах;
нужно сделать админке доступ к чатам;
нужно добавить жалобы;
нужно блокировать пользователей;
нужно тестировать плохой интернет;
нужно продумать безопасность.
В итоге предприниматель думал, что добавляет “одно окно”.
А по факту добавил целый кусок продукта.
Иногда это оправдано.
Но иногда чат добавляют просто потому, что он привычный.
И тогда бизнес платит за функцию, которая не влияет на запуск.
Когда чат действительно нужен
Чат имеет смысл, если без него ломается основной сценарий.
Например:
- маркетплейс сложных услуг;
- сервис индивидуальных заказов;
- B2B-платформа с обсуждением заявок;
- доставка, где часто нужно уточнять детали;
- приложение для специалистов, где клиенту важно задать вопрос;
- система, где переписку нужно фиксировать внутри платформы.
Но даже в этих случаях чат нужно проектировать не как “переписку”, а как часть бизнес-процесса.
Кто пишет?
Когда пишет?
Что можно отправлять?
Кто контролирует?
Как решаются споры?
Как это влияет на деньги платформы?
Без этих ответов чат легко превращается в дорогую и неудобную функцию.
Практический вывод
Чат в приложении может выглядеть простым только для пользователя.
Для бизнеса это:
- расходы;
- контроль;
- риски;
- поддержка;
- модерация;
- хранение данных;
- влияние на сделки.
Поэтому перед разработкой стоит задать не вопрос “можно ли добавить чат?”.
Можно.
Правильный вопрос другой:
какую бизнес-задачу решает чат и можно ли решить её проще?
Иногда полноценный чат действительно нужен.
Иногда достаточно комментария к заявке.
Иногда — статусов.
Иногда — шаблонных сообщений.
Иногда — связи через администратора.
Иногда — внешнего мессенджера на первом этапе.
Именно такие решения часто экономят предпринимателю сотни тысяч рублей ещё до начала разработки.
Если вы думаете о мобильном приложении для бизнеса, лучше сначала проверить не список функций, а бизнес-логику.
Что должно быть в первой версии?
Что можно отложить?
Где бюджет может вырасти?
Какие интеграции нужны?
Какие риски появятся после запуска?
Иногда бизнесу действительно нужно полноценное приложение.
Иногда дешевле и быстрее начать с Mini App, CRM, бота или простой системы заявок.
В «САП КОД» мы начинаем не с кода, а с разбора задачи: MVP, бюджета, логики, интеграций и рисков.
Оставить заявку на разбор проекта можно здесь