proactive outreach manager что это

Proactive outreach manager что это

Приглашаем Вас принять участие в бесплатном вебинаре по теме «Система исходящих взаимодействий Avaya Proactive Outreach Manager: практики применения и возможности системы», который пройдёт 23 июня с 11:00 до 12:00 по московскому времени.

О чём будем говорить?

Кому может быть полезно?

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

Другие новости Avaya:

Компания Avaya вошла в число лучших работодателей мира согласно рейтингу Forbes 2021: World’s Best Employers. Компания второй год подряд получает эту престижную оценку.

Компания Avaya провела ежегодный форум Experience Avaya 2021. Мероприятие прошло 16 сентября в отеле Radisson Славянская. В форуме приняли участие более 500 клиентов и партнеров компании. Главной темой мероприятия стала трансформация ИКТ-компаний в условиях пандемии и актуальность развития цифровых сервисов.

Источник

Proactive outreach manager что это

Приглашаем Вас принять участие в бесплатном вебинаре по теме «Система исходящих взаимодействий Avaya Proactive Outreach Manager: практики применения и возможности системы», который пройдёт 23 июня с 11:00 до 12:00 по московскому времени.

О чём будем говорить?

Кому может быть полезно?

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

Другие новости Avaya:

Компания Avaya вошла в число лучших работодателей мира согласно рейтингу Forbes 2021: World’s Best Employers. Компания второй год подряд получает эту престижную оценку.

Компания Avaya провела ежегодный форум Experience Avaya 2021. Мероприятие прошло 16 сентября в отеле Radisson Славянская. В форуме приняли участие более 500 клиентов и партнеров компании. Главной темой мероприятия стала трансформация ИКТ-компаний в условиях пандемии и актуальность развития цифровых сервисов.

Источник

Вторая жизнь вместе с Maven

Думаю, для большинства хабражителей не будет откровением, что среди крупных софтварных разработок нередко встречаются технологии и языки значительно отстающие от передовых. К сожалению, это неизбежность, т. к. невозможно в какой-то момент взять и переписать несколько миллионов строк кода на другой язык или с применением более современного фреймворка.

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

Здесь я хочу рассказать о том, как в конкретном случае я постарался оттянуть неизбежное и оживить разработку применив для этого сборщик проектов Maven.

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

Итак дано:

— Система, «ядро» которой состоит из набора dll и отдается прикладным разработчикам без исходников.
— Прикладной язык программирования, который подобен Паскалю, но кроме стандартных возможностей Паскаля(из которых доступно далеко не все) позволяет использовать объекты, реализованные в dll «ядра». Данный прикладной язык компилируется в подобие байт кода и исполняется отдельной dll «ядра».

Таким образом, основная разработка ведется на описанном выше волшебном прикладном языке, все прелести которого, пожалуй, могли бы ужаснуть уважаемое сообщество, а «ядро» периодически(новая версия раз в пару месяцев) поставляется из головного офиса и не подлежит модификации.

Очень вероятно, что разработка и поддержание собственного языка программирования похожего на Паскаль и сделанного на базе Delphi возможно была плохой идеей, но 15-17 лет назад, когда все это начиналось, об этом никто не думал. Преследовались другие цели, которые в общем-то с успехом были достигнуты.

Сама система представляет из себя продаваемый заказчику продукт с сервером, клиентом и тонким клиентом. Естественно, большинство клиентов не удовлетворяются стандартным функционалом системы, поэтому существует несколько отделов прикладной разработки, “допиливающих”систему под их нужды. Каждым проектом занимается обособленная группа программистов. Взаимодействие и обмен опытом между группами катастрофически малы. Таким образом, каждая группа получает свой шанс переизобрести велосипед и наступить по десятому разу на одни и те же грабли.

Проведя анализ, стало понятно, что такое отсутствие взаимодействия отделов объясняется прежде всего нехваткой механизмов использования общего кода. Иными словами, если все-таки, происходил обмен опытом и исходниками между группами, то библиотека(исходник) просто копировалась в другой проект(продукт для друго клиента) и начинала жить самостоятельной жизнью, сохранив в себе все глюки и недоработки, которые присутствовали на момент копирования.

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

В качестве инструмента для этого был выбран Maven, т. к. он по умолчанию выполняет схожие функции, имеет гибкий жизненный цикл и огромную гибкость плагинной системы.

