Приложение для такси: кому нужно своё и что в нём действительно сложно

Сценариев, в которых проект окупается, немного, зато они конкретные.

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

Чтобы удержать водителя, агрегатор гарантирует ему загрузку. Чтобы удержать пассажира — короткую подачу. Обе гарантии оплачиваются каждый день, а не один раз на разработке, и именно здесь заканчиваются бюджеты проектов, которые начинались как «сделаем интерфейс лучше». Механика двусторонних площадок подробно разобрана в материале про маркетплейсы.

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

Показательная деталь: к сентябрю 2024 года в России насчитали 234 Telegram-группы и 29 чат-ботов для заказа машины в обход агрегаторов. Спрос на альтернативный канал есть, и обслуживается он кое-как. Но работает это там, где уже сложилось локальное сообщество, а не там, где кто-то выложил приложение в стор.

Комиссия — то, ради чего обычно и начинают считать. По данным Яндекс Про, в Москве это 22% на тарифах «Эконом» и «Минивэн» и 25% на «Комфорте» и выше; в среднем по рынку комиссия агрегатора держится в диапазоне 10–20%, а парк добавляет свои 1,5–8% или фиксированную сумму с заказа. Цифры меняются, но порядок величин такой.

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

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

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

Как только вы принимаете заказ у пассажира и передаёте его перевозчику, вы становитесь службой заказа легкового такси по 580-ФЗ, который действует с 1 сентября 2023 года. Работают три региональных реестра — перевозчиков, легковых такси и служб заказа; данные из них собирает федеральная система ФГИС «Такси», к ней подключены все регионы.

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

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

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

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

Серверная часть — матчинг, расчёт цены, платежи, журнал и реестровый контур, интеграции. Для B2B к этому добавляется пятый продукт: корпоративный кабинет с лимитами и отчётами.

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

Наивное решение — отдать заказ ближайшей по прямой машине. В городе оно ломается сразу: автомобиль в семисот метрах, но за рекой, приедет через двадцать минут, а машина в двух километрах по шоссе — через шесть. Считать нужно время подъезда по дорожному графу с учётом текущей обстановки, а не расстояние по карте.

На время подъезда накладываются правила: класс автомобиля и требования заказа (детское кресло, животное, крупный багаж), рейтинг и история отказов, очередь на стоянке — в аэропортах и на вокзалах порядок подачи часто регламентирован. Отдельно живут предварительные заказы: машину под них нужно зарезервировать и не отдать в город за час до подачи.

Самая тонкая часть — отказы и переназначение. Сколько секунд водитель видит заказ, сколько раз заказ уходит по кругу, когда он поднимается в цене, а когда отдаётся диспетчеру. Здесь система либо работает, либо превращается в генератор жалоб с двух сторон — и здесь же появляются «слепые» заказы без внятных условий, из-за которых водители уходят.

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

Что делают на практике: адаптивная частота опроса (реже на стоянке, чаще в поездке), пакетная отправка точек вместо запроса на каждую, фильтрация выбросов и привязка позиции к дорожному графу — иначе метка «дрожит» и пассажир видит, как машина едет через дома. Плюс работа без связи: во дворах и тоннелях сеть пропадает, трек должен догружаться позже.

Карты — решение с деньгами внутри. Коммерческие сервисы тарифицируются по числу запросов, открытые данные со своим движком маршрутизации требуют поддержки и обновления. Выбор влияет на себестоимость каждой поездки, поэтому считается он на прогнозном числе заказов, а не по принципу «возьмём то, что привычнее».

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

Тарифная сетка почти всегда оказывается сложнее, чем её описывают на старте. Минимальная стоимость, посадка, километры и минуты, зоны и надбавка за выезд, платное ожидание, ночные, детское кресло, багаж, межгород с обратным пробегом.

Дальше выбор между двумя моделями. Фиксированная цена, названная до заказа, — то, к чему приучил агрегатор; она требует прогноза длительности поездки, и ошибка в прогнозе стоит денег перевозчику. Расчёт по факту технически проще, но хуже воспринимается пассажиром и чаще приводит к спорам на выходе из машины.

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

Для корпоративного сегмента добавляется своё: тарифы по договору, лимиты на сотрудника и подразделение, разрешённые маршруты и время, согласование поездки сверх лимита. Это уже не про цену, а про регламент компании, и он у каждого свой.

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

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

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

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

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

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

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

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

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

Ориентиры по нашим проектам: мобильное приложение — от 1,8 млн ₽, а в такси их два, пассажирское и водительское; MVP или PWA для проверки канала — от 1 млн ₽; серверная часть с матчингом, тарифами и админкой под ваш процесс — от 1,7 млн ₽; интеграция с платежами, телефонией, 1С или парковой системой — от 150 тыс. до 1,5 млн ₽ за контур. Оценку делаем бесплатно: оценка проекта и состава работ по вашим вводным.

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

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

Делать «Яндекс, но лучше». Продукт получается функционально похожим и пустым: без водителей нет короткой подачи, без подачи нет пассажиров. Бюджет уходит на функции, а нужен он был на плотность машин — и это расход не разовый.

Экономить на приложении водителя. Оно технически сложнее пассажирского: фоновая работа, батарея, деньги, смены, аренда. Водители уходят молча и быстро, а вернуть их дороже, чем удержать: на рынке их не хватает, и выбирают они, а не вы.

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

• Посчитать свой поток. Сколько заказов в месяц идёт мимо агрегатора — через диспетчера, звонки, мессенджеры. Это база проекта и основа расчёта окупаемости.
• Проверить канал дешёвым способом. Веб-заказ или бот в мессенджере покажет за недели и малые деньги, готовы ли клиенты заказывать не у агрегатора.
• Определить роли. Нужен ли корпоративный кабинет, есть ли аренда машин, работают ли самозанятые, кто закрывает диспетчерскую.
• Разобраться с реестрами и чеками. Кто перевозчик, кто служба заказа, от кого уходит чек — до начала разработки, а не в процессе.
• Собрать первую версию под один город или одного клиента и оставить диспетчера в контуре на время обкатки.