Почему Google Calendar не спасает
В прокате бронируют не «часы мастера», а набор единиц с пересечениями: одна камера в двух проектах, комплект света частично занят, возврат задержали на сутки. Нужен календарь загрузки с привязкой к номенклатуре и правилами: буфер на подготовку, минимальный срок аренды, автопродление.
Минимальный функционал
- Онлайн-форма и внутренние заявки менеджера
- Конфликт-детектор по датам и серийникам
- Резерв → подтверждение → выдача → возврат
- Залог и предоплата (ЮKassa / счёт)
- PDF КП и договор из шаблона
- Уведомления клиенту и бригаде (email, Telegram)
YClients и Calendly заточены под beauty-слоты. Для проката event-техники нужны kit, serial tracking и rigging calendar — это другая предметная область. MVP такой системы я делаю за 7–12 дней, полный контур с WMS — 3–4 недели.
Интеграция с CRM и складом
Бронь должна создавать резерв на складе и задачу на подготовку. При отмене — освобождать резерв и писать в историю клиента. Без связки получаете две правды: менеджер видит «свободно», кладовщик — «в rig».
Правила брони, которые спрашивают на discovery
- Минимальный срок аренды и буфер на подготовку/QC
- Частичный возврат комплекта и prolongation
- Замена позиции при поломке на площадке
- Мульти-warehouse: откуда едет kit на rig
- B2B: счёт и договор vs онлайн-оплата физлица
- Штрафы за просрочку возврата и депозит
Calendly не знает про kit. Google Calendar не знает про serial conflict. Даже Bitrix24 без кастомизации не знает, что «Moving Head #12» уже в другом проекте с перекрытием по дате strike первого и rig второго. Это предметная логика, которую я выносил в DryRent и Royal Rental как first-class rules engine.
Клиентский путь
Публичная форма на сайте создаёт черновик заявки; менеджер уточняет состав, система показывает доступность и считает залог. После подтверждения — резерв на WMS, PDF КП клиенту, задача на подготовку. Telegram-бот уведомляет бригаду о смене статуса «готово к выдаче». Клиент в ЛК видит статус «в пути / на площадке / возврат принят» — снижает звонки «где мой заказ».
Итоги и рекомендации
Система бронирования проката — сердце rental-бизнеса: не календарь слотов, а календарь загрузки парка с правилами. Залог, prolongation, замена на площадке, multi-warehouse — не «фичи второй версии», а вопросы discovery первой недели. Без резерва на WMS менеджер продаёт воздух; без Telegram/push бригада узнаёт о смене rig из WhatsApp. MVP 7–12 дней закрывает заявку, конфликт, КП, базовый резерв; полный контур с 1С и ЛК — 3–4 недели. Не сравнивайте с YClients: другая предметная область. Инвестируйте в PDF-документы и статусы для клиента — это снижает нагрузку на call-центр. DryRent и Royal Rental — живые референсы логики; перенос паттернов в ваш продукт быстрее, чем изобретение с нуля. Тестируйте edge cases: частичный возврат, strike в полночь, срочная замена прожектора. Хорошая система брони окупается первым сезоном без double booking.Если нужен разбор под ваш стек — CRM, 1С, Telegram, mobile — напишите через форму на сайте. За 130+ проектов я видел, как команды экономят на неправильном выборе архитектуры и теряют в сезон. Fixed-price MVP после короткого brief снимает неопределённость; дальше — итерации по метрикам, а не wish-list на 50 экранов. Документооборот — часть брони: КП, договор, акт выдачи генерируются из той же карточки, что и резерв. Это снижает ошибки реквизитов и ускоряет close сделки. Для межгородских проектов учитывайте transit time между складами в conflict engine. Клиентский self-service portal — phase 2, но API закладывайте в MVP. Pricing rules в прокате сложнее e-commerce: скидка за длительность, weekend rate, crew day, доставка rig. Вынесите их в конфигurator, не в голову менеджера. Conflict engine должен понимать strike первого проекта и rig второго с buffer hours. Reporting: utilization % по категориям техники — input для закупки парка. Integration tests на реальных rider-листах из прошлого сезона.