Enterprise клиенты что это

Работа с enterprise: как мы не сделали систему аналитики для SaaS сервиса

Мы сильно обрадовались новому контракту и уже представляли, как логотип клиента приукрасит наше портфолио. Но все оказалось не так радужно. Расскажем, как мы работали с дочкой крупной российской IT-компании, и почему у нас не получилось сделать крутой проект.

О проекте

Продукт клиента — SaaS в сфере B2B, который работает по формату абонентской платы. Пользователь регистрируется, проходит авторизацию, пополняет свой счет и использует сервис.
Наша задача — помочь клиенту «собрать» аналитику. Для этого нужно было выстроить процессы колл-центра, внедрить CRM и «свести» сквозную аналитику по ключевым показателям.

Структура процессов

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

Воронки продаж

Продажи у клиента велись в Enybox CRM, их мы перенесли в amoCRM для удобства интеграции. Логику продаж получилось собрать в три воронки.

_{Три последовательные воронки}

Первая воронка — консультации. Нужна была, чтобы довести клиента до регистрации на платформе. Вторая воронка — фиксация первых оплат. Далее пользователь подтверждал свою регистрацию. А мы, в свою очередь, отмечали момент оплаты и каждое новое пополнение.

Как должна была работать аналитика

Для нормальной работы системы аналитики нужно собирать все события = отмечать конверсионные действия. События уже попадали в систему аналитики, но изначально их было только два типа, что недостаточно для отчетов.

Отображение данных

_{Пример дашборда}

После того, как собирались данные по конверсиям, нужно было сделать из них отчет. Основной инструмент визуализации данных — Microsoft Power BI.

В момент конверсии на сайте генерировался отдельный ID для синхронизации рекламных систем и CRM. По этому ID мы связывали данные расходов и доходов. Так мы соотносили данные и могли строить по ним отчеты.

Юнит экономика. Retention

_{График rolling-retention’а сервиса с 1 по 12 месяц}

Retention показывает, насколько пользователи вовлечены в приложение, и как часто они в него возвращаются. Но из-за того, что сервис работает в формате пополнений, пришлось поменять этот показатель на rolling-retention. Он показывает то же самое что и ретеншн, но подразумевает что все время, которое пользователь не пополнял кабинет, он тоже использовал сервис.

Конверсия в первое пополнение

Конверсия сильно зависела от количества новых клиентов и начала их оплат. Первые 9 месяцев мы получали примерно по 430 новых регистраций и по 90 оплат от новых пользователей ежемесячно. Конверсия в покупку в месяц регистрации составила 20%, по данным за 12 месяцев.

Помимо стандартных показателей

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

Пользователь увидел рекламу → пошел на сайт → спустя время зашел и поискал в контексте → зарегистрировался, но не оплатил → погрели письмом → предложили тест драйв → потестил → ОП «дожал» на первую оплату → 3 года стабильных оплат.

Что пошло не так

В самом начале инициаторы проекта отложили старт до осени (обратились весной). Такие «пробелы» в работе происходили не раз. Но мы не задумывались об этом и принимали как должное. Главными проблемами были коммуникация и бюрократия в процессах нашего клиента. Так можно изобразить весь временной отрезок работы над проектом:

Медленная разработка

Два спринта пропустили — месяц потеряли

Все менеджеры и разработчики на их стороне работали по двухнедельным итерациям. Но они постоянно ставили наш проект последним по приоритету и часто наши задачи не попадали в «спринт».

Плохая коммуникация и отсутствие экспертизы

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

Сложнее было разбираться с некомпетентностью стейкхолдеров. Один из них был отличным руководителем, который хорошо разбирался в своем продукте. Но он не понимал даже базовых принципов построения процессов продаж. Мы потратили несколько встреч, чтобы переубедить его убрать из воронки продаж этап со статусом «Как дела?».

Представьте себе воронку продажи, как на рисунке выше. В одном из этапов менеджерам нужно узнать «как дела у клиента». Как думаете, что произойдет с аналитикой конверсий такой воронки?

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

