Облачные объяснения: создаем операторский сервис виртуальной АТС за три дня

    Буквально еще несколько лет назад поисковики в ответ на поисковый запрос «Облака» выдавали множество ссылок на детские мультфильмы и статьи в Википедии об атмосферных явлениях. В последние два-три года тенденция изменилась и в топ выдачи стали попадать публикации c описанием облачных вычислений и платформ, а сам термин «Облака» у IT-специалистов теперь вызывает неоднозначные ассоциации: уже далеко не все представляют себе «взвешенные в атмосфере продукты конденсации водяного пара», скорее в сознании «правильного айтишника» возникают образы виртуальных площадок и платформ, различных IaaS, PaaS, SaaS. Виртуализация всего и вся — один из главных трендов десятилетия, множество клиентских сервисов давно переселились в облака, крупные телеком-бизнесы внедряют все новые и новые VAS в дополнение к основным услугам, а зачастую, то, что когда-то было Value Added Service превращается в базовый продукт. Услуги связи в этом смысле не являются исключением и сервис «Облачная АТС» становится просто обязательным пунктом в списке предложений телефонного оператора. О том, как (в том числе и с нашей помощью) быстро и сравнительно непринужденно запустить собственный сервис облачной АТС мы расскажем ниже.



    Для простоты определим, что извечный вопрос «быть или не быть новому сервису» решен изначально и ни у кого из уважаемых представителей телекома не вызывает сомнений тот факт, что телефонный бизнес без виртуальных АТС в 2015-м году — это не совсем правильно, вернее неправильно совсем. Рынок в этом сегменте растет до 40% в год и с таким фактом невозможно не считаться. Те из операторов, кто еще не успел запустить в продакшн облачную IP-PBX, почти наверняка задумываются об этом или вот-вот задумаются, вопрос исключительно в методах и сроках.

    Запускаем свою облачную АТС


    Способов запуска телефонного SaaS-сервиса несколько, коротко остановимся на двух наиболее распространенных: запуск облачной АТС как собственной разработки и запуск сервиса на базе White Label платформы одного из вендоров. Если оба способа изобразить наглядно и попытаться описать несколькими словами, то получится вот такая картина:

    Собственными силами

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



    По модели PaaS

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

    Первый путь — предмет целого, отдельного, исследования и мы к нему обязательно вернемся в одной из следующих публикаций, второй же путь нам ближе и понятнее и подробно рассмотрим именно его на примере нашей облачной White Label платформы ITooLabs. Добавим лишь, что при запуске сервиса виртуальной АТС на PaaS-платформе выбор «правильного вендора» — одна из архиважных задач, правильное решение которой может нивелировать главную проблему — зависимость от этого самого вендора.

    Разработка ITooLabs Communication Server — история продолжительностью в несколько лет. В основе продукта — собственное коммуникационное ядро, собственные интерфейсы и компоненты, собственное видение того, каким должна быть «правильная» облачная АТС, множество бессонных ночей разработчиков и маркетологов. Серверная часть, или то, что и принято называть PaaS, развернута в собственном же кластере: так спокойнее и нам и нашим партнерам. Мы обеспечиваем функционирование всех сегментов, контролируем и управляем, мониторим и обновляем, поддерживаем и саппортим.

    Партнер сервис-провайдер получает доступ к панели администратора после короткой и совершенно не мучительной кастомизации: логотипы, цветовая гамма и графические элементы интерфейса меняются практически на лету. В большинстве случаев запуск — от кастомизации до первого «Алло» — занимает не больше нескольких дней. В придачу даем программный ITooLabs Communicator (тоже кастомизированный) и постоянно обновляемый, актуальный и востребованный, функционал. О возможностях платформы в инфографике:



    ITooLabs Communication Server обеспечивает доступ к двум различным видам интерфейса управления: операторский интерфейс (он же интерфейс супер администратора) и клиентский интерфейс. Задача первого — обеспечить максимальный контроль и управляемость сервиса на стороне оператора, задача второго — удобство и простота, именно поэтому под рукой «CисАдмина» множество кнопок и чекбоксов, а в интерфейсе клиента минимум лишних опций и сплошные «красивости». СисАдмин управляет и контролирует, а клиент настраивает переадресации и IVR. Оба интерфейса кастомизируются и настраиваются. Пример «покрашенного» интерфейса клиента можно увидеть на скриншоте ниже.



    Интерфейс СисАдмина выглядит чуть иначе, но тоже может быть кастомизирован в стилистике партнера-оператора.

    Шесть шагов до первого звонка


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

    Для начала запрашиваем и получаем учетную запись суперадминистратора своего сегмента платформы. Как уже говорилось выше — платформа живет в нашем кластере, никаких многодневнных инсталляций и настроек не требуется, по факту все просто: по ТЗ кастомизируется интерфейс, генерится новая учетная запись СисАдмина и отправляется партнеру-оператору. Два-три дня и партнер получает свою учетку и может авторизоваться.



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

    Шаг первый:

    создаем новую клиентскую АТС (понятно, что клиент предварительно сообщил сколько сотрудников он планирует телефонизировать и какие дополнительные сервисы он хотел бы использовать). Генерируем новый субдомен, доступный по веб-адресу, который уважаемый партнер-оператор пожелал использовать для своей новой услуги. Адрес выглядит как: название_клиента.домен_партнера.



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



    Шаг второй:

    мы оператор, у нас много стыков с различными вышестоящими провайдерами и мы хотим управлять многочисленными транками, обеспечивая возможность каждому из клиентов звонить по оптимальному маршруту. Для этого создаем то количество шлюзов, которое необходимо (шлюз — он же транк, он же стык, он же гейтвей для входящих и исходящих звонков). Тут же можно подключить биллинг, выставить все необходимые правила для пропуска caller ID, формат трансляции номера и особенности передачи АОН.



    Шаг третий:

    прописываем необходимые маршруты и говорим какие вызовы и по каким направлениям будут маршрутизироваться в определенные транки-шлюзы. Оптимизация и еще раз оптимизация. Москву отправляем на московских операторов, а «межнар» в Дюссельдорф или Гамбург. Маршруты могут быть сколь угодно разнообразными.



    Шаг четвертый:

    создаем диал-планы. Еще со времен СССР в сознании большинства людей старшего поколения любой звонок на междугородные и международные направления должен начинаться с «8», а в сознании поколения X, которое пользуются исключительно смартфонами, правильный набор всегда начинается со знака «+». Упростим жизнь и тем и другим и настроим диал-планы так, чтобы все были довольны. Потом диал-планы «раскидаем» по пользователям.



    Шаг пятый:

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



    Шаг шестой:

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



    Шесть шагов по настройке первой виртуальной АТС пройдены, наступает момент истины. Нажимаем «Сохранить» и заводим для клиента учетную запись администратора, указываем ФИО, контакты, телефоны, пароли и явки.

    Глазами клиента


    Робот генерирует учетную запись и отправляет велкам-сообщение.



    Обрадованный клиент проходит по ссылке в письме, вводит свои учетные данные (страничка авторизации предусмотрительно кастомизированна в корпоративном стиле партнера), ждет пару секунд



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



    Минимализм клиентского интерфейса смущать не должен: все необходимое есть, настройки визуализированы, раздел «Статистика» создан с расчетом на пытливый ум рачительного руководителя и отображает все детали по каждому из сотрудников, формирует графики и отчеты. Раздел «Настройки» структурирован и все «фичи» предусмотрительно спрятаны под иконкой «Еще». Кнопка коробочной интеграции с CRM находится на самом видном месте. Подробное описание функционала клиентской части облачной АТС ITooLabs заняло бы еще пару страниц убористого текста. Когда-нибудь мы опишем и его, тем более, что на наш взгляд есть чем похвастаться. Но это уже другая история.

    Вместо заключения


    Понятно, что идеальных схем в реальной жизни не бывает, так же как и не бывает идеальных способов запустить новый или условно новый бизнес. Каждая из ситуаций индивидуальна и требует вдумчивого подхода и анализа. При этом в телекоме наблюдается четкий тренд: стремление к унификации и тиражируемости продуктов, эдакий «телеком-макдональдс», в котором подключение новых клиентов, их поддержка и обслуживание, поставлены на поток по отработанной технологии. Использование PaaS-платформ — как раз и есть шаг в этом направлении, поскольку клиент становится все более требовательным и капризным и просит все больше любви и внимания. В таких условиях огромное количество ресурсов тратится на удержание, а не только на привлечение. Все, описанное выше, есть лишь один из рецептов «универсального гамбургера» и мы верим в то, что именно такая модель окажется наиболее жизнеспособной в сфере серийных продаж телеком-продуктов для SMB.

    Через некоторое время вернемся с новыми описаниями и идеями.
    ITooLabs 33,42
    Российский разработчик ПО для операторов
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 20
    • +1
      Отличное решение! Удачи вам в развитии данного продукта, обязательно буду следить за вашим блогом!
      • 0
        Спасибо за отзыв. Будем делиться информацией по рынку облачных АТС. Экспертиза накоплена существенная.
      • +1
        Что значит управление АОНами? Могу назначить любой?
        • 0
          Если вы клиент, то, конечно же, нет. Номера (и АОНы) распределяет суперадминистратор, клиент оперирует только разрешенным списком номеров. вы можете назначить пользователю или отделу соотвествующий CID исключительно из вашего списка.
      • 0
        Решение отличное и интересное. Но по практике, достаточно частое требование от операторов — это интеграция таких систем с собственным порталом оператора и биллинговой системой по API. Есть ли в Communication Server такой интерфейс, типа API?
        • +1
          Разумеется, у ITooLabs есть полноценный SOAP API. Есть несколько операторов на ITooLabs, которые полностью автоматизировали все бизнес-процессы: с сайта можно взять демо, купить АТС, выбрав тариф, изменять опции, отображать в АТС оставшийся баланс, списания и т.д. Так что наоборот, с ITooLabs сделать это очень просто.
        • 0
          «В основе продукта — собственное коммуникационное ядро»

          Вы так CommuniGate назвали, или всё уже не так?
          • +1
            Ждите следующие посты;)
          • 0
            > Как уже говорилось выше — платформа живет в нашем кластере, никаких многодневнных инсталляций и настроек не требуется

            тоесть оператор свой трафик будет через вас гонять?

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

                P.S. для IVR таки тоже трафик к вам гнать надо.
                • 0
                  В описанном вами случае (небольшой оператор и т.д) будет лучше, если все будет работать в нашем облаке. То есть между клиентом и оборудованием оператора встаем мы. Конечный клиент будет подключаться к нашей платформе, оператор подает на нас транки (см. скриншоты выше).

                  P.S. Если потребуется вынос, то на вашей площадке окажется и IVR.
                  • 0
                    я к чему клоню — чтоб оно работало в любом случае надо коннекшен до вас? даже в случае 'выноса'?
                    • 0
                      Нет, в случае выноса коннекшена до нас (основного кластера) не нужно. Вынос — мы устанавливаем платформу на вашей площадке. Работать будет как классический софтсвитч, всё будет работать в вашей сети.
            • 0
              Упомянули бы еще про альтернативы раз уж решили про PaaS писать ;)
              • 0
                Реклама это хорошо, а как насчет схемок архитектуры системы для понимания, что это вообще такое.
                Как туда например воткнуть свой биллинг или COPM?
                • 0
                  Можем и то, и другое, но это заслуживает отдельной статьи. Не всё сразу.:)

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

                Самое читаемое