Автоматизация бизнеса с помощью ИИ: нейросеть и возвраты
Автоматизация бизнеса с помощью нейросетей в аренде снаряжения: сравниваем ручную сводку, черновик в чате и отдельную программу для вечернего отчёта о возвратах.
О
Ольга
Основатель малого бизнеса, партнёр
12 мин чтения
Что должно случиться к 20 часам, когда мы закрываем прокат: появиться короткая сводка или автоматически измениться журнал аренды? Я долго не разделяла эти желания. В списке планов у меня стояло «автоматизация бизнеса с помощью нейросеть», а вечером я всё равно выясняла, кто привёз палатку и кому звонить. Оказалось, для одной сводки есть три разумных пути. Выбор начинается с действия, которое мы хотим получить, а не с самого внушительного названия технологии.
Семь заказов, из-за которых хотелось автоматизировать всё
В нашем маленьком пункте аренды палатки соседствовали с рюкзаками, а вечерние сообщения — с журналом выдачи. Человек у стойки принимал вещи и отвечал тем, кто задерживался. Я читала сводку после закрытия и решала, что надо подготовить к утру.
Однажды сводка получилась особенно короткой: «Из семи вернули четыре, трое ещё нет». Я уже собралась уточнять контакты этих троих. Потом открыла записи. Двум аренду продлили, новые сроки были согласованы и внесены. Один клиент действительно ещё не доехал и не сообщил, когда будет.
Четыре принятых заказа плюс два продления плюс один ожидаемый — те же 7 заказов. Но это совершенно другой вечерний разговор. Двум людям незачем напоминать о прежнем сроке. По одному надо принять решение. Мне требовалось видеть эту разницу, а не просто получить красивое число возвратов.
Каюсь, сначала я сказала сотруднику: «Пиши подробнее». Он стал переносить в сводку почти всю переписку. В ней появились объяснения про дорогу, планы на завтра и благодарности клиентов. Читать стало дольше. Ответ на мой утренний вопрос по-прежнему приходилось добывать отдельно.
Тогда я записала, что именно должно быть в результате: что принято, что продлено, что ещё ожидается и где нужен разговор с человеком. Сначала договорились о смысле сводки. Потом уже можно было выбирать способ её подготовки.
«Автоматизация бизнеса с помощью нейросеть»: сравниваем по работе
Мне помогло убрать слово «автоматизация» из названий вариантов и посмотреть, кто совершает каждое действие. Кто берёт сведения из журнала? Кто разбирает сообщения? Кто замечает пропуск? И где будет лежать результат к утру?
Я сравнивала ручную сводку, подготовку текста в чате и отдельно разработанную программу с обращением к API. Условия задачи оставила одинаковыми: один вечер, выбранные заказы, понятные состояния, ответ для владельца.
Критерий · Ручная сводка · Черновик в чате · Отдельная программа с API
Кто собирает исходные сведения — Сотрудник по принятому порядку — Сотрудник готовит материал для чата — Настроенный механизм получает разрешённые данные
Как появляется текст — Человек пишет по форме — Чат предлагает формулировку, человек проверяет — Программа собирает результат по разработанному сценарию
Что происходит с журналом — Его правит сотрудник — Сам по себе ответ чата журнал не меняет — Изменения возможны, если отдельно предусмотрены
Кто замечает отсутствие сводки — Дежурный или владелец — Тот, кто должен отправить запрос — Предусмотренный контроль и назначенный человек
Что придётся поддерживать — Форму и привычку сотрудников — Исходные сведения и проверку ответа — Программу, доступ и порядок обработки сбоев
Сама таблица не выбирает победителя. При одном дежурном и понятном журнале первый вариант может оказаться удобнее остальных. Если проблема в чтении длинных заметок, интереснее второй. Если одна операция должна ежедневно выполняться без ручного переноса данных, появляется предмет для разговора с разработчиком.
Смотри на тот участок, который сейчас создаёт работу. У нас первоначально мешала смешанная запись о возврате и продлении. Ничто не обязывало начинать решение этой проблемы с программы.
Ручная сводка выигрывает, когда факты уже разложены
Я попросила сотрудника показать, как он получает вечернее число. Оказалось, в журнале были отдельные отметки о возвратах и новые сроки продлений. Он их видел. Но в свободном сообщении объединял всё, что не вернулось физически, в одну группу.
Мы сделали форму с разными строками:
принятые заказы с отметками сотрудника;
согласованные продления с новыми сроками;
ожидаемые заказы и вопросы, которые требуют решения.
Если требовалось вмешательство, сотрудник дописывал вопрос. Писать литературно не нужно. Нужно отнести заказ к правильной строке.
Для той семёрки форма уже давала нужную мне картину. Четыре приняты, два продлены, один остаётся в ожидании. Не надо было выдумывать настроение дня или превращать итог в рассказ о туристах. Из сводки становилось понятно, кому задать следующий вопрос.
У такого способа есть ограничение: человек всё равно собирает сведения и проверяет, что ничего не пропустил. Если сотрудник отвлёкся на выдачу снаряжения, форма сама не заполнится. Но её легко открыть, понять и исправить без отдельной технической поддержки.
Я бы оставила ручной вариант, если исходные поля уже удобны, сводку делает один человек и основная трудность была в формулировке итога. Добавление чата в каждую такую операцию означает ещё один перенос. Он должен приносить пользу, иначе мы просто удлиним вечер.
У меня есть неприятная проверка для новых инструментов: какое действие сотрудник перестанет делать после их появления? Если ответить не получается, разговор про экономию рано начинать. Возможно, сначала надо изменить форму исходной записи.
Нейросеть для бизнеса: черновик из разрозненных заметок
Другой вечер выглядит иначе. Дежурный получил продление сообщением, отметку о приёмке внёс в журнал, а обещание задержавшегося клиента осталось в короткой записке. Сведения существуют, но собраны разными словами. Тут помощь с разбором текста имеет смысл рассмотреть.
Передай в LibraChat разрешённый фрагмент записей вместе с категориями будущей сводки. Чат может помочь разобрать текст и предложить табличное представление. Полезная часть задачи — соединить написанное по-разному и сохранить смысл каждой отметки. Проверку по источникам всё равно выполняет сотрудник.
Для разбора выбранных записей подготовь такое поручение:
Подготовь черновик вечерней сводки аренды снаряжения. Рассматриваем семь заказов, которые первоначально должны были завершиться сегодня. По четырём сотрудник подтвердил приёмку. По двум согласовано продление, новые сроки внесены в журнал. По одному приёмки и продления нет. Раздели результат на принятые, продлённые и ожидаемые заказы. Укажи вопрос владельцу только там, где требуется решение. Не называй продление нарушением срока. Записи журнала не меняй и сообщения клиентам не отправляй.
Это предлагаемый запрос, с которого можно начать свою работу. В нём задано, что считать исходной группой: семь заказов с первоначальным сроком на сегодня. Если вместо этого взять только текущие сроки из обновлённого журнала, состав выборки будет другим. Такие вещи стоит оговаривать до подсчёта.
Я бы проверила в черновике прежде всего две продлённые аренды. Сохранился ли смысл «новый срок согласован»? Не превратилось ли ожидание одного клиента в общую просьбу обзвонить троих? Хороший русский язык в сводке ещё не отвечает на эти вопросы.
Ручная работа здесь остаётся. Кто-то выбирает сведения, переносит их, отправляет запрос и принимает ответ. Этот способ помогает готовить текст. Он не означает, что ежедневная сводка теперь появится сама, пока все закрывают пункт аренды.
Проект LibraChat можно рассмотреть для повторяющихся правил и общего контекста. Его инструкции учитываются в разговорах внутри проекта. Но проект сам по себе не задаёт вечернее расписание и не получает доступ к нашему журналу только от того, что мы написали его название.
Автоматизация бизнеса с помощью API: нейросеть внутри программы
Третий путь я стала бы обсуждать, когда задача уже определена и повторяется без существенных изменений. Например, каждый вечер нужно взять сведения из разрешённого источника, подготовить сводку и доставить её владельцу. Человек не должен копировать один и тот же материал вручную.
Для такого сценария одной переписки мало. Нужна отдельно разработанная или настроенная программа, которая знает, откуда брать данные, когда начинать и куда помещать результат. Доступ по API позволяет обращаться к LibraChat из своей программы. Он не является готовым подключением к любой системе проката.
В LibraChat ключи создаются в «Консоли API», расчёты идут с отдельного предоплаченного баланса. Подписка на чат и такой доступ устроены по-разному. Поэтому в обсуждении внедрения я бы отдельно спросила, что входит в разработку, что потребуется оплачивать при работе и кто будет поддерживать решение.
Сначала определись со способом работы. Для черновика в чате сопоставь регулярную подготовку сводок с условиями тарифов LibraChat. Оплата API отдельная. При оценке программы учитывай разработку и сопровождение. Не называй стоимость доступа полной ценой внедрения.
Саму задачу полезно разделить. Если в журнале уже стоят однозначные состояния, посчитать строки по ним может обычная программа. Нейросеть разумно подключать там, где требуется работа с текстом: например, разобрать свободные заметки для черновика сводки. Не каждое действие становится лучше от обращения к ней.
Допустим, программа получила семь записей и подготовила вечерний текст. Ещё надо решить, каким образом результат попадёт ко мне и как я узнаю, что он относится к нужному дню. Подготовка текста — только часть такого сценария. Доставку и контроль актуальности тоже кто-то проектирует.
Я бы не давала первой версии право самостоятельно закрывать аренду, менять сроки и писать клиентам. Для начала можно ограничиться подготовкой сводки на проверку. Расширение действий обсуждается отдельно, после понятных правил и наблюдений за работой. Это предлагаемая граница внедрения, а не уже существующая функция нашего чата.
И тут важно не потерять масштаб. Разработчик может сделать удобный вечерний механизм, но ему всё равно нужны определения «принято», «продлено» и «ожидается». Если владелец сам смешивает эти состояния, программа только перенесёт эту неопределённость в другой экран.
Удобный способ видно и в вечер, когда всё пошло не так
На обычной сводке все варианты выглядят привлекательно. Мне интереснее спросить, как мы будем работать в неудобный вечер: сотрудник исправил запись после закрытия, ответ сервиса не пришёл или программа не смогла сохранить результат.
У ручного способа надо определить, кто допишет сводку и уведомит об изменении. У черновика в чате — кто проверит, что отправлена актуальная подборка сведений. У программы — что она сделает при сбое и как сообщит об этом человеку. Сам факт наличия кода проблему не решает.
Для обсуждения приёмки я бы дала разработчику такой набор:
Подготовить результат по семи заказам с заранее известными четырьмя возвратами, двумя продлениями и одним ожиданием.
Повторить запуск на тех же сведениях и проверить, что не появилось лишних операций с заказами.
Исправить одну исходную отметку и увидеть, как обновляется сводка и обозначается её версия.
Имитировать отсутствие ответа сервиса и проверить, что человек заметит незавершённую обработку.
Открыть сохранённый результат и проверить дату, состав выбранных заказов и возможность вернуться к исходным записям.
Повторный запуск требует отдельного внимания. Если программа только заменяет свой черновик, один набор последствий. Если ещё и меняет журнал или отправляет сообщения, появляются другие. Одна и та же операция при повторе не должна неожиданно исполняться ещё раз. Это надо проверять в самой разработанной программе.
Отсутствующая сводка не должна выглядеть как вечер без событий. Я хочу различать «нет заказов для отчёта» и «отчёт не подготовился». Иначе утром снова придётся звонить дежурному, только теперь прежде выяснять, работала ли наша автоматизация.
Кому я оставила бы каждый из трёх вариантов
Для нашего пункта аренды я начала бы с ручной формы. В той семёрке сведения уже были разложены, а неверным оказался способ их пересказать. Нет смысла начинать с разработки ради исправления одного общего слова.
Чат я бы выбрала для тех дней и участков, где трудно читать разрозненные заметки. Здесь заранее понятен результат: черновик по нашим категориям, который сотрудник сверит с журналом. Если же после переноса текста в чат приходится заново проверять всё с самого начала, надо выяснить, какую часть работы он действительно облегчает.
Программу с API стоит рассматривать для устойчивого повторяющегося сценария, в котором ручной перенос и регулярный запуск уже стали отдельной работой. В этом случае сравниваются не только ответы сервиса. Сравниваются разработка, сопровождение, проверки и запасной ручной порядок на время сбоя.
После выбора способа вечерней сводки можно присмотреться к другим операциям через разбор задач бизнеса для нейросети. Я бы брала следующую задачу лишь тогда, когда могу назвать её исходные сведения и дальнейшее решение. «Навести порядок в прокате» для этого слишком широко.
И данные не становятся локальными от выбора API. Обращение к внешнему сервису предполагает передачу разрешённого материала. Для обсуждения нашей семёрки достаточно вымышленных записей. Для реальной работы объём и условия передачи надо согласовать внутри компании; подключение само по себе такого решения не принимает.
В конце вечера мне нужен один понятный выбор
Я больше не считаю фразу «автоматизация бизнеса с помощью нейросеть» готовым заданием. Сначала заканчиваю предложение: «К закрытию пункта должно произойти…». Появиться проверенный текст? Обновиться запись? Прийти сообщение владельцу? Для каждого продолжения нужен свой объём работы.
Попробуй описать свой ближайший вечер в трёх строках: откуда берутся сведения, какой результат нужен, что после него должен сделать человек. Затем реши, какое действие ты хочешь убрать из ручной работы. Возможно, хватит формы. А если нужен ежедневный сценарий без копирования, у тебя уже появится предметное задание для разработчика.
Для варианта с текстовым черновиком открой чат LibraChat и отправь вымышленные записи нашей семёрки по предложенному запросу. Проверь прежде всего два продления: остались ли они продлениями, а не поводом звонить клиентам? Так можно оценить, приносит ли пользу ещё один перенос сведений.