Но обо всем по порядку

Главной проблемой, о которой я и не подозревал в начале своих изысканий, оказалось то, что Пакеты должны содержать в себе не скомпилированные в байт код файлы, а именно исходники, т.к. компиляция должна происходить именно под той версией «ядра», для которой они будут использоваться. Для простоты назовем наши прикладные исходники bpas. Это немного противоречит стандартному ЖЦ в Maven.

Немного о том как работает Maven

Жизненный цикл Maven достаточно полный, и набор фаз(phases) учитывает практически все этапы сборки проекта, которые могут потребоваться.

Причем пытаясь запустить какую-то фазу ЖЦ, например «mvn compile», я на самом деле запускаю всю цепочку фаз от validate (валидация проекта) до compile, не пропуская ни одной. Для каких-то фаз существуют так называемые плагины по умолчанию, которые будут вызваны несмотря на то, что в pom.xml(основной файл Maven проекта) существует только заголовок и ни одного указания на запуск плагинов.

Здесь стоит отдельно отметить тот факт, что Maven — это полностью плагинная система. Иными словами, он не умеет практически ничего, кроме запуска плагинов, а вот они уже умеют делать потрясающе много. Получается, что когда мы хотим научить Maven каким- то особенностям сборки проекта, мы должны добавить в pom.xml указание на запуск нужного плагина в нужную фазу и с нужными параметрами.

Вот такой абсолютно валидный пустой pom.xml, несмотря на свою пустоту, при получении команды mvn deploy запустит Плагин инициализации, компиляции, упаковки и деплоя Java исходников из папки src/main.

Основной политикой использования в Maven является то, что для любого действия есть свои параметры по умолчанию и дополнительные настройки требуются только в том случае, когда этих умолчаний не хватает или они грубо нарушаются. В моем случае пришлось отказаться от очень многих умолчаний, поэтому pom.xml уже не выглядит так скромно.

Построение нового ЖЦ в pom.xml

Для реализации пакетов был подобран следующий жизненный цикл.

initialize (инциализация) – Читаем настройки из конфиг(property или key = value) файла и добавляем их в тег properties. О теге properties поговорим чуть позже.
generate-sources (генерация исходного кода) – Загружаем и распаковываем из zip все Пакеты, которые являются зависимостями данного пакета/проекта, в отдельную директорию для последующей компиляции вместе с исходниками текущего пакета/проекта.
compile (компиляция) – Запускаем свой плагин компиляции для наших bpas, который определяет правильный порядок компиляции и запускает компилятор командной строки для нашего языка. Кратко я расскажу о собственном плагине ниже, но гайд по его написанию предлагаю вынести за пределы данной статьи.
assembly (сборка) – запаковываем пакет, состоящий из исходников bpas в zip с сохранением структуры подкаталогов исходных файлов.
deploy (в нашем случае выгрузка в репозиторий) – Собранный на фазе assembly zip отправляется в локальный репозиторий Maven с добавлением к нему pom.xml и другой информации по пакету. Данная процедура почти идентична нормальному deploy jar файла, но с особыми параметрами.

clean (очистка) – Данная фаза не входит в общий ЖЦ фаз сборки, а стоит несколько особняком, но поскольку она также была модернизирована, ее тоже стоит упомянуть. Кроме стандартного удаления директории, в которой лежат скомпилированные файлы. (targetDirectory), потребовалось удалять тот мусор, который образуется в процессе скачивания и распаковки пакетов-зависимостей.

Общая структура pom.xml

Я условно делю pom.xml на две части: заголовок и сборка.

Заголовок представляет из себя идентификацию пакета (groupId, artifactId, version), свойства (properties, которые выполняют роль внутренних констант), указание локального репозитория (distributionManagement), указание локального репозитория плагинов (pluginRepositories), указание локального репозитория пакетов (repositories) и указание зависимостей этого пакета (dependencies). При этом все три репозитория могут указывать на одно и то же хранилище, но принципиально это три разные сущности, каждую из которых нужно указывать отдельно. Так например, мы можем решить хранить плагины отдельно от остального кода, а для доступа к пакетам в хранилише использовать http доступ, тогда как «деплоить» туда мы будет как в файловое хранилище.