В процессе продажи невозможно ставить промежуточные этапы, в которых будут накапливаться сделки. Иначе вся аналитика превратится в «кашу», а менеджеры потеряют кучу контактов.

Факапы с нашей стороны

Мы не учли пропускную способность системы. На одно событие платформы в пике мы передавали до 10 запросов к amoCRM, чтобы выполнить логику бизнес-процессов.

100 000 ивентов в сутки * 10 запросов к amoCRM = 1 000 000 запросов в сутки

1 000 000 запросов в сутки / 10 запросов в секунду (ограничение амо) = 100 000 секунд = ±27 часов

Итог: синхронизация никогда не закончится

Изначально выбрали amoCRM, так как «проходи» по лимиту запросов к системе. Но с течением развития проекта требования и функции увеличились и мы «уперлись» в лимит.

Мы выбрали неподходящий инструмент. AmoCRM физически не подходит для обработки большого количества запросов.

Также ошибка была в том, что мы разрабатывали все на GO, и за это отвечал один специалист. Когда он ушел, осталась гора legacy кода, который никто не смог бы разобрать. Но, к сожалению, или к счастью это не было нужно.

Опять все сломали

Этот кейс — еще один пример проекта, который закопали в согласованиях и куче неоправданного менеджмента.

Нам не хватило экспертности в техническом плане. Клиенту — устойчивости в управлении и желания довести проект до конца.

Но это опыт. Благодаря ему теперь подобные задачи выглядят максимально тривиально и мы уже воспроизвели подобное решение в рамках другого проекта.

Как можно было избежать неудачи

Чтобы не повторять таких кейсов в будущем, мы выделили аспекты, которые нужно соблюдать в работе с enterprise клиентами.

Источник

Дилемма в определении целевого рынка для стартапа: SMB или Enterprise?

Томаш Тангюз (Tomasz Tunguz) — венчурный предприниматель и партнер американского фонда Redpoint, имеющего в своем портфолио такие проекты, как социальная сеть Myspace, стриминговый сервис Netflix, облачный сервис по поддержке клиентов Zendesk, сайт вопросов-ответов Answers.com и др. Главный интерес Томаша — инвестиции в софт: сейчас он работает с Looker, Axial, Expensify и другими стартапами, а до этого участвовал в разработке AdSense от Google в качестве проектного менеджера.

По его мнению, большинство стартапов на пути своего развития рано или поздно встает перед выбором: остаться в сегменте малого и среднего бизнеса (SMB, small-to-medium business), с которого они начинали, или искать поддержки у более влиятельных игроков рынка и прокачивать продукт для enterprise.

Box, Hubspot, Zendesk — эти и многие другие проекты начинали с SMB и постепенно перешли к обслуживанию и крупных компаний.

Почему так происходит?

Томаш называет этот переход «Дилеммой новатора» (Innovator’s Dilemma), по аналогии с идеей Клейтона Кристенсена (Clay Christensen) из его книги «Дилемма инноватора: Как из-за новых технологий погибают сильные компании» (The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail). Кристенсен говорит о подрывной силе инноваций — что развитие новых технологий влияет на устойчивость компаний, делая их продукт устаревшим и неконкурентноспособным.

Читайте в сегодняшнем посте о сложном выборе в жизни SaaS-стартапов.

Инновации, churn и малый бизнес

Если вы начинающая SaaS-компания, то очевидно, что ориентация на малый бизнес или SMB-сектор имеет значительные преимущества за счет простоты продукта (сравните — Box и Sharepoint), доступности его мобильных приложений (Expensify и Concur) и контент-маркетинга (Zendesk и Oracle/Peoplesoft). На первых порах именно SMB-клиенты обеспечивают финансовый рост и развитие молодым проектам, что позволяет команде усовершенствовать свой продукт и сделать его более привлекательным.

Линейка продуктов Zendesk

Линейка продуктов Oracle

