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

image

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

Однако настоящая проблема возникает тогда, когда запись просто «пропадает». Ведь на самом деле, даже если 90-99% записей оказываются на месте, нехватка какой-то части разговоров может оказаться критической, так как по закону Мёрфи именно они чаще всего бывают нужны для анализа. Но и, в конечном счете, за что же вы платите, если не можете получить все записи разговоров?

Итак, собираем статистику: почему у клиентов облачных АТС пропадают записи:

1. Разговор записан не полностью.


Клиенты, которые приходят к нам с запросами от других операторов, часто сталкиваются с такой проблемой, как неполная запись разговоров. Это явление очень часто встречается на популярной платформе облачной телефонии с открытым кодом Asterisk. Например, если секретарь звонит клиенту по запросу, уточняет, что ему нужно и соединяет с сотрудником, оказывается, что сам разговор вовсе не записан.

image

Секрет в данном случае прост: дело в том, что запись происходит в привязке к одному из участников разговора, чаще всего – к первому участнику. А первым участником является секретарь. И если у него не возникло желания дослушать, как клиент будет общаться с сотрудником компании, запись оборвется в тот момент, когда секретарь положит трубку. В нашей виртуальной АТС Hive данная проблема была вылечена специальным дополнением функционала, который «отвязывает» запись от первого участника разговора. Однако, как показывает практика, целый ряд сервисов облачных АТС даже не подозревает, что такой баг существует у используемой платформы.

2. Пропали новые разговоры


Одна из самых распространенных проблем, это исчезновение целой пачки разговоров, в частности, самых новых. Причина может быть очень простой. Например, из-за ограничений на хранение разговоров на сервере оператора внезапно может кончиться доступная емкость. Тут возможны разные ситуации – клиент может не заметить уведомления о том, что место кончается, уведомление способно улететь в папку «спам», либо поток разговоров может оказаться внезапно активным. Характерный пример: софтовая компания выпустила глючную версию своего продукта, и посыпались звонки в техническую поддержку в таком объеме, в каком никто не ожидал. И их-то как раз хорошо было бы проанализировать…но кончилось место и последние разговоры не записались. Чтобы избежать такой ситуации компания IPtelefon предлагает неограниченное хранилище на своих серверах.

image

3. Пропали старые разговоры


Проблема более редкая, но, тем не менее, периодически встречающаяся. Некоторые клиенты, которые пришли к нам за «безлимитным хранилищем», теряли старые записи разговоров, так как на предыдущих АТС у них были неправильно настроены правила и политики хранения записей. При ограничении места может быть автоматизирована выгрузка сохраненных записей и чистка хранилища, что позволяет не столкнуться с предыдущей проблемой – переполнением и невозможностью сохранить новые записи. Но при этом могут возникать такие неприятные ситуации, как ошибка при выгрузке, но при этом полное удаление старых записей, либо неполная выгрузка. Все это чревато утерей важных данных, которые вы могли использовать для контроля качества или даже разрешения споров.

4. Подвела выгрузка на email


Популярный способ сэкономить на хранилище – выгружать все записи на email. А что, дешево и сердито! Этот метод вполне подходит, если вы можете смирится с откровенным неудобством при сортировке записей и поиску не в специализированной системе, а, например, в MS Outlook или веб-интерфейсе почтового ящика. Но, увы, даже с учетом компромиссов не всегда можно гарантировать, что отправленные сообщения дойдут до нужного ящика. Проблемы могут быть совершенно различными. Первая и самая банальная – переполнение целевого ящика. Далее следует временная недоступность сервиса (не все заглушки будут пытаться отправить запись несколько раз), а также отбой на прием больших писем – если ваши сотрудники выслушивали ругань клиента более часа, например. Комментарии тут излишни: если запись важна для вас, то выгрузка на email должна быть лишь дополнительной мерой.

5. Записи не видны в CRM.


