Cisco Support Community
отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

Вопрос по передаче информации о контакте при помощи Session Steps

Уважаемые коллеги!

Решаю такую задачу. Есть скрипт 1, где клиент попадает в очередь и распределяется на операторов. И есть скрипт 2, на который оператор вручную переводит вызов для выставления оценки качества обслуживания. Мне нужно для переводимого оператором вызова передать из скрипта 1 в скрипт 2 АОН клиента и далее записать его в базу данных вместе с оценкой. Как я понимаю, для передачи АОНа между скриптами можно и нужно использовать (в ветке Connected оператора Select Resource) операторы GetSession (для создания новой сессии) и Set Session Info (для хранения АОНа клиента). И соответственно в скрипте 2 использовать GetSession и Get Session Info (для получения данных из сессии). Все вроде бы передается и работает, но при попытке вызвать напрямую скрипт 2 (не при переводе оператором) я вижу что Get Session Info выдает в скрипт данные последней созданной в скрипте 1 сессии. Т.е. у меня возникает опасение что при работе множества операторов информация о сессиях будет перепутываться между операторами при переводе, т.е. оператор будет переводить вызов на скрипт оценки в котором во внешнюю базу данных будет передаваться информация о АОНе  клиента другой сессии (последней инициированной созданной при распределении вызова на другого оператора). Возможно ли как то этого избежать? Возможно я некорректно понимаю механизм работы Session? Буду благодарен за любую помощь.

3 УТВЕРЖДЕН. РЕШЕН.

Утвержденные решения
Cisco Employee

Андрей,По смешения переменных

Андрей,

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

Константин

Добрый день, АндрейДля

Добрый день, Андрей

Для передачи контекста вызова при "путешествии" вызова по контакт-центру в том числе используются переменные контекста вызова. Посмотрите страницу 2-53 по ссылке

Что касается объекта Session, то он связан с объектом Contact (текущим "звонком" / http-запросом), а не с объектом Scripts. И когда звонок forward-ится (то есть текущий вызов переводится с одного Application/Scripts на другое), то сессия автоматически также "переезжает" из одного скрипта к другому.  Чтобы получить связанную с Contact-том Session нужно использовать шаг Get Contact Info (поле Session) и после получить значение интересующей переменной (Get Session Info).

На заметку

Объект Session также может быть использован  для передачи "контекста" между сценариями, не только пока звонок жив (не прерывается), но и том случае, когда звонок был завершен.

Пример использования этого свойства.

  • абонент позвонил со своего мобильного телефона
  • постоял в очереди
  • начал общаться с оператором
  • и в этот момент у него разорвалась связь.

Абонент перезванивает и:

  • мы проверяем существует ли Session его "предыдущего" звонка
  • проверяем есть ли в Session переменная с ID оператора (с которым он общался)
  • и если ID оператора есть, то переводим звонок на этого же оператора.
  • абонент счастлив!!!

Как это работает (алгоритм)?

  1. В начале каждого скрипта мы создаем сессию (Get Session) и в поле "Mapping ID" указываем CallerID (АОН) абонента. Значение поля Mapping ID по сути своей является уникальной меткой / уникальным именем объекта Session (в пуле объектов Session). Так как номер мобильного телефона (CallerID/АОН) можно отнести к разряду уникальных имен (и принимая во внимание, что Session по умолчанию "живет" 30 минут), то мы можем предположить, что если один и тот же CallerID второй/третий раз звонит в Контакт-центр за последние 30 минут, то скорее всего у него вопрос к тому же оператору.
  2. Если сессия не существует, то считаем, что абонент звонит "первый" раз и сценарий работает по стандартной логике .
  3. Если сессия существует, то проверяем значение переменной AgentID оператора (Get Session Info). Значение переменной AgentID мы установили (Set Session Info, имя переменной можно придумать любое, указывается на вкладке Context) во время "предыдущего" звонка абонента, в тот момент когда звонок из очереди был направлен на оператора (Select Resource, параметр Connect = No, выход Selected).
  4. Если значение переменной AgentID существует (то есть абонент в прошлый раз дождался своей очереди и был переведен на оператора), то переключаем этот вызов на того же оператора (Select Resource, значение Routing Target Type равно Resourse).
  5. Если значение переменной AgentID не существует (то есть абонент в прошлый все еще был в очереди), то повышаем приоритет вызова (Set Priority). И чтобы сметливые абоненты не стали злоупотреблять логикой этого шага ("длинная очередь?" -> отбей звонок, тут же перезвони и ты будешь первым в очереди), то в Session нужно добавить переменную "WaitingTime", небольшие значение которой не будет включать логику этого шага.

