SQL-пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Система автоматического исходящего обзвона – это программное обеспечение, с помощью которого любой Call-центр может в разы сократить время и затраты на исходящий обзвон. Существует 4 основных способа организовать обзвон списка номеров:
ручной набор - оператор делает набор вручную. Это неэффективное расходование времени оператора (набор номер, писк контакта в базе и так далее);
preview – диалер загружает списки контактов, в которых оператор заранее видит информацию по каждому клиенту и принимает решение о звонке самостоятельно. При этом, он не набирает номер телефона и не снимает трубку до того момента, как абонент ответит на звонок;
progressive – так же, как и в preview загружаются списки контактов, но в этом варианте у оператора нет возможности отказаться от внешнего звонка. Диалер стремится занять звонками максимальное количество доступных каналов. Это подходит для автоматических извещений, IVR (когда вызываемого абонента нужно подключить на интерактивное меню) и прозвона номеров;
predictive dialer – самое интересное. При предиктивном дозвоне используются сложные сценарии и реальный математический расчет. Dialer предназначен для максимального сокращения времени ожидания оператором звонка при минимальных потерях успешных звонков. Для этого используются алгоритмы, «просчитывающие» необходимое количество звонков в следующий момент на основании данных о количестве операторов, которые будут доступны на момент соединения, о средней длительности разговора (ACD), о проценте успешных соединений (ASR) и прочих. У каждого продукта данные секретны и не публичны :).
Хочу презентацию продукта!
Программный продукт IqDialer
В качестве основной телекоммуникационной платформы для IqDialer был выбран Asterisk. Дайлер кроссфункционален и стабилен – он справляется с разными задачами, а его надежность протестирована в десятках инсталляций. Все функциональные возможности диалера (интеграция с внешними компонентами, CRM, например) управляются посредством RESTful API.
Работает это примерно так: устанавливается и настраивается оборудование, необходимое для начала работы Call-центра, затем загружается база контактов для обзвона, и операторы входят в систему, занимая свои виртуальные рабочие места и вставая в очередь на телефонии. IqDialer определяет доступные ресурсы для работы, и в этот момент программа начинает расчеты, запрашивает статистику звонков, рассчитывает, сколько нужно взять лидов (контактов для обзвона), занимает расчетное количество операторов, трансформирует лиды в звонки и отправляет все на телефонию. Первый этап закончен :)
В следующем этапе звонки, попавшие в телефонию, при дозвоне до клиента попадают в очередь и диалер собирает всю доступную ему информацию о звонке. На основании собранной информации программа отправляет карточки лидов операторам, и те видят на своих экранах всю информацию по контакту и обрабатывают звонок в соответствии с поставленной задачей. На последнем этапе по завершению звонка, оператор дополнительно обрабатывает карточку лида, сохраняя ее (срабатывает интеграция CRM и диалера) дает понять системе сколько длилась дообработка и что оператор готов принять новые вызовы (освобождается в очереди). Система обрабатывает завершенный звонок, производя манипуляции с лидом, меняет его статус и создает задачи для пропущенного звонка.
«Под капотом» это выглядит примерно так:
Время статистики. Для сравнения эффективности различных режимов набора, мы возьмем 3 (три) самых распространенных варианта обзвона (Preview, Progressive и Predictive), которые практикуют Call - центры, и для примера возьмем Call – центр, где один оператор работает 5 дней в неделю, по 8 часов в день:
Действие
Preview
Progressive
Predictive
Поиск карточки клиента (сек)
0
0
0
Ознакомление с карточкой клиента (сек)
10
0
0
Набор номера (сек)
0
0
0
Дозвон (сек)
20
20
0
Занятость оператора в разговоре (сек)
90
90
90
Всего времени на звонок (сек)
120
110
90
Звонков в день
240
262
320
Формула получения звонков в день и месяц
8*60*60/120240*22
8*60*60/110262*22
8*60*60/90320*22
Звонков в месяц
5280
5764
7040
Если привести здесь в качестве примера статистику, учитывающую еще и ручной набор, то результатом сравнения будет превосходство предиктивного набора над ручным почти в 2 раза. Даже при таком простом анализе, который не учитывает множество дополнительных факторов и полностью исключает сравнение с ручным набором оператором телефонных номеров, очевидна выгода :)
Таким образом, основываясь на вышесказанном, любой Call - центр просто обязан использовать только Predictive (предиктивный) Dialer. Однако не все так просто. Этот режим эффективен в том случае, если число работающих операторов не опускается ниже 20–30. В противном случае predictive dialing вместо пользы будет приносить только вред.
Смешанный режим работы оператора
В работе каждого Call - центра случаются временное затишье или резкий всплеск количества обращений, которые тяжело прогнозировать. В такой ситуации действенным инструментом поддержания необходимого и достаточного уровня сервиса могут стать работа в смешанном режиме – blended Agent. Смешанный режим позволяет оператору обрабатывать входящие и исходящие обращения по различным каналам коммуникаций в рамках единой очереди.
Чтобы проиллюстрировать выгоду, полученную при добавлении исходящих звонков в кейс (рабочие задачи) оператора, можно привести такой пример: допустим, операторы принимают только входящие звонки и при этом в течение одного рабочего дня простаивают 20% своего времени. Тогда в течение дня оператор не работает (8*60*0.2) = 96 минут. Пусть в Call - центре работает 10 операторов, тогда легко вычислить, что колл-центр уже простаивает (96*10/60) = 16 часов в день , а в месяц уже (16*22) = 352 человеко-часа.
При этом, у колл-центра могут быть заказы на проведение опросов (исходящая кампания на обзвон), и во время простоя оператору будут подмешиваться звонки с опросами. Производительность и качество обслуживание входящих звонков останутся на должном уровне, а Call - центр получит дополнительную прибыль.
Есть определенные тонкости, которые необходимо учитывать при планировании кампаний исходящего обзвона и входящих звонков, дело в том, что смешанный колл-центр будет эффективно работать только в режимах preview и progressive. Поскольку режим predictive подразумевает 100% занятость и любые отвлечения оператора приведут к потерям клиентов.
IqDialer: интерфейс и как он выглядит
Посмотрите, как выглядит дашборд супервизора, который следит за компаниями исходящего обзвона:
Двигаемся к отчетности – ниже отчет агентов по статусам (включает круговую диаграмму):
Заказать продукт
Отчеты реального времени – кто говорит, сколько времени:
Можно посмотреть самую важную информацию по каждой очереди:
Тайм – лайны! Смотрим, что делал наш агент на протяжении отрезка времени – звони, говорил, делал пост – ворк (работа после звонка) и так далее:
Интересен продукт? Напишите нам на dialer@merionet.ru
Файл cookie HTTP сохраняет информацию в веб-браузере пользователя. Веб-серверы генерируют файлы cookie и отправляют их в браузеры, которые затем включают их в будущие HTTP-запросы.
Что из себя представляют файлы cookie на веб-сайтах?
Файлы cookie – это небольшие информационные файлы, которые веб-браузер генерирует и отправляет в веб-браузер. Веб-браузеры хранят файлы cookie, которые они получают, в течение заранее определенного периода времени или в течение сеанса пользователя на веб-сайте. Они добавляют соответствующие файлы cookie к любым будущим запросам, которые пользователь делает на веб-сервере.
Файлы cookie помогают информировать веб-сайты о пользователе, позволяя персонализировать взаимодействие с ним. Например, интернет-магазины используют файлы cookie для того, чтобы узнать, какие товары пользователи кладут в свои корзины. Кроме того, некоторый файлы cookie необходимы в целях безопасности, например, файлы cookie аутентификации.
Файлы cookie, которые используют в Интернете также называются «файлами cookie HTTP». Как и большинство, что связано с Интернетом, файлы cookie отправляются с использованием протокола HTTP.
Где хранятся файлы cookie?
Веб-браузеры хранят файлы cookie в специальном файле на устройствах пользователей. Например, веб-браузер Google Chrome хранит все файлы cookie в файле под названием «Cookies». Пользователи Chrome могут просмотреть файлы cookie, хранящиеся в браузере, открыв Средства разработчика, щелкнув вкладку «Приложение» и «Файлы cookie» в меню слева.
Для чего используются файлы cookie?
Сеансы пользователей: файлы cookie помогают связать действия веб-сайта с конкретным пользователем. Сеансовый файл cookie содержит уникальную строку (комбинацию букв и цифр), которая соответствует сеансу пользователя с соответствующими данными и содержимым для этого пользователя.
Предположим, у Алисы есть учетная запись в интернет-магазине. Она заходит в свою учетную запись с главной страницы сайта. Когда она входит в систему, сервер веб-сайта создает файл cookie сеанса и отправляет файл cookie в браузер Алисы. Этот файл cookie указывает веб-сайту загрузить содержимое учетной записи Алисы, чтобы на главной странице теперь было написано «Добро пожаловать, Алиса».
Затем Алиса переходит на страницу товара с джинсами. Когда веб-браузер Алисы отправляет HTTP-запрос для этой страницы, он включает файл cookie сеанса Алисы с запросом. Поскольку на веб-сайте есть этот файл cookie, то он распознает пользователя как Алису, и ей не нужно снова входить в систему при загрузке новой страницы.
Персонализация: файлы cookie помогают веб-сайту «запоминать» действия или предпочтения пользователя, позволяя тем самым веб-сайту настраивать взаимодействие с пользователем.
Если Алиса выходит из интернет-магазина, ее имя пользователя может быть сохранено в файле cookie и отправлено в ее веб-браузер. В следующий раз, когда она будет загружать этот веб-сайт, веб-браузер отправит этот файл cookie на веб-сервер, который затем предложит Алисе войти в систему с именем пользователя, которое она использовала в прошлый раз.
Отслеживание: некоторые файлы cookie записывают, какие веб-сайты посещают пользователи. Эта информация отправляется на сервер, который создал файл cookie, тогда, когда браузеру необходимо будет снова загрузить содержимое с этого сервера. Со сторонними отслеживающими файлами cookie этот процесс происходит каждый раз, когда браузер загружает веб-сайт, использующий эту службу отслеживания.
Если Алиса ранее посещала веб-сайт, который отправил ее браузеру файл cookie для отслеживания, то этот файл cookie может записать, что Алиса сейчас просматривает страницу товара с джинсами. В следующий раз, когда Алиса загрузит веб-сайт, который использует эту службу отслеживания, она может увидеть рекламу джинсов.
Реклама – не единственное применение файлов cookie для отслеживания. Многие службы аналитики также используют отслеживающие файлы cookie для анонимной регистрации действий пользователей.
Какие существуют типа файлов cookie?
Ниже представлены некоторые из самых важных типов файлов cookie, которые следует знать:
Сеансовые файлы cookie
Сеансовый файл cookie помогает веб-сайту отслеживать сеанс пользователя. Сеансовые файлы cookie удаляются после завершения сеанса пользователя – после того, как он выходит из своей учетной записи на веб-сайте или покидает веб-сайт. Сеансовые файлы cookie не имеют срока действия, а для браузера это значит, что они должны быть удалены после завершения сеанса.
Постоянные файлы cookie
В отличие от сеансовых файлов cookie, постоянные файлы cookie остаются в браузере пользователя в течение заранее определенного периода времени (это может быть день, неделя, несколько месяцев или даже лет). Постоянные файлы cookie всегда имеют срок действия.
Файлы cookie аутентификации
Файлы cookie аутентификации помогают управлять сеансами пользователей. Они генерируются, когда пользователь входит в учетную запись через свой браузер. Они гарантируют, что конфиденциальная информация доставляется в правильные сеансы пользователя, связывая информацию об учетной записи пользователя со строкой идентификатора файлы cookie.
Отслеживающие файлы cookie
Отслеживающие файлы cookie генерируются службами отслеживания. Они записывают активность пользователя, и браузеры отправляют эту запись в соответствующую службу отслеживания при следующей загрузке веб-сайта, использующего это службу отслеживания.
Зомби-cookies
Подобно «зомби» из популярной фантастики, зомби-cookies восстанавливаются после удаления. Зомби-cookies создают свои резервные копии за пределами обычного места хранения файлов cookie браузера. Они используют эти резервные копии для того, чтобы снова появиться в браузере после их удаления. Такие зомби-cookies иногда используют недобросовестные рекламные сети и даже злоумышленники.
Что такое сторонний файл cookie?
Сторонний файл cookie – это файл cookie, который принадлежит домену, отличного от того, который отображается в браузере. Сторонние файлы cookie чаще всего используются для целей отслеживания. Они отличаются от основных файлов cookie, которые принадлежат тому же домену, который отображается в браузере пользователя.
Когда Алиса делает покупки на сайте jeans.example.com, сервер-источник jeans.example.com использует сеансовый файл cookie для того, чтобы запомнить, что она вошла в свою учетную запись. Это пример основного файла cookie. Однако Алиса может не знать, что файл cookie с сайта example.ad-network.com также хранится в ее браузере отслеживает ее действия на сайте jeans.example.com, даже если в данный момент она не заходит на сайт example.ad-network.com. Это пример стороннего файла cookie.
Как файлы cookie отражаются на конфиденциальности пользователей?
Как упоминалось ранее, файлы cookie могут использоваться для записи активности в Интернете, в том числе и в рекламных целях. Однако многие пользователи против того, чтобы их действия в сети отслеживались. Пользователям также не хватает видимости и контроля над тем, что службы отслеживания делают с данными, которые они собирают.
Даже если отслеживание на основе файлов cookie не привязано к конкретному имени пользователя или устройству, при некоторых типах отслеживания все еще можно связать запись и действия пользователя с Интернете с его реальной личностью. Эта информация может использоваться любыми способами, от нежелательной рекламы до наблюдения, навязчивого преследования и травли пользователей (Это относится не ко всем файлам cookie.)
Некоторые законы о конфиденциальности (о неприкосновенности личной жизни), такие как Директива ЕС о защите электронных данных, касаются и регулируют использование файлов cookie. В соответствии с этой директивой пользователи должны предоставить «информированное согласие» - они должны быть уведомлены о том, как веб-сайт использует файлы cookie, и дать согласие на их использование – до того, как веб-сайт начнет использовать файлы cookie. (Исключением являются файлы cookie, которые «строго необходимы» для работы веб-сайта.) Общий регламент ЕС по защите данных рассматривает идентификаторы файлов cookie как персональные данные, поэтому его правила распространяются и на использование файлов cookie в ЕС. Помимо этого, любые личные данные, собранные с помощью файлов cookie, попадают под юрисдикцию общего регламента по защите данных.
Во многом из-за этих законов многие веб-сайты теперь отображают баннеры файлов cookie, которые позволяют пользователям просматривать и контролировать файлы cookie, которые используют эти веб-сайты.
У нас есть Windows Server 2008 R2 и сейчас мы сделаем из него Контроллер домена - Domain Controller (DC). Погнали!
Первым делом – запускаем Server Manager:
Затем выбираем опцию Roles и добавляем новую роль для нашего сервера, нажав Add Roles:
Нас встречает мастер установки ролей, а также просят убедиться, что учетная запись администратора имеет устойчивый пароль, сетевые параметры сконфигурированы и установлены последние обновления безопасности. Прочитав уведомление кликаем Next
Сервер, выступающий в роли DC обязан иметь статический IP адрес и настройки DNS Если данные настройки не были выполнены заранее, то нас попросят выполнить их в дальнейшем на одном из этапов.
В списке доступных ролей выбираем Active Directory Domain Services. Мастер сообщает, что для установки данной роли нужно предварительно выполнить установку Microsoft .NET Framework. Соглашаемся с установкой, нажав Add Required Features и кликаем Next
Нас знакомят с возможностями устанавливаемой роли Active Directory Domain Services (AD DS) и дают некоторые рекомендации. Например, рекомендуется установить, как минимум 2 сервера с ролями AD DS (т.е сделать 2 DC) на случай, чтобы при выходе из строя одного сервера, пользователи домена все ещё могли бы залогиниться с помощью другого. Также, нас предупреждают о том, что в сети должен быть настроен DNS сервер, а если его нет, то данному серверу нужно будет дать дополнительную роль – DNS. После того, как прочитали все рекомендации, кликаем Next чтобы продолжить установку.
Наконец, нам предоставляют сводную информацию об устанавливаемой роли и дополнительных компонентах для подтверждения. В данном случае, нас уведомляют о том, что будет установлена роль AD DS и компонент .NET Framework 3.5.1. Для подтверждения установки кликаем Install.
Дожидаемся пока завершится процесс установки роли и компонентов.
Через какое-то время перед нами появится результат установки, он должен быть успешным как для роли так и для компонентов Installation succeeded. Закрываем мастер установки, нажав Close.
Вернувшись в Server Manager мы увидим, что у нас появилась роль AD DS, однако ее статус неактивен. Чтобы продолжить настройку кликаем на Active Directory Domain Services.
Перед нами открывается уведомление о том, что наш сервер пока ещё не является контроллером домена, и чтобы это исправить нам следует запустить мастер настройки AD DS (dcpromo.exe). Кликаем на ссылку Run the Active Directory Domain Services Installation Wizard или же запускаем его через Пуск – Выполнить – dcpromo.exe.
Перед нами открывается мастер настройки AD DS. Расширенный режим установки можно не включать. Для продолжения кликаем Next
Нас встречает уведомление о том, что приложения и SMB клиенты, которые используют старые небезопасные криптографические алгоритмы Windows NT 4.0 при установке соединений, могут не заработать при взаимодействии с контроллерами домена на базе Windows Server 2008 и 2008 R2, поскольку по умолчанию, они не разрешают работу по данным алгоритмам. Принимаем данную информацию к сведению и кликаем Next
Далее нам нужно выбрать принадлежность данного контроллера домена. Если бы у нас уже имелся лес доменов, то данный DC можно было бы добавить туда, либо добавив его в существующий домен, либо же создав новый домен в существующем лесу доменов. Поскольку мы создаем контроллер домена с нуля, то на следующей вкладке мы выбираем создание нового домена и нового леса доменов Create a new domain in a new forest и кликаем Next.
После этого нам предлагают задать FQDN корневого домена нового леса. В нашем случае мы выбрали merionet.loc. Сервер проверит свободно ли данное имя и продолжит установку, нажимаем Next.
Далее задаем функциональный уровень леса доменов. В нашем случае - Windows Server 2008 R2 и кликаем Next.
Обратите внимание, что после задания функционального уровня, в данный лес можно будет добавлять только DC равные или выше выбранного уровня. В нашем случае от Windows Server 2008 R2 и выше.
Далее, нам предлагают выбрать дополнительные опции для данного DC. Выберем DNS Server и нажимаем Next.
В случае, если ваш сервер ещё не имеет статического IP адреса, перед вами появится следующее предупреждение с требованием установить статический IP адрес и адрес DNS сервера. Выбираем No, I will assign static IP addresses to all physical network adapters
Устанавливаем статические настройки IP адреса и DNS. В нашем случае – в роли DNS сервера выступает дефолтный маршрутизатор (Default Gateway) нашей тестовой сети.
Далее, установщик предлагает нам выбрать путь, по которому будут храниться база данных Active Directory, лог-файл и папка SYSVOL, которая содержит критичные файлы домена, такие как параметры групповой политики, сценарии аутентификации и т.п. Данные папки будут доступны каждому DC в целях репликации. Мы оставим пути по умолчанию, но для лучшей производительности и возможности восстановления, базу данных и лог-файлы лучше хранить в разных местах. Кликаем Next.
Далее нас просят указать пароль учетной записи администратора для восстановления базы данных Active Directory. Пароль данной УЗ должен отличаться от пароля администратора домена. После установки надежного сложного пароля кликаем Next.
Далее нам выводят сводную информацию о выполненных нами настройках. Проверяем, что все корректно и кликаем Next.
Мастер настройки приступит к конфигурации Active Directory Domain Services. Поставим галочку Reboot on completion, чтобы сервер перезагрузился по завершении конфигурирования.
После перезагрузки сервер попросит нас залогиниться уже как администратора домена MERIONET.
Поздравляем, Вы создали домен и контроллер домена! В следующей статье мы наполним домен пользователями и позволим им логиниться под доменными учетными записями.