Однако, несмотря на хорошую адаптацию малого бизнеса, эксперименты и интерес к научно-техническим и управленческим новинкам, это одновременно его достоинство и недостаток. Из-за мобильности SMB-сектора облачные-компании регулярно сталкиваются с высокий оттоком (churn rate) клиентов, который замедляет рост бизнеса, и с определенного момента они вынуждены искать поддержку у более стабильных и крупных предприятий.

Чем меньше клиент, тем выше его churn. Чтобы проиллюстрировать это, Томаш приводит следующую таблицу:

Показатели месячного (monthly) и ежегодного (annual) оттока клиентов для малого (SMB), среднего (Mid-Market) и крупного бизнеса (Enterprise).

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

В итоге, показатели оттока растут, цена приобретения новых клиентов (CAC, customer acquisition cost) увеличивается и проект требует все больших инвестиций, чтобы просто остаться на плаву.

Переход на enterprise рынок

Если churn SMB-компаний достигает такого размера, что дальнейшее развитие (growth) проекта затруднительно, то в этот момент стартап должен вывести свой продукт на новый масштаб. Согласно Томашу, это и есть причина того, почему все известные компании-разработчики ПО со временем ориентируются на крупных игроков или enterprise сегмент.

Дилемма новатора

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

Быстрый прирост клиентской базы малого бизнеса на начальном этапе стимулирует рост проекта, обеспечивает его развитие и может послужить неплохой поддержкой.

Но с увеличением прибыли, расширением продукта и привлечением крупных заказчиков перед компанией встает вопрос: играть на скорости продаж и прогнозе инноваций для SMB-части рынка или сосредоточиться на масштабных предприятиях и разработке стабильного оффера. В этом и состоит дилемма новатора для SaaS-стартапов.

Nota bene: в этом посте приведен лишь обобщающий обзор, а как известно, из каждого правила есть исключения. Так, Intuit и Xero — отличные антипримеры компаний, которые с самого начала и до сих пор работают только для малого бизнеса.

Кроме того, как отмечает инвестор Кенни ван Зант (Kenny van Zant) из Asana, существуют проекты, ориентированные на крупный бизнес, которые используют стратегию входящего маркетинга, а значит, приведенные выше данные об эффективности продаж и размере churn не могут быть применены к таким компаниям.

Источник

Enterprise клиенты что это

Несколько лет тому назад на ИТ-рынке вдруг (а может, и не вдруг) поставщики “тяжелого” софта, “ тяжелого” оборудования и “тяжелых” ИТ-услуг вдруг в один голос начали клясться в том, что теперь для них очень важны стали потребители, относящиеся к категории “Средний и малый бизнес” (СМБ) и теперь они на базе своих Enterprise-продуктов (то есть продуктов, ориентированных на крупные корпорации), будут выпускать SMB-продукты – то есть продукты, адресованные среднему и даже малому бизнесу.

Даже была (где-то по Питером) специальная крупномасштабная многовендорная ИТ-конференция, на которой известные отечественные и зарубежные ИТ-компании озвучивали свои планы по захвату СМБ-сегмента российского ИТ-рынка. Но что примечательно: почти никто из спикеров этой конференции не проводил даже приблизительных границ между крупными (Enterprise), средними (Medium), небольшими (Small) и совсем маленькими (SoHo) заказчиками (клиентами). Более того, на все вопросы относительно этой границы отвечали ну очень уклончиво. Диапазон ответов был таков: от “Э то всем известно” до “У каждой компании эта граница своя”.

Довелось мне на той ИТ-конференции поговорить в кулуарах с одним известным аналитиком. Среди прочего, я задал ему такой вопрос: “Где, на ваш взгляд, пролегает граница между крупным и средним бизнесом?”. Он сказал: “Это очень интересный вопрос. В моей записной книжке есть примерно два десятка вариантов ответа на него”. Однако от публикации (и даже озвучивания) этих вариантов отказался. В шутку отметив, что это своего рода ноу-хау.