Сборка (тег build) — это вторая часть pom.xml, в которой настраиваются особенности обработки той или иной фазы жизненного цикла различными плагинами с недефолтными настройками. Кроме этого там настраиваются директории и параметры, которые будут участвовать в сборке проекта:
sourceDirectory – директория, в которой находятся исходники для компиляции.
finalName – конечное имя файла после запаковки в архив.
directory – рабочая директория, в которую будут положены скомпилированные файлы.
Кроме этого еще раз хочу напомнить, что для всех этих параметров, существуют значения по умолчанию, и их отдельное указание в нашем случае требуется только потому, что они должны отличаться от этих самых умолчаний.

Реализация ЖЦ в теге build

Теперь вернемся к определенному нами ЖЦ и посмотрим, как каждая из фаз жизненного цикла реализована при помощи вызова нужного плагина с той конфигурацией, которая нам нужна.

initialize

Тут опять давайте немного отвлечемся и отдельно упомянем тег properties. Объясним, зачем он нужен и как используется.

Если говорить очень грубо, то этот тег похож на объявление констант, которые в дальнейшем будут использоваться в нашей программе (pom.xml). Но попадать туда значения могут тремя разными способами. И у каждого способа есть приоритет, определяющий, какое в итоге значение будет в тот момент, когда оно реально потребуется.

Низший приоритет у прямой записи свойств в тег properties, например так:

Более высокий приоритет у прямого задания параметров при запуске Maven, примерно так «mvn –DhelloText=Hi initialize»
При запуске Maven с таким параметром исходное значение тега helloText будет заменено на переданное в строке запуска для текущего сеанса, т.е. в xml оно не сохранится. Если такой константы вообще не существовало, то на этот сеанс она будет существовать и может быть использована. Значения всех несуществующих констант — пустая строка.

Наивысшим приоритетом обладает добавление значений в тег proprties плагинами в текущей сессии. Они так же не сохраняться в pom.xml. Именно этот механизм и будет использован нами для вынесения отдельных настроек сборки в properties файл, содержащий “имя=значение”
Для этого используется плагин properties-maven-plugin

generate-sources

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

Конструкция $ означает, что нужно взять значение из тега “/project/properties/packagesPath”.

Отдельно хочу отметить, что использования плагина maven-assembly-plugin для распаковки считается deprecated и не рекомендуется к использованию в Maven 3. Вместо него используется maven-dependency-plugin с настройками аналогичными указанным выше. Я же использую более старую версию плагина, чтобы еще раз наглядно показать, как один и тот же плагин настраивается на выполнение нескольких задач из его ассортимента.

compile

Со стадией компиляции пришлось изрядно повозиться, но основные трудности возникли с написанием собственного плагина компиляции. Пошаговая инструкция по написанию собственного плагина для Maven — это тема для отдельной статьи, поэтому сейчас мы не будем заострять на этом внимание. В конце-концов изложенный здесь материал может быть использован и для скриптовых языков, компиляция которым вообще не требуется.
Одно можно сказать наверняка, как бы вы не старались, не удастся отключить запуск родного плагина maven-compile-plugin, призвание которого компилировать исходники на Java( Не рассматривая возможности редактирования superPom.xml). Итак настройки моего плагина компиляции выглядят следующим образом:

используемые параметры:
protectionServer — сервер защиты, без которого невозможен запуск компилятора командной строки.
protectionAlias — секция используемой лицензии сервера защиты.
bpasccPath — полный или относительный путь к компилятору командной строки.
binaryVersion — Версия, которая будет «вмонтирована» в скомпилированную библиотеку.

Это далеко не все настройки моего плагина, но как я и говорил, это тема для отдельной большой статьи. В принципе секцию configuration можно было вообще не указывать и тогда все параметры, которые необходимы плагину, были бы проинициализированы плагином значениями по умолчанию, что соотвествует основной концепции Maven.

assembly

При прохождении фазы assembly у Maven по умолчанию настроен запуск maven-assembly-plugin, явно указав его запуск в фазе assembly в теге build, мы можем переопределить его настройки и заставить работать на нас. Этот же плагин мы использовали для распаковки пакетов перед компиляцией, поэтому теперь я приведу полную версию настроек этого плагина, включающую и запаковку и распаковку.

packagesDirName — это константа из /project/properties файла pom.xml
Отдельно хочу отметить, что такое вынесение настроек запаковки в отдельный файл, позволило мне создать один конфиг запаковки на все Пакеты, что крайне удобно.

deploy

