Яхта на неделю: почему за красивым поиском быстро начинается настоящая работа

Аренда яхты на сайте выглядит красиво.

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

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

Каталог — это только начало

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

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

Вот тут «каталог» заканчивается. Начинается рабочее место.

И если его не сделать, бизнес всё равно будет работать — просто через вкладки, таблицы, мессенджеры и ручные договорённости. Мы такие процессы видели. Снаружи вроде живо, внутри всё держится на памяти конкретного человека.

Цена не должна прыгать

В аренде яхт цена — больное место.

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

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

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

Это звучит менее эффектно, чем «умный поиск яхт». Зато именно это делает продукт пригодным для реальной продажи.

Предложение — это не PDF из воздуха

В этом бизнесе предложение клиенту — отдельный продукт.

Это не просто «вот лодка, вот цена». Там есть даты, условия, срок действия, бренд капитана или агентства, контакты, договорённости, иногда ручная цена, иногда скидка, иногда особый сценарий для конкретного клиента.

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

Это сильно лучше, чем отправлять всё вручную в сообщениях и потом искать последнюю актуальную версию.

У каждого своя правда, и её надо ограничивать

В AhoyRent много ролей. Турист, менеджер, ассистент, администратор, капитан, партнёр.

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

Это не вопрос «показать или спрятать кнопку». Это вопрос доверия к системе. Если человек видит лишнее или может сделать чужое действие, продукт начинает ломать процесс, а не помогать ему.

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

Партнёрский доступ — это тоже продукт

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

Но «отдать данные» и «сделать партнёрский продукт» — разные вещи.

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

Мы сделали для этого отдельный developer portal. Без пафоса: ключи, usage, документация, стартовые примеры. Ровно то, что нужно партнёру, чтобы не писать нам каждый раз «а как это подключить?».

И да, партнёру не нужно видеть внутреннюю кухню. Ему нужны данные, на которые можно опереться.

Коммуникация не должна выпадать из сделки

Сначала кажется, что хватит формы заявки и email.

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

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

Это простая мысль: если коммуникация важна для сделки, она не должна жить отдельно от сделки.

Многоязычность нельзя прикрутить в конце

Яхты продаются не в одном языке. Это сразу влияет на каталог, описания, географию, ссылки, письма, предложения и партнёрский доступ.

Если сначала написать всё под один язык, потом локализация превращается в раскопки. На поверхности вроде «перевести тексты». На деле надо, чтобы весь путь клиента и менеджера работал одинаково на разных языках.

В таких местах дисциплина скучная, но нужная. И лучше заложить её в начале, чем потом чинить каждую ссылку отдельно.

Прод здесь тоже часть продукта

AhoyRent нельзя держать как «приложение где-то на сервере».

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

Это всё звучит не так сексуально, как «мы сделали маркетплейс яхт». Но именно это отделяет продукт от демки. Демо можно показать с ноутбука. Продукт должен пережить импорт каталога, сбой внешних данных, перезапуск фоновых задач, новую страну в поиске и партнёра, который пришёл утром с реальным трафиком.

Что получилось

AhoyRent получился не просто витриной с лодками.

Внутри есть:

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

Мне нравится этот проект тем, что он честно показывает: нормальная разработка начинается там, где красивая страница перестаёт быть достаточной.

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

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