Возможности и ограничения нового поколения систем обслуживания клиентов

Представьте себе такую картину: вместо дорогостоящих центров телефонного обслуживания, «привязанных» к конкретному месту, вы создаете виртуальный мультимедийный центр, работники которого могут трудиться дома или в удаленных офисах, выходя на связь через IP-сеть с возможностью передачи голоса.

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

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

Такая картина — рекламный трюк или реальность? На самом деле в ней есть элементы и того и другого. Современные технологии позволяют создавать подобные центры, но полнофункциональные реализации встречаются редко.

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

При проектировании центров обслуживания клиентов следующего поколения придется воплотить две архитектурные концепции. Первая — это переход от технологии TDM/PBX к VoIP (передача речи по Internet-протоколу) при создании сетевой инфраструктуры. Вторая касается инфраструктуры приложений. Здесь придется перенести маршрутизацию вызовов и подготовку отчетов, традиционно выполняемые системой автоматического распределения вызовов (Automatic Call Distributor, ACD), из закрытых систем коммутации на открытые стандартные серверы.

Открытая архитектура

Открытая архитектура предполагает использование приложений, не зависящих от инфраструктуры. Функции маршрутизации, подготовки отчетов и управления могут выполняться на сервере, через который происходит обращение к инфраструктуре коммутации. Открытые приложения имеют возможность выполнять бесшовную маршрутизацию речевых вызовов, электронной почты и контактов через Web, а также в оперативном режиме соединять абонентов с агентами центра обслуживания через чат, целенаправленный просмотр в браузере или совместное заполнение форм. Коммутаторы для контакт-центров с открытой архитектурой предлагают такие фирмы, как Aspect Communications, Avaya, Cisco Systems и Nortel Networks.

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

Например, шведской компании Nordea, предоставляющей финансовые услуги, обслуживающей 3 млн. клиентов и обрабатывающей 44 млн. обращений в год (из них 85% — автоматически), внедрение Framework компании Genesys позволило преобразовать работу ее центра обслуживания клиентов, обрести большой авторитет в их глазах и сэкономить более 1,5 млн. долл. в год.

Nordea перешла от ACD-приложений на своем коммутаторе Nortel на программное обеспечение для сервера компании Genesys, предназначенное для работы не только с телефонными вызовами, но и с другими средствами. Genesys IP Contact Center прокладывает маршрут для контактов и осуществляет интеграцию с информационными системами и базами данных компании Nordea. Если базовая инфраструктура уже создана, система довольно быстро разворачивается на дополнительных сайтах.

Клиенты могут выбирать канал для связи с компанией по своему желанию, а программное обеспечение Genesys выводит их на наиболее доступного и квалифицированного агента из тысячи работающих в 14 центрах. При подборе агента учитывается язык, продукт или услуга, а также тип клиента.

Возможности и ограничения

Теоретически в системах с открытой архитектурой пользователи могут смешивать и сочетать продукты различных производителей. Правда, пока только теоретически. Например, производители инфраструктуры коммутации предлагают специализированные приложения, настроенные на их продукты, или же продвигают серверные приложения с предварительно интегрированными возможностями, объединяя ACD, средства интерактивного голосового ответа (Interactive Voice Response, IVR) и компьютерной телефонии (Computer-Telephone Integration, CTI). Как видите, не так уж открыта эта архитектура, как может показаться.

К плюсам относится возможность использования стандартных интерфейсов, что значительно облегчает интеграцию. Так, для подключения коммутаторов к серверам используются такие интерфейсы API, как TAPI и JTAPI. Решения CRM и CTI интегрируются с помощью ранее разработанных адаптеров наподобие CRM Ready Kit компании Siemens или G-Plus от Genesys. В этих условиях интеграция с пакетами CRM старшего класса, такими как Siebel, займет дни или даже часы, а не недели или месяцы. Аналогичным образом интегрируются системы интерактивного голосового ответа и инструменты для формирования отчетов.

Существуют определенные приемы для достижения большей открытости, облегчающие интеграцию, взаимодействие и переносимость. Примерами послужат уже стандартизованные гибкие схемы управления доступом к информации частной базы данных, открытой пользователям Internet через шлюз Micrsoft dbWeb и доступ через SQL, ODBC и XML. Широкое распространение в приложениях для центров обслуживания клиентов получили также архитектуры J2EE, .Net и CORBA.