Фаза deploy так же запускается Maven’ом независимо от того, указали ли мы настройки этого плагина или нет. Переопределив их, мы и этот плагин заставили работать на себя.

С такими ручными настройками maven-deploy-plugin позволяет любой файл(или даже группу файлов) выложить в репозиторий Maven как валидную библиотеку(Пакет). Теперь разберем настройки по порядку.
file — файл, который будет отправлен в репозиторий Maven как Пакет.
url — путь к репозиторию Maven
repositoryId — идентификатор репозитория, в который будет производиться депллой.
groupId, artifactId, version — стандартная идентификация пакета в репозитории Maven. Именно по этим трем параметрам можно однозначно идентифицировать библиотеку. packaging – функционал деплой так же включает в себя запаковку файлов, которые будут отправлены в репозиторий, поэтому необходимо снова указать ему zip, чтобы он ничего не делал с пакетом, иначе распакует и запакует как jar :-).
pomFile – если данный параметр указан, то в комплект к Пакету будет добавлен тот файл, который мы укажем как pom.xml, при этом его изначальное имя может быть другим. Сохранять оригинальный pom.xml выгодно по многим причинам, поэтому мы не будем брезговать данной возможностью.

clean

Фаза clean, как я уже говорил, не входит в стандартный ЖЦ. Изначальная ее задача состоит в том, чтобы после выполнения команды mvn clean в проекте не осталось никаких следов жизнедеятельности. В нашем случае кроме стандартной папки targetSource(указана в теге build) требуется так же удалить все Пакеты, которые были «слиты» как зависимости для успешной компиляции пакета/проекта.

directory — собственно указание директории, которую необходимо удалить. Надо отметить, что тут создатели плагина отошли от общепринятой концепции, и явное указание настроек плагина не отменяет его действий по умолчанию. Но в данном случае, это очень хорошо, т. к. избавляет нас от лишний настроек.

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

Итоги

Несмотря на то, что я сам остался чертовски доволен своей работой, я готов признать, что в данном виде система пакетной сборки проекта еще далека от совершенства, однако, приведенное описание достаточно иллюстрирует реализацию полного жиненного цикла пакета/проекта. Фактически это работоспособный каркас, поверх которого можно почти неограниченно расширять возможности.

Источник

Maven: неразрешимый родительский POM

У меня мой проект maven настроен как 1 проект оболочки и 4 дочерних модуля. Когда я пытаюсь построить оболочку. Я получил:

Если я пытаюсь создать одинокий модуль, я получаю ту же ошибку, только заменяю модуль1, каким бы модулем он ни был.

Пусть все они ссылаются на родителей в своих пометках.

Вот соответствующие части помпона:

сработало для меня.

Просто для справки.

Это также можно исправить, поместив правильный settings.xml файл в