Таким образом CallerID (АОН) абонента используется как уникальное имя ("Mapping ID") Session, к которой можно обратится и между звонками. В качестве "Mapping ID" может выступать любой уникальный идентификатор, однозначно идентифицирующий клиента в интервале 30 минут.

New Member

Как обещал, напишу как мы

Как обещал, напишу как мы применили данный функционал у нашего Заказчика (страховой компании). Напомню. Нам нужно было перенести данные переменной (наименование заказчика) из одного голосового приложения в другое. В нашем случае есть несколько подобных голосовых приложений обрабатывающих вызовы от клиентов. Каждое голосовое приложение создано для обработки вызовов определенного заказчика. Зачастую операторы не успевают обработать вызовы в приемлемое время. На этот случай в скриптах предусмотрено, что после нахождения 120 секунд в очереди клиенту периодически проигрывается сообщение с предложением оставить свой номер для того чтобы сотрудник страховой компании перезвонил клиенту. Если клиент выбирает данную возможность, то вызов исключается из очереди и с помощью Call Redirect перенаправляется на голосовое приложение Call Back. В это приложение нам и нужно перенести наименование заказчика – значение переменной Customer. Если клиент не нажимает ничего или жмет постороннюю комбинацию кнопок, то продолжает находится в очереди. Кому интересно как это сделано – прилагаю скрин, хотя тут все довольно просто:

Приложение CallBack обеспечивает возможность клиенту оставить номер двумя способами – голосом (при выборе такого способа вызов перенаправляется на номер голосовой почты, где клиент просто оставляет голосовое сообщение) или DTMF-набором строки номера на который нужно перезвонить. При выборе любого из способов производится запись во внешнюю базу данных. При выборе варианта оставления номера голосом нужно было записать: дату/время, АОН и наименование заказчика. При оставлении номера через DTMF: дату/время вызова, АОН клиента, введенную строку и наименование Закачика. Наименование заказчика определяется переменной Customer в голосовом приложении откуда пришел вызов. Для того чтобы значение данной переменной перенести в приложение CallBack , в исходном приложении на нужном шаге c помощью Get Session, я создал новую сессию и с помощью шага  Set Session Info добавил в созданную сессию контекстную информацию - данные переменной Customer.

В скрипте CallBack, в который переносятся данные, с помощью шага Get Session мы подключаемся к текущей сессии и затем при помощи шага Get Session Info получаем контекстные данные содержащиеся в сессии. Наименование контекстных данных сессии должно совпадать с исходным (т.е. в обоих скриптах данные о заказчике в сессии хранятся в поле называемом «Customer»).

Таким образом, мы перенесли с помощью Sessions данные переменной Customer при перенаправлении вызова из одного голосового приложения в другое. Исходная задача немного отличалась, но я полагаю, что выполню ее немного позже  с применением этого же способа переноса данных между скриптами.

16 ОТВЕТ.
New Member

Попробую перефразировать свой

Попробую перефразировать свой вопрос. Возможно ли передать переменные из скрипта 1 в скрипт 2 при распределении вызова из скрипта 1 на оператора и дальнейшего перевода вызова оператором вручную на скрипт 2?

Cisco Employee

Андрей,По смешения переменных

Андрей,

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

Константин

Здравствуйте!В нашем КЦ

Здравствуйте!

В нашем КЦ бывают трансферты звонка от одного оператора к другому, и когда уже конечный оператор переводит вызов на номер приложения с оценкой качества работы оператора, Caller ID первоначально позвонившего в КЦ пользователя - теряется (по крайней мере, каким образом его определить - непонятно).

