ИИ для автосервиса: 5 процессов, где эффект виден быстрее всего

Какие процессы автосервиса подходят для ИИ

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

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

Запись и ответы после закрытия

Где теряется время. Сервис закрывается в 20:00, а клиенты пишут и позже: после работы, в выходные, ночью перед поездкой. Утром администратор разбирает очередь, часть людей уже записалась в другом месте. Днём та же история, только по другой причине: администратор у стойки с клиентом и не успевает ответить в мессенджере.

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

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

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

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

Согласование дополнительных работ

Где теряется время. Мастер снял колесо и увидел изношенные колодки. Дальше начинается цепочка: мастер идёт к приёмщику, приёмщик звонит клиенту, клиент не берёт трубку, машина стоит. Когда клиент перезванивает, приёмщику нужно заново найти, о какой машине речь и что именно предлагали.

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

У письменного согласования есть ещё один плюс: остаётся след. Клиент видит, что именно ему предложили и за сколько, а сервис видит, на что клиент согласился. Меньше споров при выдаче машины в духе «мне такого не говорили».

• Собирает предложение мастера в короткое сообщение: что нашли, что предлагают сделать, стоимость из сметы, сколько займёт.
• Отправляет его клиенту в мессенджер и отвечает на простые уточнения по тексту сметы.
• Фиксирует ответ клиента «согласен» или «не согласен» и передаёт его мастеру.
• Если клиент спорит или задаёт вопрос не по смете, сразу зовёт приёмщика.

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

Напоминания о ТО и сезонной смене шин

Где теряется время. Перед сезоном спрос на шиномонтаж резко растёт, и все записываются в одни и те же две недели. Если сервис не напомнил о себе заранее, клиент запишется туда, где напомнили. С плановым ТО похоже: интервал по пробегу или времени у клиента в голове держится плохо.

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

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

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

Что измерить: долю ответивших на напоминание, долю записавшихся из них, число отписок и жалоб.

Разбор звонков администраторов

Где теряется время. Руководитель сервиса обычно знает, сколько было звонков, но не знает, почему часть из них не закончилась записью. Прослушивать записи вручную долго, поэтому их почти не слушают. Причины отказов остаются в разговорах: «дорого», «нет времени на этой неделе», «не тот бренд», «не перезвонили».

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

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

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

Что измерить: точность распознавания на ваших записях, долю звонков без записи по причинам, изменение этой доли после правок в скрипте.

Подбор и остатки запчастей

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

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

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

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

Что измерить: ошибку прогноза по сравнению с текущим способом планирования, число ремонтов, отложенных из-за отсутствия запчасти.

С чего начать: один процесс, пилот, метрики

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

До пилота зафиксируйте, как процесс работает сейчас: сколько обращений, сколько записей, сколько времени уходит у администратора. Через несколько недель сравните те же цифры. Если обращений меньше примерно 30 в каждой группе, результат пока ничего не доказывает, и пилот стоит продлить.

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

Отдельно договоритесь, кто в сервисе отвечает за пилот. Этот человек разбирает вопросы, которые ИИ передал сотрудникам, отмечает ошибки и решает, какие правила поправить. Без такого владельца пилот превращается в «бот что-то отвечает», и через месяц непонятно, работает он или нет.