Logo

Билетные системы

Хоть на край света!

Вероятно, один из самых сложных для создания и развития вариантов веб-приложения.

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

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

Как осуществляется реализация поиска?

Откуда берутся билеты?

Вопреки возможным заблуждениям, билеты приобретаются не напрямую у авиакомпаний. Для этого существуют Глобальные Дистрибьюторские Системы, GDS. Авиакомпании предоставляют тарифные сетки этим системам, которые, в свою очередь, осуществляют предоставление конечным агентам предложений.

Однако, если работать только с одной GDS, вы можете упустить (а значит, и не предоставить клиентам) массу более выгодных предложений от других.

Мы в этом вопросе полагаемся на опыт сотрудничества с webservices.aero.
Это модульная система организации многоуровневой сети продажи авиабилетов

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

  • Нет необходимости отдельно интегрировать API каждой отдельной GDS, все предложения поступают по одному запросу;
  • «Подводные камни» в виде санкций за невыполнение определенных процессов со стороны GDS ликвидируются изначально, нет необходимости в лишних часах наладки;
  • Высокая скорость выдачи;
  • Быстрая интеграция новых «плюшек» и критических требований со стороны авиакомпаний или самих GDS;
  • Выгодное (по сравнению с оригинальной выдачей) представление поисковых результатов, поддающееся более масштабной обработке без потери ресурсов и без затраты излишних средств на приобретение или аренду более дорогих серверных ресурсов;
  • Возможность предоставить клиенту несколько методов онлайн-оплаты;
  • Интеллектуальные алгоритмы поиска: например, при поиске билета по маршруту система автоматически просматривает альтернативные варианты пересадок на предмет понижения цены перелёта, а ещё просматривает предложения на предмет возможности стыковки двух или более перелётов в рамках предложений от разных GDS от разных авиакомпаний и без привязки к Альянсам. Это особенно актуально для ситуации, когда ваш Клиент находится не в городе, являющемся крупным авиационным хабом.
  • Календарь цен - возможность предоставить клиенту для сравнения стоимости перелётов на соседние даты, что является несомнным плюсом;

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

  • Возможность интеграции агентского блока в рамках b2b-услуг в любом вашем офисе. При этом вы будете видеть графики и отчетность в рамках каждого офиса и отдельно - вашего сайта;
  • Для быстрого опционального решения, требущего минимальных вложений, предоставляется несколько вариантов b2c-решения.
  • Возможность интеграции любого сервиса оплаты на ваш выбор помимо предоставляемых сервисом;
  • Интегрированные в агентском блоке возможности расширенной работы с клиентом - уведомления на почту и в SMS, автозаполнение данных;
  • Возможность выбрать любую альтернативную систему уведомлений;
  • Экспорт в любую систему учета/отчетности (если она имеет возможность импорта), включая 1С;

Что следует знать?

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

Вот несколько шагов для создания приложения для поиска и продажи авиабилетов.

Четкое техническое задание

Уровень сложности - 10 из 10 :)

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

Разработка дизайна

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

Консультативно или нашими силами сюда включаются следующие этапы:

  • Отработка представлений формы поиска

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

  • Отработка представлений результатов поиска

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

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

  • Разработка мобильной версии сайта

    Мобильные представления (а в их необходимости, я думаю, ни у кого нет сомнений) прорабатываются для всех элементов. Тут помогают в том числе и варианты результатов поиска с меньшей информативностью, просчитываются и создаются модальные или скрываемые блоки.

  • Менее сложные элементы

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

    Все эти элементы упрощаются или усложняются в зависимости от Ваших амбиций.

  • Разработка стиля бланка билета

    Билет, который мы отдаем пользователю после покупки, пока ещё не является бланком строгой отчетности, однако красивое индивидуальное отображение, которое отдается для скачивания, например, в формате pdf, заявляет о серьезности Вашего сайта.

  • Любые другие решения

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

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

Программная разработка

  • Фреймворки в качестве основы

    С течением времени становится абсолютно ясно, что для серьезных приложений CMS «со всем готовым» - это лишь помеха. Больше лишнего - больше веса, меньше пользы. Основные элементы системы все равно необходимо прорабатывать индивидуально.

    Поэтому в качестве основы для разработки мы выбираем фреймворки - причем в самом минималистичном варианте.

  • Любое количество языков системы

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

    Отдельно стоит упомянуть, что при переводе на языки с написанием справа налево (Арабский или Иврит, например), дизайн должен быть подготовлен к этому. Тут масса факторов - расположение блоков, тени, шрифты и многое другое нельзя менять внезапно, это повлечет за собой низкую или отсутствующую конверсию, поэтому к таким действиям необходимо готовиться заранее.

    Мы всегда рекомендуем осуществлять перевод (либо сами его заказываем) исключительно силами носителей языка перевода (то есть русский язык для них должен быть иностранным).

  • Интеграция внешних сервисов.

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

    Всё это - обычно - требуется в самом неожиданном варианте и виде.

  • Создание онлайн-чатов.

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

  • Настройка любых событий и сервисов

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

    А ещё можно присылать вам уведомления о свежей покупке билета на выбранном направлении, или о том, что у определенного пользователя сегодня День Рождения (вдруг вы захотите для повышения лояльности предложить ему тур со скидкой?)

  • Разработка административного интерфейса.

    То, что остается за кадром для пользователя. У готовых CMS есть административная панель, но её польза в нашем случае также весьма сомнительна. Нам (а точнее сказать - вам) нужны будут абсолютно уникальные, не схожие с обычными функциональные особенности.

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

    Управление пользователями: выбор более или менее лояльных, сортировка, удаление, да мало ли какие ещё действия придут вам в голову?

    Переключатели: разорвали договор с поставщиком услуг, чей API интегрирован в Вашем приложении? Вот кнопки, чтобы отключить его из выдачи. Запущен A/B-тест с новым дизайном элемента (а в ходе развития сайта это понадобится) и результаты показывают, что можно повысить процент пользователей, переходящих в новый дизайн? Вот кнопка и поле для ввода нового процентного соотношения.

    При создании чата сюда так же должен включаться отдельный интерфейс для общения с пользователями.

  • Тестирование

    После того, как мы всё разработаем, мы всё будем тестировать. И вас тоже к этому привлечём.

  • Запуск

    В зависимости от тяжести финальной или промежуточной версии приложения данный этап может занимать разное количество времени

Это лишь верхушка айсберга. Среднестатистическое техническое задание по такой системе занимает от 10 листов убористым шрифтом.

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