Как извлечь информацию об изначально позвонившем пользователе (его Caller ID) в скрипте оценки качества работы оператора? С этой проблемой справиться самостоятельно пока никак не получается :(

New Member

Владимир, приветствую. Вы

Владимир, приветствую.

 

Вы пробовали сделать так как я написал выше в ответе, который с картинками? Я в своей задаче переносил данные между приложениями. У вас между приложениями есть еще операторы, но вроде бы как это не должно быть препятствием при передаче информации о вызове при помощи Sessions.

Владимир, добрый деньCallerID

Владимир, добрый день

CallerID вы можете получить с помощью шага Get Call Contact Info из поля Calling Number . Получайте сразу после поступления вызова, до переключения на "первого" оператора.

Далее, по примеру, как описал выше Андрей, вы передате значение CallerID через переменную внутри объекта Session. И когда вызов "дойдет" до приложения с оценкой качества, то вы берете CallerID из переменной объекта Session.

Как конкретно передавать переменную через  объект Session подробно показано выше. 

 

 

Добрый день, АндрейДля

Добрый день, Андрей

Для передачи контекста вызова при "путешествии" вызова по контакт-центру в том числе используются переменные контекста вызова. Посмотрите страницу 2-53 по ссылке

Что касается объекта Session, то он связан с объектом Contact (текущим "звонком" / http-запросом), а не с объектом Scripts. И когда звонок forward-ится (то есть текущий вызов переводится с одного Application/Scripts на другое), то сессия автоматически также "переезжает" из одного скрипта к другому.  Чтобы получить связанную с Contact-том Session нужно использовать шаг Get Contact Info (поле Session) и после получить значение интересующей переменной (Get Session Info).

На заметку

Объект Session также может быть использован  для передачи "контекста" между сценариями, не только пока звонок жив (не прерывается), но и том случае, когда звонок был завершен.

Пример использования этого свойства.

  • абонент позвонил со своего мобильного телефона
  • постоял в очереди
  • начал общаться с оператором
  • и в этот момент у него разорвалась связь.

Абонент перезванивает и:

  • мы проверяем существует ли Session его "предыдущего" звонка
  • проверяем есть ли в Session переменная с ID оператора (с которым он общался)
  • и если ID оператора есть, то переводим звонок на этого же оператора.
  • абонент счастлив!!!

Как это работает (алгоритм)?

  1. В начале каждого скрипта мы создаем сессию (Get Session) и в поле "Mapping ID" указываем CallerID (АОН) абонента. Значение поля Mapping ID по сути своей является уникальной меткой / уникальным именем объекта Session (в пуле объектов Session). Так как номер мобильного телефона (CallerID/АОН) можно отнести к разряду уникальных имен (и принимая во внимание, что Session по умолчанию "живет" 30 минут), то мы можем предположить, что если один и тот же CallerID второй/третий раз звонит в Контакт-центр за последние 30 минут, то скорее всего у него вопрос к тому же оператору.
  2. Если сессия не существует, то считаем, что абонент звонит "первый" раз и сценарий работает по стандартной логике .
  3. Если сессия существует, то проверяем значение переменной AgentID оператора (Get Session Info). Значение переменной AgentID мы установили (Set Session Info, имя переменной можно придумать любое, указывается на вкладке Context) во время "предыдущего" звонка абонента, в тот момент когда звонок из очереди был направлен на оператора (Select Resource, параметр Connect = No, выход Selected).
  4. Если значение переменной AgentID существует (то есть абонент в прошлый раз дождался своей очереди и был переведен на оператора), то переключаем этот вызов на того же оператора (Select Resource, значение Routing Target Type равно Resourse).
  5. Если значение переменной AgentID не существует (то есть абонент в прошлый все еще был в очереди), то повышаем приоритет вызова (Set Priority). И чтобы сметливые абоненты не стали злоупотреблять логикой этого шага ("длинная очередь?" -> отбей звонок, тут же перезвони и ты будешь первым в очереди), то в Session нужно добавить переменную "WaitingTime", небольшие значение которой не будет включать логику этого шага.

Таким образом CallerID (АОН) абонента используется как уникальное имя ("Mapping ID") Session, к которой можно обратится и между звонками. В качестве "Mapping ID" может выступать любой уникальный идентификатор, однозначно идентифицирующий клиента в интервале 30 минут.

New Member

Павел, благодарю за столь

Павел, благодарю за столь развернутый ответ!

>>>Чтобы получить связанную с Contact-том Session нужно использовать шаг Get Contact Info (поле Session)
Вот этого у меня в скрипте не хватало. Теперь понятно - будем проверять на практике.

Сообщите пож-та когда все

Сообщите пож-та когда все получиться.

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

New Member

Договорились, Павел.

Договорились, Павел.

New Member

Как обещал, напишу как мы

Как обещал, напишу как мы применили данный функционал у нашего Заказчика (страховой компании). Напомню. Нам нужно было перенести данные переменной (наименование заказчика) из одного голосового приложения в другое. В нашем случае есть несколько подобных голосовых приложений обрабатывающих вызовы от клиентов. Каждое голосовое приложение создано для обработки вызовов определенного заказчика. Зачастую операторы не успевают обработать вызовы в приемлемое время. На этот случай в скриптах предусмотрено, что после нахождения 120 секунд в очереди клиенту периодически проигрывается сообщение с предложением оставить свой номер для того чтобы сотрудник страховой компании перезвонил клиенту. Если клиент выбирает данную возможность, то вызов исключается из очереди и с помощью Call Redirect перенаправляется на голосовое приложение Call Back. В это приложение нам и нужно перенести наименование заказчика – значение переменной Customer. Если клиент не нажимает ничего или жмет постороннюю комбинацию кнопок, то продолжает находится в очереди. Кому интересно как это сделано – прилагаю скрин, хотя тут все довольно просто:

Приложение CallBack обеспечивает возможность клиенту оставить номер двумя способами – голосом (при выборе такого способа вызов перенаправляется на номер голосовой почты, где клиент просто оставляет голосовое сообщение) или DTMF-набором строки номера на который нужно перезвонить. При выборе любого из способов производится запись во внешнюю базу данных. При выборе варианта оставления номера голосом нужно было записать: дату/время, АОН и наименование заказчика. При оставлении номера через DTMF: дату/время вызова, АОН клиента, введенную строку и наименование Закачика. Наименование заказчика определяется переменной Customer в голосовом приложении откуда пришел вызов. Для того чтобы значение данной переменной перенести в приложение CallBack , в исходном приложении на нужном шаге c помощью Get Session, я создал новую сессию и с помощью шага  Set Session Info добавил в созданную сессию контекстную информацию - данные переменной Customer.

В скрипте CallBack, в который переносятся данные, с помощью шага Get Session мы подключаемся к текущей сессии и затем при помощи шага Get Session Info получаем контекстные данные содержащиеся в сессии. Наименование контекстных данных сессии должно совпадать с исходным (т.е. в обоих скриптах данные о заказчике в сессии хранятся в поле называемом «Customer»).

Таким образом, мы перенесли с помощью Sessions данные переменной Customer при перенаправлении вызова из одного голосового приложения в другое. Исходная задача немного отличалась, но я полагаю, что выполню ее немного позже  с применением этого же способа переноса данных между скриптами.

Браво АндрейОтличный отчет! 

Браво Андрей

Отличный отчет!
 

New Member

Павел, настроил все как вы

Павел, настроил все как вы написали. Работает как часы! Но заказчика очень напрягает одна мелочь. В том случае если мы распределяем вызов не в очередь, а на конкретного оператора (при обнаружении повторного вызова), то после завершения обслуживания CAD переходит в состояние "Работа" (Work) и оператор автоматически "Готов" не становится. Т.е. операторы привыкли что CAD сам станет Готов, а для повторных вызовов по завершению обслуживания им надо клацать дополнительную кнопку.

Можно что то придумать чтобы не нужно было нажимать эту кнопку? 

Cisco Employee

Посмотрите настройки очереди

Посмотрите настройки очереди

Вы можете поставить тайм-аут, через сколько времени агент перейдет в Ready

New Member

Константин, С очередью

Константин, С очередью понятно. Но в данном случае вызов не на очередь распределяется, а на оператора. Т.е. в шаге SelectResource выбран таргетом не очередь а Resource (Т.е. какой то оператор)

Андрей,

Андрей,

Посмотрите на настройки:

Subsystem -> RmCm -> Agent Based Routing Settings 

Возможно, это поможет в проблеме.

New Member

Константин, а слона то я и не

Oleksii Stepanenko, а слона то я и не заметил :)

Огромная благодарность за оперативную подсказку.

81
Просмотры
30
Полезный материал
16
Ответы
СоздатьДля создания публикации, пожалуйста в систему