Как я создал Еадеск — сервис для первой линии поддержки. Часть 1

В прошлом я руководил виртуальной АТС onlinePBX, где выстроил лучшую техподдержку в нише, по крайней мере, так говорят партнёры, клиенты и конкуренты. Но до идеала не хватало хорошего инструмента — хелпдеска. На рынке не оказалось подходящего и я решил сделать свой, так появился Еадеск.

Статья разбита на две части, в первой зачем миру нужен ещё один сервис и почему мы сделали его таким. Если философские вопросы вас не интересует — во второй части расскажу о практической стороне: о ресурсах, команде, технологиях, запуске и первых клиентах.

Виртуальная АТС — довольно массовый продукт по меркам b2b. Сейчас onlinePBX обслуживает 20 тысяч абонентов, которые генерируют непрекращающийся поток заявок — звонят и пишут каждый день.

Когда мы были маленькими, всё было проще: почта и телефон покрывали 100% нужд, мы знали клиентов наизусть и почти не теряли обращения. Проблемы появились потом.

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

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

Для третьей линии куча софта, мы использовали в разное время: Redmine, Taiga, Trello, Asana, пробовали Jira. Второй линии всё ещё подходят классические тикет-системы, мы использовали Zendesk и Omnidesk. Но для первой линии они не подходят — ниже разбираю почему.

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

Сложный интерфейс

Посмотрите на современные CRM-системы и хелпдески — между ними пропасть. Разработчики CRM думают об удобстве пользователей: прячут лишние элементы, объединяют похожие, сохраняют изменения на лету, экономят клики. Хелпдески же сразу вываливают на вас свои фильтры, поля, макросы, подсказки и прочее.

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

Медленно

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

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

Мало информации о клиентах

Часто в хелпдесках нет полноценного модуля управления клиентами — нельзя сегментировать базу, искать дубли, объединять контакты. А история взаимодействий ограничивается списком тикетов и их статусами.

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

Неактуальные каналы

Техподдержка хочет работать с традиционными каналами — почта, форма заявки, портал самообслуживания, и поэтому для хелпдесков они основные. Клиенты же хотят пользоваться привычными каналами: чатом или мессенджером, иногда позвонить.

Хотим мы или нет, но работа с клиентом уходит в более доступные каналы. Клиенты не хотят регистрироваться на порталах, проверять почту, составлять заявку и заполнять поля. Они хотят написать о проблеме и получить решение, и я их понимаю.

Всё крутится вокруг тикетов

Проблемы выше вытекают из одной — всё крутится вокруг тикетов, а не людей и взаимодействия между ними. Системы заточены на решение конкретного вопроса и соблюдение SLA, а не выстраивание долгосрочных отношений. И это в 2019 году, когда по подписке доставляют пробники вин, когда правят юнит-экономика и длинный LTV.

Но иногда тикеты всё же нужны:

В остальных случаях тикеты на первой линии должны умереть.

Наблюдая эти проблемы с 2014 года, я так и не увидел, чтобы кто-то из хелпдесков их решал. Поэтому, когда ушёл из предыдущего бизнеса и продал долю партнёру, решил заняться этим вопросом сам.

При разработке продуктов для меня важны вопросы идеологии: что мы делаем, для кого, для чего, а что не делаем? Поэтому в Еадеск заложил философию ещё до начала разработки. Она состоит из четырёх ключевых моментов: омниканальность, скорость, контроль и фокус.

Настоящая омниканальность

Иногда понятия многоканальность и омниканальность путают. Многоканальность — обслуживание через разные каналы: чат, сообщество ВК, телефон, почта. Омниканальность про обслуживание без привязки к каналу, когда клиент оставляет заявку на сайте, согласовывает по телефону, получает напоминание в СМС, а оценивает в мобильном приложении.

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

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

Скорость

Скорость — это новая лояльность, я писал об этом несколько заметок в своём Телеграм-канале. Клиенты покупают и возвращаются к тем, кто быстро обслуживает. Поэтому Еадеск мы делаем для первой линии поддержки и аккаунтинга, и в этом наше ключевое отличие от конкурентов.

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

Также принцип скорости лёг в основу разработки продукта — мы делаем 2−3 релиза в месяц с новыми возможностями. В планах сделать всё возможное, чтобы автоматизировать работу сотрудника и сократить время на обслуживание.

Контроль

Специалисты по сервису знают: чтобы качественно работать с клиентами, нужно всё контролировать. Клиентскую базу, чтобы удерживать и управлять нагрузкой; сотрудников, чтобы вовремя отвечали и соблюдали стандарты; обращения, чтобы ничего не потерялось.

Чтобы проще было контролировать, главная единица смысла у нас — коммуникация с клиентом, попробую объяснить. Если работать с тикетами, их можно удалить или забыть внести в систему и вы потеряете клиента. С коммуникациями проще: клиент либо обращался к вам, либо нет, и поэтому мы не даём удалять коммуникации.

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

Фокус

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

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

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

Эта статья — «лирика», которая объясняет что и почему мы делали дальше. Вторая будет «физикой», она полностью посвящена реализации. Расскажу, как делали кастдев и анализ конкурентов, где искали сотрудников и из кого состоит команда, на каком стеке работаем и что с архитектурой, как выпускали MVP и где искали первых клиентов, в какой стадии проект сейчас и наши планы.

Вторая часть статьи ещё в процессе, поэтому если хотите, чтобы я раскрыл в ней какую-то тему — напишите в комментариях.