Развитие онлайн-диспетчерской такси

Стороннее решение

Доработка фукционала

API

для доработок

3

этапа

Клиент

Диспетчерская такси
Услуги
  • Дополнительные услуги
  • Разработка онлайн-калькуляторов

О клиенте

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

Какая боль?

Крупные операторы такси постепенно захватывают рынок.

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

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

Обратились к знакомому - где взять толковых прогеров на проект?

И ему порекомендовали нас.

Задача №1 - форма заказа такси на сайте

Проблема

Разработчики комплекса предлагали для использования на сайте только такой вариант: два поля для ввода адресов и кнопка “заказать”. Как стандартная форма заявки. Что-то типа этого:

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

  • поиск,

  • отложенные заказы,

  • отслеживание заказа на карте,

  • использование бонусов,

  • дополнительные опции

  • и прочее.

Этого не было в программном комплексе такси в API.

Программный комплекс предлагал:

  • сервер,

  • приложение водителя,

  • приложение клиента,

  • диспетчерская

  • и т.д.

При всем богатстве предлагаемого функционала не было возможности прикрутить готовый подходящий вариант. Клиентам сильно не хватало этого функционала.

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

Решение

Пришлось спроектировать это веб-приложение - сценарий использования не совсем простой. Не просто “забил адрес 1, забил адрес 2”.

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

  2. Во-вторых, получается 2 экрана состояния - когда ты только заказываешь машину и когда уже нажал на кнопку “поиск машины”, то уже другой экран - все параметры заказа выводятся, тут же в реальном времени выводится:

    1. Машина назначена - тебе надо подтвердить что ты увидел уведомление.

    2. Машина подъезжает, водитель у себя нажимает кнопку “я на месте”.

    3. На сайте тут же появляется уведомление о том, что машина уже на месте, подтверждаешь что уже выходишь.

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

  4. Так же добавили аутентификацию по номеру телефона и подключили бонусы

Задача №2 - Подключить онлайн-оплату

Проблема

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

  1. Основное неудобство водителям доставляло пополнение счета через терминалы типа “Киви”. Учитывая то что на условный сибирский город подобных аппаратов в среднем всего 2 штуки - такое себе удовольствие. Да и зачем, если можно принимать платежи онлайн? 

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

Решение

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

Задача №3 - такси-бот

Проблема

Далее продолжили работать с клиентом - подкинули нам еще один незавершенный проект. На этот раз это был такси-бот. Разобрались что уже есть, что хотели, что можем сделать. Подразумевалось, что бот нужен не только для Telegram, но и для Вк. А также с перспективой подключения всех мессенджеров, с которыми бота реально подружить.

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

Решение

Основные фичи такси-бота:

  • Базовые функции - работа с кнопками, отправка сообщений. ты ему вопрос, он тебе ответ.

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

  • Тарификация по зонам.

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

  • Избранные адреса, маршруты - в конце поездки бот предлагает создать любимый маршрут. Удобно если часто ездишь по одному и тому же маршруту, не нужно выбирать начальную и конечную точку.

  • Отказоустойчивость. Сделали так, чтобы бот не падал из-за неадеквата, повышенной нагрузки, пропавшей сети. Адекватно реагировал на непонятные диалоги и прочие узкие места.

  • Функция “Спросить гео-локацию”: Отслеживание машины к пункту отправления; Где машина находится во время заказа.

Времени потратили - множество часов на тестирование и тестовое использование. Также реализовали механизм отлова ошибок. Если что-то пойдет не так, то пользователь не зависнет в диалоге. Будет уведомление в системе и запись в лог.

Узкие места

Больше всего заморочек обнаружилось у ВК. Причем, заморочки эти отсутствовали в документации. Например:

  • Для стабильной работы ВК сервер пришлось перенести в московский дата-центр, так как отклик из Сибири для ВК слишком долгий. Бот начинал разговаривать с ошибками долгого ожидания и падал.

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

Вывод

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

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

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

Клиент

Диспетчерская такси
Услуги
  • Дополнительные услуги
  • Разработка онлайн-калькуляторов

Нас легко найти

Посмотреть на карте Перми
© ООО «Praweb», 2022