SaaS-платформа и CRM для таксопарков

Контекст

Парки одновременно работают с десятками процессов. Их работа изначально ведется в нескольких системах: автомобили и водители хранятся в «Яндекс.Диспетчерской» и «1С», объявления — в «Авито», заявки — в кастомных CRM или «Битриксе». Менеджерам приходилось вручную связывать данные и держать полный контекст в голове, записках и множестве чатов.

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

Задача

Нам нужно было развить BeeBeep из разрозненных инструментов в полноценную SaaS-платформу для таксопарков, в которой должны были работать:

•

автопарк и подразделения;

•

объявления и их публикация;

•

публичная лента автомобилей;

•

CRM и воронка найма водителей;

•

телефония;

•

сотрудники, роли и права доступа;

•

задачи и история действий;

•

аналитика;

•

внешние интеграции.

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

Авито

Один из ключевых контуров платформы мы развивали в прямом сотрудничестве с продуктовой и технической командой «Авито». Вместе выстраивали весь процесс работы с объявлениями: определяли состав и формат данных, обязательные поля, статусы, ошибки, правила обновления и действия пользователя в спорных сценариях.

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

CRM должна подстраиваться под реальные процессы

Мы изучили существующие CRM, ежедневную работу менеджеров и собрали требования бизнеса. Центром системы сделали заявку. Здесь сотрудник видит данные водителя, историю обращений и изменений, фиксирует договоренности, оставляет комментарии и ставит задачи.

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

Автоматизация вместо рутины

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

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

Поэтому даже онбординг стал не обучающей экскурсией по интерфейсу, а последовательной настройкой реального рабочего контура таксопарка.

Сложная логика, которой пользователь не видит

Один водитель может позвонить несколько раз, оставить заявку на сайте, откликнуться на объявление «Авито» и обратиться в разные таксопарки.

•

Если на каждое такое действие создавать новую заявку, CRM быстро заполняется дублями.

•

Если объединять всё без разбора в одну карточку, менеджеры теряют новые обращения.

Поэтому мы отдельно проработали правила создания и объединения заявок. Система учитывала:

•

конкретный таксопарк;

•

номер телефона водителя;

•

источник обращения;

•

состояние предыдущей заявки;

•

наличие активного процесса;

•

действия менеджеров.

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

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

Для пользователя всё это выглядело просто. Но именно эта логика защищала CRM от дублей, потерянных денег и споров между менеджерами.

Телефония стала частью CRM

Звонок от водителя не должен начинаться с поиска его номера в нескольких вкладках. Мы встроили в BeeBeep виртуальную «АТС Билайн» и связали телефонию с заявками.

Каждый таксопарк подключал собственную АТС. Телефонные номера можно было связать с источниками: например, «Авито», сайтом или отдельной рекламной кампанией.

Когда поступал звонок, система искала водителя внутри конкретного парка и открывала связанную заявку. Если её не было, BeeBeep создавал новую.

В истории сохранялись данные о звонках:

•

дата и время;

•

менеджер;

•

длительность;

•

статус;

•

запись разговора.

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

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

Найти автомобиль должно быть так же просто, как заказать такси

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

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

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

Масштаб без потери скорости

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

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

Гибкость без компромиссов

У каждого таксопарка свои процессы. Кто‑то работает с несколькими менеджерами, кто‑то — с десятками сотрудников, и всем нужны разные уровни доступа к системе.

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

Так удалось сохранить детальную настройку доступа, но сделать ее понятной буквально с первого взгляда.

Все изменения под контролем

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

Система фиксировала в каждом событии всю необходимую информацию.

Фильтры и поиск помогали восстановить цепочку событий без просмотра бесконечного технического лога.

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

Аналитика, которая отвечает на вопросы

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

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

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

Telegram связал привлечение водителей с CRM

Через Telegram в BeeBeep работали два сценария: реферальная программа для привлечения водителей и уведомления менеджеров о новых заявках.

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

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

Новые заявки из CRM одновременно дублировались в Telegram-чат менеджеров, чтобы команда могла быстрее связаться с водителем.

При этом Telegram не становился второй CRM: заявки, ответственные, этапы и история действий оставались внутри BeeBeep. Бот отвечал за привлечение и скорость реакции, а вся операционная работа — за системой.

Биллинг

Встроили биллинг в работу платформы: таксопарк, указав реквизиты компании, мог провести оплату и получить документы, не переходя в отдельные сервисы. Он заранее пополнял баланс BeeBeep. Когда в CRM поступал новый лид, система автоматически списывала его стоимость по действующему тарифу. В кабинете парк видел остаток средств и историю операций, мог контролировать расходы и количество оплаченных заявок.

Результат

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

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