Знаю, здесь много читателей, которые создают свои стартапы. Если вы один из них, или если вы менеджер продукта, будет полезно посмотреть на две классические ошибки из за которых уходят пользователи, и узнать как не допустить подобного у себя.
Примечание: лично я не имею к команде данного TWA и самого Телеграма никакого отношения. Прочитав эту статью, вы можете убедиться, что даже у крупных стартапов с огромной аудиторией могут быть ошибки и недочёты в продакшене.
Так как это "антигайд", советы ниже воспринимайте с точностью до "наоборот"!
1. Не тестируйте выполненную работу разработчиков
Если разработчик сдал работу и отметил галочкой "готово", даже не проверяйте, она точно работает. И даже не думайте подключать внешнее тестирование, ведь это просто лишние затраты. Позвольте вашим клиентам самим наткнуться на проблемы в вашем ПО, хотя какие в вашем ПО вообще могут быть проблемы?
Так может получиться, что вы повеселитесь, сделав вид, что хотите дать пользователю пользу, а на деле разыграть его, выставив дураком, и отняв у него время:

2. Не добавляйте возможность связаться с вами
У пользователей не должно быть возможность связаться с вами. Зачем вам обратная связь? Вы же наверняка человек занятой, а лишних денег на сотрудника поддержки у вас нет, и так на разработчиков и рекламу всё уходит. Так вы никогда не узнаете, есть ли в вашем продукте проблемы – и правильно, зачем вам лишний стресс!

3. Если даже у вас есть возможность с вами связаться – особо не рассказывайте о ней
Если у вас как в примере бот с TWA, информацию о связи с поддержкой в TWA точно не обязательно размещать. Также как и в ответах на частые вопросы. Если есть места где пользователь может написать в надежде связаться с поддержкой, напишите что поддержка тут не отвечает, но не размещайте никакой информации как связаться с поддержкой.
Вы можете оставить для особо целеустремлённых пользователей информацию на вашем сайте (ссылки на который размещать в TWA и боте конечно тоже не нужно), ну и в описании профиля бота, хотя последнее уже можно посчитать лишним.
Готово!
Пользователи натыкаются на ошибки, не могут с вами связаться, уходят раньше чем находят способ связи, а вы об этом даже не знаете.

Пользовательский путь, или почему пользователь скорее всего уйдёт
Вот даже возьмём в пример меня. Я зашёл в приложение, не особо им пользовался, не особо получил от него какой-то толк. Ну закинул несколько копеек, изредка заглядываю. И мне как бы приложение в целом нейтрально безразлично. Но я не удаляю его, иногда захожу, и это могло бы перейти в более активное использование.
Но происходит следующее, что мы видим на скринах – мне предлагается подарок, а из за того что функционал недостаточно протестировали, я сталкиваюсь с ошибкой: когда я откликаясь на это уведомление и захожу в приложение, у меня будто бы отнимают то, что ещё не успели дать, но сказали что это уже моё.
Ещё недавно я относился нейтрально к приложению, а теперь оно побеспокоило меня, и устроило такой малоприятный розыгрыш!
Тут я готов войти в понимание, что специального злого умысла вероятнее всего не было по отношению ко мне, и это лишь ошибка. И хочу сообщить об этом команде – службе поддержки, разработчикам, владельцу, кому угодно. В этом же разделе я не нахожу информации как связаться, как и во всём TWA. Начинаю уже гадать, думаю может так как это бот надо написать в чат – пишу, и там сообщения что поддержка не отвечает в этом чате. И то, что в этом сообщении нет инфо как написать в поддержку, наводит на мысли, что поддержки вообще не существует.
Вообще кто как-то сталкивался с действиями "среднестатистического пользователя", может работал с обращениями в поддержку, или смотрел вебвизор, или наблюдал со стороны вживую, вероятнее всего заметили, что создавая продукт для пользователей, н��жно рассчитывать, что они будут максимально "деревянные", то есть не стоит рассчитывать, что они будут очень догадливые и смекалистые, а также настойчивы в желании использовать ваш продукт.

Это означает, что продукт должен быть максимально простым в использовании, одинаковые элементы всегда должны быть в одних и тех же местах (например не нужно менять местоположение кнопки "назад" или кнопки "профиль" на разных страницах).
Также всегда под рукой должна быть информация как связаться с поддержкой, т.к. часто бывает, что пользователю нужна помощь. Даже с отделом тестирования баги иногда попадают в прод, и особенно если вы просите оплату с пользователей, позаботьтесь о том, чтобы они могли сообщить вам об ошибке, даже если вы не готовы обеспечивать возможность ответить им в следующие же 5 минут. Везде "как связаться с поддержкой", на каждой странице. Точно так же как кнопка "целевого действия" должна повторяться практически на каждой секции лендинга, чтобы пользователь мог сразу ей воспользоваться, не листая долго вверх и вниз.
Да, я начал гуглить сайт, и позже нашел в шапке бота ссылки на поддержку. Но перед эти�� я сделал три попытки связаться с поддержкой в логичных для этого местах. Сколько реальных пользователей дойдёт до второй, третьей попыток? На самом деле очень немного. Среднестатистическому пользователю проще удалить приложение, если что-то не получается. Существенная часть пользователей даже не станут искать способы написать в поддержку.
Справедливо будет сказать, что поддержка ответила быстро, и оперативно решили проблему. В этом они не облажались, и моя лояльность сохранена. Но повторюсь, я предпринял для этого больше действий, чем количество, на которое стоит рассчитывать.
Эти ошибки просты, но очень распространены
Не допускайте их у себя, тем самым станете ближе к пользователям, и повысите успех своего продукта! Помните – репутация растёт медленно, а падает быстро. Если пользователи столкнутся с нерабочим продуктом, и невозможностью связаться с поддержкой, они переморщатся и отвернутся навсегда, и ещё могут анти-рекомендации давать другим людям – мол у них ничего не работает там, и на пользователей им плевать.
Когда я лично в своих продуктах разместил возможность мгновенной связи со мной или службой поддержки, это было одним из лучших решений, так как я получил много полезной обратной связи и сообщений об ошибках, которые смог устранить на лету.
Спасибо за внимание!
Надеюсь статья была полезна. Такой формат-стиль "анти-гайд" для меня экспериментальный.

Я Андрей Рик, ИТ-волшебник, с 9 лет занимаюсь написанием кода, помог запуститься множеству продуктов, и за более 12 лет коммерческого опыта обрёл большую насмотренность как "должно" и как "не должно" быть, что работает а что не работает. Если вы чувствуете, что у вас могут быть похожие моменты, но не знаете как их выявить, можете обратиться ко мне за аудитом и консультацией.
Также можете подписаться на мой телеграм-канал @fullstack_freelancer, где я миксую лайв-контент жизни разработчика, с полезными советами, и мыслями о саморазвитии.
Всем добра и лояльности от пользователей!