Автоматизация проката: доступность на даты, резерв и возврат оборудования

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

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

Что нужно автоматизировать в прокате

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

Маршрут заказа состоит из связанных, но разных этапов:

1. Клиент отправляет предварительный запрос: оборудование, количество, даты, способ получения и нужный состав комплекта.
2. Система проверяет состояние парка, подтверждённые резервы, обслуживание и буфер подготовки.
3. Сотрудник или согласованное правило подтверждает резерв. Только после успешной записи оборудование становится недоступным для конкурирующей заявки.
4. При выдаче сотрудник фиксирует фактически переданные единицы и проверяет комплект.
5. При возврате сотрудник отмечает состояние, комплектность и необходимость обслуживания.

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

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

Как описать парк оборудования и комплекты

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

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

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

Как проверять доступность на выбранные даты

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

Для точного расчёта удобно хранить интервалы в одном формате. Например, в полуоткрытой модели [начало, конец) интервалы A и B пересекаются, когда начало A раньше конца B и начало B раньше конца A. Такая запись позволяет считать момент окончания одного интервала началом следующего. Если прокат работает с включительными календарными днями, это нужно описать отдельно и не смешивать две модели в одном расчёте.

Порядок проверки:

1. Найти пригодные единицы нужной модели и комплектации.
2. Исключить обслуживание, ремонт и другие периоды недоступности.
3. Расширить занятые интервалы на согласованный буфер подготовки.
4. Вычесть единицы в пересекающихся подтверждённых резервах.
5. Непосредственно перед подтверждением повторить проверку и записать резерв как одну неделимую операцию.

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

В документации Booqable доступность описана через общее количество, число зарезервированных предметов и необязательный buffer time. Там же buffer time временно закрывает оборудование до или после аренды, например для зарядки камеры или обслуживания. Это пример реализации в Booqable по документации, обновлённой в 2025–2026 годах, а не универсальная настройка любой системы и не свидетельство проведённого нами теста.

Документация Booqable также предупреждает: изменение buffer time у товара не меняет существующие заказы автоматически. Это ограничение относится к описанной версии продукта. Для другой системы нужно отдельно проверить правила перерасчёта, API, права и поведение уже подтверждённых резервов.

Как подтвердить резерв и оформить выдачу

Статус должен отвечать на вопрос, что уже произошло:

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

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

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

Как обработать продление, повреждение и возврат

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

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

При возврате сотрудник проверяет:

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

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

Учебный пример пересекающихся заявок на камеры

Ниже — синтетический пример, а не клиентский кейс и не результат внедрения Switch On AI.

В парке три одинаковые камеры: C1, C2 и C3. Камера C3 находится на обслуживании, поэтому пригодная ёмкость равна 3 − 1 = 2. Клиент A просит две камеры с пятницы до конца воскресенья. Клиент B просит одну камеру с субботы до конца воскресенья.

Предположим, что заявка A уже проверена и подтверждена. В пятницу она занимает обе пригодные камеры. В субботу и воскресенье совокупный запрос A и B составил бы три камеры при ёмкости две: 2 + 1 − 2 = 1 лишняя камера. Поэтому заявку B на пересекающийся период подтверждать нельзя.

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

Обязательную сводку по заявкам можно записать так:

C3 остаётся недоступной, хотя находится на складе: обслуживание исключает её из пригодной ёмкости. Нельзя показать B как занятость, потому что её резерв не был подтверждён. Повтор заявки A также не должен занять ещё две камеры: система находит прежний идентификатор заявки и возвращает сохранённый результат.

Клиенту B можно предложить одну камеру со вторника после проверки либо другой интервал. Это предложение ещё не обещает наличие: перед подтверждением учётная система должна повторно проверить состояние C1, C2, C3 и новые резервы.

Как принять процесс и обсудить интеграцию

До разработки зафиксируйте контрольные ситуации и ожидаемое действие:

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

Switch On AI может спроектировать для этой операции ИИ-помощника, бота или интеграцию. Помощник уместен, когда нужно разобрать сообщение клиента и запросить недостающие сведения. Бот даёт клиенту диалоговый канал. Обычная интеграция передаёт и проверяет структурированные данные без свободного разговора. Конкретный вариант выбирают после проверки данных и доступных подключений.

Начать можно с одного типового заказа: передать обезличенное описание парка, статусы единиц, правила периодов, комплектацию и примеры исключений. Затем согласовать прототип маршрута «запрос → проверка → резерв → выдача → возврат». Прототип не равен внедрению, а совместимость с конкретным продуктом, тарифом и правами проверяется отдельно.

Подробнее о подходящем сценарии обработки обращений — на странице ИИ-помощника для продаж. Чтобы разобрать одну операцию и согласовать границы прототипа, свяжитесь со Switch On AI.