Большинство поставщиков, желающих интегрировать свои решения с решениями CRM, имеют или будут иметь соединительные звенья для подключения к продуктам от четверки производителей высокого уровня: Oracle, PeopleSoft, SAP и Siebel Systems. У них, вероятно, получится полнофункциональный продукт. Для других поставщиков это будет открытый блок и получение готового продукта будет связано с использованием набора инструментальных средств разработки программного обеспечения или API. Интеграция CRM и CTI в настоящее время тяготеет к архитектуре тонкого клиента, в сторону которой мигрируют также большинство пакетов CRM.

Примером успешного объединения может служить использование созданной компанией AT&T системы интерактивного кабельного телевидения Headend in the Sky (HITS) и разработанного Clarify (ныне Amdocs) адаптера Siemens CRM Ready. HITS Digital Media Center обслуживает компании кабельного телевидения по всем Соединенным Штатам. Им необходимо переправлять нерешенный вопрос агенту, который последним занимался этим вопросом, и выдавать на экран ярлык невыполнения. Siemens и AT&T в течение одного уик-энда смогли интегрировать 60 рабочих мест агентов, избежав больших затрат сил на интеграцию систем.

VXML стимулирует развитие приложений самообслуживания
В приложении поддержки интерактивного голосового взаимодействия (IVR) на базе открытого стандарта VXML, на сервере А работает ПО автоматического распознавания речи и преобразования текста в речь, а на сервере В — VXML-код ядра базового приложения.
1. Клиент звонит в центр взаимодействия с клиентами и соединяется в приложением самообслуживания, работающим на серверах А и В
2. Приложение IVR связывается с бизнес-приложением и основной базой данных

Голосовые приложения самообслуживания становятся стандартом

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

Поставщики интерактивных голосовых систем поддерживают стандарт VXML, большинство из них придерживаются или скоро будут придерживаться его второй версии. Эти архитектурные подвижки дают большие возможности для расширения ранее небольшого сообщества поставщиков, а также для обеспечения мобильности приложений при использовании инфраструктуры Web и общих данных.

Однако стандарт VXML Version 2.0 нуждается в значительных дополнениях для поддержки приложений, обеспечивающих контакты с клиентами. За рамками стандарта пока остаются, например, функции управления вызовами на базе средств компьютерной телефонии, выдача всплывающих окон на экраны компьютеров и составление обобщенных отчетов. Это не позволяет переносить удовлетворяющие стандарту приложения на другие платформы.

Многие поставщики создают код VXML на основе своего фирменного графического интерфейса. Это облегчает переход в рамках одной платформы при использовании собственных программных наработок (однако на другую платформу при применении расширений код не переносится). Некоторые поставщики как, например Genesys, скептически относятся к стандартам. Они намерены активизировать работы по развитию VXML и стандартов Call Control XML, а также соблюдать и поддерживать требования Speech Application Language Tags, конкурирующей спецификации, продвигаемой корпорацией Microsoft.

Мероприятия, необходимые для перехода на открытые архитектуры

Для перехода на системы с открытой архитектурой необходимо следующее:

  • Понимать свою бизнес-стратегию. Компании, стремящиеся предлагать лучшее в своем класса обслуживание, снижать затраты, добиваться большей гибкости и адаптируемости к изменяющимся потребностям бизнеса, должны обеспечить возможность разработать бизнес-применение для открытой архитектуры.
  • Понимать свои бизнес-потребности. Компаниям, которые хотели бы наладить обработку контактов, самообслуживание через Web и по телефону, улучшить подготовку отчетов и интеграцию настольных приложений, самое время обратить внимание на более открытые решения.
  • Разработать свою стратегию в отношении технологии. Определите свое место в бизнесе и сроки, в которые этого надо достичь, с тем чтобы поддержать намеченные бизнес-потребности. Определить, как изменения в приложениях будут согласовываться с изменениями инфраструктуры.
  • Определить принципы проектирования и внедрения. Более быстрая разработка приложений, переносимость, интероперабельность и гибкость — все это указывает не необходимость более открытых сред.
  • Начать процесс изучения различных приложений и способов интеграции, предлагаемых на рынке центров взаимодействия с клиентами. Понять, какие из стратегических партнеров предлагают действительно открытые решения.
  • Выбирать поставщиков, предлагающих открытые решения. Требовать от них демонстрации возможностей их продуктов. Убедиться, что выбранная стратегия лучшая в своем классе или оптимально подходит в данном случае, и знать почему, а также понимать, с чем придется мириться.
  • Не руководствоваться при выборе только ценой. Это имеет смысл, только если речь идет об общей стоимости владения. Необходимо понимать, что купленная недорого система может потребовать очень дорогостоящего обслуживания и управления.
  • Внедряйте новые приложения только после тщательного тестирования, широко используя пилотные проекты. Этот процесс требует времени — от года до полутора лет, а иногда и больше. Поэтому начинать планирование надо уже сейчас.