Speaker A
И начнёт. Так, уважаемые участники, ещё раз всех приветствую на нашем мероприятии. А это наш такой уже традиционный разбор протов, где я в роли ведущего и человека, который разбирает собственно ваши фронты. Меня зовут Бещтников Антон. Я
Разбор и анализ промтов для AI-ботов в отделах продаж на примере барбершопа с рекомендациями по улучшению.
Key Takeaways
- Конкретика и лаконичность в промтах повышают эффективность AI-бота.
- Излишняя информация о боте может сбивать клиента и создавать диссонанс.
- Правильная структура сценария — ключ к успешному взаимодействию с клиентом.
- Интеграция с CRM-системой упрощает и автоматизирует работу бота.
- База знаний должна быть структурирована по отдельным вопросам и ответам.
Summary
- Ведущий Антон Бещтников представляет традиционный разбор промтов для AI-ботов.
- Обсуждается кейс бота барбершопа ИГЕТ из Казани, его функции и сценарии взаимодействия с клиентами.
- Подробно разбирается структура сценария: приветствие, выбор услуги, согласование времени, выбор мастера, подтверждение записи.
- Дается рекомендация убрать из промта излишнюю информацию о самом боте, чтобы не создавать диссонанс у клиентов.
- Отмечается важность конкретики и лаконичности в промтах, а также необходимость интеграции с CRM-системой.
- Обсуждается правильное оформление базы знаний с разделением вопросов и ответов по отдельным файлам.
- Подчеркивается, что при интеграции с системой Вайклайнс многие этапы автоматизируются и не требуют ручного прописывания.
- Ведущий отмечает улучшение качества промтов у участников и важность конкретных вопросов, ведущих к записи клиента.
- Обсуждается необходимость корректного построения базы знаний для эффективной работы AI-бота.
- Видео содержит практические советы по созданию и оптимизации промтов для AI-ботов в продажах.
Full Transcript — Download SRT & Markdown
Speaker A
основатель платформы САVI. Это платформа для создания мощных AI ботов. Их ещё называют AI агенты. Мы их называем AI сотрудники или сотрудники, то есть сотрудники с искусственным интеллектом такие. Недавно тут записывали ролик для проморолика, и там мы это называли
Speaker A
автономный сотрудник с искусственным интеллектом, да. Вот. И, собственно, здесь мы встречаемся для того, чтобы разбирать разные всякие кейсы. И в том числе вот у нас есть такой формат, который мы называем разбор протов. Это означает, что у нас, как правило, три
Speaker A
участника. А мы подключаемся к их ботам, смотрим, как они настроены, и дальше я там их корректирую, по ходу комментирую, где что так, где что не так. Сегодня у нас в эфире традиционно будет три участника. Я их предварительно посмотрел.
Speaker A
А, ну и чтобы не откладывать долгий ящик, предлагаю к ним переходить. Так, сейчас.
Speaker A
Да, момент. Значит, первый у нас участник — это будет у нас Марат. Марат прямо, значит, Марат, если вы здесь, помашите, помашите ручкой, чтобы я вас увидел. Да, привет. Всё, да, Марат, добрый день. Вижу вас. Значит, я сейчас подключаюсь к вашему боту и расширю
Speaker A
экран. Значит, мы сегодня разбираем бота, который называется бот ЭТ. ЭТ — это название барбершопа. Ну и давайте смотреть, что у нас здесь такое.
Speaker A
Значит, а общие сведения о компании: Барбершоп и Геть мужских парикмахерских, работающих в Казани. Компания оказывает услуги по уходу за мужским стилем: стрижки, оформление бороды, уходовые процедуры, основной акцент — качество, скорость, индивидуальный подход, атмосфера комфорта. О боте. Ты — это персональный
Speaker A
консультант барбершопа ИГЕТ. Ты являешься представителем компании в мессенджерах и в социальных сетях. Твоя основная роль — помогать клиентам с выбором услуг, мастера и времени, снимать возможные страхи и записывать клиентную процедуру. В целом всё хорошо.
Speaker A
Единственное, можно убрать вот эту информацию о боте. Кажется, что она лишняя и может сбивать. Ну, тут в некоторых кейсах может вызывать некоторый диссонанс бота.
Speaker A
Поэтому вот эту историю я бы убрал. А так, ну, всё логично. То есть есть описание компании и её услуг, есть какие-то основные акценты, хотя тоже такой вопрос, ну, спорный, я не стал к нему придираться, но как бы можно
Speaker A
оставить, но качество, скорость, индивидуальный подход, атмосфера комфортная. Кажется, общие, слишком общие такие фразы, которые как бы и так у бота, ну, будут по умолчанию включены.
Speaker A
Вот если мы говорим о том, что он как бы консультант. Вот. Ну, всё остальное там кем является, что делает, вроде как бы так логично и без сильной воды. Дальше.
Speaker A
Цели и задачи. Твоя основная задача — довести клиента до записи на услугу. Окей, принимается. Дальше. Этап за этапом выясняю у клиента его потребность. Этап один: определи услуги.
Speaker A
Там ты приветствуешь клиента и задаёшь ровно один вопрос, задавая вопрос из раздела приветствие. Ну вот раздел приветствие. Ну вынесли, вынесли. Окей, в принципе, open ай, да, рекомендую так даже делать. Вот, хотя, мне кажется, разницы не будет. Можно это и сюда
Speaker A
засунуть. Блок не такой большой. То есть можно было его указать прямо здесь. Потом этап два. Согласование даты и времени. После получения ответа на первый вопрос ты задаёшь следующий одиночный вопрос: на какую дату и время вам было бы удобно
Speaker A
записаться? Ну, допустим, этап три. Выбор мастера. Получив желаемую дату и время, ты задаёшь один вопрос о предпочтениях мастера. Есть ли у вас предпочтение по мастеру или доверитесь нашему выбору? Этап четыре. Проверка слотов и подтверждение записи. После выбора мастера ты обращаешься к базе,
Speaker A
проверяешь свободные слоты и предлагаешь клиенту конкретный филиал, дату и время для подтверждения. А если брать в целом вот этот как бы сценарий, то, как он описан, то выглядит неплохо. Ну, то есть глобально это нормальный такой лаконичный сценарий. Без ничего лишнего
Speaker A
тут глобально нет. Вот единственное, что вот дальше вот эта фраза, вот эта вообще строчка, она немножко ломает как бы всю систему, потому что если бы у вас был просто бот, который там должен консультироваться и который интегрируется с какой-то там вашей
Speaker A
CRM-системой, это одно. То есть есть действительно какая-то структура, какой-то порядок, плюс есть вот информация о том, там ты предоставляешь информацию о стоимости, времени выполнения услуг, мастерах, записи и правилах посещения, если клиент спрашивает. Опять же, если у вас есть
Speaker A
это в базе знаний, то вот эту строчку её писать вроде как бы и не нужно, потому что, ну, и так понятно, что там в базе знаний есть информация. Если клиент задаст этот вопрос, он и так там как бы
Speaker A
это увидит. Ну, хотя ладно, пускай она будет. В принципе, в некоторых случаях, да, может быть, это будет нелишним. Если собеседник задаёт встречный вопрос, например, о стоимости условий, ты отвечаешь, предоставляя базовую информацию и сразу возвращаешь диалог к новому действию, выбору времени,
Speaker A
записи либо уточнения услуги. Тоже, ну, нормально. То есть в целом вот что меня сегодня как бы тут порадовало, что в принципе все кейсы, которые отправляли, там не так много мест, к которым можно придраться. То есть либо, не знаю, так
Speaker A
просто совпало, либо наши с вами эфиры не проходят зря. То есть видно, что вот по, ну, стало лучше по пром гораздо. А всегда завершаю ответ вопросом, который ведёт к назначению записи. Ну, тоже вот есть конкретика.
Speaker A
Видите, почему я не придираюсь вот к этим материалам, да? Потому что везде есть как бы конкретика. В каждом случае есть конкретное как бы описание ситуации и конкретное решение, как нужно поступать. Ну, остальное — это там приветствие, там язык русский и стиль
Speaker A
общения. То есть, ну, окей. А единственное, что вот меня здесь как бы больше всего вот это смущает, да, фраза.
Speaker A
Вот эта фраза, что ты обращаешься к базе. Я посмотрел интеграцию с Клайсом. Здесь у вас она не подключена.
Speaker A
И вообще, вообще вот у вас, вы в базе знаний тоже вот сюда я зашёл, да, я увидел, что у вас тут барбер Рафаэль, там информация о барберах, о компании, вопросы там клиентов. Ну вот, кстати, тоже топвопросы. Ну вот, кстати,
Speaker A
топвопросы вот уже заведено неправильно. Вот у вас по идее должно быть один вопрос — это один файл базы знаний. То есть должен быть один вопрос, то есть, например, стоимость стрижки или там стоимость. Дальше идёт ответ. Потом, что входит в услугу или, например, ну, как
Speaker A
тут правильно переформулировать, чтобы без вопроса было? Это можно назвать, например, наполнение услуги. Ну, к примеру, да, можно с чатом GPT спросить, чтобы он в утвердительной форме это написал, и это будет заголовком файла базы знаний. Это уже идёт в базу знаний.
Speaker A
Потом опять есть ли комбоуслуги и сколько стоит? Опять же, можно прямо написать комбо услуг. Вот всё. И создать этот файл и вот на него ответить. То же самое по времени, да? То есть вот по каждому вопросу, это будет один вопрос,
Speaker A
отдельный файл. Пихать всё в отдельный файл не нужно. Вот если, ну, то есть вот у вас создан отдельный файл, например, Барбер Рафаэль, наверное, или там Барбер, Барбер Рамин, а то вот как бы вы просто берёте и, ну, [музыка]
Speaker A
а, ну, в принципе здесь окей. То есть, если они спросят что-то про Расула, то он как бы этот файл откроет и посмотрит всю информацию, которая там есть. Но повторюсь, глобально, если вы всё-таки здесь интегрируете с Вайклайнсом, то вообще вот это всё по идее не нужно,
Speaker A
потому что у Айкланса, когда вы подключаете его, мы прописываем специальную служебную инструкцию. И даже вот эти все этапы там они автоматически прописаны. То есть у нас интеграция с Клайсом, она делается по сути там одной кнопочкой. И когда вы подключили,
Speaker A
у него уже вот эта вся базовая информация и об этапах, и об услугах, и о мастерах, она вся у него есть в как бы в отдельной памяти, потому что интеграция там довольно сложная, довольно такая плотная. И он он вот эту
Speaker A
всю информацию, в том чи...
Speaker A
Значит, клайнса. Значит, вот здесь, если мы перейдём в интеграцию, мы здесь увидим следующие моменты. А, то есть вот они услуги, которые есть уклали, да? То есть, например, у каждой услуги вот будет там своё название и своё соответствие из Ylines. То есть услуга,
Speaker A
которую вот видит и услугаs. Кроме того, можно выбрать аналоги сейчас. То есть, например, вот эта проблема, когда у нас есть, например, стрижка у обычного барбера и у топбар, и надо, чтобы, когда клиент обращается, чтобы он смотрел и там, и там, вот для этого есть аналоги.
Speaker A
То есть, например, мы можем выбрать, что если человек обращается на стрижку модельную плюс блитьё бороды, то в данном случае вот ещё как бы можем можем выбрать какие-то услуги, которые бот им предложит, если, например, там он не найдёт свободное время на ту услугу. А
Speaker A
сейчас тут какое-то сообщение. Да, на этот вопрос отвечу кофе. То есть вообще, ну вот и как бы дальше, если посмотреть, тут видите, тут тоже предоставитьботу, список сотрудников, разрешить назначение сеанса, разрешить, ну, то есть тут есть ряд настроек, тут
Speaker A
уже вот эта интеграция, она разрослась, она как бы идёт немножко таким особняком со своими как бы принципами работы.
Speaker A
Поэтому, если вы создаёте бота под barberшоop, имеет смысл сначала подключить white cli, а потом уже настраивать как бы бота, исходя из того, что вам будет не хватать, потому что фундаментально у него уже есть своя структура, и она как бы довольно неплохо
Speaker A
работает из коробки. То есть вот если просто взять чистого бота и подключить к нему cliт нормально работать. Вот.
Speaker A
Ну я думаю, что вот, пожалуй, на этом всё. Больше. А можно ещё вопрос? Антондам. А вот скажите, по поводу стоимости стрижки, он тоже тогда из iCl будет брать? Да.
Speaker A
Да, да. И это будет дешевле, да, чем из базы данных. Из базы данных. Я бы не сказал, что это будет дешевле.
Speaker A
Интеграция CLI, она сама по себе такая недешёвая, потому что там порядка там больше десяти функций используется, вот именно интеграционных. Но как бы других вариантов нет. То есть, э-э, данные постоянно как бы меняются, и логично их брать из йклалиса. Всё-таки они во
Speaker A
внутренней базе добавляют. Поэтому, как правило, кейсы Whelines, они отличаются тем, что база знаний, она будет небольшая, довольно небольшая. Такие типовые ответы на типовые какие-то вопросы, а всё остальное вот будет брать из изйкланса. Он даже может оттуда описание услуги брать. Вот там есть
Speaker A
отдельное поле вклали, описание услуги расширено, и там можно его добавить, и он может это описание тоже брать. Но тут надо тоже аккуратно. Чем больше описания, тем больше токенов. тем больше дороже будет стоить ответ. Я так скажу, что если сейчас взять типовой вот
Speaker A
средняя стоимость 15 руб. за диалог по платформе средней, пойклансу она будет 20 руб. То есть она чуть выше. Ну вот там на процентов на на 15, на 20 она будет выше, да? Потому что из-за чего спрашиваю? Я вот обращаюсь даже сейчас к боту, да,
Speaker A
если вы посмотрите у меня в чатах, в чате в моём переписка, у меня стоимость, то есть обращение к боту, сколько стоит стрижка? То есть, по сути, он открыл вопрос топ вопросов. У меня там 10 руб.
Speaker A
за диалог бы за сообщение. Но с интеграцией его скланесом будет дороже 100% просто потому что как бы а повторюсь там там там там там цена увеличена за счёт того что используется большое количество вот этих функций дать отменить запись перенести запись
Speaker A
получить список сотрудников получить расписание э по услуге получить расписание по сотрудникам то есть там ну порядка там 10ти по-моему тринадцати функций используется и каждая функция она как как бы в диалоге, ну, всегда подключается каждый раз. И за счёт
Speaker A
этого, ну, год как бы может сразу давать релевантные ответы. Ну, можно попробовать. Я как бы, видите, нет, скорее всего не получится, скорее всего, потому что здесь, видите, когда даже мыс подключаем, мы здесь перечисляем услуги, которые бот видит, которые он не видит,
Speaker A
потому что у каждой услуги у неё есть ID. Если мы хотим потом сделать запись в White Cliance, да, например, чтобы бот записал, нам нужно там ID услуги, ID мастера, там время и так далее. То есть там набор целый определённых
Speaker A
идентификаторов, которые мы изначально из йколайнса получаем, и бот ими потом оперирует, потому что он, когда записывает человека в йклансе, он же не просто там ставит услугу, как слово, да, вот там стрижка, а он именно айдишник использует, там цифровое значение 08 1 2
Speaker A
5 6. У каждого сотрудника, у каждой услуги есть свой ID и плюс там ещё сеансы, грубо говоря, там тоже свои идентификаторы.
Speaker A
Ну то есть тут как бы процесс чуть-чуть сложения построен. диалог будет стоить 20 руб., а у меня получается одно сообщение было 10 только где-то даже 13. Ну, это, ну, вот как бы это слишком дорого. Ну, опять же, почему
Speaker A
надо смотреть? То есть у вас база у вас в принципе там не ну у вас, видите, например, вопрос-ответ у вас неправильно составлено, то есть у вас файл база знаний большой слишком. В прямых вопросах он не должен быть таким
Speaker A
большим, потому что каждый раз, когда бот его получает, он как бы весь текст читает все вопросы, а вам все не нужны.
Speaker A
Там вам нуж нужен только один ответ на вопрос. Ну то есть там точно есть, что оптимизировать за счёт вот таких вещей, но я бы шёл от обратного. Я сначала бы подключил Wielines, а потом уже как Антон, а там ещё можно
Speaker A
же это время, э, помнить, сколько историй, поставить 15 минут и будет проще. Клиент это время уже запишется.
Speaker A
Ну, это тоже, да, это, ну, это в любом случае для йлайнса это такая характерная история, что если это white cliтся, там должен история, да, история как бы сообщения, она должна быть ограничена, потому что люди приходят на стрижку там
Speaker A
каждые 3 недели или там каждые 4 недели там, да, и условно, ну, а если там бритьё ещё чаще, то как бы если всю историю тянуть, вот начнёт путаться. То есть обычно там тянется история за 24 часа. Всё, что свыше 24 часов, он до
Speaker A
этого уже не помнит. Но при этом в интеграции склалисом есть другие ряд других как бы моментов, что, во-первых, он может подтянуть последние три услуги человека. То есть если, например, номер телефона уже был в базе до этого, он уже
Speaker A
знает его последние процедуры, плюс он знает, как его зовут. То есть как бы тут тоже есть вот эти моменты автоматизации в части вот этих вещей.
Speaker A
А вот по поводу работы и наполнения клайнса есть какие-то видеоинструкция, может быть, или вообще как нет. Ну, укласа есть, я думаю, у самого А у именно у нас на нашей стороне есть, да?
Speaker A
Вот здесь, когда подключите, здесь есть вот такое видео превью, которое, ну, видео, которое можно посмотреть. Ага. И всё настроить, в принципе, можно, да. А у вк вот какие там нужно будет там сложно что-то в самом ies настраивать или там всё автоматически потянется, что
Speaker A
я здесь настроил в нашем интерфейсе в Сави? Нене, там как бы смотрите сави подключается к уже настроенному cliлису.
Speaker A
То есть сначала white cliвается там внутри. Ну как бы если у вас работающий барбершоп, там же внутри всё должно быть настроено уже, правильно?
Speaker A
Ну, наверное, да. Это не мой просто товарищи. А там вы просто нажимаете на кнопку подключить и дальше просто, ну, одной кнопкой вот эта интеграция происходит со стороны.
Speaker A
Там есть виджет у нас отдельный на на стороне йлайнса именно для подключения как бы к саве. Вы на кнопку подключить нажимаете, выбираете бота, ну, авторизуетесь в саве, выбираете бота, к которому подключить и просто создаёте нового бота. И всё, всё создаётся как
Speaker A
бы. Ну, автоматически интеграция подключается. Дмитрий, ко всем получается, ко всем у меня, да, у меня есть вопрос по поводу Айкланса. Если на сегодняшний день ies полностью, ну, всё заполнено да при подключении, он может ли сейчас, если не подключать его к перепискам, сбить
Speaker A
работу либо какие-то делать дополнительные записи, наверное, как мне протестировать уже в рабочем процессе, когда, ну, если вы его к каналу не подключаете, просто он ничего не собьёт, просто, ну, чате можете прямо с ним пообщаться.
Speaker A
И, ну, единственное, да, если вы сделаете запись, то она появится уже укласса. Вам просто нужно проконтролировать, чтобы её удалить потом. О'кей, хорошо. А если подключить, можно ли подключить ies и Bitrix вместе, грубо говоря, в iClindes запись Bitrix передачи полностью информации по
Speaker A
переписке с клиентом? А, можно, но только через вебхуки. То есть Битрикс он в данном случае у нас является как бы каналом. И работа вот именно как бы с ним, она производится в части, когда из него приходит сообщение. Если
Speaker A
вам нужно использовать Bтрикс как просто некую фиксацию информации, то его можно вызывать через просто апи, ну, через вебки. У нас кто-то из интеграторов, я помню, точно делал такую штуку, что как бы просто на вебхуках обращался к Битриксу и туда прокидывал. Ну, всё, что
Speaker A
нужно, сделку создавал, там ещё что-то там. Ну, мне необходимо, чтобы создавалась сделка, полностью информацию по переписке отображалась в Битриксе.
Speaker A
Такое возможно сделать? Ну, как бы я так не делал сам, но в теории опять же, если Bтрикс позволяет, у него есть апи, которая позволяет создавать сделку и отражать историю переписки, ну, а там есть, да, типа примечание, куда можно
Speaker A
указать, то, используя вебхуки Битрикса и их апи, это можно сделать. О'кей. Благодарю. Вопросов больше нет.
Speaker A
Хорошо, давайте переходим к следующему боту. Сегодня время у нас не затягивает. Значит, следующий бот мы рассмотрим. А мы рассмотрим сейчас бот, который от Юрия. Значит, сейчас не знаю. Юрий, вы здесь? Дайте сигнал какой-нибудь.
Speaker A
Да, здравствуйте, я Ага, супер, спасибо. Значит, бот называется Tenzor Taviat. Открываем этого бота и смотрим в него. Значит, ты опытный аналитик отдела разработки. Твоя задача - провести предпроектное интервью с клиентом, выявить цель проекта, зафиксировать требования, проблемы, пожелания, подготовить основу для
Speaker A
технического задания. Общайся, естественно, как профессионал, а не как бот. Показывай внимательность, интерес и включённость.
Speaker A
А, ну я бы задачу бы, как вот я говорю, да, я бы её унёс всё-таки во второй блок, потому что второй блок он как раз про цели и задачи. То есть ладно, там общие сведения, э, как бы роль, о'кей,
Speaker A
можем здесь оставить, но как бы вот по задаче я бы унёс вот вот вот вот это предложение я бы унёс вот сюда, а вот это предложение, общаясь, естественно, как профессионал, я бы, ну, как бы унёс бы в стиль ответа, вот на самом деле,
Speaker A
потому что как бы получается, что вы здесь написали, да, а потом ещё отдельно идут. Ну, это в принципе не критично, на самом деле. Кажется, что это может быть тоже ок. Единственное, что оно может как бы перебивать. Если вот здесь будет
Speaker A
написано одно, а здесь будет противоречить этому, то оно может просто, ну, что-то из этого не не воспринять, не учесть. Вот сначала выясни, что именно хочет клиент, и перейди к соответствующему сценарию.
Speaker A
Разработка сайта, интеграция, сайт плюс интеграция, сторонний продукт. Задавай все обязательные вопросы, относящиеся к выбранному сценарию. А где эти обязательные вопросы? Вот. Вот где идут идут ниже.
Speaker A
Ага. Обязательные вопросы. Ну, здесь идёт типа обязательные вопросы, да? Ну, вот а обязательные вопросы. Ну вот, вот здесь хорошо, давайте сейчас вот типа вот возьмём вот это предложение. Задавай все обязательные вопросы, относящиеся к выбранному сценарию. Тут как будто не
Speaker A
очень понятно, а какие вопросы к какому сценарию относятся. То есть это он сам должен как бы догадаться.
Speaker A
Там у меня как было то, что 10 первых вопросов, они идут как общего плана, а дальше идёт уже такое разветление, то есть в зависимости от того, есть ли там ТЗ или нет ТЗ. Вот. И там дальше ещё идут вопросы. О'кей. О'кей. В принципе,
Speaker A
тогда здесь вот, ну, в явном виде опять же, да, вот я пытаюсь как бы пронты, ну, вот как бы понимать, да, как их воспринимает бот, точно так же, как это воспринимаю я. Вот для меня вообще то, что вы сейчас говорите, ну, вообще как
Speaker A
бы не очевидно, да, потому что, ну, типа, да, есть общие, при том, что это как, ну, даже не как заголовок, как будто, а просто вот общие и это один какой-то вопрос, да, потом идёт актуально какие-то, потом, ну, как бы
Speaker A
если нет ТЗ. Ну, вот здесь на самом деле, да, здесь как будто форматирование просто немножко страдает, и я бы вообще, ну, разделил, наверное, как-то иначе. То есть либо обязательные вопросы, типа они идут, если они идут для всех сценариев,
Speaker A
то я бы выделил тогда блок, ну, типа общие обязательные вопросы, потом там типа о вопросы, если есть ТЗ, вопросы, если нет ТЗ, да, и потом вот здесь я бы описал это, что типа а в каком случае мне как вот какие вопросы вообще
Speaker A
вызывать, да? Типа, что сначала обязательно вызываем, задаём все общие вопросы, потом потому что здесь написано: "Задай все обязательные вопросы, относящиеся к выбранному сценарию". Ну, э здесь просто как бы, ну, типа, какие вопросы к какому сценарию относятся? То есть вот этот
Speaker A
первый вопрос, который ставит немножко в диссонанс, потому что я говорю, как будто либо для каждого сценария тогда должны быть должен быть свой набор вопросов, и мы там должны вынести в блок, что типа вопросы для разработки сайтов, вопросы для интеграции, вопросы
Speaker A
для сайта интеграции, вопросы для сторонних продуктов и как обычно там, например, мы делаем. То есть если у нас есть человек сказал, что его интересует разработка сайта, да, и там есть какой-то ряд вопросов, то обычно мы выносим это в базу знаний. То есть мы
Speaker A
просто создаём файл, например, называем файл в базе знаний, вопросы по разработке сайтов или там общие вопросы по разработке сайтов. А здесь прямо так и прописываем, что если клиент интересует разработка сайтов, типа выбираем общие вопросы, которые относящися к нему, вызови функцию get
Speaker A
fileтек и даём ссылку на конкретный файл. Ну, понимаете, это более, да, структурировано, то есть более понятно, что типа вот у меня есть разработка сайта, если он выбрал этот вариант, то я прошу вызвать файл базы знаний с этими вопросами. Всё, он эти вопросы видит,
Speaker A
начинает их задавать. Вот здесь же получается, что, ну, немножко вот эта история, ну, непрозрачная. Она как бы для меня непрозрачная, да. Также и для ну, как бы и для клиента будет опять же верхнеуровневая оценка. К чему это относится? Ну, как эту оценку применять?
Speaker A
Это же уже не вопрос. То есть ну ладно, может быть, где-то здесь написано будет. А пока просто такой комментарий, вот, чтобы было понятно.
Speaker A
Потом после каждого ответа оценивай его полноту. Если ответ непонятный, развёрнутый, переходи к следующему вопросу. Если ответ слишком общий, непонятный, а опять же вот этот блок я использую деловой понятный язык. Не говори следующий вопрос. в финале обязательно. Вот вот я бы вот этот блок
Speaker A
вообще я бы его а значит ну вынес, потому что он как бы это вообще к стилистике как будто относится. К стилистике. Ну и как бы некое там как важный какой-то блок о том, как вести диалог. Ну то есть это не не к целям и
Speaker A
задача, не к сценариям, да, как будто бы это просто как некие общие рекомендации. То есть нет такого, что вот чёткий какой-то здесь идёт поэтапный сценарий.
Speaker A
Это просто как какие-то рекомендации. Вот в финале обязательно запроси номер телефона. Это уже часть сценария. То есть вот я сначала задал вот этот вопрос, определил, потом я задал общие вопросы, потом я запросил номер телефона, а там по всем ответам сделал,
Speaker A
сохранил в Google таблицу. Опять же здесь вот, ну, все ответы клиента сохраняются в таблицу, Google таблица, да. Вот, на самом деле, э, ну, можно так, наверное, сделать, как бы. И, ну, единственное, что вот у вас в таблице, если
Speaker A
посмотреть во-первых тут э ну как минимум, вот я бы вот это имя функции поменял, оно тут автоматически проставилось. Я у ребят уточню, почему оно представляется. Во-вторых, нет описания таблицы вообще, для чего она нужна, потому что как минимум, ну, она
Speaker A
здесь для чего-то нужна. Опять же, вам надо получать что-то из таблицы. У меня ощущение, что вам ничего получать из таблицы не нужно. Вам нужно только добавить информацию в таблицу. Вот.
Speaker A
Да, можно скажу. Там получается собираются данные в таблицу и потом ээ соответственно ещё там другой сервис прикручиваем и они передаются уже в готовый Google Docs формат. Вот. Ну то есть тут сборка происходит и потом дальнейшая уже передача. Ну хорошо, но
Speaker A
боту не надо, да, получать данные из этой таблицы и в диалоге, чтобы они участвовали.
Speaker A
Ээ нет, почему? Ну вот он как раз же на при ответе на вопрос вот он как раз ориентируется, ну, от ответов от он задаёт вопрос, ему поступает ответ от клиента, и он дальше ориентируется на этот ответ. То есть он может дальше
Speaker A
уточняющие вопросы задать, либо понять, что ответ полный, и перейти уже к следующему вопросу. Ну, я понял, он он эти вопросы из таблицы берёт. Он он берёт какую-то информацию вот из этой таблицы или нет?
Speaker A
А, нет, из самой таблицы нет. Таблица изначально пустая, и она только для, ну, сохранения данных. Вот. Вот. Ну, во-первых, здесь как бы, ну, тогда вот эта галочка вам не нужна, как бы она здесь, ну, вот эта галочка, она отвечает
Speaker A
за добавление данных в таблицу, точнее, за получение видите, разрешить получение данных через функцию. То есть как бы, ну, она здесь вам не нужна. Во-вторых, вот этот предварительный скель запрос, он не так пишется. И здесь вот, вот здесь же есть, да, пример прямо
Speaker A
конкретный. То, что вы текстом написали - это просто текст, а здесь нужен SQL-запрос. Ну, видно, что вы не смотрели, как работает с таблицей в руководстве. Там в руководстве вот описано, как эти поля заполнять.
Speaker A
Изменения вам тоже не нужно. А вот добавление, вот добавление здесь можно было. Сейчас единственное вот, да, здесь, конечно, кривовато. Ну давайте по сейчас questions, по-моему, я не не ошибся. Questions. Ну-ка, давайте давайте вот так. При проектном обследовании assessment пускай будет
Speaker A
так. Значит, мы всё убираем. Ну то есть вам изменения получения не надо. Вам нужно только добавление в таблицу. То есть в данном случае вот у вас функция, которая работает с добавлением в таблицу.
Speaker A
Значит, запись запрещена. Здесь запись нигде не запрещена. Ну вот как бы вот вот как у вас должно быть настроено. Вот как минимум. А второй момент, второй момент. Ну вот это я сказал, это надо выносить в как бы в отдельный блок. Это
Speaker A
это как отдельный пункт, наверное, надо опять же вот у вас типа должно быть тогда пункт один условно, потом там типа пункт два. Опять же здесь надо расписать, да, подробно. А это пункт три, это пункт четыре. Ну вот опять же, сохраняй
Speaker A
информацию кратко и по делу без дублирования пересказов. Это, ну, если речь о таблице. Тогда, ну, как-то вот, наверное, здесь не надо вот этого разрыва. Вот так вот пускай будет, если это к таблице относится. Вот также что здесь ещё
Speaker A
заметил, что несколько раз в разных местах вот вы пишете, если они пытаются определить, являетесь ли вы человеком или нет, ответите, что вы человек. Здесь тоже, да, вот типа где у вас тут где-то было тоже сейчас.
Speaker A
Ну, то есть раз информация, потом два информация по стилю. Вот, э, три информации, опять же, по стилю, которая как бы вообще к сценарию не относится. То есть, ну, как бы если у вас сценарий, да, вот заголовок, то это
Speaker A
тоже заголовок. Ну, зачем? Почему оно здесь? То есть текст он должен быть отформатирован очень чётко в, ну, в структуре, потому что вот вот это как бы оно как будто вот показывает, что вот эта часть - это заголовок, как бы, хотя
Speaker A
явно видно, что, ну, вот заголовок вот, да, тут пробел может быть здесь, ну, потому что перенос строки ещё здесь стоит, а здесь его нет. В общем, вот это надо не надо это дублировать и надо это убирать всё-таки всё в стилистику
Speaker A
ответа. И когда вы всё в стилистику ответа соберёте в одном месте, её надо переработать, чтобы не было опять же там масломасляного, что вы одно и то же другими словами просто прописыва. А ещё вот опять, если они пытаются отдеть,
Speaker A
опять вы это здесь вот вставляете. Убрать повторы, грубо говоря. Ну да, убрать повторы, убрать их из заголовков и вообще не нужно их. И опять же, и здесь вы ещё, то есть вы четыре уже или пять раз прописали, что если они
Speaker A
пытаются определить, являетесь ли вы человеком или нет, ответите, что вы человек. Ну, во-первых, [музыка] вообще, в принципе, если человек начинает уже выяснять, то глупо как будто говорить ему, что это человек. Тут изначально нужно так настройку сделать, чтобы у человека не возникло даже этого
Speaker A
вопроса. А если он возник, прямо говорить, что это бот, потому что он всё равно, скорее всего, догадается, что это бот. И как бы то, что бот будет упираться, что он человек, будет вызывать только негатив. Ну, это так моё
Speaker A
мнение субъективное. Можете его применять, а можете нет. Вот. Ну, всё остальное с вопросами тут надо погружаться. Я бы их делила как бы на отдельные блоки и чётко, повторюсь, прописывал бы здесь прямо конкретно последовательное описание, как эти вопросы правильно задавать, потому что
Speaker A
вот из этого описания это вообще никак не следует. И это прямо чувствуется, как у вас есть это понимание, да, потому что вы эту предметную область как бы понимаете и знаете, а у нас вот у остальных мы не понимаем. Ну хотя я вот
Speaker A
сам тоже как бы типа айтишник, да, но всё равно я как бы не зная вашего конкретного сценария, ну я сразу типа смотрю и мне вот так вот сходу, ну как не очень понятно. То есть мне придётся задавать уточняющие вопросы, погружаться
Speaker A
там и и на выходе я всё равно буду ошибаться где-то, да, ошибусь и сделаю не так. Поэтому вам нужно просто описать более подробно, предметно и конкретно, как вам, как он должен работать с вопросом. Угу. Понял. Антон, а можно
Speaker A
вопрос дополнительный задать вот по поводу таблиц? Он может быть бот из-за этого не, ну не сохранить как раз данные в таблице из-за того, что вот промт так немного кривовато будем говорить. Ну, конечно, да. И тут таблица непонятно как бы зачем
Speaker A
она нужна. Тут, правда, ребята вот убрали тоже вот это описание функции. Я бы здесь её добавил. Ну, несмотря на то, что можно, в принципе, разрешить оставить вот эту галку включённым, назвать, что типа, а, используется для фиксации, используется для фиксации, а,
Speaker A
для фиксации ответов на вопросы от клиента. Вот так. И дальше вот если у нас идёт добавление, вот можно скопировать вот этот текст, скопировать и прямо прописать, э, значит, сейчас прямо прописать вот здесь в общем промкте, вот там, где про таблицу вы говорите, вот
Speaker A
так. Все ответы клиента сохраняй. А после, значит, после получения всех ответов от клиента вызови функцию вот эта и передай туда вопрос и ответ.
Speaker A
Всё, по большому счёту, вот этого уже достаточно для того, чтобы как бы, ну, он записывал. Ну, дальше протестируйте, если что-то не получится, напишите в техподдержку, разберёмся. Но вообще запись как бы работа с таблицей, она, как и с любой другой функцией, работает
Speaker A
вот таким вот образом. на у меня есть мысли немножко как бы тут перестроить, сделать преднастроенные вещи, что там типа если говорят таблица, то это там такая функция, если это такая-то, ну, чтобы типа он понимал, если имеет в виду
Speaker A
таблица, что нужно такой, но фундаментально он работает как бы с функциями. У него есть функции и у него есть их название и он с ними работает.
Speaker A
Для него нет понятия там таблица, база знаний и прочего. Это как бы, ну, он этого не знает. Он это не понимает так, как мы понимаем, да? Он понимает это просто в виде функции. Функция за что-то отвечает. Вот вот эта функция, она
Speaker A
отвечает за добавление вопросов. Всё, передал туда ответ вопрос, а на бейке уже произошла запись в таблице.
Speaker A
Да, понял. Спасибо большое. Хорошо. Да, удачи вам с вашей настройкой. Спасибо. Спасибо. Теперь Татьяна. Татьяна, нейрограция.
Speaker A
Татьяна, вы здесь? Да. Отлично. Давайте смотреть вашего бота. Значит, это бот консультант школы флористики. А значит, ты консультант по обучению в школе флористики Елены Поповой. Школа помогает женщинам раскрыть творческий потенциал, обрести источник стабильного дохода и сохранить баланс между семьёй,
Speaker A
карьерой и собой благодаря цветам. Основная задача школы- обучать флористики людей с разным уровнем подготовки от новичков до владельцевточного бизнеса. Обучение проходит в онлайн-формате. У некоторых тарифов предусмотрена практическая часть кураторами в студии в Санкт-Петербурге.
Speaker A
Для ряда программ предусмотрены выпускные проекты в студии в Санкт-Петербурге. Ну, хорошо написано. Отлично. Дальше я вторую часть прописала более подробно. Просто вот вопрос: корректно ли это будет, либо оставить короткую часть, которая была зависит зависит от того, насколько Да, это
Speaker A
зависит от того, насколько это важно. для коммуникации с клиентом. Если клиенты задают часто, ну вот типа вопросы, связанные с вот с этой частью, то вы как бы можете её добавить. А если оно является как бы таким второстепенным и может как бы, ну, как сказать, оно не
Speaker A
участвует в основном сценарии, а участвует только тогда, когда клиент задаёт прямой вопрос, тогда это здесь не нужно. Это можно вынести в базу знаний.
Speaker A
Ну, хуже не будет. Что-что хуже не будет? Ну, тут же вопрос, как не то, что хуже не будет, тут вопрос, что как бы в промкте не должно быть ничего лишнего, да, потому что любая любой дополнительный символ, токен, он снижает
Speaker A
как бы фокус модели, да, вот её качество, её ответов. И тут всегда нужно выдерживать баланс между качеством и стоимостью и объёмом вот как бы промта.
Speaker A
Поэтому если типа можно не добавлять, лучше не добавлять. То есть я так говорю, что добавлять нужно вот в основной промт только то, без чего реально работает плохо. То есть вы как бы, когда задаёте этот вопрос, нужно мне задать встречный вопрос: "А что не
Speaker A
работает?" То есть вот сейчас работает, ну, справляется с задачей, работает. Есть какие-то замечания? Ну, можно сделать умнее.
Speaker A
А как это измерить? Ну-ка, в чём вы измеряете его умность? А, ну, когда отвечает на все вопросы.
Speaker A
Так, то есть бот отвечает сейчас не на все вопросы. Нет, ну если мы говорим, что он как бы а рекламирует эксперта, то он должен как бы его экспертность всю и рекламировать. То есть максимально, а не придумывают что-то от себя, либо брать
Speaker A
должно выражаться вот в том тексте, который прописан более подробно. Хорошо, я поняла. Не, ну тут, да, смотрите, я как бы э пытаюсь ээ э специально так придраться немножко, да, для того, чтобы на конкретику выйти, потому что вот в конкретику я услышал
Speaker A
только в конце, чтобы он не придумывал, да, отсюда возникает вопрос: а были случаи, когда он что-то придумал?
Speaker A
Но видно, что он как бы говорит от себя из общей информации, не акцентируя именно на экспертности нашего эксперты.
Speaker A
Вот если вы говорите это в базу знаний конкретно, куда, как её, допустим, тогда то есть я же не знаю, как они вопрос будут задавать, которая касается именно той информации, которая здесь прописана.
Speaker A
Вот в какое место мне её зажить, под каким кодовым словом? Вы должны знать. Вы должны знать. Ну то есть как бы вот по идее, когда мы настраиваем бота, мы должны знать, какую информацию у нас будет запрашивать клиент. В рамках
Speaker A
нашего сценария обычно таких вопросов 50 тире 70 штук. И да, это надо знать заранее до настройки бота. Ну, как бы если мы настраиваем бота, мы бот - это как бы автоматизация, то есть мы автоматизируем некий процесс. Если у нас
Speaker A
процесса изначально нет, то его как минимум надо сначала создать. То есть надо сначала, значит, с клиентами пообщаться, накопить базу этих вопросов и потом эти вопросы заводить в базу знаний. И вот нет, вопрос был в другом.
Speaker A
Как бы, если конкретно я знаю, я задаю в прямые вопросы, то в базу знаний здесь вот каким, так скажем, хештегом его туда забивать, чтобы бот обращался именно к этой базе знаний. Может быть, я вас спрашиваю. А здесь простая очень как
Speaker A
бы, ну, технология. Должен быть прямой вопрос и прямой ответ. То есть как бы, ну, то есть всё равно только через прямой ответ и от вопрос. Всё, как бы по-другому никак получается.
Speaker A
Нет, ну есть ещё большие файлы, где мы можем тоже загрузить по сути какие-то, не знаю, какие-то, может быть, статьи, статьи экспертов, которых будут ключевые слова, по которым задают, ну, например, эксперт пишет какие-то статьи или выжимки каких-то его блогов, да? А и там
Speaker A
есть какие-то ключевые слова, которые, ну, вот содержат информацию вот эту экспертную. В принципе, если человек задаст вопрос, где будет вот в больших файлах, например, какой-то смысл совпадать, он эту тоже смысл выдернет и передаст. То есть тут надо как бы смотреть от контекста идти. Если
Speaker A
у вас объём этих и вариативность этих вопросов, она настолько большая, что вы не можете это уместить в прямые вопросы, ну, это странно. Либо тут вероятность очень маленькая, что это действительно так, потому что, ну, редко так получается, как правило, как я говорю,
Speaker A
50-70 типовых вопросов, либо вы просто не прошли ещё все вот эти вопросы. Ну, как правило, они всегда конечные. Вот.
Speaker A
Хорошо. И да, тут как бы вот эти именно вещи, они звучат как бы как будто ну немножко как будто это для прямых вопросов. Ну, например, а клиент спрашивает: "У вас онлайн или оффлайн уроки?" То есть у нас типа мы создаём в
Speaker A
базе знаний файл, который называем, а, вид доступа или там онлайн оффлайн. И в нём ответ онлайн с доступом к уроку записи. А дальше клиент спрашивает: "Есть ли у вас какая-то практическая часть?" Мы говорим: "Да", типа. Ну и вот
Speaker A
вот эти два ответа на вопроса, типа практически один проек студии Санкт-Петербурга, выпускные проекты проходят в студии школы Санкт-Петербурге. Дальше вопрос: а чем обучение отличается от других? Это прямой вопрос, который так можно назвать. А, типа, основные отличия нашего обучения
Speaker A
или основные отличия обучения. Всё. Вот мы называем так файл и вот это всё туда запихиваем полностью. Вот. То есть зачем оно нам здесь? Как бы это же типа если, например, ну да, в основном это как отличие или там сильные стороны
Speaker A
обучения. То есть как сформулировать, надо подумать. Над этим всегда надо думать, когда мы создаём файл базы знаний. Угу. Дальше твоя задача помочь посетителю сайта выбрать подходящую обучающую программу, задавая уточняющие вопросы, рассказывая о содержании и ценности курсов. А, о'кей, важно. А, без
Speaker A
обсуждения стоимости тарифов и скидок при любых вопросах о цене направляе клиент к менеджер как ответственном за такие вопросы. А, ну я бы вот эту часть, я бы, во-первых, её, а, значит, ну, я бы её как-то по-другому бы сделал, потому
Speaker A
что, во-первых, направляй клиента к менеджеру как к ответственному за такие вопросы для бота не очевидно, что значит направить к менеджеру, да, то есть какую функцию ему нужно вызвать. У вас там ниже, я смотрел, есть отдельный, да, блок вот здесь, где, значит, вот вызови
Speaker A
функцию getf manеджер, да, либо её тогда надо здесь дублировать, ну, либо всё-таки вот эту историю её надо как-то, ну, либо убирать, потому что у вас вроде как вот здесь есть вот конкретно описание, да, как ему действовать. Либо, если он спрашивает про стоимость,
Speaker A
создава создайте файл стоимость или там стоимость, тариф и скидки. И вы, ну, и вызывайте этот файл, который точно также у вас будет передавать на менеджера. То есть писать ему об этом, о том, что ему надо куда-то что-то передать, можно
Speaker A
вообще даже не писать, а можно прямо в через файл базы знаний это сделать. Дальше идём. Порядок работы. Выясни уровень подготовки клиента, задав вопрос в свободной форме, например. Вот здесь лишние вот эти как бы отступы можно не делать, мне кажется. Расскажите, вы уже
Speaker A
работали сми, переходи к следующему вопросу только после ответа клиента. Ну, здесь в целом, кстати, по вопросам нормально. Ну, то есть вот я смотрел, да, что у вас как бы типа дальше определи сегмент клиента. Новичок там, флорис с опытом, владелец, просто
Speaker A
интересуется. Единственное, вот у меня возникла мысль, что я бы вот этот блок я бы его вынес короче а ну в вообще в отдельного бота, может быть, подчинённого.
Speaker A
То есть у вас в принципе не такой уж, конечно, большой промт, чтобы это делать. То есть глобально вроде как в этом нет необходимости. Но если бы проект был бы чуть побольше и пром был бы чуть побольше, то вот эту историю
Speaker A
явно надо было бы выносить в отдельного бота. То есть можно создать отдельного бота, которому описать, что ты типа твоя задача определять сегмент клиента. А-а значит ну, кстати, вот вопрос, а как как он нужен как он должен определить вообще?
Speaker A
определить сегмент клиента или вы только планируете новичок флорист. Ага. То есть у него как бы вот здесь смотрите, вы написали, да, но у него как бы нет критериев, по которым он должен определять. Ну типа да.
Speaker A
Ну где-то он у меня прямо запрашивал конкретно. Вы занимаетесь? Он в вопросах это выясняет см что ли, наверное.
Speaker A
Ну я бы тогда бы как-то прямо бы я я бы так бы, наверное, и писал бы, типа, определи сегмент клиента. Ну, может быть, я бы конкретный вопрос какой-то здесь прописал, либо, ну, если работает и работает. То есть можно было бы так
Speaker A
сделать. Опять так. А он в начале и спрашивает: "Вы работаете, только планируете начать?" А потому как он отвечает, уже понятно, они отвечают: "Я новичок, занимаюсь, у меня свой бизнес".
Speaker A
Вот уже в первом вопросе они это всё отдают. Понять? О'кей, хорошо. Ну, супер, как бы работает. И ладно.
Speaker A
Единственное, что, да, я бы, почему я говорю, что я бы вынес это в отдельный блок? Просто для того, чтобы опять же уменьшить вот здесь этот пром. Потому что представьте, вот у вас идёт, ну, порядок работы, он разбит на 1 2 3 4, на
Speaker A
пять этапов, да? У каждого этапа есть своя какая-то последовательность, свои правила. И получится, что когда мы выяснили, кто он является, когда мы уже будем переходить, он будет переходить к следующему этапу, у него вот вся вот эта часть инструкции, она будет каждый раз
Speaker A
передаваться. А зачем она ему, когда уже по сути он уже получил как бы информацию, ну, об этом? То есть он уже как бы у него информация об этом есть. И типа передавать ему ещё раз эту информацию вроде как не нужно.
Speaker A
Единственное, что я вот сейчас думаю: "А вызов подчинённого бота". Ну нет, кстати, по-моему, подчинённый бот, да, если мы вызвали подчинённого бота, он отработал как отдельный блок и потом нам вернул. Ну да. То есть получается, что мы каждый раз не будем тащить вот каждый
Speaker A
раз вот там, не знаю, сколько здесь, ну там 80-100 токенов, да, вот вот как минимум. И это лучше скажется на работе и по определению. То есть мы единственно в подчинённого вота можем передать просто, ну, какой-то его ответ. То есть
Speaker A
типа определи сегмент клиента и вызови функцию, там функция, которая называется подчинённый бот. Типа и, ну, типа, и передай туда ответ клиента. Дальше задаётся подчинённый бот, в котором пере который передаётся ответ клиента. А его задача по этому ответу просто
Speaker A
определить, кто он, кто он есть. Он дальше определяет, возвращает нам чисто вот вот это новичок, рис с опытом, владелец этот, тт. Всё, мы как бы отправили запрос, получили чисто уже готовый результат. И вот эта вся история каждый раз у нас не тянется в в диалоге.
Speaker A
Угу. Хорошо. Дальше при любом интересе уточни: "Хотите, я помогу вам ознакомиться с программой курса основы флористического мастерства?" Ну, о'кей, хорошо. Если пользователь спрашивает про дату начала обучения, по основному курсу сообщить, что старт обучения в ближайшие дни, по курсу бизнеса сообщить, что тдт.
Speaker A
А вот у меня тоже вопрос по этому пункту, как бы это корректно прописывать здесь или по каждому курсу мне задавать прямой вопрос и это в базу выводить, потому что как пока там сейчас немного курсов, если их будет больше 20-трицати,
Speaker A
под каждое название в базу в прямому вопроса выводить. Ну, наверное, да. Наверное, да. Тут можно, тут смотря сколько курсов, если их там больше двадцати, то имеет смысл таблицу сделать, Google таблицу и к ней обращаться. Просто это можно сделать
Speaker A
отдельного бота точно так же. То есть как бы просто сделать отдельного бота, который будет определять по а по ну там в зависимости от того, какой курс интересует клиент, он будет возвращать э ну вот конкретный ответ. Вот. И у него в
Speaker A
инструкции там будет много всего. Да, оно один раз вызовет, но в последующие разы уже вызываться не будет. Он только вернёт как бы результат и всё. А у этого бота будет только результат. Вот вот эта вся история тянуться как бы не будет. То
Speaker A
есть какой способ выбирать надо, ну, зависит, наверное, от объёма. То есть если объём небольшой, вставляем в основной пром. Если чуть больше, в базу знаний. Если гипер как бы, ну, там большой, то в таблицу. Если надо какие-то ещё там вычисления какие-то там
Speaker A
сделать там всякие штуки в отдельного бота. Угу. Хорошо. Если клиент хочет узнать стоимость скидки, тарифы, а, пообщаться с менеджером, действую по схеме. Ну вот опять же, по сути, вот вот это можно было бы вынести вообще на базу знаний,
Speaker A
то есть прямо написать стоимость скидки, тарифы, вам отдельный файл базы знаний, пообщаться с менеджером, ну, тот же самый файл базы знаний, либо, ну, такой же файл базы знаний, просто вот как бы с отдельным названием. Потом, а, значит, внутри этого файла базы знаний можно
Speaker A
прямо вот это, ну, как это, а, угу, заключить это вот в такие, например, э вот в такие кавычки.
Speaker A
Ну, вот даже вот так вот, я бы сказал. То есть вот как бы внутри файла базы знаний будет вот такая история. То есть типа действуй под схеме и он как бы просто, ну, типа вызвал этот файл, достал оттуда вот эту информацию. В
Speaker A
целом это не критично, как у вас прописано. У вас небольшой пром здесь, поэтому это как бы нормально. То есть может и будет нормально работать, да? Если как бы, ну вот промт был бы большой, я бы максимально старался его
Speaker A
вносить туда, вот в во всякие вот эти места, чтобы он не был здесь в основном пром. Ну вот после получения контактов зафиксируй цель обращения, а тт, да, цель. Вызови функцию менеджер, создай сделку и назначь менеджера команды Assign Managжеer. Ну вот здесь создай
Speaker A
сделку - это лихо, конечно. То есть сам он сделку не создаст, у него нет просто такой функции. А менеджера назначить он может. Но вопрос в том, что он может назначить менеджера как бы уже в существующей сделке. То есть, если у вас
Speaker A
это кама СРМ подцеплено, то как бы он, ну, уже по идее сделка должна быть. Ну, как бы если клиент обратился, автоматически создаётся сделка и в рамках существующей сделки идёт, а, идёт общение. И вот вот эту историю, да, он
Speaker A
может внутри сделки как бы проставить менеджера. Если у вас там несколько менеджеров и там по какому-то принципу они проставляются, а если менеджер один, то эта строчка вообще не нужна, потому что когда сделка создаться, там и так автоматически менеджер проставится. А
Speaker A
вот у меня вопрос. Я написал ему создай сделку. Он её и создаёт сделку. Или попробовать без этого словосочетания создать сделку брать и посмотреть, будет ли она создаваться тогда, потому что сейчас создаётся. Не может быть. Не верю. Как не может быть? У меня люди
Speaker A
пишут, я смотрю в воронку специальнодела отдельно сделала. У меня создалась сделка с этим человеком. Она она автоматически создаётся у вас, когда вам человек первый написал. Если он вам вам если он вам написал на какой-то канал, у вас вама она автоматически создаётся без
Speaker A
нашего сервиса. А, ну всё. То есть как бы надо попробовать ещё и без этой фразы создай сделку и посмотреть, будет работать либо нет. Я вам я вам даю 200%, что наш год он никак не участвует в создании сделки, потому что как бы у нас
Speaker A
нету такого метода, который бы эту сделку создавал. У нас сам процесс интеграции с АСРМ, он построен с обратного. Сначала создаётся сделка всм, а потом уже из этой сделки отправляется сообщение в нашу систему. И когда сообщение приходит, оно всегда идёт с
Speaker A
привязкой к сделке конкретной. То есть вот видите, я думала магия произошла. Я написала создану сделку, и он сделал.
Speaker A
Слушайте, вы нас переоцениваете. Мне, конечно, приятно, что не Я вас верю. Вы молодцы. У меня вопрос сразу по менеджеру. Когда я назначаю менеджера о проинтеграции, у меня он выдаёт список всех менеджеров, которые как бы у меня не существуют в реальном
Speaker A
АМА. То есть я, допустим, не знаю, я пришла в проект, да, там кто был менеджером, ну, захожу в Сави, выбираю менеджера, он мне выдаёт список всех, которые, может быть, были до того, как я пришла в проект.
Speaker A
Это как бы так есть, либо это потом будет до настройка, потому что я сначала, да, наверное, есть такая тема, но возьму на карандаш все ребятам скажу, да, там, скорее всего, передаются просто все, в том числе и типа уволенные там,
Speaker A
ну, они, да, потому что там такой список прямо, который вообще не существует вам на текущий момент. Понял, понял.
Speaker A
Слушайте, надо, я сначала думала, что у меня эта ошибка, я делаю конкретного менеджера, а смотрю, у меня не тот вываливается. И только потом допетрила, что надо просто состаковать эти данные.
Speaker A
Ну во-первых да здесь во-первых надо понять, а надо ли вам вообще назначать менеджера. Повторюсь, потому что как будто бы если у вас сделка там создалась, там менеджер уже как бы есть, он уже там стоит, ну, автоматически.
Speaker A
Вот. И вообще, если вам нужен какой-то другой, то как бы, ну, пускай он назначается средствами АМАСРМ. ВСРМ есть механизмы назначения менеджеров, условно, да, это я уже так сделала, да, также с тегами, потому что хотела создать сделки конкретный тег, когда она
Speaker A
из Сави провалилась, а Вама там настолько большой список тегов, что он в Саве даже не выводится, он заканчивается на 1/3. Есть такое, есть такое. Ну там, да, там есть такое, что как бы иначе там, ну, поэтому я это создала и вама
Speaker A
сразу и с тегами. Ну, значит, с менеджером тоже надо так сделать, да? Хорошо. Ну да. То есть, смотрите, у нас вообще, когда мы делаем архитектуру какого-то решения программного, всегда нужно, э, как бы минимизировать, э, минимизировать роль и и его участие в
Speaker A
тех или иных процессах, потому что, а, ну, модели, языковые модели вот этим, да, нерасети, они так устроены, что это всегда, ну, некая вероятностная как бы модель, которая как бы, ну, всегда имеет вероятность что-то сделать не так. И чем
Speaker A
больше мы логики в неё заводим, тем выше вероятность, что где-то что-то пойдёт не так. И поэтому, если у нас есть возможности какие-то вещи сделать программно, то лучше это сделать программно, там, локально, где-то в другом месте. Это просто повысит общую
Speaker A
стабильность, как и работаю, стабильность работы этого бота, так и стабильность ну как бы того, что будет вот вот эта отсрочка выполняться более стабильно. Хорошо, принято.
Speaker A
Так, ну, всё остальное, остальное в целом как бы нормально. То есть всё остальное вот как бы я говорю лучше как-то в этот раз вот оно так без каких-то критичных таких моментов даже вот со всем этим оно и тоже будет
Speaker A
работать в принципе глобально. Отвечая, опять же вопрос, то, с чего мы начали. Как сделать, чтобы бот отвечал как бы не из своей какой-то базы, а отвечал из базы компании. Эту базу просто нужно наполнять и всё. То есть в этом и
Speaker A
заключается, по сути, внедрение. Это в максимизации наполнения базы знаний с целью как бы, ну, ну, просто с целью полноты информации у бота. Угу. Хорошо.
Speaker A
Спасибо. Так, давайте теперь пробежимся по вопросам. Сейчас. Ох, что-то вопросов как много. Так, вопрос студию. На момент ответов на вопросы, когда подключаешь нельзя грамму, он отвечает только на сообщения или ещё на комментарии под постами.
Speaker A
Можно поподробнее пояснить, как и на что отвечает Сави в этой сети. Отвечает только на сообщения пока. Да, возможно скоро будет, думаю, будет актуально для интеграторафама. Робот операционист, который заполняет поля и так далее.
Speaker A
Будет большая БД автосфера сейчас реализована. Будет интересно услышать обратную связь от вас. Ну как будет.
Speaker A
Давайте, конечно, ходить разберём. У меня есть проблема в проекте с интеграцией в cli подключились, так подключить пришлось категории, а не услуги. Может это влияет, но суть в том, что если спрашивать, какой мастер оказывает такую-то услугу, то бот часто путается,
Speaker A
выдаёт список из пяти мастеров. Клиент выбирает мастера, бот смотрит уже услуги этого мастера. Отвечает, что он не оказывает услугу, которую спрашивает клиенты. Разные такие ситуации, когда он говорит одно, а потом другое. Смоль услуг, 15 мастеров. Есть такой опыт. Ну,
Speaker A
White Clies, да, это такая история, как бы, которая там по сей день допиливается, улучшается. Вот буквально там за пара там тройку дней последних там тоже были улучшения с точки зрения вот работы ответов на эти вопросы. Я предлагаю вам просто прислать конкретный
Speaker A
кейс нам в, ну, там, с конкретным прямо диалогом, и мы его разберём, посмотрим, либо уже решили эту ситуацию, и там просто ждёт обновления, ну, либо рассмотрим этот кейс и как бы доработаем его, потому что там действительно самих комбинаций очень много, как может там
Speaker A
одно на другое наслаиваться. Вот. И не всегда как бы получается так вот. Да, вот по поводу Битрикса, то, что спрашивали. Битрикс можно передавать через вебхуки, данные в каршку и в том числе в диалог, но если нужно переписываться из Битрикса, то
Speaker A
потребуется другая интеграция. А чем стандартная интеграция BТР не устраивает? Там же все поля можно заполнять. Самре передавать моменты, общаться, в том числе из Битрикса можно через открытую линию. Ну вот, кстати, да, от Сергея хорошее замечание, что по идее, да, если вы хотите, чтобы туда в
Speaker A
Bitриx передавалась информация, а у вас White Cliance, то по идее тогда у вас и внутри Битрикса должно строиться общение как канал. Ну, это вот просто так логичнее кажется, да? Тогда подрубите все каналы к Битриксу и, пожалуйста, используйте интеграцию вместе
Speaker A
склалисом. А переписываться через WhatsApp? Ну, WhatsApp он подключается спокойно к Битриксу, поэтому как открытая линия он там работает. Это всё. Подскажите, когда будет включена настройка, чтобы Сави видел всю переписку, предыдущую переписку в карточке сделки вам СРМ, которая была до него. А на днях вот
Speaker A
прямо уже на днях вроде уже это сделано, вроде уже на беке, на тесте, поэтому по идее вот может быть сегодня, завтра эта возможность появится, а может быть она уже появилась. Мне надо проверить, потому что, ну, там что-то пару дней
Speaker A
назад я проверял, она была на тесте эта история. Вот она уже вот прямо на подходе. Если клиенты просят прислать фото товара, а в каталоге 2.000 товаров, то какие есть пути решения? Создать базе нани 2.000 функций, одна функция, одна
Speaker A
картинка или здесь другой вариант? А нет, в этом случае вам нужно создать таблицу, э, где каждая строчка - это будет ссылка на товар, ну, наименование и, например, ссылка на фото. И всё. И дальше по наименованию в таблице осуществляется поиск и ссылка
Speaker A
предоставляется в диалог. Причём у нас реализована возможность, что ссылки из таблицы, если это изображение, они автоматически преобразовываются в картинке, поэтому это будет работать. А можете моего бота посмотреть. Вопрос интеграции с Телеграма, расчёт по таблице. Ну, в следующий раз приходите на разбор. Мы
Speaker A
перед когда мы публикуем разбор, за 2 дня до этого идёт анонс и там в анонсе надо в комментариях написать: "Хочу на разбор". Дальше с вами свяжется наш специалист, э, и там уточнит детали, запросит у вас всю информацию. Вот
Speaker A
поэтому, а, ну, как бы нужно записываться, кого мы разбираем. Мы заранее как бы готовим. А, Павел. Так, я через таблицу. Ну вот, да, кстати, тут Спасибо, ребята. Вот видите, у нас уже опытные интеграторы а отвечают отвечают вопросы. Формат обучения и отличие от
Speaker A
других точно логичнее в базе знаний разместить как будто так проще менеджера. Значит, внутрима Антон нужна помощь, а поддержка него ещё оперативно чать. Какие есть варианты? Не всегда вызывает функция. Хотя написано всегда вызывает функцию пытается подчинённый бод.
Speaker A
Ну, как бы есть отдельная линия в рамках подписки интегратора. Как иногда, да, загруз бывает тяжелее больше, иногда меньше.
Speaker A
Как бы стараемся в целом все кейсы разбирать. Вот напишите в личном чате, если он у нас есть персональный, разберём. Вот. А-а, что ещё? Что ещё?
Speaker A
Мм, не всегда вызывается функция, хотя написано всегда. Ну, тут смотрите, надо смотреть как бы промт. Если промт большой, то бывает банально просто как бы большой промт и он просто не, ну, фокус теряется. То есть надо уменьшать прот, улучшать его ответы. Ещё может
Speaker A
быть такая ситуация, когда в явном виде что-то прописано, он этого не следует. Возможно, у вас где-то есть противоречивое, ну, противоречащее этому другое предложение, которое он воспринимает, а ваше не воспринимает.
Speaker A
Обычно такие можно найти просто через загрузить этот профат GPT и спросить его, почему вот эта функция, вот эта строчка вызывается не всегда, хотя здесь написано, что может сбивать бота в этом случае. И как бы и он вам выдаст, ну,
Speaker A
какие-то идеи, по крайней мере, на что обратить внимание. И я нередко так находил косяки, где у меня в промте в другом месте стоит просто противоречащее этому предложение, и из-за этого он как бы работает нестабильно.
Speaker A
Что за серый цвет в тексте в промте? Это называется комментарии. А серый текст означает, что этот текст бот не видит. И вот этот текст, он обрамлён вот такими символами. Это сш тире сш, ну, в начале и стире сш в конце. И, ну, это как бы
Speaker A
комментарии, то есть это то, что мы видим, а мы то, что мы видим, например, но бот это не видит. Это нужно просто для того, ну, для удобства.
Speaker A
программирование прота, чтобы, например, не удалять нигде, не хранить, там в отдельном месте, например, ты что-то тестируешь, одну часть закомментил, протестировал, потом раскомментил, ну и так далее.
Speaker A
Вот. Ну вот здесь пишет Александр: "Контекст очистите". Он тянет старый контекст. Это вот Аэ да. Ну вот, кстати, да, относительно Телеграма, да, когда вы тестируете в Телеграме, будьте очень внимательны, потому что как бы в Телеграме там бесконечный контекст. Если вы в чате
Speaker A
тестируете в тестовом, там контекст как бы одним, да, образом, а вы можете его очищать, новый диалог создавать, то в случае с Telegram у вас как бы один диалог на всю как бы на всю, ну, на весь диалог получается. И это, ну, бо
Speaker A
сбивает, там просто контекст перегружается в определённый момент, и он начинает тупить, и стоимость диалога становится космической. Как заставить бота искать ответы в базы знаний, сделанный на 1s Bриx? использовать встроенные методы 1S Bitrix. Ну, скорее всего, если у 1S
Speaker A
Bitrix есть какой-то API, API, так называемая, то вы можете к нему обращаться через веб-куки. Сейчас я вам в чат вот конкретно персонально для вас, а, значит, Александр, я скину сейчас ссылку на видео, значит, на нашем канале. То есть у нас есть канал на
Speaker A
Ютубе а с, ну, записями всех подкастов, которые мы делаем. Так, сейчас, блин, сейчас я его найду.
Speaker A
Момент. Не знаю. Нету там. У меня идёт эфир. Так, сейчас, сейчас я найду этот канал наш.
Speaker A
Блин, что-то он у меня отсоединился. Сейчас сайт. Так, значит, как ну там клин Мам, блин, сейчас я не могу, короче, у нас, ну, был разбор недавно.
Speaker A
М, у нас было видео прямо такое, а, где мы разбирали подключение к 1С. Очень хороший такой был.
Speaker A
такой кейс вот я сейчас скину ссылку просто на канал вот там можно посмотреть там было видео по подключению саринес вот и э ну очень очень классно как бы там я так показал мне кажется очень наглядно там Много было откликов.
Speaker A
Вот такой полезный эфир. Вот, кстати, я нашёл ссылку на него. Сейчас вот можете посмотреть. По сути, подключение к 1S Bitrix и ко всем остальным системам, оно происходит подобным образом. То есть есть такае понятие, как Webхуhook. Это просто как бы некие обращение на
Speaker A
стороннюю точку входа, да, на вот сторонней системы. Через действие и шаг webхуhook можно это использовать. Так, Антон, начинающий, поэтому у меня может быть странный вопрос. Как настроить бота, чтобы он сделал запись на услугу и добавил в Google календарь, мог сделать
Speaker A
напоминание клиенту за 1 час до начала услуги. Ну, по поводу подключения в Google календарь можете посмотреть в руководство. Я сейчас тоже сюда скину ссылку. Вот есть отдельное прямо подключение, как подключать Google календарь. А у нас, э, значит, вот в
Speaker A
интеграциях он есть. Кидаю тоже ссылку в чат. Вот. Аэ. А так, чтобы напомнил за один час до начала события, это сейчас в процессе разработки, да, скоро появится механизм напоминаний, который может динамически ставить динамический follow, то есть в нужное запрограммированное
Speaker A
время. То есть нужно за час напомнить, нужно за 2 часа напомнить, нужно и за два, и за час, и за 5 минут. То есть это в процессе пока доработки. Как можно собирать информацию с разных сайтов о ценах на товары и сравнивать между
Speaker A
собой, находить наиболее наиболее выгодно? Ну, LM модели, я бы не сказал, что это лучшее решение для подобной задачи.
Speaker A
Вообще, в принципе, это такой парсинг, по сути, парсинг сайтов, а парсинг не требует LM, как бы для этого существуют просто алгоритмы, написанные на Питоне или на чём-то ещё. Вот. А там уже вопрос, что с этими данными уже делать,
Speaker A
да? Там уже их можно как-то для lm использовать. Просто если парсить при помощи LLM, это просто будет дорого выходить. Сейчас мы, кстати, сделали у себя вот эту возможность. пока ещё на фронт её не вывес, ну, не вынесли. Это
Speaker A
возможность использования браузера. То есть бот может сам, э, там через поисковик искать нужные сайты, переходить по этим сайтам, заполнять формы там и всё остальное, то есть производить некие действия. Но там есть одна один большой минус. Это очень дорого стоит и довольно длительно по
Speaker A
времени операции. То есть там, например, найти, не знаю, там какой-нибудь на зайти на букинг, забронировать какой-нибудь отель, ну, будет стоить типа 500 руб. и 10 минут времени. Ну, как бы такая история. Мы её прикрутили, чтобы было, потому что есть вероятность,
Speaker A
что подешевеет, но пока вот как бы, ну, чисто с экономической точки зрения использовать м для этой задачи не очень хорошо. Как сделать, если бот не может ответить клиенту или клиент просит ему перезвонить, чтобы мне приходило сообщение об этом и я мог перезвонить к
Speaker A
клиенту? А вызываете файл базы знаний по триггеру, то есть ставите триггер, что клиент просит позвонить, дальше ставите, а, значит, в файле базе знаний ставите переключатель, чтобы он передавал, ну, оповещение в Telegram. Ну, и всё, и вы будете об этом знать. То есть это
Speaker A
встроенный механизм работы с базой знаний. Ну, опять же, рекомендую в руководстве с этим ознакомиться.
Speaker A
Так, чат же GP реально нашёл несколько возможных нестыковок. Ну вот, видите, я же говорил.
Speaker A
Так, а есть возможность, чтобы он по почте отвечал? Ну вот вам сейчас сделали. То есть если АRM есть и приходит по почте запрос вам, то вам он может по почте отвечать. А просто, ну, в типовой почте. Нет, не может. Мы все не
Speaker A
делали. Ну, и, честно говоря, пока не планируем всё. Аэ. Уважаемые слушатели, большое спасибо, что пришли на этот эфир. Видно, как динамика у нас такая положительная, да, видно, что как бы работает лучше уже работа с промтами уже промты такие более
Speaker A
осознанные, как мне кажется. Вот думаю, что может буду рад, если это моя роль не последняя в этом. Вот. В любом случае, опять же, полезные вещи сегодня какие-то были, а значит, эфир прошёл не зря.
Speaker A
Значит, а эфир будет, запись эфира обязательно будет. Она будет, ну, сегодня там пока прогрузится, пока загрузим на YouTube. Ну, в течение ближайших пару дней появится в эфире. Всё, всем большое спасибо.
Speaker A
А да.
Topics:AI-ботпромтыразбор промтовотдел продажбарбершопискусственный интеллектинтеграция CRMбаза знанийавтономный сотрудниксценарий общения