Процессы смещения “горизонтальных” фокусов ИТ-предприятий продолжаются и поныне. На СМБ-сегмент заглядываются как поставщики Enerprise-решений, так и компании, ранее ориентировавшиеся преимущественно на сегмент SoHo. Поэтому проблема единой “пограничной” терминологии, на мой взгляд, продолжает оставаться актуальной. В этом плане меня очень порадовала состоявшаяся вчера презентация итогов работы компании Lenovo (как в мире, так и в России). На ней среди прочего, были обозначены границы между теми категориями потребителей, которые компания для себя выделяет.

На мой взгляд, очень даже правильная градация. А на ваш?

Источник

Enterprise или SaaS: что выбрать бизнесу

Сперва определимся с терминами:

Software as a Servise: облачная модель размещения ПО. Компания оформляет подписку и подключается через интернет к серверам поставщиков софта. То есть работа осуществляется в облаке и обслуживается провайдером.

В статье будем использовать термины: SaaS и облако.

Enterprise: корпоративное решение, которое разворачивается на собственных серверах компании, покупающей софт у производителя. Работа осуществляется без участия поставщика ПО. Проще говоря, это облако, помещенное в инфраструктуру компании-клиента.

В статье будем использовать термины: Enterprise, In-House, On-premise.

Примеры ПО, у которых есть облачное и Enterprise-решения:

Для того, чтобы понять, какое решение более выгодно для вашего бизнеса, необходимо сравнить SaaS и In-House. Можно провести аналогию с арендой квартиры и покупкой собственного жилья:

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

То же работает в отношении облака и On-Premise: вы пользуетесь «арендованным» софтом, находящемся в ответственности провайдера, или приобретаете сервис, где «хозяин» вы сами.

Как это работает с чат-центром

SaaS: сообщения клиентов сперва попадают на серверы WhatsApp, Telegram, Viber и прочих мессенджеров. После этого они попадают на серверы чат-центра. Далее вы подключаетесь через интернет к серверам чат-центра и видите сообщения ваших клиентов. При этом на пути следования данных есть посредники — интернет провайдеры и DNS-сервера.

Enterprise: сообщения клиентов поступают на серверы мессенджеров, откуда попадают напрямую к вам. В этой цепочке отсутствуют посредники, провайдеры и поставщики.

Нужен ли вам In-House?

Существует мнение, что In-House выбирают только крупные государственные и финансовые организации. На самом деле, такой тип подключения пользуется не меньшей популярностью среди сотовых операторов, транспортных и логистических организаций, страховых компаний. Это частные компании с большим числом клиентов и высокой нагрузкой на операторов.

Каждая компания, которая работает с персональными данными клиентов, несет ответственность за личную информацию и попадает под действие закона №152-ФЗ «О персональных данных». Enterprise-решение в таком случае помогает более четко следовать закону, чем SaaS.

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

Преимущества Enterprise

1. Безопасность информации

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

1.1 Персональные данные

Клиент, общаясь с компанией, зачастую передает свою личную информацию: реквизиты банковских карт, паспортные данные, номер телефона — конфиденциальную информацию, которая не должна попасть в руки третьих лиц. In-House решение позволит хранить всю информацию на своих серверах, что исключает утечку личных данных.

1.2 Данные компании

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

Закон 152-ФЗ «О персональных данных» гласит:

«Операторы и иные лица, получившие доступ к персональным данным, обязаны не раскрывать третьим лицам и не распространять персональные данные без согласия субъекта персональных данных, если иное не предусмотрено федеральным законом»

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

Chat2Desk оснащен системой безопасности, которая предоставляет доступ только тем, кто авторизовался в системе. Вся информация зашифрована, а значит, даже если произойдет взлом или утечка, то расшифровать данные смогут только какие-нибудь спецслужбы. В отличие от SaaS, In-House исключает посредника между клиентом и компанией, поэтому безопасность такого решения выше. Поэтому компании со статусом оператора персональных данных будет проще следовать закону. Но тогда владелец Enterprise берет ответственность на себя и самостоятельно внедряет систему мониторинга защиты данных.

