Skillbox нейросети для бизнеса: где нужен мой контроль
Skillbox нейросети для бизнеса: разбираем реальные блоки программы на заявках выездной уборки, выбираем границы автоматизации и условия остановки перед действием.
Ольга
Основатель малого бизнеса, партнёр
8 мин чтения
Клиент оставил заявку на сайте, затем написал в мессенджер: «Я уже отправлял форму, на всякий случай повторю». Обращений два. Уборка нужна одна. Если будущая автоматизация просто красиво запишет обе строки, мне придётся разбираться с двумя выездами вместо одного.
Я открыла публичную программу Skillbox «Нейросети для бизнеса» с этой задачей. Хотелось понять, чему учиться для сервиса выездной уборки: собирать обращения, связывать повторы и останавливаться перед обещанием клиенту. Выбирала по тому, какой кусок процесса смогу описать и проверить после обучения.
Skillbox нейросети для бизнеса: что сравниваю в программе
На странице есть не только общие слова про применение ИИ. Я собрала из программы четыре блока, связанные с моим процессом. Их содержание ниже пересказываю по публичной программе, а последний столбец — мои требования к будущему упражнению.
Блок программы · Что в нём заявлено · Что мне нужно уметь показать
«GPT-ассистенты на базе знаний» — Помощник с материалами компании и заданными ограничениями — Различать сведения об услуге и разрешение подтвердить заказ
«Автоматизация заявок и входящих обращений» — Приём через бота, запись сведений и извещение сотрудника — Сохранить обращения из разных каналов, не раздвоив уборку
«Сложные автоматизации с ИИ» — Несколько видов рабочих сценариев и их тестирование — Отработать повтор, изменение задания и неопределённость
«Боты и рабочие задачи в n8n» — Диалоговый бот, учитывающий предыдущий разговор — Не принять историю переписки за одобрение нового действия
Первый блок мне нужен для правил ответа. Например, что входит в обычную уборку, а что администратор должен уточнить отдельно. Если клиент написал про мытьё окон, одной общей фразы о чистоте недостаточно. Нужен вопрос о составе заказа и дальнейшее решение ответственного.
Блок входящих обращений относится уже к движению сведений между сервисами. Появилась запись, сотрудник получил сигнал, исходное сообщение можно найти. Для меня это отдельное умение. Хороший текст ответа ещё не показывает, что обращение действительно попало в рабочий список.
Я проверила, есть ли тестирование в описании сложных сценариев. Оно упомянуто. Теперь я бы привязала его к конкретным сбоям, а n8n — к продолжению диалога. Важны не названия инструментов сами по себе, а поведение всей связки. Умеет ли она возобновить разговор без второй уборки и понять, что клиент изменил условия?
Эти вопросы я подготовила бы до выбора обучения. Из краткого описания блока нельзя узнать, какой именно пограничный случай разберут на практике. Поэтому я спрашивала бы о повторной доставке сообщения, обращениях из двух каналов и согласовании выезда. Подробности упражнения здесь важнее общего обещания автоматизировать бизнес.
Одна уборка, разные записи: какой объём автоматизации мне нужен
Для начала я сделала небольшой набор сообщений. Без настоящих имён, телефонов и адресов. Пусть форма сайта создала обращение Ф-17 на обычную уборку объекта А. Вслед за ним пришло М-04: клиент прямо ссылается на Ф-17 и пишет, что повторяет запрос.
Это два обращения об одном задании. Я хочу сохранить оба источника, но связать их с одной карточкой уборки. Стирать второе сообщение целиком мне неудобно: в нём может оказаться уточнение, которого не было в форме.
Потом добавила ещё два случая. Сайт повторно передал то же событие Ф-17. А тот же клиент написал М-05 — уже про другой объект Б. Первое не должно порождать новый выезд, второе нельзя автоматически приклеивать к прежнему заказу только по совпавшему контакту.
Получился набор для проверки будущего сценария:
Повтор того же события: сохранить его идентичность и не создавать ещё одну уборку.
Новое обращение о прежнем задании: связать с карточкой, удержать историю и уточнения.
Новое задание того же клиента: завести отдельную работу после необходимых уточнений.
Неясное сходство: передать на разбор, пока связь не подтверждена.
Я не называю два похожих текста доказанным дублем. Сначала нужны основания. В моём примере клиент сам указал номер прежнего обращения. Когда такого основания нет, автоматическому объединению я предпочту вопрос. Иначе можно потерять второй заказ, очень аккуратно избавившись от повтора.
У карточки уборки я оставлю собственный номер. В ней будут ссылки на исходные обращения, объект и состав услуги, желаемое время, решение администратора и сведения о подтверждении. Тогда М-04 можно добавить к прежней работе, не уничтожая его отдельный источник. И видно, чего именно ждёт следующий шаг.
На этой задаче я сравнила три возможных объёма работы. Первый — помощник составляет карточку и вопросы, а администратор переносит их сам. Второй — настроенная связка собирает обращения, предлагает связи и ждёт решения перед подтверждением выезда. Третий — система сама подтверждает время и меняет расписание бригад.
Для старта мне подходит второй вариант. Он снимает часть переноса сведений, но не обещает клиенту свободную бригаду без проверки. Первый тоже полезен, если сам процесс ещё меняется. Третий я бы обсуждала после того, как понятны правила повторов, изменений и согласований. Перескакивать к нему ради красивой демонстрации не хочется.
Что подготовить в LibraChat до выбора обучения
Я бы принесла в чат правила процесса, а не доступы к сайту и мессенджеру. Обычный диалог LibraChat может помочь сформулировать карточку заявки, перечислить развилки и написать критерии проверки. Из этого не следует, что он сам подключит два канала, заполнит внешний сервис или отправит подтверждение клиенту.
Для собственного упражнения можно дать такое задание:
Помоги описать процесс заявок выездной уборки. Каналы: форма сайта и мессенджер. Различи обращение, карточку уборки и подтверждение выезда. Предложи правила для повторной передачи того же события, дублирования через другой канал и нового заказа того же клиента. При недостатке оснований оставляй вопрос администратору. Отдельно укажи действия, которые ждут согласования. Сначала оформи карточку процесса, затем примеры входных сообщений и ожидаемое поведение. Никаких внешних действий не выполняй. Условия сервиса: [правила без личных данных].
С этим запросом откройте чат LibraChat и попробуйте описать одну услугу. Цель — получить обсуждаемое задание: что должно случиться с каждым сообщением и кто принимает спорное решение.
Тут полезно не смешивать три сущности. Обращение хранит источник сообщения. Карточка уборки собирает согласуемое задание. Подтверждение выезда фиксирует отдельное решение. Если хочется разобрать такие роли подробнее, продолжите с материала про нейросетевых агентов для бизнеса.
Мне важна остановка именно перед действием. Предложение написать «Бригада приедет завтра» ещё можно обсудить. Отправленное клиенту обещание уже требует реакции. Поэтому в задании на внедрение я укажу, что администратор видит время, состав услуги и текст подтверждения до отправки.
Если после одобрения клиент добавил окна, прежнее решение не стоит переносить на изменённый заказ автоматически. Нужно вернуться к согласованию. Не ответил администратор — подтверждение остаётся неотправленным. Так граница человеческого решения превращается в понятное условие сценария, а не в надежду, что кто-нибудь заметит проблему.
С каким упражнением я пойду разбирать программу
Я не буду оценивать сценарий только по тому, появилась ли строка в таблице. Важно, что случилось дальше. Клиент может обратиться 2 раза по одной уборке, а повторная попытка обработки не должна создавать ещё одну работу или повторно обещать выезд.
Для разговора о практике я подготовлю вопросы:
Как связать два обращения с одной уборкой и сохранить их отдельные источники?
Как отличить повтор события от нового задания с похожими данными?
Что увидит администратор перед подтверждением и как остановить действие, если условия изменились?
Что произойдёт, если решение не принято или отправка подтверждения не завершилась?
Такая проверка требует настройки самой связки, а не только удачного запроса к нейросети. В документации n8n, например, отдельно описаны сравнение повторов по выбранным данным и ожидание одобрения перед запуском инструмента. Наличие этих механизмов не выбирает за меня, какие обращения считать одной уборкой. Это правило моего сервиса.
Ещё один случай для учебного задания: подтверждение ушло клиенту, а отметка об отправке не сохранилась. Я не хочу, чтобы повторный запуск вслепую отправлял то же обещание заново. Здесь мне нужен разбор того, как установить факт отправки и с какого места продолжать обработку. Просто запустить всё сначала недостаточно.
Свой учебный результат я сформулирую так: собран сценарий для заданных примеров, сомнительные связи видны администратору, а клиентское обещание ожидает его решения. Порядок повторного запуска тоже должен быть понятен. Это уже можно разбирать с преподавателем и исполнителем на конкретных входных сообщениях.
Свой доступ для регулярной работы сверю в тарифах LibraChat. А в учебную задачу я сначала запишу одну границу: при каких условиях моему сервису разрешено подтвердить выезд. С неё и начну разговор о том, какой навык хочу получить от программы.