Впрочем, даже те компании, которые считают для себя необходимым работать с упорядоченными записями, часто сталкиваются с проблемой: не все записи разговоров с конкретным клиентом могут быть доступны в его профиле в CRM. На самом деле это достаточно частая проблема при недостаточной оптимизации совместной работы CRM и АТС, и некоторые провайдеры (не будем показывать пальцем) сами скажут вам, что все записи доступны в АТС, но могут не отображаться в CRM. Что же, мы специально работали над плотной интеграцией AmoCRM и Hive, и часть наших клиентов появилась именно из-за надежности этой связки.

Один билет, второй билет…и проездной.


Есть такая серия детского тележурнала «Ералаш», когда мальчик едет в автобусе, и у него в правом кармане один билет, в левом – второй билет, а на случай, если потеряет оба – во внутреннем кармане лежит проездной. И если в автобусе это смешно, то в случае с записью разговоров – скорее практично. Ведь вы записываете их именно для того, чтобы они были у вас в любом случае, поэтому сервис Hive предлагает и безлимитное хранилище, и подключение по API, и доступ к записям через AmoCRM, и отправку на email. Все это можно использовать одновременно, заказав услуги виртуальной АТС у компании IPtelefon.

image
Поделиться с друзьями
-->

Комментарии (6)


  1. BlenderRU
    06.09.2016 08:53
    +1

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


    1. poxu
      06.09.2016 09:13

      Какие ещё детали, какая ещё техника? Там на картинке из деталей только кресло и паркет. Какие к ним могут быть претензии!


      Погодите, вы что, статью читали? Зачем? Врядли она имеет хотя бы косвенное отношение к картинке в начале.


      1. AlexanderS
        06.09.2016 10:43
        +3

        А я посмотрел картинку и сразу к комментариям промотал.
        Ваш коммент заставил улыбнуться)


    1. fish9370
      07.09.2016 14:49

      Я постараюсь изложить суть проблемы. Речь идет о телефонии на базе Asterisk. А именно о подсистеме Audiohook. Если говорить метафорично, то audiohook это возможность осуществить врезку в газовую трубу, где газовая труба это канал, а газ это аудио-поток. Так вот, MixMonitor (а так же ChanSpy и т.п.) используют этот механизм, для того чтобы подключаться к выбранному каналу. И в бесконечном цикле считывают аудио данные и записывают их в файл — так производится запись. Однако, все это происходит до тех пор, пока этот канал (в который произведена врезка) существует. Как только он завершается, а именно это происходит когда вы делаете трансфер, завершается и запись.


      1. fish9370
        07.09.2016 14:59

        Прошу прощения, за дубль комментария — еще не научился пользоваться


  1. fish9370
    07.09.2016 14:57

    Я постараюсь изложить суть проблемы. Речь идет о телефонии на базе Asterisk. А именно о подсистеме Audiohook. Если говорить метафорично, то audiohook это возможность осуществить врезку в газовую трубу, где газовая труба это канал, а газ это аудио-поток. Так вот, MixMonitor (а так же ChanSpy и т.п.) используют этот механизм, для того чтобы подключаться к выбранному каналу. И в бесконечном цикле считывают аудио данные и записывают их в файл — так производится запись. Однако, все это происходит до тех пор, пока этот канал (в который произведена врезка) существует. Как только он завершается, а именно это происходит когда вы делаете трансфер, завершается и запись.
    Так было не всегда, еще в 11 версии, эту проблему можно было решить с помощью функции AUDIOHOOK_INHERIT(MixMonitor), которая и осуществляла наследование дескриптора audiohook новому каналу.
    В последней версии 13 и выше, AUDIOHOOK_INHERIT признан устаревшим, а вместо кода красуется вот такая заглушка

    if (!warned) {
            ast_log(LOG_NOTICE, "AUDIOHOOK_INHERIT is deprecated and now does nothing.\n");
            warned++;
    }
    


    Но проблема осталась. Поскольку дескриптор все еще указывает на тот самый канал, которому суждено умереть.