Собственная билетная платформа за 1000 USD. Миф или реальность?

В статьях «Классика жанра» и «Хочу свой сайт для продажи билетов…» я уже описывал разработку сайтов, отталкиваясь от множества однотипных заказов, размещаемых на фриланс-биржах. В этой статье хочу уделить внимание смежному множеству задач из тех же краев. Речь пойдет о создании билетных платформ, по усредненной постановке: «Хочу свою собственную платформу, как Eventbrite или Ticketmaster, бюджет – 1000 баксов».

Зачем эта статья?

Думаю, что заказчики платформ в массе своей профессионалы с опытом организации событий и продажи билетов через свои и чужие сайты, мобильные приложения, социальные сети. Они уже использовали системы основных участников рынка, и этот опыт привел их к желанию создать собственную платформу для управления событиями и продажами. Как правило, они хорошо понимают, как все устроено организационно, и не осознают, как все работает технически. И это причина неверной оценки работы по созданию платформы в начале проекта, и фрустрации в конце.

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

Что нам стоит дом построить. Нарисуем - будем жить

Сравним, хотя бы приблизительно, создание сайтов (frontend) и платформы (backend) со строительством домов в городе. Предположим, у профессионального застройщика уже есть несколько модульных домов-сайтов, удачно построенных и подключенных к коммуникациям, таким как электроэнергия, тепло, вода, канализация. Эти дома приносят прибыль, но за коммуникациями виднеется ТЭЦ (платформа), которой надо постоянно платить.

В какой-то момент, заказчик-застройщик решает, что ему нужна собственная ТЭЦ, чтобы класть деньги за «коммуналку» в свой карман, и не только от своих жильцов, но и от жильцов других домов, построенных другими заказчиками. Мыслится так: «Круто же! Кто как не я, съевший собаку на строительстве и обустройстве города, достоин собственной ТЭЦ». Добавляет масла в огонь то, что с улицы ТЭЦ выглядит просто «коробкой», даже поменьше тех, что заказчик уже строил. Вот так, по внешнему виду здания ТЭЦ и определяется ее цена - пресловутая тысяча баксов.

ТЭЦ как backend
ТЭЦ как backend

Что ускользнуло от внимания заказчика? Верно, вся начинка ТЭЦ, которая сильно сложнее, технологичнее, и, как следствие, дороже его домов-сайтов. Заказчика не смущает, что модульный дом-сайт ему собрали на одной из популярных CMS за неделю, а ТЭЦ строят уже 8 лет и конца и края этому процессу не видно. Ему не важно, что ТЭЦ бесконечно эволюционирует в руках опытных разработчиков. Заказчик - умный, и найдет «свободного каменщика» на фриланс-бирже, который за пару недель построит ему «вот точно такую ТЭЦ, только меньше и другую».

Продолжая аналогию. Что под капотом?

Обычному жильцу дома, совершенно не видно и абсолютно не интересно, откуда в его квартире берется тепло, горячая вода и электроэнергия. Очевидно, у среднестатистического пользователя околонулевые знания как о внутреннем устройстве ТЭЦ, так и о том, как «коммуналка» поступает в его квартиру по API. Жильцу главное, чтобы было бесперебойно тепло, светло и сухо. Точно также, и покупателю билетов нужно быстро и за минимум кликов купить билеты на понравившиеся места, без изучения внутреннего строения платформы.

Проблема в том, что «тысячедолларовый заказчик» смотрит на платформу как обычный покупатель билетов, ошибочно полагая, что сайт (frontend) – это и есть большая часть платформы, и представляя, что чем меньше кликов – тем проще система. А это совсем не так. Во-первых, frontend обычно составляет не более 20% проекта, тогда как backend – 80% и более.

Собственная билетная платформа за 1000 USD. Миф или реальность?

А во-вторых, чем меньше кликов делает пользователь, тем больше действий делает за него платформа. В итоге выходит, что центральный сервер платформы - сложная штука, которая старается сделать все сама, уменьшив количество действий пользователей всех ролей до возможного минимума.

Обрисую крупными мазками некоторые процессы в билетной платформе, которые надо бы реализовать за 1000 USD:

Продажа билета – это ключевое взаимодействие платформы, то, ради чего все и затевалось. Чтобы продать даже один, самый маленький билетик, надо дать возможность пользователю выбрать событие и сеанс, показать ему схему зала, где у каждого места есть координаты (сектор, номер ряда, номер места), статус (свободно, забронировано, продано), ценовая категория, тариф (например, взрослый или детский). Наглядно понять, сколько параметров и настроек нужно задать и сохранить (в быстрой СУБД) для вывода события в продажу можно по скриншоту главного окна Редактора Событий платформы BIL24.

Редактор платформы BIL24
Редактор платформы BIL24

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

После успешной оплаты, необходимо выпустить билет по созданному организатором шаблону, разместить на нем штрихкод и/или QR-код для системы контроля доступа. Часто, данные билета, штрихкод и QR-код нужно своевременно получить из внешней системы. После формирования билета, егот необходимо отправить покупателю на email или в мобильный мессенджер. А если пользователь захочет вернуть билет, то нужно присвоить билету статус «возвращен» и вернуть в продажу место, на которое он был куплен.

Роли пользователей и их взаимодействие. Любая платформа – это, прежде всего, про роли пользователей, их взаимодействие в экосистеме и сетевые эффекты. Основные роли пользователей в платформе для билетного рынка - это Организатор, Агент и Покупатель билетов.

Цикл взаимодействия пользователей
Цикл взаимодействия пользователей

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

API экономика (API Economy) – важнейшая часть мира платформ, или наоборот (как кому нравится). С помощью API билетные платформы как получают информацию о событиях, сеансах, схемах, местах и ценах, так и отдают её. Создание современной платформы без собственного API и реализации множества API сторонних систем – довольно бессмысленное занятие.

Собственная билетная платформа за 1000 USD. Миф или реальность?

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

Как мы создаем платформу и сколько уже потратили

Мы, как команда разработчиков, создаем платформу BIL24 с 2015 года. Уже потрачено около 40 000 нормо-часов, и платформа продолжает эволюционировать с ускорением. Исходя из рыночной стоимости нормо-часа опытного разработчика, можно прикинуть, во сколько реально обходится только создание (не эксплуатация) такой платформы.

Очень хочется свою платформу. Как быть?

Воспользовавшись услугой Собственная платформа, можно сразу начать работать, подключать клиентов и оттачивать бизнес-процессы, пропустив длительный и затратный этап разработки. С этой услугой, заказчик-застройщик сразу получает собственную «виртуальную ТЭЦ», подключает к ней свои и чужие дома-сайты. С полной техподдержкой. Довольно удобно, если не сказать больше.

8
4 комментария

Допиливаем за $1000 свой маркетплейс европейских футбольных билетов. Приглашаем продавцов и инвесторов в билеты.

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

1
Ответить

Мне кажется неправильно "многих людей" считать дебилами, а "зрелые бизнесы" наоборот шибко умными. В зрелых бизнесах, особенно с госучастием, надо пройти 7 кругов ада, прежде чем что то произойдет. Поэтому зрелые бизнесы часто сами себя сжирают этой бюрократией. А "многие люди" (малый бизнес) этим не ограничены. И то, что люди запорят пару тройку проектов - им на пользу. Купить такой опыт за 1000 долларов - это отличная инвестиция. Окупится тысячекратно))

4
Ответить

Познавательно

1
Ответить

Комментарий недоступен

Ответить