Прикладные решения CRM для call-центров
Теперь перейдем от общих слов к делу и посмотрим, каким конкретно образом внедрение компьютерно-телефонной интеграции может влиять на повышение эффективности обслуживания вызовов. К числу основных функций, которые можно реализовать с помощью CTI, я бы отнесла следующие:
- дополнительная маршрутизация;
- «всплывающие окна»;
- перенаправление вызова вместе с данными;
- исходящий обзвон;
- телефон на экране.
Теперь рассмотрим подробнее каждую из этих функций: как она реализуется и что конкретно она обеспечивает.
Дополнительная маршрутизация
Возможно, вас несколько удивит термин «дополнительная маршрутизация». Но мне он кажется достаточно логичным. Как мы уже не раз подчеркивали, основная, базовая маршрутизация, без которой вообще невозможно никакое обслуживание вызовов, осуществляется непосредственно в рамках системы ACD. И связка «ACD плюс система мониторинга» вполне способна работать самостоятельно, без CTI, хотя и с гораздо меньшей эффективностью. Использование средств компьютерно-телефонной интеграции привносит в маршрутизацию вызовов большую гибкость, даже, я бы сказала, интеллектуальность — недаром CTI еще часто называют интеллектуальной маршрутизацией.
Говоря о прикладных решения CTI, можно четко проследить разницу между такими понятиями, как маршрутизация и распределение вызовов. CTI отвечает именно за маршрутизацию, то есть за способ обслуживания данного конкретного звонка. Таким образом, CTI, например, может выбрать конкретную группу операторов, которые должны ответить на данный вызов. А вот за распределение вызовов внутри этой группы операторов ответственна уже система ACD.
CTI незаменима для организации обслуживания вызовов на основе сегментации клиентов. Там, где есть грамотная политика сегментации клиентов и где маршрутизация вызова напрямую зависит от категории вызывающего абонента, CTI просто необходима.
Как же реализуется функция маршрутизации? Немедленно при поступлении вызова, еще до постановки в очередь, система самостоятельно направляется в базу данных, с целью определить, какой именно абонент совершает звонок, к какой именно категории его следует отнести, для того чтобы потом выбрать наилучший способ обслуживания именно этого конкретного вызова. Также имеет смысл интегрировать вашу crm систему с call-центром.
Как мы уже говорили, существуют два способа получения информации о вызывающем абоненте для дальнейшего запроса в базу данных:
1) на основании его телефонного номера (АОН);
2) на основании каких-либо персональных данных, введенных вызывающим абонентом.
Идентификация по АОНу — самый удобный способ и с точки зрения самого абонента, и с точки зрения эффективности работы ЦОВ. К сожалению, в наших условиях этот способ имеет существенные ограничения. Но мне кажется, если вы уверены, что по крайней мере для 60-70% всех вызовов вы сможете получить АОН, то вам стоит им воспользоваться.
Метод идентификации абонента на основании введенных им персональные данных является гораздо менее удобным с точки зрения самого абонента и гораздо более дорогостоящим с точки зрения управляющего персонала call центра. Дело в том, что часто такой способ идентификации тянет за собой использование системы интерактивного речевого взаимодействия (о которой мы подробно расскажем в следующем разделе). Естественно, это требует дополнительных инвестиций.
Тем не менее во всех операторских центрах, где при обслуживании вызовов особенно важно соблюдать конфиденциальность (самый яркий пример — это, конечно, банки), в целях безопасности для идентификации абонента следует применять именно этот способ. Только после того как клиент введет определенный набор персональных данных (например, номер кредитки и ПИН или номер страхового полиса и т.п.), начнется индивидуализированное обслуживание вызова.
В заключение хочется привести пример, иллюстрирующий разные возможности обслуживания вызовов с применением CTI и без ее применения.
Предположим, что некая компания не имеет средств компьютерно-телефонной интеграции, однако все же пытается реализовать некоторую политику сегментации клиентов. Так, она разделила всех своих клиентов на категории А, В, С. Клиентам, относящимся к каждой из этих категорий, компания присвоила их собственный номер доступа в call-центр: абоненты категории А набирают номер 111-11-11, категории В— номер 222-22-22, категории С — номер 333-33-33.
Итак, в систему поступает вызов от абонента X. Далее система понимает, что раз данный абонент набрал номер 222-22-22, то он относится к категории В, и направляет его вызов операторам, обслуживающим вызовы именно данной категории. И на этом сегментация клиентов заканчивается.
То, что этот абонент X, во-первых, в рамках своей категории В относится к VIP-клиентам, во-вторых, звонит уже третий раз подряд в течение одного дня и до сих пор не может решить свою проблему — все это не принимается %о внимание.
Мало того, если абонент X еще и перепутает номер телефона, по которому он должен звонить, и наберет 333-33-33 или 111-11-11 вместо назначенного для него 222-22-22, то система вообще не сможет правильно идентифицировать данного клиента и его вызов поступит на обслуживание совсем не к той группе операторов. Между тем, путаница в номерах случается довольно часто. Например, клиенты могут запомнить рекламный номер и пользоваться только им. И тогда вся политика сегментации клиентов обратится в пыль.
Теперь представим, что та же гипотетическая компания имеет средства компьютерно-телефонной интеграции. В этом случае она может даже не заботиться о назначении разных номеров доступа в call-центр разным категориям абонентов, поскольку категория будет определяться из базы данных. Итак, поступил вызов от абонента X. Система тут же обращается в базу данных, чтобы определить, что это за абонент и каким образом следует обслужить его вызов.
Предположим, условно говоря, что в клиентской базе данных в поле 1 стоит буква В. Значит, абонент относится к категории В. В поле 2 стоит символ «VIP». Что ж, и тут все ясно: вызову должен быть присвоен высший приоритет и он должен быть направлен в группу операторов, обслуживающих абонентов категории В. А вот в поле 3 стоит цифра 2. Что это значит? А то, что данный абонент уже звонил дважды в течение дня по одной и той же проблеме, и раз звонит в третий раз, то эта проблема, скорее всего, так и осталась нерешенной. Определяем, какие операторы call-центр обслуживали клиента при первых двух звонках: Иванов и Рабинович (ну так, для разнообразия). Проверяем, свободны ли они сейчас. Если свободен один из них, к нему и направляем. Если свободны оба, направляем вызов к тому, кто обслуживал вызов последним. Если оба заняты, присваиваем вызову наивысший приоритет и направляем его в очередь напрямую к тому, кто обслуживал вызов последним (Direct Agent Call). И только если ни тот ни другой не могут обслужить вызов (ушли на перерыв, закончили смену и т.д.), абонент X будет обслужен другими операторами.
Ну как, почувствовали разницу?