Приложение для делового сообщества: два макета по три экрана

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

Задача

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

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

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

Что я предложил

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

Макет 1. Запрос вместо потока в чате. Идея: приложение сразу находит нужного человека.

• Главная. Большое поле «Кого ищем сегодня?». Участник пишет задачу обычным языком, например, нужен юрист по загородной недвижимости. Ниже его прошлые запросы с количеством откликов и рекомендаций, а также люди, которые могут помочь.
• Подбор ИИ. По запросу система находит нескольких участников и объясняет, почему именно их. Например, один вёл споры в нескольких посёлках, его рекомендовали другие участники. У другого общая знакомая, которая была у него на консультации.
• Карточка человека. Кто это, чем занимается, что ищет, где находится сейчас и какие у вас общие контакты.

Макет 2. Ужин, города и клуб в одном месте. Идея: ИИ подсказывает, с кем познакомиться на встрече, а подписка клуба приносит выручку между событиями.

• События. Фильтр по городам, ближайшие встречи с числом оставшихся мест, кнопка покупки билета и календарь.
• Знакомства на ужине. После покупки билета приложение показывает, сколько человек придёт, и выбирает троих, с кем стоит познакомиться: что человек делает, что ищет и чем вы можете быть полезны друг другу. Можно написать сразу всем троим до встречи.
• Клуб. Подписка с набором преимуществ: консультации юриста раз в месяц с остатком, партнёрские условия, закрытые ужины раньше всех и со скидкой, доступ в несколько городов.

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

Что учёл и где риски

Самое слабое место макетов в том, что они держатся на допущениях. В списке открытых вопросов у меня несколько пунктов.

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

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

Третий: данные. Подбор людей по запросу означает, что приложение обрабатывает профили и намерения участников. Для этого нужны согласие участников на показ профиля, возможность скрыться и понятные правила, откуда берутся рекомендации. Для сообщества с участниками из разных стран это ещё и вопрос применимого права. Базовые вещи я описывал в статье про 152-ФЗ для организатора мероприятий.

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

Пятый: формат. Для такого продукта можно сделать мини-приложение в мессенджере, PWA или нативное приложение. Варианты я разбирал в статьях про PWA из сайта за выходные и про бота вместо мобильного приложения. Для первой версии я бы выбрал то, что быстрее проверяется на живом сообществе.

В каком статусе

Экраны это картинки, а не рабочие страницы. Подбор ИИ в них показан иллюстрацией, настоящей модели за ним нет. Я не проверял его работу на данных сообщества.

Что дальше

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

Если ответа не будет, макеты остаются примером того, как деловое сообщество можно превратить из чата в сервис, и эту же логику можно применить к другому сообществу.

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

Приложение уже существует?

Нет. Есть два макета по три экрана. Разработка не начиналась, договора нет.

ИИ-подбор уже работает на данных сообщества?

Нет. В макете это иллюстрация. Как будет вести себя подбор на реальных профилях, предстоит проверить на малой группе.

Это то же, что чат или бот?

Чат остаётся местом общения. Приложение нужно, чтобы запрос не тонул, участники находились по задачам, а встречи и клуб были в одном месте. Для первой проверки часть сценариев можно собрать в боте.

Коротко о главном

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

Если у вас сообщество, клуб или серия мероприятий, посмотрите разработку сайтов и приложений. Напишите в Telegram, MAX или VK, обсудим, какой сценарий проверить первым.