В моем случае проблема была еще более сложной из-за Eclipse: репозиторий был активен только в специальном профиле (

Решением было временно объявить репозиторий вне профиля (безоговорочно), запустить Alt+F5 Maven Update Project, активировать профиль и вернуть объявление репозитория в профиль. Это скорее ошибка Eclipse, а не ошибка Maven.

Неразрешаемый родительский POM: это означает, что вы не можете разрешить родительский репо.

Транг в режиме отладки:

Поскольку родительский репо не является частью центра maven. Решение состоит в том, чтобы указать файл setting.xml в

m2 /, чтобы помочь создать родительский POM. /Users/username/.m2/settings.xml

В этом XML вам может потребоваться указать информацию о репозитории.

Просто добавьте так, чтобы родительский элемент в pom выглядел так:

проверьте, есть ли у вас правильные значения в дочерних POM

В Eclipse, например, вы можете искать его:

Если вы строите в рамках дочернего проекта, это может помочь вам разрешить родительский pom.

установить родительский pom

Но если вы создадите дочерний проект из его папки, это не сработает. Вы можете install сначала поместить родительский pom в свой локальный репозиторий, а затем построить дочерний проект.

Источник

Презентация была опубликована 7 лет назад пользователемВадим Ряхин

Похожие презентации

Презентация на тему: » The Power of Proactive Outreach Proactive Outreach Manager Overview Name Title Location/Date.» — Транскрипт:

1 The Power of Proactive Outreach Proactive Outreach Manager Overview Name Title Location/Date

3 ©2010. All rights reserved. Self-Funded Roadmap in Action Financial Services Example Loan Loss Account/Loan Restructuring Account Servicing Economic Assistance Programs AttritionSales of New Services Delinquencies Increased Regulations & Volume in Lending High Risk Customers on the Move

4 ©2010. All rights reserved. Key Business Challenges 4 Costs Out of Control Over Budget Low Customer Satisfaction Scores Missing Revenue and Profit Targets Fear Loss of Sensitive Data

5 ©2010. All rights reserved. Business Impact of Proactive Outreach 5 Reduce Cost and Complexity Improve Customer Satisfaction Increase Revenue and Profits Lower Risks, Improve Control

6 ©2010. All rights reserved.6 Proactive Outreach Manager simplifies creation, execution, and management of outbound self service campaigns helping businesses reduce costs, capture more revenue, and improve customer satisfaction Value Proposition

8 ©2010. All rights reserved. Promote New Products and New Revenue Leveraging Outbound Automation Increase awareness of new products and services by creating campaigns Generate interest and revenue by automating initial cross-sell/up-sell to Associate agent notification, as required, to complete self service ordering Throttle live support based on sales agent queue times 8

9 ©2010. All rights reserved. Anticipate Needs and Improve Response Utilizing Outbound Notifications Anticipating customer concerns Alerting customers in real time Leveraging communication mode preferences Automating surveys 9

10 ©2010. All rights reserved. Control Campaigns and Coordinate Service While Lowering Costs Control development, updates, timing Coordinate outbound alerts with contact center Throttle campaigns based on queue times Unify management by leveraging Voice Portal Reduce risk of exposing sensitive data 10

12 ©2010. All rights reserved. Architecture 12 Live Agent (only as needed) Campaign and Customer Data Dialog Designer Application Server (existing or new) Dialog Designer Apps VoiceXML Apps CTI Apps Voice Portal Management System VoiceXML Interpretation Call Classification Telephony Admin/Configuration Licensing Reporting Database Media Processing Platforms Server E Mail SMSC Text PSTN Voice Voice Portal Media Processing Platforms Proactive Outreach Manager Campaign Management SMS Gateway

13 ©2010. All rights reserved. Execute Multiple Concurrent Outbound Campaigns from Single Environment Customer C Customer A SIP Proactive Outreach Live Agent (only as needed) Customer B Voice Text E Mail Welcome Aboard Payment Reminder Product Promotion Subscription Renewals Example Applications

15 ©2010. All rights reserved. Reduce Costs Shape Inbound Traffic Customer SIP Proactive Outreach Customer Agents Voice Text E Mail Customer Voice Transfer as Needed Customer

16 ©2010. All rights reserved. Throttle Outreach on Agent Queues Transfer screen pop with call, as needed Base outreach on agent queue time 16 SIP Proactive Outreach Agents Voice Text E Mail Customer Caller Transfer Customer Reduce Outcall Rate

17 ©2010. All rights reserved.17 Leverage Avaya Voice Portal to Unify Inbound Self Service + Outbound Customer Care Outbound Voice Text E Mail Customer Inbound Customer Voice Voice Portal SIP Proactive Outreach SIP Self Service Live Agent (as needed) Welcome Aboard Payment Reminder Product Promotion Subscription Renewals Product Support Corporate Directory Ordering and Payments Applications

18 ©2010. All rights reserved. Campaign and Systems Management Leverages Voice Portal for unified OA&M Multiple campaigns on same system Multi-tenancy and roles based access Event API for notifications and escalations Administrative or Web Services interfaces Do-Not-Call, campaign, compliance, disposition reports 18

19 ©2010. All rights reserved.19 Manage within Avaya Voice Portal

20 ©2010. All rights reserved.20 Centralize Administration on Voice Portal Administration Logging/Alarming User Roles Licensing

21 ©2010. All rights reserved.21 Access Real-time and Historical Reporting via Voice Portal

22 ©2010. All rights reserved. Optimize Resources with Multi-Tenancy Enable business units to execute their own campaigns Delegate by role Centralize control Share general lists and status 22

23 ©2010. All rights reserved. Segregated Management Within Multi-tenant View 23

24 ©2010. All rights reserved. Multi-tenant Client View Example Using Sales Client 24

25 ©2010. All rights reserved. Designing Campaigns Design applications with Dialog Designer Support time zones and retries that look across attempts and channels Flat file & database connector support (or write your own in Java) Pre-built data connectors for customer status and business rules Web Services interfaces 25

26 ©2010. All rights reserved.26 Designing Applications with Dialog Designer

27 ©2010. All rights reserved.27 Defining Campaigns

28 ©2010. All rights reserved. Reports Customer Systems Status Contact Selection ODBC Web Services Status Updates Campaign Information Flows E Mail Text Voice Customer Data Campaign Proactive Outreach Manager Management

29 29 Proactive Outreach Use Cases and Applications – Financial Services SEE NOTE:

31 ©2010. All rights reserved.31 Proactive Outreach in Financial Services Collections Sales/cross- sell/up-sell Surveys/ Commercial & CSAT Renewals & Win back Fraud detection Welcome Calls Retention Collections Acquisition

32 ©2010. All rights reserved.32 Enhance On-Boarding Acquisition Use Case Strategy Deliver high touch interaction Expand customer reach Encourage personalization Leverage automation Validate receipt through proactive alerts Offer additional services based on usage patterns Automate outbound calling Improve agent productivity Lower risk, penalties, fees using do not call Tactics Multi-channel New customer welcome Follow-up on missing info Notify customers of key events First bill explanation Multi-channel Proactive automated card activation Remind customer to use their cards Leverage up-selling skills Manage campaign & lists Facilitate enrollment in new services Screen pops to agents Top Benefits Reduce early attrition Improve customer satisfaction Lower cost Decrease process cycle time Lower cost Improve customer satisfaction Increase card usage Increase revenue Improve customer retention Increase right party contact Increase agent productivity New Account Opening Acquisition & Cross-selling/ Up-selling Overdraft

33 ©2010. All rights reserved.33 Personalize Each Experience Retention Use Case Strategy Expand customer reach Preventive and proactive Leverage automation Provide immediate overdraft notification Mitigate customer dissatisfaction by minimizing fee accumulation Enable stickiness through automated renewal reminders Simplify payment, minimize past due Leverage automation Tactics Multi-channel Make transaction completion easy Immediate notification Multi-channel Proactive notification Make fund transfer easy Multi-channel Proactive notification Facilitate paying and renewing Notify when bill payment amount > account balance Certificate of Deposit renewal Top Benefits Improve customer retention Improve customer satisfaction Lower cost Improve customer retention by avoiding fees Improve customer satisfaction Increase revenue Improve customer retention Lower cost Account Status Alerts Renewals & Bill Payments Overdraft account balance Certificate of Deposit renewal Top Benefits Improve customer retention Improve customer satisfaction Lower cost Improve customer retention by avoiding fees Improve customer satisfaction Increase revenue Improve customer retention Lower cost Account Status Alerts Renewals & Bill Payments Overdraft»>

34 ©2010. All rights reserved. Lower Costs and Improve Performance Collection Use Cases Strategy Preventive and service driven contacts Earlier contact increases likelihood of collections Focus on improved agent productivity Expand contact options Tactics Multi-channel account alerts Make paying easy Automation for 100% list penetration Make paying easier and less embarrassing Top agents focus on verified customers Screen pop info to agents Multi-channel contact Skip tracing Top Benefits Lower delinquency Increase customer satisfaction Lower roll rate Lower cost per collection Increase collection rate Increase right party contact Increase agent productivity Increase collection rate Current Accounts Early Stage ( days) Mid-Stage ( days) Late Stage (90+ days)

35 ©2010. All rights reserved. Avaya Advisory Services Formulate a clear plan with predictable business outcomes Services: Ensuring Value & Success Business Communications Advisory Services Identify and qualify business improvement communication strategies Identify business requirements through structured discovery & review Unite business needs and technical capabilities Align with key stakeholders Prioritizes an architectural roadmap which delivers cost savings to help fund future technology investments Assess and prioritize business needs Discover and quantify cost savings opportunities Implement and measure Self-Funded Roadmap Technical Advisory Services Technical support services, including architecture design reviews, network migration analysis, and more Recommendation on design, approach and solutions that can deliver reliable and best- in-class capabilities

36 ©2010. All rights reserved.© 2009 Avaya Inc. All rights reserved.36 End-to-End Avaya Services Maximizing value through a comprehensive suite of services Plan, Design, Integrate Avaya Professional Services Drive business results with communications technology Support Global Support Services Maximize the value of your investment Operate Avaya Operations Services Manage your environment holistically

Источник