Как я создал Еадеск — сервис для первой линии поддержки. Часть 1
В прошлом я руководил виртуальной АТС onlinePBX, где выстроил лучшую техподдержку в нише, по крайней мере, так говорят партнёры, клиенты и конкуренты. Но до идеала не хватало хорошего инструмента — хелпдеска. На рынке не оказалось подходящего и я решил сделать свой, так появился Еадеск.
Статья разбита на две части, в первой зачем миру нужен ещё один сервис и почему мы сделали его таким. Если философские вопросы вас не интересует — во второй части расскажу о практической стороне: о ресурсах, команде, технологиях, запуске и первых клиентах.
История нашей техподдержки
Виртуальная АТС — довольно массовый продукт по меркам b2b. Сейчас onlinePBX обслуживает 20 тысяч абонентов, которые генерируют непрекращающийся поток заявок — звонят и пишут каждый день.
Когда мы были маленькими, всё было проще: почта и телефон покрывали 100% нужд, мы знали клиентов наизусть и почти не теряли обращения. Проблемы появились потом.
Во-первых, самих клиентов и обращений стало сильно больше. Во-вторых, разрасталась команда поддержки и стало сложно распределять задачи и звонки. И третье, росло количество каналов — клиенты стали писать в соцсети и хотели чат на сайт, чтобы быстро получать консультации.
Сейчас техподдержка разделена на три линии: первая принимает все обращения, консультирует, делает базовые настройки, аккаунтит клиентов. Вторая решает более сложные вопросы со связью и интеграциями; третья помогает с API, исправляет баги и разрабатывает продукт, почти не общается с клиентами.
Для третьей линии куча софта, мы использовали в разное время: Redmine, Taiga, Trello, Asana, пробовали Jira. Второй линии всё ещё подходят классические тикет-системы, мы использовали Zendesk и Omnidesk. Но для первой линии они не подходят — ниже разбираю почему.
Тикеты должны умереть
За три года мы перепробовали около десятка классических тикет-систем, похожих друг на друга как две капли воды. А одинаковые решения имеют одинаковые проблемы. Попробуйте на скриншотах ниже найти хотя бы два принципиальных отличия.
Сложный интерфейс
Посмотрите на современные CRM-системы и хелпдески — между ними пропасть. Разработчики CRM думают об удобстве пользователей: прячут лишние элементы, объединяют похожие, сохраняют изменения на лету, экономят клики. Хелпдески же сразу вываливают на вас свои фильтры, поля, макросы, подсказки и прочее.
Для второй линии это оправдано — в среднем там выше квалификация сотрудников. Но не для первой: здесь высокая текучка и приходится постоянно обучать новичков, при этом их квалификация ниже и чем проще будет инструмент, тем проще научить.
Медленно
Состоявшиеся на рынке решения разрабатывались несколько лет назад и технологически там и остались. Поэтому многим не хватает рилтайма — когда данные обновляются и подгружаются динамически, без обновления страницы. Часть вендоров это понимают и пытаются исправиться.
Опять же, для второй линии обновить страницу лишний раз — не проблема. Но на первой линии, где важна скорость реакции и время решения проблемы в первом контакте, инструмент должен помогать, а не тормозить.
Мало информации о клиентах
Часто в хелпдесках нет полноценного модуля управления клиентами — нельзя сегментировать базу, искать дубли, объединять контакты. А история взаимодействий ограничивается списком тикетов и их статусами.
Возможно, для второй линии не так важно — есть ли у клиента другие обращения, когда он последний раз выходил на связь и через какой канал. В конце концов, у него есть время найти всё необходимое. У фронтлайна же вся информация должна быть под рукой, ведь клиент прямо сейчас висит на линии или ждёт ответа в чате.
Неактуальные каналы
Техподдержка хочет работать с традиционными каналами — почта, форма заявки, портал самообслуживания, и поэтому для хелпдесков они основные. Клиенты же хотят пользоваться привычными каналами: чатом или мессенджером, иногда позвонить.
Хотим мы или нет, но работа с клиентом уходит в более доступные каналы. Клиенты не хотят регистрироваться на порталах, проверять почту, составлять заявку и заполнять поля. Они хотят написать о проблеме и получить решение, и я их понимаю.
Всё крутится вокруг тикетов
Проблемы выше вытекают из одной — всё крутится вокруг тикетов, а не людей и взаимодействия между ними. Системы заточены на решение конкретного вопроса и соблюдение SLA, а не выстраивание долгосрочных отношений. И это в 2019 году, когда по подписке доставляют пробники вин, когда правят юнит-экономика и длинный LTV.
Но иногда тикеты всё же нужны:
- На второй линии и дальше тикеты вполне работают. Поэтому при эскалации вопросов, первая линия может их создавать и передавать дальше.
- Когда вы работаете строго по ITIL и ITSM, ну тут без вариантов.
- Когда вопрос долго решается или имеет длинный цикл согласований и передачи между этапами.
В остальных случаях тикеты на первой линии должны умереть.
Наблюдая эти проблемы с 2014 года, я так и не увидел, чтобы кто-то из хелпдесков их решал. Поэтому, когда ушёл из предыдущего бизнеса и продал долю партнёру, решил заняться этим вопросом сам.
Идеология Еадеска
При разработке продуктов для меня важны вопросы идеологии: что мы делаем, для кого, для чего, а что не делаем? Поэтому в Еадеск заложил философию ещё до начала разработки. Она состоит из четырёх ключевых моментов: омниканальность, скорость, контроль и фокус.
Настоящая омниканальность
Иногда понятия многоканальность и омниканальность путают. Многоканальность — обслуживание через разные каналы: чат, сообщество ВК, телефон, почта. Омниканальность про обслуживание без привязки к каналу, когда клиент оставляет заявку на сайте, согласовывает по телефону, получает напоминание в СМС, а оценивает в мобильном приложении.
Мы уже поддерживаем множество каналов, и в первую очередь текстовые: почта, чаты, мессенджеры, соцсети, — и учитываем их специфику. Например, если Вотсап не поддерживает форматирование — спрячем лишние кнопки. Другой пример, если во ВКонтакте пишут не только в личку, но и на стене — добавим поддержку стены.
Многоканальность поддерживают практически все, поэтому мы делаем ставку на омниканальность. Например, когда посетитель сайта укажет емейл в чате, мы «склеим» его переписку из обоих каналов. А с помощью интеграций дополним профиль пользователя любой информацией.
Скорость
Скорость — это новая лояльность, я писал об этом несколько заметок в своём Телеграм-канале. Клиенты покупают и возвращаются к тем, кто быстро обслуживает. Поэтому Еадеск мы делаем для первой линии поддержки и аккаунтинга, и в этом наше ключевое отличие от конкурентов.
Для увеличения скорости работы сделали максимально простой интерфейс, похожий на привычные мессенджеры. Он работает в реальном времени — данные подгружаются моментально, не нужно обновлять страницу и ждать загрузки. Постепенно добавляем фишки: шаблоны быстрых ответов, горячие клавиши, автосохранение ответа и так далее.
Также принцип скорости лёг в основу разработки продукта — мы делаем 2−3 релиза в месяц с новыми возможностями. В планах сделать всё возможное, чтобы автоматизировать работу сотрудника и сократить время на обслуживание.
Контроль
Специалисты по сервису знают: чтобы качественно работать с клиентами, нужно всё контролировать. Клиентскую базу, чтобы удерживать и управлять нагрузкой; сотрудников, чтобы вовремя отвечали и соблюдали стандарты; обращения, чтобы ничего не потерялось.
Чтобы проще было контролировать, главная единица смысла у нас — коммуникация с клиентом, попробую объяснить. Если работать с тикетами, их можно удалить или забыть внести в систему и вы потеряете клиента. С коммуникациями проще: клиент либо обращался к вам, либо нет, и поэтому мы не даём удалять коммуникации.
В сервисе есть несколько инструментов контроля: полноценная история взаимодействия с клиентом, история действий сотрудников и дашборд с показателями обслуживания клиентов.
Фокус
В разработке продукта важно быть гибким, но клиенты не всегда знают, чего хотят на самом деле. И чтобы из продукта не получился уродливый Франкенштейн, с самого начала у нас есть фокус и мы его придерживаемся. Фокус, это про то, что вы делаете и что не делаете.
Звучит это примерно так: мы помогаем небольшим компаниям с сотрудниками аккаунтинга и поддержки перестать терять обращения и быстро отвечать с помощью нашего сервиса, когда к ним обращаются клиенты через соцсети, мессенджеры и традиционные каналы, чтобы обслуживать и удерживать больше клиентов.
Также мы понимаем, чего не делаем и делать не будем. Эти вещи мы выносим в интеграции со сторонними сервисами. Например, нас уже несколько раз просили сделать воронку продаж, но вместо этого мы сделаем интеграции с уже популярными решениями на рынке, продажи — не наш фокус.
Продолжение следует…
Эта статья — «лирика», которая объясняет что и почему мы делали дальше. Вторая будет «физикой», она полностью посвящена реализации. Расскажу, как делали кастдев и анализ конкурентов, где искали сотрудников и из кого состоит команда, на каком стеке работаем и что с архитектурой, как выпускали MVP и где искали первых клиентов, в какой стадии проект сейчас и наши планы.
Вторая часть статьи ещё в процессе, поэтому если хотите, чтобы я раскрыл в ней какую-то тему — напишите в комментариях.
Раньше у onlinepbx была и правда крутая Поддержка. Сейчас (по моему мнению) самая топовая Поддержка по параметру скорость/полезность у Sipuni
Хорошо, что статья не об этом :-)
Я уже почти два года, как не работаю в onlinePBX
Очень крутой продукт. Тестировала, понравилось! Удачи в развитии!
Спасибо за поддержку, Юлия! Будем рады видеть среди наших клиентов )
Не могу получить тест. На почту ничего не приходит.
Здравствуйте! В поддержку писали? Спам и промо-акции проверили?
Комментарий недоступен
Посмотри на чем работают операторы ж/д вокзалов, дизайн как будто в биосе.
Когда ты работаешь на результат, тебе не интересует внешний вид, важна функциональность, неделю посмотришь на красивый дизайн и все. На дизайн смотрят ребята, которым важен фантик (facepalm smile).
Комментарий недоступен
Спасибо за вброс, ждал чего-то подобного. Но без конкретики мне вам ответить нечего, сделаете бизнес-линч — тогда поговорим.
Что касается продаж: мы же не дизайнеры и не веб-студия, мы продаём ценность и пользу нашего решения, а не UI. Мы помогаем собрать всю коммуникацию в одном месте, распределенить обращения между сотрудниками и проконтролировать их работу.
Комментарий недоступен
А теперь совсем не понял: речь про UI продукта или дизайн лендинга?
Комментарий недоступен
Мне не нравится экстерьер Лады Приоры, они не могли "чекнуть" других дизайнеров молодых или у Опеля и Митсубиси спереть дизайн?
Рекомендую лично поюзать сервис недели 2, затем еще 2-3 аналогичных сервиса и каждый по 2 недели, потом высказать свое мнение о визуальности всего проекта.
Из чего складывается ценообразование тарифных планов? Не дорого?
Пока очень дёшево, как мне кажется. К середине года запустим тариф пожирнее и к концу года планируем поднять цены для новых клиентов
Мне кажется стоит рассмотреть вариант приобретения лицензий.
SaaS - это хорошо, но абонентская плата лично у меня убивает желание работать с данным продуктом. Удачи в развитии :)
Посчитайте в деньгах во сколько обходится поддержка любого коробочного продукта, резервное копирование, проблемы с обновлением. потраченное время и уходите в облака :)
Спасибо! )
Это вопрос фокуса, сейчас мы делаем только SaaS.
Комментарий недоступен
В принципе, можно взять любой стек, программистов и с нуля написать что угодно и интегрировать с чем угодно. А можно взять Еадеск для первой линии и через 10 минут пересадить всю команду, и тоже не заморачиваться.
У нас разные клиенты, есть например, продавец трансформаторов. У него один клиент от 10к до миллиона может принести, а нам он платит 6 тысяч за полгода. Зачем ему гибкость OTRS — непонятно: внедрение шло полчаса, обучение сотрудников ещё 15 минут. Как вы понимаете, он не заморачивался от слова совсем...
А когда вторая статья?
В процессе, всё не успеваю доделать, оформить и выложить... Думаю, недели через две будет.
Никита, привет! Хочется уже вторую часть почитать :–)
Спасибо, что напоминаете )
Я написал половину и забросил — не успеваю, но эта неделя посвободнее, постараюсь ещё немного написать или дописать.
Буду ждать! Спасибо.
(не туда)