вы делаете классную вещь, буду рад следить за вашим прогрессом
вы сосредоточены на негативных эффектах, типа мата или "подам на вас в суд". обычно такие разговоры редки, и о них оператор нормального колцентра сообщит гораздо раньше своему руководителю, чем система алерт пошлет ))
другое дело, что в процессе обслуживания разговора оператор должен пройти ключевые вехи: приветствие, определение проблемы, предоставление решения, сообщить о том, что с клиентом свяжутся, перевести на другого специалиста.
более того в зависимости от процесса, заложенного в звонок - например, менеджеры продавали на входящие звонки одну услугу, а после определенной даты должны предлагать воспользоваться акцией, дополнительным предложением или начать продавать другую услугу - также трудно понять сколько и как прошли звонки по критериям.
а от успешного прохождения звонка по всем ключевым вехам зависит впечатление клиента от сервиса, и как следствие более длительный цикл сотрудничества с клиентом и повторные/дополнительные продажи.
отсюда вытекает, что скорее необходимо сосредоточиться на положительных моментах, сколько соответствия критериям набрал звонок.
что например делаем сейчас мы в тестовом своем пилоте: выбрали часть звонков - только первые звонки от новых лидов (это могут быть исходящие или входящие). новых лидов мы определяем по CRM. Первый звонок важен потому что это первое впечатление о компании.
для него определяем критерии: приветствие, говорить об услуге, предложить перейти к видеовстрече.
в каждом критерии: определяем ключевые слова, если одно из слов было в репликах менеджера. если совпало ставим балл за выполнение критерия.
затем после оценки звонка - отправляем оценку в CRM и менеджер видит свою оценку, видит критерии, где он не набрал балл. - это очень удобно в динамике, например, поменяли критерий - теперь надо поздравлять клиента с Новым годом, а про акции 3 по цене 2-х говорить не надо, у вас оценка сразу просядет, если вы не начнете поздравлять, и это увидит и руководитель менеджеров в отчете, и сам менеджер в CRM в своих сделках.
в вашем случае, может быть было бы интересно понять, сколько положительно-эмоциональных звонков было.
Присоединюсь к @AigizKпо поводу того, что вы хотите реализовать. Например, чтобы применять наше решение - без разницы какая у вас телефония - главное уметь записывать каналы менеджера и клиента раздельно, т.к. по сути мы оцениваем только менеджеров. при этом для распознавания мы используем сейчас Яндекс, можем заменить движок распознавания на другой. Может быть где-то надо применить машинное обучение для оценки звонков, но пока тупо по вхождению лексем в фразы.
подумал, может быть дополнительным баллом к оценке быть положительно-эмоциональный окрас разговоров, или доброжелательность/невозмутимость менеджера, или сказал ли клиент в конце разговора спасибо )))
и как у вас отмечено, конечно, организации зачастую выбирают готовые решения по распознаванию - ибо это уже готовое, нам для оценки разговоров неважно какой движок распознавания, нам важно просто выделить из потока звонков - те, на которые стоит обратить внимание и только.
пара скринов из нашей системы оценки, может на какие мысли наведет?
журнал звонковкритерии менеджераконструктор критериев
обычно утекает много данных -> списывать будут коллективно -> например на 100 пострадавших будет 100 млн возмещения (из вашего примера 1 млн потерь) -> значит проще бизнес закрыть-продать-обанкротить, чем заниматься такой выплатой
еще вариант, обработкой данных в бизнесе будут перекладывать на какое-то стороннее юр.лицо типа однодневки, которое будет "мальчиком для битья" в случае проблем, а основной бизнес/юрлицо будет работать и дальше
возможно, поскольку все-таки это риски ущерба, то надо мыслить в сторону страхования - страховать риск утечки. по аналогии с ОСАГО/КАСКО и в анкете на согласие обработки персональных данных указывать кто страхует ответственность бизнеса, и если нет страховщика, то вы вправе выбрать другой бизнес, который все-таки застраховал свою ответственность.
кстати, можно также относиться и к управлению автомобилем - вероятность ДТП с вашим участием ненулевая, учитывая количество автомобилей, интенсивность движения и разный уровень водителей - вы покупаете страховку, чтобы как-то снизить претензии по ущербу в свою сторону.
но, например, откуда такой подход возьмется? т.е. книги по базам данных рассказывают про стойкость пароля, а не то, что учетки надо хранить закодированными, и разные БД можно использовать
какие инструменты использовать, чтобы разработчикам было прозрачно подключить их к их сервисам и приложениям, чтобы эту безопасность можно было включить быстро, дешево и сердито? какие-то обертки над библиотеками по доступу к данным?
вариантов много и каждый может придумывать свои костыли. вот в плане авторизации сделали oAuth для логина в веб-сервисы, и стало очень удобно, ваши пользователи авторизуются через любой сервис Google/VK/другой сервис oauth-провайдер. и безопасно, т.к. вы по сути не занимаетесь авторизацией
если перевести в экономический разрез, то сейчас штраф за утечку данных небольшой, а разработка в плане безопасности - сложно и затратно. как сделать разработку в плане безопасности дешевле и быстрее? прям чтоб по чек-листу: это включили, это добавили, это внедрили - данные в безопасности
интересуют стандарты/книги/блоги/статьи
как пример, snyk.io интегрируется в процесс CI/CD просто, внедряешь и регулярно сканируешь свой код и зависимости на уязвимости - поддерживать проект актуальным достаточно дешево
что делать сервисам, чтобы их БД, даже утекши, не несли чувствительных данных? или невозможно было использовать на стороне?
на стороне компании даже если данные будут разнесены по базам данных, разным сервисам есть возможность собирать и "компилировать" новую бд с сопоставленными данными
Не знаю, может А-бренды все таки очень тесно трутся с Гугл, поэтому в своих прошивках стараются быть ближе к политике Гугла, а Б-брендам как бы далеко, и они в своих прошивках на каждом Андроиде поддерживают и запись. Поэтому Б-брендовый аппарат берешь и пишешь, без перепрошивок, рутования, с максимумом бытового удобства.
поддерживать спеку и соответствующий код - та еще задача, как вариант, если у вас spec first, писать спеку, затем писать код, по которому генерится спека и сверять их на соответствие друг другу.
до nestjs пользовался express-openapi, там в коде дополняешь объекты и по ним потом соответствующая swagger spec генерится, описание лежит рядом с кодом. удобно, как пример https://github.com/antirek/sonata/tree/master/api/manage
чисто имхо, вы выбрали весьма академический путь - вот основы, вот IDE, вот еще Office365 и т.д.
когда если я начну писать курс по workflow automation & rpa, то вначале будет пример "как отправлять каждый день маме емейл или смс о том, что с тобой все хорошо" или "все знают этого программера, который запускать варку кофе на кофеварке в соседнем крыле здания, и как раз к тому моменту, когда к ней подходил, кофе был готов" вот репо, где вы можете взять эти workflow для uipath. вот эта штука в workflow рассматривается в главе 1, эта штука - в главе 5. а теперь, когда у вас появились идеи, что автоматизировать, пройдемся последовательно по курсу )))
кстати, почему используете uipath? как-то сравнивали с другими коммерческими и open-source решениями?
т.е. монорепозиторий - не очень, а мультирепозиторий - это каеф? а можно привести пример на чем строится мультирепозиторий? это что-то типа conda? или это можно использовать на вашей платформе?
может вы видели или знаете html-ui фреймворк или компоненты в каком либо фреймворке на react или vue для создания чатов: сообщений, картинок с превью, проигрывания в сообщения видео и аудиозаписей?
например, использую quasar (фреймворкк на vue, quasar собирает мобильное приложение под android/ios), там есть простейшее chat message компонент. для текстового обмена сообщениями - вполне, но хочется мультимедиа. и поддержку в компоненте отображения reply сообщения
что на счет js? и typescript?
вы делаете классную вещь, буду рад следить за вашим прогрессом
вы сосредоточены на негативных эффектах, типа мата или "подам на вас в суд". обычно такие разговоры редки, и о них оператор нормального колцентра сообщит гораздо раньше своему руководителю, чем система алерт пошлет ))
другое дело, что в процессе обслуживания разговора оператор должен пройти ключевые вехи: приветствие, определение проблемы, предоставление решения, сообщить о том, что с клиентом свяжутся, перевести на другого специалиста.
более того в зависимости от процесса, заложенного в звонок - например, менеджеры продавали на входящие звонки одну услугу, а после определенной даты должны предлагать воспользоваться акцией, дополнительным предложением или начать продавать другую услугу - также трудно понять сколько и как прошли звонки по критериям.
а от успешного прохождения звонка по всем ключевым вехам зависит впечатление клиента от сервиса, и как следствие более длительный цикл сотрудничества с клиентом и повторные/дополнительные продажи.
отсюда вытекает, что скорее необходимо сосредоточиться на положительных моментах, сколько соответствия критериям набрал звонок.
что например делаем сейчас мы в тестовом своем пилоте: выбрали часть звонков - только первые звонки от новых лидов (это могут быть исходящие или входящие). новых лидов мы определяем по CRM. Первый звонок важен потому что это первое впечатление о компании.
для него определяем критерии: приветствие, говорить об услуге, предложить перейти к видеовстрече.
в каждом критерии: определяем ключевые слова, если одно из слов было в репликах менеджера. если совпало ставим балл за выполнение критерия.
затем после оценки звонка - отправляем оценку в CRM и менеджер видит свою оценку, видит критерии, где он не набрал балл. - это очень удобно в динамике, например, поменяли критерий - теперь надо поздравлять клиента с Новым годом, а про акции 3 по цене 2-х говорить не надо, у вас оценка сразу просядет, если вы не начнете поздравлять, и это увидит и руководитель менеджеров в отчете, и сам менеджер в CRM в своих сделках.
в вашем случае, может быть было бы интересно понять, сколько положительно-эмоциональных звонков было.
Присоединюсь к @AigizKпо поводу того, что вы хотите реализовать. Например, чтобы применять наше решение - без разницы какая у вас телефония - главное уметь записывать каналы менеджера и клиента раздельно, т.к. по сути мы оцениваем только менеджеров. при этом для распознавания мы используем сейчас Яндекс, можем заменить движок распознавания на другой. Может быть где-то надо применить машинное обучение для оценки звонков, но пока тупо по вхождению лексем в фразы.
подумал, может быть дополнительным баллом к оценке быть положительно-эмоциональный окрас разговоров, или доброжелательность/невозмутимость менеджера, или сказал ли клиент в конце разговора спасибо )))
и как у вас отмечено, конечно, организации зачастую выбирают готовые решения по распознаванию - ибо это уже готовое, нам для оценки разговоров неважно какой движок распознавания, нам важно просто выделить из потока звонков - те, на которые стоит обратить внимание и только.
пара скринов из нашей системы оценки, может на какие мысли наведет?
обычно утекает много данных -> списывать будут коллективно -> например на 100 пострадавших будет 100 млн возмещения (из вашего примера 1 млн потерь) -> значит проще бизнес закрыть-продать-обанкротить, чем заниматься такой выплатой
еще вариант, обработкой данных в бизнесе будут перекладывать на какое-то стороннее юр.лицо типа однодневки, которое будет "мальчиком для битья" в случае проблем, а основной бизнес/юрлицо будет работать и дальше
возможно, поскольку все-таки это риски ущерба, то надо мыслить в сторону страхования - страховать риск утечки. по аналогии с ОСАГО/КАСКО и в анкете на согласие обработки персональных данных указывать кто страхует ответственность бизнеса, и если нет страховщика, то вы вправе выбрать другой бизнес, который все-таки застраховал свою ответственность.
кстати, можно также относиться и к управлению автомобилем - вероятность ДТП с вашим участием ненулевая, учитывая количество автомобилей, интенсивность движения и разный уровень водителей - вы покупаете страховку, чтобы как-то снизить претензии по ущербу в свою сторону.
спасибо за ваш комментарий, почитал про DPAN
но, например, откуда такой подход возьмется? т.е. книги по базам данных рассказывают про стойкость пароля, а не то, что учетки надо хранить закодированными, и разные БД можно использовать
какие инструменты использовать, чтобы разработчикам было прозрачно подключить их к их сервисам и приложениям, чтобы эту безопасность можно было включить быстро, дешево и сердито? какие-то обертки над библиотеками по доступу к данным?
вариантов много и каждый может придумывать свои костыли. вот в плане авторизации сделали oAuth для логина в веб-сервисы, и стало очень удобно, ваши пользователи авторизуются через любой сервис Google/VK/другой сервис oauth-провайдер. и безопасно, т.к. вы по сути не занимаетесь авторизацией
если перевести в экономический разрез, то сейчас штраф за утечку данных небольшой, а разработка в плане безопасности - сложно и затратно. как сделать разработку в плане безопасности дешевле и быстрее? прям чтоб по чек-листу: это включили, это добавили, это внедрили - данные в безопасности
интересуют стандарты/книги/блоги/статьи
как пример, snyk.io интегрируется в процесс CI/CD просто, внедряешь и регулярно сканируешь свой код и зависимости на уязвимости - поддерживать проект актуальным достаточно дешево
ничего не понятно, но очень интересно 😊 продолжайте, больше деталей
рассматриваете только как пользователь
что делать сервисам, чтобы их БД, даже утекши, не несли чувствительных данных? или невозможно было использовать на стороне?
на стороне компании даже если данные будут разнесены по базам данных, разным сервисам есть возможность собирать и "компилировать" новую бд с сопоставленными данными
за vivo спасибо, надо будет посмотреть поближе, он работает на своей оболочке Funtouch OS
режим для чтения для отдельного счета 👍
а есть уже какие-то сервисы аналитики или программы, которые используют Tinkoff Invest API? платные, бесплатные?
когда я второй раз увидел КДПВ в ленте - подумал, что пропустил какой-то новый мем )))
в моей папке: 'покушоц.xls' и 'игры для PS.xls'
Не знаю, может А-бренды все таки очень тесно трутся с Гугл, поэтому в своих прошивках стараются быть ближе к политике Гугла, а Б-брендам как бы далеко, и они в своих прошивках на каждом Андроиде поддерживают и запись. Поэтому Б-брендовый аппарат берешь и пишешь, без перепрошивок, рутования, с максимумом бытового удобства.
самое простое решение 👍
А экспорта через API, например, у них нет? Можно было бы свое приложение сделать на каком-нибудь no-code конструкторе и там слушать.
и что с этим обещанием делать? подписываться на вас? за еще одним твитом? ё-маё, вы не готовились по теме ))
вообще, PoE узкая ниша. Доля PoE портов из продаваемых портов коммутаторов по вашим данным какая? Есть что для SOHO?
Вы знаете всю логику предстоящей системы и все переменные, которые будут использоваться в системе?
неистово плюсую @nestjs/swagger )))
поддерживать спеку и соответствующий код - та еще задача, как вариант, если у вас spec first, писать спеку, затем писать код, по которому генерится спека и сверять их на соответствие друг другу.
до nestjs пользовался express-openapi, там в коде дополняешь объекты и по ним потом соответствующая swagger spec генерится, описание лежит рядом с кодом. удобно, как пример https://github.com/antirek/sonata/tree/master/api/manage
поэтому и есть open source, и возможность запускать приложения на ОС от других разработчиков
тема интересная и актуальная 👍
чисто имхо, вы выбрали весьма академический путь - вот основы, вот IDE, вот еще Office365 и т.д.
когдаесли я начну писать курс по workflow automation & rpa, то вначале будет пример "как отправлять каждый день маме емейл или смс о том, что с тобой все хорошо" или "все знают этого программера, который запускать варку кофе на кофеварке в соседнем крыле здания, и как раз к тому моменту, когда к ней подходил, кофе был готов" вот репо, где вы можете взять эти workflow для uipath. вот эта штука в workflow рассматривается в главе 1, эта штука - в главе 5. а теперь, когда у вас появились идеи, что автоматизировать, пройдемся последовательно по курсу )))кстати, почему используете uipath? как-то сравнивали с другими коммерческими и open-source решениями?
вроде слова правильные, а смысл не уловил ((
т.е. монорепозиторий - не очень, а мультирепозиторий - это каеф? а можно привести пример на чем строится мультирепозиторий? это что-то типа conda? или это можно использовать на вашей платформе?
может вы видели или знаете html-ui фреймворк или компоненты в каком либо фреймворке на react или vue для создания чатов: сообщений, картинок с превью, проигрывания в сообщения видео и аудиозаписей?
например, использую quasar (фреймворкк на vue, quasar собирает мобильное приложение под android/ios), там есть простейшее chat message компонент. для текстового обмена сообщениями - вполне, но хочется мультимедиа. и поддержку в компоненте отображения reply сообщения
Спасибо, почитал и погуглил. У гугла оказывается API есть https://cloud.google.com/speech-to-text/docs/multiple-voices называют такое разделение Speaker diarization