2. Стабильность и скорость

Доступ к облаку обеспечивается интернет-провайдерами. Компании обеспечивают постоянную работу сервиса за счет мощностей своих серверов и поставщиков интернета. Но это не исключает возможных сбоев в работе, на которые вы не сможете повлиять.

При подключении In-House вы самостоятельно находите провайдеров и ответственность за работу интернета переходит под ваш личный контроль. Теперь любые возникшие трудности решаете вы сами.

Но если вы используете In-House-решение Chat2Desk для внутренней работы отделов, то никакие сбои и задержки вам не страшны. Внутри одной локальной сети документы и сообщения передаются без проблем.

Например: ваш офис расположен на Кипре, а облако Chat2Desk развернуто на российских и европейских серверах. В таком случае вы можете столкнуться с низкой скоростью доставки сообщений и сбоями в работе сервиса. Размещение On-Premise решает эту проблему: работа сервиса не будет зависеть от сторонних посредников и вы сможете свободно общаться внутри компании.

3. Кастомизация софта

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

In-House-решение дает возможность самостоятельно кастомизировать и адаптировать софт под ваши нужды. Открытый API позволяет разработчикам вашей компании вносить изменения, проводить дополнительные интеграции со сторонними облачными сервисами, искусственным интеллектом, системами безопасности и собственными чат-ботами, независимо от создателей софта.

Кроме функциональной части вы можете изменить внешний вид интерфейса, например, разместить в углу экрана логотип компании. Настройте виджет на сайте компании: разработайте свой дизайн, а вместо Chat2Desk укажите название компании.

4. Производительность

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

В случае с In-House ситуация меняется: вы сможете самостоятельно регулировать мощность сервера и увеличивать ее в особых случаях. Представьте себе ситуацию: вы запускаете рекламу с выгодным предложением. Вы сможете спрогнозировать наплыв клиентов и вероятную нагрузку на сервера и вовремя принять необходимые меры.

Требования для Enterprise

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

Чтобы развернуть On-Premise на своем сервере, необходимо соблюдение следующих условий:

1. Оборудование:

2. Отдел разработки: чтобы развернуть In-House на серверах, необходимы специалисты с обеих сторон. Однако, если у вас нет своих разработчиков — это не проблема. Chat2Desk готов полностью настроить Enterprise самостоятельно.

3. ПО: не имеет значения, так как универсальные решения Chat2Desk совместимы с любым программным обеспечением.

4. Виртуальные серверы: для расширения вашей инфраструктуры и снижения нагрузки.

Мы предлагаем 3 схемы развертывания In-House:

Минимальная: для 1000-2000 обращений в сутки. Такой тип подходит для первого подключения, чтобы определить нагрузку на сервера.

Средняя: увеличенная производительность и повышенная безопасность.

Максимальная: для хранения больших объемов данных внутри локальных сетей крупных корпораций.

SaaS vs Enterprise

Для подведения итогов рассмотрим и сравним облако и Enterprise-решение.

Почему In-House более выгоден

Итоговая стоимость SaaS-решения складывается из количества операторов, подключенных мессенджеров и дополнительных опций и модулей. Оплата происходит каждый месяц, квартал или год со скидкой. В случае с On-Premise вы покупаете сервис раз и навсегда. Сравним затраты одной кредитной организации на SaaS и аналог Enterprise-решения:

Наглядно видно, что начальный взнос за облако гораздо ниже, чем разовая покупка In-House. Если сравнить затраты в долгосрочном периоде, то SaaS-решение за 5 лет обойдется в 1 800 000 рублей. И, хотя On-Premise-решение изначально требует большого вложения денег, спустя годы такое приобретение окупится. На графике ниже мы наглядно показали, как будут выглядеть суммарные затраты на облако и In-House.

Заключение

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

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

Источник