Pull to refresh
8K+
1
Илхом Сафаров@Merney

Программист, CEO Gooly

7
Rating
1
Subscribers
Habr CareerHabr Career
Send message

Да, вы правильно подсветили несколько сложных мест.

Только я бы разделил это на текущий этап и будущую инфраструктуру.

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

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

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

Поэтому я не пытаюсь сразу строить «единую систему для всех площадок». Сейчас проверяю базовый сценарий: событие -> участники -> подтверждение -> повторяемость.

Если этот сценарий подтвердится, тогда уже можно аккуратно двигаться в сторону B2B и интеграций, но не наоборот.

Да, вы очень точно описали проблему.

Как только сценарий становится сложнее обычного «иду/не иду», организатор превращается уже не просто в человека, который создал чат, а в координатора всей логики: - кто идёт - кто голосовал - кто слился - как пересекаются интересы участников - как принять итоговое решение

И всё это приходится держать вручную.

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

На самом деле это как раз хороший пример того, как люди постепенно сами достраивают систему поверх обычного чата

Появляются: - правила - штрафы - отдельные чаты - фиксация оплат - ограничения - ручная модерация

И да, для многих сообществ этого действительно достаточно.

Но мне как раз стало интересно: можно ли часть этой организационной нагрузки снять с организатора и превратить это в более структурированный процесс.

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

Для разовых и небольших сборов - да, согласен

Я и сам так много лет собирался через чаты.

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

То есть Telegram отлично решает коммуникацию, но не очень хорошо решает именно структурирование повторяющихся офлайн-активностей.

Собственно, из наблюдения за этим и появилась идея Gooly.

Да, согласен 🙂

Я как раз постепенно к этому и пришёл в процессе.

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

Поэтому сейчас одна из идей развития - как раз подключение самих площадок в систему.

Чтобы это был уже не просто «чат для сборов», а нормальная инфраструктура:
участники ↔ организаторы ↔ площадки.

Скорее тут проблема была не столько у самих владельцев полей, сколько у людей, которые регулярно собирают игроков 🙂

Поле свою задачу выполняет: время забронировано - деньги получены.

А вот дальше начинается хаос уже на стороне организатора: кто придёт, кто оплатил, хватает ли людей, нужно ли срочно кого-то искать и т.д.

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

Information

Rating
913-th
Location
Тверь, Тверская обл., Россия
Works in
Date of birth
Registered
Activity

Specialization

Фулстек разработчик, Архитектор программного обеспечения
Средний
From 10,000,000 ₽
Git
SQL
PostgreSQL
MySQL
ООП
Базы данных
REST
PHP
PHPMyAdmin
JavaScript