Да, на самом деле идея как раз и появилась из собственного опыта
Когда переехал в Тверь, сам столкнулся с тем, что банально не мог нормально найти людей для футбола. В итоге месяцами лазил по чатам, группам, комментариям и пытался понять: - где вообще собираются люди - кто реально играет - как попасть - состоится ли игра
А потом уже начал наблюдать сам процесс организации изнутри и увидел, насколько многое держится буквально на одном человеке.
И чем дальше читаю комментарии, тем сильнее понимаю, что вы очень правильно подсветили одну важную мысль: возможно, главный пользователь системы - действительно не участник, а именно организатор.
Потому что участнику важны: - минимальный friction - быстро ответить - получить напоминание - прийти
А организатору как раз нужна вся структура: - подтверждения - голосования - добор людей - напоминания - повторные сборы - фиксация активности
И если честно, идея с ботом внутри существующих чатов сейчас уже тоже начинает выглядеть намного логичнее, чем попытка сразу увести людей в отдельную платформу.
Да, я как раз постепенно тоже начинаю приходить к мысли, что при росте масштаба мероприятия проблема координации начинает резко усложняться
Потому что одно дело - собрать знакомых людей в чате. И совсем другое: - незнакомые участники - билеты - подтверждения - QR-вход - отмены - подрядчики - аналитика - повторные мероприятия - коммуникация после события
И чем больше читаю комментарии и общаюсь с организаторами, тем сильнее понимаю, что здесь действительно постепенно начинает появляться B2B-слой.
Но при этом мне всё равно кажется важным не терять и сторону самих сообществ/участников, потому что именно вокруг них в итоге и возникает движение внутри системы.
Скорее сейчас вижу это как постепенное движение: от community/coordinator продукта → в сторону полноценной event-инфраструктуры.
Мне кажется, тут как раз очень важна разница между «регистрацией на мероприятие» и постоянной координацией сообщества
Потому что для разового события действительно часто достаточно простой формы:
- зарегистрировался
- получил билет
- пришёл
И подобных сервисов уже много.
Но чем больше я изучаю тему, тем сильнее вижу, что самые сложные сценарии начинаются именно там, где активность становится регулярной:
- спорт
- локальные сообщества
- клубы
- повторяющиеся встречи
- совместные активности
Где уже появляются:
- постоянное ядро людей
- повторяемость
- добор участников
- отмены
- координация
- удержание активности
И вот там обычная «регистрация на мероприятие» уже начинает не закрывать всю проблему.
Поэтому я сейчас всё меньше смотрю на Gooly как на «сервис регистрации», и всё больше - как на попытку упростить саму координацию офлайн-сообществ и повторяющихся активностей.
Если честно, я как раз всё больше начинаю понимать, что без подобных механик дальше социальные продукты действительно будут запускаться всё тяжелее
Потому что сейчас организатор во многом вручную выполняет роль: - координатора - диспетчера - напоминалки - человека, который постоянно «толкает» активность вперёд
И чем дальше, тем больше появляется мысль, что часть подобных процессов действительно логичнее отдавать автоматизации и AI-механикам: - добор участников - напоминания - повторные сборы - рекомендации - поиск похожих людей и активностей - удержание активности внутри сообщества
Так что, возможно, «бот-массовик-затейник» - это уже не шутка, а вполне реальное направление развития подобных систем 😄
Да, с обратной связью полностью согласен - сейчас как раз начинаю понимать, насколько на раннем этапе важно максимально быстро получать сообщения от пользователей прямо внутри системы. Пока в основном общение шло через Telegram после статей на Хабре, но полноценный feedback-виджет/чат уже действительно нужен.
По городам тоже согласен. Изначально список специально ограничивал на этапе закрытого тестирования, чтобы не плодить пустые города внутри системы, но сейчас регистрация уже открыта, поэтому буду постепенно добавлять все крупные города.
И отдельное спасибо за замечание про письмо - такие вещи самому иногда уже сложно замечать после долгой работы над проектом 😄
Вот это, кстати, очень интересный пример того, насколько по-разному выглядят разные типы мероприятий
Потому что в походах, как мне кажется, сама организация действительно больше похожа не на «одного организатора и участников», а на маленькую распределённую команду, где у каждого появляется своя зона ответственности.
И как раз из-за этого там возникает огромное количество долгих процессов: - подготовка - закупки - логистика - снаряжение - распределение ролей - согласование маршрутов - билеты - трансферы
Причём всё это растягивается не на один вечер, а иногда на недели и месяцы.
И ещё очень точно подмечена история про ядро сообщества.
Потому что чем больше читаю подобные комментарии, тем сильнее замечаю, что многие офлайн-активности держатся не столько на самом событии, сколько на устойчивом круге людей вокруг него.
А когда это ядро распадается - из-за переездов, семьи, работы, детей - зачастую начинает разваливаться и сама активность, даже если интерес к ней у людей остаётся.
Вот это уже вообще уровень, о котором обычный человек даже не задумывается 😄
И самое интересное, что подобные вещи действительно начинают выглядеть «мелочью» ровно до того момента, пока один VIP-гость не окажется аллергиком на что-нибудь, веганом, человеком с особыми требованиями или просто не вспомнит, что в прошлый раз организаторы учли его предпочтения, а сейчас - нет.
И в этот момент оказывается, что за хорошим мероприятием стоит не только логистика, а огромный пласт накопленного контекста о людях, взаимодействиях и опыте.
А дальше начинается: - таблицы - CRM - заметки - личные сообщения - комментарии менеджеров - история посещений - отдельные файлы «на всякий случай» 😄
И чем больше читаю подобные кейсы, тем сильнее понимаю, что event management - это на самом деле очень data-heavy сфера, просто большая часть этих данных до сих пор живёт в максимально хаотичном виде.
Вот после таких комментариев начинаешь ещё сильнее понимать, насколько организация мероприятий - это на самом деле огромная отдельная индустрия со своим уровнем сложности
Потому что когда смотришь со стороны обычного участника, кажется: «ну собрали людей, арендовали площадку и всё».
А потом появляются: - международные мероприятия - онлайн/офлайн гибриды - логистика - подрядчики - безопасность - погодные условия - тайминги - VIP-гости - ограничения площадок - медицина - тот самый клещ, за которого отвечает уже организатор 😄
И в какой-то момент понимаешь, что event management - это уже не просто «организация события», а полноценное управление огромным количеством зависимых процессов и рисков.
Мне сейчас очень интересно читать подобные комментарии именно потому, что они помогают увидеть, насколько глубоко вообще может масштабироваться сама проблема координации людей и процессов вокруг мероприятий.
Вот это как раз очень хорошо показывает, насколько сильно уровень сложности мероприятий растёт вместе с масштабом и требованиями
И да, история с бейджами — отличный пример того, как вокруг одного события постепенно начинает появляться огромное количество отдельных сервисов, костылей и связок между системами.
И в какой-то момент организатор начинает уже не мероприятие делать, а буквально управлять целой распределённой инфраструктурой.
На самом деле именно из-за таких историй у меня постепенно и появляется мысль, что в идеале система должна закрывать не только «создание мероприятия», а вообще весь цикл процессов вокруг него.
Потому что сейчас очень многое существует фрагментированно и сильно зависит либо от бюджета, либо от опыта конкретного организатора, либо вообще от количества ручной координации.
И отдельно очень интересно читать подобные кейсы именно от людей из более серьёзного event-сегмента, потому что начинаешь намного лучше видеть, насколько глубоко вообще может уходить эта проблема.
Вот как раз после подобных комментариев всё сильнее понимаю, насколько огромный пласт процессов вообще находится вокруг мероприятий
Потому что на самом деле само «создание события» — это только верхушка айсберга.
И да, часть вещей уже сейчас есть в системе. Например, QR-подтверждение входа участников: человек приходит на мероприятие, QR-код сканируется, и в системе сразу фиксируется его присутствие.
Но чем дальше этим занимаюсь, тем больше появляется мысль, что в идеале хочется связать в одной системе вообще весь цикл организации мероприятий: — организаторов — участников — площадки — ведущих — фотографов — подрядчиков — бронирования — доступность по датам — портфолио — координацию — аналитику после события
Потому что сейчас очень многое существует фрагментированно: что-то в чатах, что-то в таблицах, что-то в заметках, что-то в голове организатора.
И в какой-то момент сама организация мероприятия превращается уже не в «создать событие», а в управление огромным количеством коммуникаций между людьми.
Да, вы правильно подсветили несколько сложных мест.
Только я бы разделил это на текущий этап и будущую инфраструктуру.
Сейчас Gooly не интегрируется с системами бронирования площадок и не обрабатывает платежи внутри платформы. Оплата, если она есть, идёт напрямую между участником и организатором, а в системе фиксируется только организационный статус участия.
На текущем этапе задача проще: проверить, помогает ли структура события организатору собрать людей лучше, чем обычный чат.
Интеграция с площадками и бронированиями - это уже следующий слой, и там действительно появляются отдельные вопросы: безопасность, права доступа, синхронизация, юридическая модель, персональные данные и т.д.
Поэтому я не пытаюсь сразу строить «единую систему для всех площадок». Сейчас проверяю базовый сценарий: событие -> участники -> подтверждение -> повторяемость.
Если этот сценарий подтвердится, тогда уже можно аккуратно двигаться в сторону B2B и интеграций, но не наоборот.
Как только сценарий становится сложнее обычного «иду/не иду», организатор превращается уже не просто в человека, который создал чат, а в координатора всей логики: - кто идёт - кто голосовал - кто слился - как пересекаются интересы участников - как принять итоговое решение
И всё это приходится держать вручную.
Про интеграции с мессенджерами — хороший поинт, взял на заметку. Нужно подумать в этом направлении, потому что людям действительно важно оставаться в привычной среде.
На самом деле это как раз хороший пример того, как люди постепенно сами достраивают систему поверх обычного чата
Появляются: - правила - штрафы - отдельные чаты - фиксация оплат - ограничения - ручная модерация
И да, для многих сообществ этого действительно достаточно.
Но мне как раз стало интересно: можно ли часть этой организационной нагрузки снять с организатора и превратить это в более структурированный процесс.
Потому что чем больше людей, организаторов и регулярных активностей — тем сильнее всё начинает держаться на ручном администрировании и дисциплине участников.
Проблемы начинаются обычно позже: - когда активности становятся регулярными - когда появляется несколько организаторов - когда нужно фиксировать оплаты - когда люди начинают сливаться в последний момент - когда нужно добирать участников - когда параллельно идут флуд, мемы и сам сбор
То есть Telegram отлично решает коммуникацию, но не очень хорошо решает именно структурирование повторяющихся офлайн-активностей.
Собственно, из наблюдения за этим и появилась идея Gooly.
Изначально смотрел на проблему только со стороны организаторов и участников, но потом понял, что площадки тоже теряют из-за всей этой неструктурированности: - отмены в последний момент - недоборы людей - пустые слоты - сложность с повторными бронированиями
Поэтому сейчас одна из идей развития - как раз подключение самих площадок в систему.
Чтобы это был уже не просто «чат для сборов», а нормальная инфраструктура: участники ↔ организаторы ↔ площадки.
Скорее тут проблема была не столько у самих владельцев полей, сколько у людей, которые регулярно собирают игроков 🙂
Поле свою задачу выполняет: время забронировано - деньги получены.
А вот дальше начинается хаос уже на стороне организатора: кто придёт, кто оплатил, хватает ли людей, нужно ли срочно кого-то искать и т.д.
Но в процессе как раз понял, что площадки тоже могут получать пользу от такой системы. Например, через нормальную систему бронирований, автоматизацию и более стабильную загрузку.
Да, на самом деле идея как раз и появилась из собственного опыта
Когда переехал в Тверь, сам столкнулся с тем, что банально не мог нормально найти людей для футбола. В итоге месяцами лазил по чатам, группам, комментариям и пытался понять:
- где вообще собираются люди
- кто реально играет
- как попасть
- состоится ли игра
А потом уже начал наблюдать сам процесс организации изнутри и увидел, насколько многое держится буквально на одном человеке.
И чем дальше читаю комментарии, тем сильнее понимаю, что вы очень правильно подсветили одну важную мысль:
возможно, главный пользователь системы - действительно не участник, а именно организатор.
Потому что участнику важны:
- минимальный friction
- быстро ответить
- получить напоминание
- прийти
А организатору как раз нужна вся структура:
- подтверждения
- голосования
- добор людей
- напоминания
- повторные сборы
- фиксация активности
И если честно, идея с ботом внутри существующих чатов сейчас уже тоже начинает выглядеть намного логичнее, чем попытка сразу увести людей в отдельную платформу.
Да, я как раз постепенно тоже начинаю приходить к мысли, что при росте масштаба мероприятия проблема координации начинает резко усложняться
Потому что одно дело - собрать знакомых людей в чате. И совсем другое:
- незнакомые участники
- билеты
- подтверждения
- QR-вход
- отмены
- подрядчики
- аналитика
- повторные мероприятия
- коммуникация после события
И чем больше читаю комментарии и общаюсь с организаторами, тем сильнее понимаю, что здесь действительно постепенно начинает появляться B2B-слой.
Но при этом мне всё равно кажется важным не терять и сторону самих сообществ/участников, потому что именно вокруг них в итоге и возникает движение внутри системы.
Скорее сейчас вижу это как постепенное движение:
от community/coordinator продукта → в сторону полноценной event-инфраструктуры.
Если честно, после вашего первого комментария я как раз и начал об этом серьёзно думать
Потому что чем дальше изучаю поведение людей внутри подобных систем, тем сильнее понимаю, что главная проблема
- не просто «создать событие», а постоянно поддерживать движение:
- напоминать
- добирать людей
- реактивировать активности
- удерживать внимание
- не давать сообществу затухнуть
И в этом месте AI/бот уже начинает выглядеть не как дополнительная фича, а как вполне логичный следующий слой системы.
Потому что сейчас очень многое держится на одном выгоревшем организаторе, который вручную выполняет роль:
«координатора + диспетчера + массовика-затейника»
Мне кажется, тут как раз очень важна разница между «регистрацией на мероприятие» и постоянной координацией сообщества
Потому что для разового события действительно часто достаточно простой формы:
- зарегистрировался
- получил билет
- пришёл
И подобных сервисов уже много.
Но чем больше я изучаю тему, тем сильнее вижу, что самые сложные сценарии начинаются именно там, где активность становится регулярной:
- спорт
- локальные сообщества
- клубы
- повторяющиеся встречи
- совместные активности
Где уже появляются:
- постоянное ядро людей
- повторяемость
- добор участников
- отмены
- координация
- удержание активности
И вот там обычная «регистрация на мероприятие» уже начинает не закрывать всю проблему.
Поэтому я сейчас всё меньше смотрю на Gooly как на «сервис регистрации», и всё больше - как на попытку упростить саму координацию офлайн-сообществ и повторяющихся активностей.
Если честно, я как раз всё больше начинаю понимать, что без подобных механик дальше социальные продукты действительно будут запускаться всё тяжелее
Потому что сейчас организатор во многом вручную выполняет роль: - координатора
- диспетчера
- напоминалки
- человека, который постоянно «толкает» активность вперёд
И чем дальше, тем больше появляется мысль, что часть подобных процессов действительно логичнее отдавать автоматизации и AI-механикам: - добор участников
- напоминания
- повторные сборы
- рекомендации
- поиск похожих людей и активностей
- удержание активности внутри сообщества
Так что, возможно, «бот-массовик-затейник» - это уже не шутка, а вполне реальное направление развития подобных систем 😄
Спасибо большое за такой подробный фидбек
Да, с обратной связью полностью согласен - сейчас как раз начинаю понимать, насколько на раннем этапе важно максимально быстро получать сообщения от пользователей прямо внутри системы. Пока в основном общение шло через Telegram после статей на Хабре, но полноценный feedback-виджет/чат уже действительно нужен.
По городам тоже согласен. Изначально список специально ограничивал на этапе закрытого тестирования, чтобы не плодить пустые города внутри системы, но сейчас регистрация уже открыта, поэтому буду постепенно добавлять все крупные города.
И отдельное спасибо за замечание про письмо - такие вещи самому иногда уже сложно замечать после долгой работы над проектом 😄
Вот это, кстати, очень интересный пример того, насколько по-разному выглядят разные типы мероприятий
Потому что в походах, как мне кажется, сама организация действительно больше похожа не на «одного организатора и участников», а на маленькую распределённую команду, где у каждого появляется своя зона ответственности.
И как раз из-за этого там возникает огромное количество долгих процессов: - подготовка - закупки - логистика - снаряжение - распределение ролей - согласование маршрутов - билеты - трансферы
Причём всё это растягивается не на один вечер, а иногда на недели и месяцы.
И ещё очень точно подмечена история про ядро сообщества.
Потому что чем больше читаю подобные комментарии, тем сильнее замечаю, что многие офлайн-активности держатся не столько на самом событии, сколько на устойчивом круге людей вокруг него.
А когда это ядро распадается - из-за переездов, семьи, работы, детей - зачастую начинает разваливаться и сама активность, даже если интерес к ней у людей остаётся.
Да, кстати, чем дальше погружаюсь в эту тему, тем сильнее начинаю видеть именно эту параллель 🙂
Потому что по сути мероприятие - это действительно маленький живой проект:
- дедлайны
- роли
- ресурсы
- коммуникация
- форс-мажоры
- координация людей
- зависимые процессы
- ответственность организатора
И самое интересное, что многие проблемы там очень похожи на проблемы в IT:
если где-то вовремя не синхронизировались люди или сломалась коммуникация - начинает сыпаться всё остальное.
Только в офлайне это ощущается ещё острее, потому что «откатить прод» уже не получится 😄
Вот это уже вообще уровень, о котором обычный человек даже не задумывается 😄
И самое интересное, что подобные вещи действительно начинают выглядеть «мелочью» ровно до того момента, пока один VIP-гость не окажется аллергиком на что-нибудь, веганом, человеком с особыми требованиями или просто не вспомнит, что в прошлый раз организаторы учли его предпочтения, а сейчас - нет.
И в этот момент оказывается, что за хорошим мероприятием стоит не только логистика, а огромный пласт накопленного контекста о людях, взаимодействиях и опыте.
А дальше начинается: - таблицы - CRM - заметки - личные сообщения - комментарии менеджеров - история посещений - отдельные файлы «на всякий случай» 😄
И чем больше читаю подобные кейсы, тем сильнее понимаю, что event management - это на самом деле очень data-heavy сфера, просто большая часть этих данных до сих пор живёт в максимально хаотичном виде.
Вот после таких комментариев начинаешь ещё сильнее понимать, насколько организация мероприятий - это на самом деле огромная отдельная индустрия со своим уровнем сложности
Потому что когда смотришь со стороны обычного участника, кажется: «ну собрали людей, арендовали площадку и всё».
А потом появляются: - международные мероприятия - онлайн/офлайн гибриды - логистика - подрядчики - безопасность - погодные условия - тайминги - VIP-гости - ограничения площадок - медицина - тот самый клещ, за которого отвечает уже организатор 😄
И в какой-то момент понимаешь, что event management - это уже не просто «организация события», а полноценное управление огромным количеством зависимых процессов и рисков.
Мне сейчас очень интересно читать подобные комментарии именно потому, что они помогают увидеть, насколько глубоко вообще может масштабироваться сама проблема координации людей и процессов вокруг мероприятий.
Вот это как раз очень хорошо показывает, насколько сильно уровень сложности мероприятий растёт вместе с масштабом и требованиями
И да, история с бейджами — отличный пример того, как вокруг одного события постепенно начинает появляться огромное количество отдельных сервисов, костылей и связок между системами.
Сканирование. Регистрация. Печать. CRM. Тайминги. Подрядчики. Аналитика. Коммуникация.
И в какой-то момент организатор начинает уже не мероприятие делать, а буквально управлять целой распределённой инфраструктурой.
На самом деле именно из-за таких историй у меня постепенно и появляется мысль, что в идеале система должна закрывать не только «создание мероприятия», а вообще весь цикл процессов вокруг него.
Потому что сейчас очень многое существует фрагментированно и сильно зависит либо от бюджета, либо от опыта конкретного организатора, либо вообще от количества ручной координации.
И отдельно очень интересно читать подобные кейсы именно от людей из более серьёзного event-сегмента, потому что начинаешь намного лучше видеть, насколько глубоко вообще может уходить эта проблема.
Вот как раз после подобных комментариев всё сильнее понимаю, насколько огромный пласт процессов вообще находится вокруг мероприятий
Потому что на самом деле само «создание события» — это только верхушка айсберга.
И да, часть вещей уже сейчас есть в системе. Например, QR-подтверждение входа участников: человек приходит на мероприятие, QR-код сканируется, и в системе сразу фиксируется его присутствие.
Но чем дальше этим занимаюсь, тем больше появляется мысль, что в идеале хочется связать в одной системе вообще весь цикл организации мероприятий: — организаторов — участников — площадки — ведущих — фотографов — подрядчиков — бронирования — доступность по датам — портфолио — координацию — аналитику после события
Потому что сейчас очень многое существует фрагментированно: что-то в чатах, что-то в таблицах, что-то в заметках, что-то в голове организатора.
И в какой-то момент сама организация мероприятия превращается уже не в «создать событие», а в управление огромным количеством коммуникаций между людьми.
Да, вы правильно подсветили несколько сложных мест.
Только я бы разделил это на текущий этап и будущую инфраструктуру.
Сейчас Gooly не интегрируется с системами бронирования площадок и не обрабатывает платежи внутри платформы. Оплата, если она есть, идёт напрямую между участником и организатором, а в системе фиксируется только организационный статус участия.
На текущем этапе задача проще: проверить, помогает ли структура события организатору собрать людей лучше, чем обычный чат.
Интеграция с площадками и бронированиями - это уже следующий слой, и там действительно появляются отдельные вопросы: безопасность, права доступа, синхронизация, юридическая модель, персональные данные и т.д.
Поэтому я не пытаюсь сразу строить «единую систему для всех площадок». Сейчас проверяю базовый сценарий: событие -> участники -> подтверждение -> повторяемость.
Если этот сценарий подтвердится, тогда уже можно аккуратно двигаться в сторону B2B и интеграций, но не наоборот.
Да, вы очень точно описали проблему.
Как только сценарий становится сложнее обычного «иду/не иду», организатор превращается уже не просто в человека, который создал чат, а в координатора всей логики: - кто идёт - кто голосовал - кто слился - как пересекаются интересы участников - как принять итоговое решение
И всё это приходится держать вручную.
Про интеграции с мессенджерами — хороший поинт, взял на заметку. Нужно подумать в этом направлении, потому что людям действительно важно оставаться в привычной среде.
На самом деле это как раз хороший пример того, как люди постепенно сами достраивают систему поверх обычного чата
Появляются: - правила - штрафы - отдельные чаты - фиксация оплат - ограничения - ручная модерация
И да, для многих сообществ этого действительно достаточно.
Но мне как раз стало интересно: можно ли часть этой организационной нагрузки снять с организатора и превратить это в более структурированный процесс.
Потому что чем больше людей, организаторов и регулярных активностей — тем сильнее всё начинает держаться на ручном администрировании и дисциплине участников.
Для разовых и небольших сборов - да, согласен
Я и сам так много лет собирался через чаты.
Проблемы начинаются обычно позже: - когда активности становятся регулярными - когда появляется несколько организаторов - когда нужно фиксировать оплаты - когда люди начинают сливаться в последний момент - когда нужно добирать участников - когда параллельно идут флуд, мемы и сам сбор
То есть Telegram отлично решает коммуникацию, но не очень хорошо решает именно структурирование повторяющихся офлайн-активностей.
Собственно, из наблюдения за этим и появилась идея Gooly.
Да, согласен 🙂
Я как раз постепенно к этому и пришёл в процессе.
Изначально смотрел на проблему только со стороны организаторов и участников, но потом понял, что площадки тоже теряют из-за всей этой неструктурированности:
- отмены в последний момент
- недоборы людей
- пустые слоты
- сложность с повторными бронированиями
Поэтому сейчас одна из идей развития - как раз подключение самих площадок в систему.
Чтобы это был уже не просто «чат для сборов», а нормальная инфраструктура:
участники ↔ организаторы ↔ площадки.
Скорее тут проблема была не столько у самих владельцев полей, сколько у людей, которые регулярно собирают игроков 🙂
Поле свою задачу выполняет: время забронировано - деньги получены.
А вот дальше начинается хаос уже на стороне организатора: кто придёт, кто оплатил, хватает ли людей, нужно ли срочно кого-то искать и т.д.
Но в процессе как раз понял, что площадки тоже могут получать пользу от такой системы. Например, через нормальную систему бронирований, автоматизацию и более стабильную загрузку.