
Куда уходят четыре часа в заявке на аренду
Путь от заявки до отгрузки занимал четыре часа, а теперь три минуты. Эти четыре часа никогда не были одной задачей, и починка почти не про ИИ.
Четыре часа никогда не были одной задачей
Спросите координатора проката, сколько времени проходит от заявки до выехавшей машины, и услышите пожатие плечами и число. Часа четыре, обычно. В июле дольше.
Разложите эти четыре часа, и работой окажется почти ничего. Заявка приходит, в одно из четырёх или пяти мест. Кто-то открывает таблицу доступности. Кто-то другой должен подтвердить, что машина, которую ждали вчера, действительно вернулась. Договор собирают из последнего похожего. Подпись выпрашивают. Водителю звонят, а водитель на выезде.
Каждый шаг забирает несколько минут чьего-то внимания. Четыре часа это промежутки между ними, ожидание, когда освободится следующий человек.
От этого различия зависит, сколько стоит проект автоматизации. Автоматизация шагов экономит минуты, а минуты никогда и не были проблемой. Разрыв закрывает автоматизация передач, и именно она увела одну компанию с четырёх часов до трёх минут.
Двойная бронь это проблема одновременного доступа
Овербукинг принято считать невнимательностью, поэтому обычное лекарство от него это просьба быть внимательнее. Оно не работает, и понять почему стоит до того, как что-то покупать.
У общей таблицы нет блокировок. Два координатора открывают её в 10:02. Оба видят трёхтонный экскаватор свободным в четверг. Оба его обещают, один по телефону, другой письмом. Каждый был прав в тот момент, когда смотрел, и ни у кого не было способа узнать, что второй уже на середине обещания.
Ошибку создал инструмент, а не люди. Чтобы её убрать, нужны две вещи: одна запись, которая является единственным источником правды о забронированном, и проверка, выполняемая в момент подтверждения, а не только в момент заявки. Конфликты живут в окне между «посмотрел» и «пообещал».
Доступность это не поле «да или нет»
Вторая причина, по которой брони сталкиваются, в том, что большинство систем хранит доступность одним флагом, а состояний у единицы техники больше.
| Состояние в четверг утром | На площадке | Можно сдать в четверг |
|---|---|---|
| В аренде, возврат в среду | Нет | Да, если возврат состоится |
| В аренде, работа затягивается | Нет | Нет |
| В пути обратно с объекта | Нет | Зависит от расстояния |
| Вернулась, ждёт осмотра | Да | Нет |
| На обслуживании | Да | Нет |
| Забронирована, не подтверждена | Да | Нет |
| На месте и свободна | Да | Да |
Четыре строки из семи описывают машину, которая стоит на площадке и выехать не может. Проверка, которая спрашивает только про действующий договор аренды, отвечает «свободна» во всех четырёх случаях.
Отсюда и берётся основная масса двойных броней, и отсюда же понятно, почему починка это в основном работа с моделью данных, а не с ИИ. Вопрос о доступности нужно задавать по всем состояниям, в которых может быть единица, включая те, где её видно из окна офиса.
Основную часть починки сделала не языковая модель
Коммерчески самое интересное в этом проекте то, как мало в нём ИИ в том смысле, в каком это слово обычно продают.
| Шаг | Чем делается | Почему |
|---|---|---|
| Проверка доступности и конфликтов | Правила | Обязана отвечать одинаково всегда и быть проверяемой |
| Цена по прайс-листу | Правила | Цена это обязательство, а не догадка |
| Договор и подтверждения | Шаблоны | Утверждённая формулировка обязана остаться утверждённой |
| Порядок отгрузки и уведомления | Правила | Детерминированная последовательность без суждений |
| Чтение заявки свободным текстом | Модель | Неструктурированный вход, который иначе перепечатывает человек |
| Классификация необычного запроса | Модель, затем человек | Суждение, поэтому маршрутизирует, а не решает |
Детерминированные шаги делаются правилами именно потому, что обязаны вести себя одинаково каждый раз. Вероятностная проверка доступности это дефект под модным названием.
Модель зарабатывает своё место у входной двери, где заявка приходит в одиннадцать вечера сообщением, называет машину словами клиента, а даты записаны в форме, которой не ждёт ни одно поле. Превратить это в структурированный запрос трудно для правила и легко для модели. Чёткая граница ещё и позволяет объяснить систему потом, потому что всегда видно, какая половина выдала ответ.
Что остаётся человеку
Четыре вещи по замыслу уходят человеку, и рассуждение по каждой из них изложено в наших правилах о человеке в контуре.
Всё обязывающее решает человек: скидка вне прайс-листа, условия, отличные от стандартного договора, любое обещание, которое свяжет компанию. Исключения приходят с полным контекстом, а не голым уведомлением, потому что уведомление без контекста просто перекладывает работу. Документы собираются из утверждённых шаблонов, а не сочиняются. И каждое автоматическое решение логируется, поэтому у вопроса, почему система поступила так в конкретный четверг, есть ответ.
Отдельно стоит назвать бронь, которая не оставляет запаса до следующей работы: она выглядит автоматизируемой и не является ею. Приемлем ли двухчасовой оборот, зависит от клиента, от объекта и от того, как прошла прошлая работа с ним.
Сколько это стоило
Цифры внедрения полностью: обработка брони сократилась с 4 часов до 3 минут, двойные брони исчезли совсем, сотрудники освободились для работы с клиентами вместо календаря, а ёмкость пикового сезона выросла в 2,5 раза. Сделано за 3 недели. Подробности на странице кейса по аренде оборудования.
Коммерчески интересна именно ёмкость, и стоит точно сказать, откуда она берётся. Сами часы деньгами не стали. Деньгами они стали потому, что раньше пиковым заявкам отказывали из-за нехватки оборота, и отказы превратились в принятые заказы. Это первый из двух путей, которыми сэкономленные часы доходят до бухгалтерии, и четыре вопроса, которые ломают большинство расчётов окупаемости, стоит задать любой цифре такого вида, включая нашу.
С чего начать
Измерьте разрыв до того, как оценивать починку, и измеряйте его по системе, а не по опросу сотрудников.
Выгрузите две отметки времени по каждой брони за полный пиковый месяц: когда пришла заявка и когда подтвердили отгрузку. Смотрите на распределение, а не на среднее, потому что среднее прячет хвост, а в хвосте живут отказы. Потом посчитайте, сколько заявок пришло вне рабочих часов и на сколько вообще не ответили.
Это измерение и есть первая стадия аудита, который мы проводим до согласия что-либо строить, и оно же говорит, реален ли расчёт. Если хвост пикового месяца тонкий и никому не отказывали, честный ответ такой: четыре часа это раздражение, а не издержка, и деньги лучше потратить в другом месте.
Что именно закрывается в прокатной компании, описано на странице ИИ-автоматизация для аренды оборудования и в процессе обработки заказов.
01Как на самом деле предотвращается овербукинг?+
Проверка доступности переносится из памяти сотрудника в правило, а момент проверки переносится с того мгновения, когда человек посмотрел, на то, когда он подтвердил. У общей таблицы нет блокировок, поэтому два координатора открывают её в одну и ту же минуту, оба видят свободный в четверг экскаватор и оба его обещают. Никто из них не был невнимателен: каждый был прав в тот момент, когда смотрел, а таблица не имела способа сообщить одному, что другой уже на середине обещания. У починки две половины, и нужны обе. Одна запись становится единственным источником правды о том, что забронировано, и второй копии, способной с ней разойтись, просто не остаётся. И проверка выполняется заново в момент подтверждения брони, а не только когда отвечали на заявку: именно в этом окне и жили конфликты. Эта часть системы сознательно не языковая модель. Она обязана возвращать один и тот же ответ на один и тот же вопрос каждый раз, и для этого существуют правила.
02Нам придётся менять учётную систему?+
Нет, и в большинстве прокатных компаний это был бы дорогой способ решить дешёвую проблему. Почти у каждого оператора крупнее пары десятков единиц уже есть что-то для договоров и учёта склада. Часы теряются редко внутри этой системы, они теряются в ручной эстафете вокруг неё: между системой, общим ящиком, телефоном и тем, кто в этот момент оказался на площадке. Поэтому автоматизация обычно ложится поверх того, что есть, и интегрируется с ним, а работа приходится на стыки, а не на миграцию. Это важно и коммерчески: проект замены измеряется месяцами и несёт риск потерять историю, а закрытие эстафеты измеряется неделями и оставляет учёт там, где он уже ведётся. Мы выводим 1-3 процесса в продакшен за 2-4 недели именно потому, что объём работ остаётся на стыках.
03Что должно быть правилом, а что моделью?+
Граница проходит по тому, разрешено ли шагу проявлять суждение. Доступность, обнаружение конфликтов, цена по прайс-листу, сборка документов из утверждённых шаблонов и последовательность шагов отгрузки полностью детерминированы. Они обязаны вести себя одинаково на одинаковых входных данных, их нужно уметь проверить постфактум, и вероятностный ответ здесь дефект, а не достоинство. Это правила. Языковая модель зарабатывает своё место там, где вход неструктурирован и человеку иначе пришлось бы читать и перепечатывать: заявка приходит свободным текстом в мессенджер в одиннадцать вечера, машина названа словами клиента, даты записаны в форме, которой не ждёт ни одно поле. Превратить это в структурированный запрос по-настоящему трудно для правила и по-настоящему легко для модели. Чёткая граница нужна ещё и затем, чтобы систему можно было объяснить, когда что-то пойдёт не так: всегда понятно, какая половина выдала ответ.
04У нас сезонный бизнес. Стоит ли трёхнедельное внедрение?+
Сезонность это довод за, а не против. В пиковый сезон прокатная компания зарабатывает большую часть года, и именно ручная отгрузка обычно ограничивает, сколько этого пика можно принять. Когда очередь растёт быстрее, чем координаторы её разбирают, ограничением перестаёт быть парк техники и становится эстафета, поэтому заявки получают отказ, пока машины стоят свободными. Из этой ситуации и вышла цифра в 2,5 раза: компания уже отказывала в пиковых заявках, и закрытие разрыва между бронью и отгрузкой превратило отказы в принятые заказы. Внедрение занимает 2-4 недели, поэтому проект, начатый в межсезонье, работает до открытия сезона. Не окупается как раз тот вариант, где начинают в разгар: люди, которые должны отвечать на вопросы во время внедрения, это ровно те люди, которых пик уже съедает.
05Что по-прежнему остаётся человеку?+
Всё обязывающее, всё необычное и всё, в чём система не уверена. Скидка вне прайс-листа, условия, отличные от стандартного договора, клиент с открытым спором по повреждениям и бронь, которая не оставляет запаса до следующей работы, уходят человеку, причём с полным контекстом, а не голым уведомлением. Так спроектировано намеренно, и это не недоработка, за которую мы извиняемся: автоматика, которая молча обязывает компанию к цене или условиям, это риск, и одно неудачное обязательство стоит дороже, чем все сэкономленные на нём часы. Документы собираются из утверждённых шаблонов, а не сочиняются, поэтому формулировка, которую согласовал юрист, и уходит клиенту. Каждое автоматическое решение логируется и проверяемо, а это единственный способ ответить на вопрос, который рано или поздно задают всегда: почему система поступила именно так в конкретный четверг.

Автоматизация бизнес-процессов: от одного процесса до эксплуатации за 2-4 недели

RPA в 2026: где роботы выигрывают у ИИ-агентов, а где проигрывают
