Буквально еще несколько лет назад поисковики в ответ на поисковый запрос «Облака» выдавали множество ссылок на детские мультфильмы и статьи в Википедии об атмосферных явлениях. В последние два-три года тенденция изменилась и в топ выдачи стали попадать публикации 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.
Через некоторое время вернемся с новыми описаниями и идеями.
Для простоты определим, что извечный вопрос «быть или не быть новому сервису» решен изначально и ни у кого из уважаемых представителей телекома не вызывает сомнений тот факт, что телефонный бизнес без виртуальных АТС в 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.
Через некоторое время вернемся с новыми описаниями и идеями.