Наши процессы. Опыт формирования support-команды и немного про SMM



    В продолжение темы «Наш процесс разработки: 50 месяцев эволюции» разрешите вам рассказать историю формирования нашей support-команды.

    Экспозиция и дисклеймер


    Здравствуйте, меня зовут Антон (человек-чашка на первом снэпшоте), последние два года я занимался формированием команды и становлению процессов в отделе заботы о клиентах (Customer Care Team). Во-первых, я буду рассказывать историю от первого лица, потому что очень не люблю безликие статьи о том, как «наша компания привила у себя корпоративные ценности и сформировала набор правил, которые помогли увеличить эффективность взаимоотношения с клиентами, что позволило компании достичь новых высот». Во-вторых, статья пишется в блог компании Taucraft, что позволяет мне не абстрагироваться от нашего флагманского продукта TargetProcess, а также нашего open-source инструмента – HelpDesk Portal (мне, помимо прочего, лень замазывать лэйблы).

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

    Немного истории




    Основатели TargetProcess какие-то странные: они не ходили по «Стартап-Уикендам», не обивали порогов венчурных фондов, не брали менторов, которые, конечно же, помогут открыть двери в мир глобального бизнеса и познакомят с какими-то «нужными людьми». Они просто взяли и за шесть месяцев выпустили продукт, который быстро получил Proof of Concept, и тут же посыпались первые фидбэки. Стартапу команда технической поддержки не нужна, первых клиентов фаундеры носят на руках и выполняют все их прихоти и пожелания. Когда пожелание клиента может быть реализовано за 2-4 дня, то это действительно производит впечатление, и, как говорится, такие клиенты могут стать клиентами на всю жизнь. Сложности начинаются, когда у компании больше ста клиентов и все пожелания выполнить просто невозможно (желаю всем стартапам в СНГ таких проблем). На этом уровне без команды тех. поддержки уже не обойтись.

    Люди




    Немногие понимают, как важно делать суппорт персональным и открытым. Стоит отметить, что события происходят в Минске, но 70% клиентов находятся в США и Канаде. По данным агентства Gartner Беларусь в категории «уровень владения английским языком» всегда получает стабильную оценку «неудовлетворительно» (но считается, что здесь хорошая система образования, которая делает высококвалифицированных работников, работающих за недорого).

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

    С точки зрения классического менеджмента команду технической поддержки разделяют на три уровня:
    1 уровень – может найти ответ на часто задаваемый вопрос.
    2 уровень – может ответить на вопрос повышенной сложности.
    3 уровень – может решить любую сложную проблему, чаще всего для этого нужна помощь программиста и изменение кода.

    Большинство наших клиентов – профессиональные программисты, и у нас нет необходимости отвечать на большой поток запросов (благо, все умеют пользоваться «Гуглом»). Другими словами, в команду нам нужны сильные люди для решения проблем на втором и третьем уровне, но которым лишь иногда нужно отвечать и на вопросы первого уровня.

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

    Стандартные размещения вакансий на сайтах о поиске работы не помогли (я размещал в отделе support и QA). Очень помогли нестандартные решения, инфографика и довольно оригинальная вакансия в ЖеЖе (у меня иногда складывается впечатление, что, кроме Студии Артемия Лебедева и Алёны Владимирской, вакансии вообще никто описывать не умеет).

    Мы предлагаем зарплаты на 20-30% больше чем средния зарплата опытного QA-инженера по Минску. Проведя примерно 20 собеседований, я сделал только 2 предложения (я хотел, чтобы у коллег английский был лучше, чем у меня, но больше всего меня расстраивало то, что опытные QA читают мало книг и даже не знают, как пользоваться RSS). В основном, люди отказывались, потому как не хотели уходить из QA или автоматизации.

    Работая по 12 часов больше трёх месяцев, я уже начал паниковать и потратил два дня на выходных, чтобы послать персональное приглашение каждому человеку в Минске, у кого в профиле «Моего Круга» был указан QA.

    Удача нам улыбнулась, и к нам пришёл Сергей (забавную вакансию в ЖеЖе ему показала жена, но он решил отреагировать только после личного приглашения). Он работал в крупной корпорации лидером команды (обучал бывших учителей компьютерным премудростям) и принёс в компанию много хороших системных практик.

    Потом пришла Катя, она три года работала в тех. поддержке, а опыт в туристической индустрии помог ей приобрести колоссальную стрессоустойчивость. У неё шикарный английский и всегда хорошее настроение (люди-катализаторы необходимы каждой команде). Алексей работал начальником IT-отдела в Национальном академическом Большом театре оперы и балета, но больше известен как создатель популярного в Беларуси портала www.otryv.by (игра-путеводитель по городам Беларуси и ближнего зарубежья). Не так давно к команде присоединились еще двое клевых ребят. Вячеслав раньше занимался системами безопасности, и его опыт сразу оказался полезным дополнением в копилку команды. Аня последние пару лет занималась поддержкой сложной системы с большими нагрузками. Ее опыт работы с клиентами из СНГ крайне ценен, т.к. требует некоторых… дополнительных навыков.

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


    Сергей крупным планом, новый лидер отдела заботы о клиентах. Как и я, чувствует себя комфортно только с тремя мониторами (на одном у меня TweetDeck, на втором Facebook, на третьем для приличия что-нибудь по работе).

    Инструменты:


    Emails

    Основным инструментом работы с клиентами по-прежнему является общение через письма. Когда нам приходит письмо на support, мы создаём реквест (запрос) в нашей системе, и клиент получает письмо о том, что «бла-блабла, вы для нас очень важны, номер реквеста такой-то».


    Также мы сортируем запросы, основываясь на ключевых словах в заголовке.



    Все запросы попадают в так называемый Requests List, но для обработки запросов пользоваться им реально неудобно.



    Поэтому мы создали специальную очередь для обработки реквестов (удобно работать, когда создаёшь инструменты для себя). Практика показала, что сортировать по LIFO удобней. Логика там такая: реквест добавляется в очередь (хотя на самом деле это стек), а после того, как мы отвечаем на него, реквест из очереди исчезает. Если клиент не отвечает в течение двух дней, реквест опять попадает в очередь, и мы дублируем последнее сообщение или интересуемся, всё ли у него хорошо. Если после второго напоминания клиент не отвечает — мы просто закрываем запрос. Когда очередь пуста, мы играем в настольный футбол, сидим по фэйсбучикам или играем в MortalCombat на Xbox (а когда надоедает заниматься ерундой – мы начинаем писать документацию).

    Обычно реквесты выглядят примерно так.


    Иногда мы конвертируем реквест в идею, не забывая поблагодарить за фидбэк (идеями у нас занимается Product Owner). Или создаём из запроса bug, или там, аттачим к существующей user story.



    По нашим процессам, кроме Product Owner-а, только команда техподдержки имеет права добавлять что-нибудь в процесс разработки. Когда карточки имеют разные цвета, в терминологии Kanban это называется Classes of Services. То бишь, взглянув на нашу доску, можно увидеть, что, если на карточке есть тэг sup, то это задача по суппорту и она имеет свой цвет (не знаю, как он называется, скажем так, карточка с цветом #ffecb3). Пока что у нас только один выделенный программист на суппорте (но мы ищем еще одного). Когда завал — устраивается так называемый субботник, и такими задачами занимается вся команда (случается редко).

    Live Chat + gotomeeting
    Один из самых эффективных путей взаимодействия с клиентом — общение в онлайн-чате. Мы используем providersupport, которым мы, если честно, не очень довольны (клиенты жалуются, что глючит). Если становится ясно, что с помощью онлайн-чата решить проблему сложно, то мы запускаем gotomeeting, который позволяет увидеть проблему заказчика собственными глазами, попросить у него доступ к его компьютеру и быстро всё ему “починить” или объяснить.



    Как на сайте, так и на SaaS версии продукта есть иконка, которая позволят быстро с нами связаться.



    В providesupport мне очень нравится вкладка geo-location, которая позволяет узнать, откуда звонит клиент.


    Post Chat Survey
    Comments: Anna helped me quick, however I am not always a «good'n'smart» user. Thank you, and Anna. Regards, Tamas SZulman
    Politeness: 5
    Proficiency: 5

    Post Chat Survey
    Comments: I am just a new user, and Sergey helped fast, effective, polite. Respect, and thanks for having such a great team!
    Politeness: 5
    Proficiency: 5

    Post Chat Survey
    Comments: One of the best supports I have ever encountered. Twice already I was helped also regarding technical issues.
    Politeness: 5
    Proficiency: 5


    Так же классно получить моментальный feedback от клиента сразу после завершения общения.

    Post Chat Survey
    Comments: Very slow and questions not answered fully.
    Politeness: 3
    Proficiency: 2


    Примерно 90% процентов наших клиентов оценивают нашу работу как хорошо и отлично (что является очень хорошим показателем по индустрии). Но при боевом крещении возможны разные ситуации. Мы стараемся дать максимальные полномочия сотрудникам для каждого члена команды и не создавать узких специализаций.

    Культурные различия


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

    Понятно, что люди некультурные встречаются везде, но жаль, что среди наших IT-шников процент таких людей больше. Мы пытаемся испытывать эмоциональное вовлечение и всегда сохранять хорошее настроение, но, после того, как тебе нахамили, бывает трудно восстановиться. Если бы мне нужно было организовывать отдел технической поддержки, ориентированный только на СНГ, то я бы, наверное, пошёл другим путём и составил список стандартных фраз и моделей шаблонного поведения при общении с клиентом. У нас же каждый может отвечать так, как он считает нужным. Может, это не совсем верно с точки зрения бизнеса, но человек из техподдержки имеет право порекомендовать сложному клиенту другую систему по управлению проектами (другими словами, уволить клиента).

    Еще наши молодые хакеры с постсоветского пространства считают, что если ты нашёл небольшую уязвимость в продукте, то об этом нужно написать сначала в twitter, потом на facebook, а потом уже сообщить в команду технической поддержки. Думаю, это оттого, что наша отрасль еще молодая и общие правила этикета еще не сформировались.

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

    Кому писать документацию?




    Писать документацию никто не любит. Лично я настаивал на найме специально обученного человека, но CEO раньше всегда сам писал документацию, и теперь он решил, что этим будет заниматься команда технической поддержки. В возмущении я даже отписал в команду 37Signals, но они ответили, что у них документацию тоже пишет техподдержка.

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

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

    SMM (Social media marketing)


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



    В «Фэйсбуке» у нас 2400 лайков, а во время проведения PR-акций там активно задавали технические вопросы, на которые нужно было отвечать и отслеживать. Благо, сейчас туда пишут гораздо меньше.

    LinkedIn


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

    twitter




    Единственное, что мы постоянно мониторим, — это твиттер. Думали создать специальный аккаунт для суппорта, но, поскольку обычно отвечаем персонально, то используем основной аккаунт.



    Вот вроде и всё. Всем удачи, побольше хороших клиентов и позитивного настроения!

    P.S. и еще одна последняя вещь


    Как любят говорить в телемагазинах, зарегистрироваться лучше прямо сейчас (займёт 30 секунд). Да, это грязный приём, но мы с августа действительно не будем больше предоставлять бесплатную On-Site-версию до 5 человек (которую вы можете хостить у себя, Help Desk предоставляется тоже бесплатно). Вместо этого будет облегченная версия SaaS (хостится на наших серверах), но там, к сожалению, не будет поддержки Help Desk (только в платных версиях). Так что у вас есть возможность использовать качественный и бесплатный (редкое сочетание) инструмент для организации своей небольшой команды технической поддержки. Все имеющиеся бесплатные версии мы будем поддерживать, пока мы живы.

    Taucraft Limited

    43,38

    Компания

    Поделиться публикацией

    Похожие публикации

    Комментарии 18
      0
      Мне кажется, вы изобретаете велосипед :)

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

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

      А что для gotomeeting используете? Нативное решение от cisco, или нашли что-то более удобное?
        +1
        Я как раз недавно триалил Kayako — не понравилось, что клиент не может переслать файл через чат ( для тех. саппорта нам это важно), а при отправке логов в виде текстового сообщения теряет line breaks.
        Буду признателен, если кто посоветут чат, в котором это можно делать нормально.
        К тому же мы eat our own dogfood — используем то, что сами производим ( для саппорта у нас есть отдельная часть приложения, не самая мощная на мой взгляд). Это помогает нам сделать продукт лучше.

        Что до левелов — мы как раз тоже не разбиваем. Т.е. стараемся использовать savvy support, но некоторые проблемы требуют привлечения девелоперов ( например, неизведанный ранее баг).

        Используем тул который так и называется «GoToMeeting». Есть вопросы по скорости, думаем перейти на TeamViewer.
          0
          Основная идея как раз в том, что общение через чат лучше минимизировать по многим причинам:

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

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

          Лайв-чат имеет смысл, но он имеет смысл для первого уровня поддержки и сейлсов.
            +1
            Мне кажется, что общаться через емэйл – комфортней вашей команде. Для клиента гораздо удобней общаться через лайф чат или голосом через gotomeeting. Людям не нужен структурированный ответ, им нужно, что бы им как можно быстрее решили их проблему.
            Какая у вас кстати средняя скорость реакции на емэйл?
            Ну и ждём статьи конечно :) На хабре про тех. поддержку очень мало историй.
              +1
              Я просто слабо представляю, с чем обращаются к вам клиенты. Насколько я понимаю, есть две категории обращений, первая: обращения уровня «у меня не работает такая-то фича, надо доработать» — тогда и команде и клиенту удобнее по емейл. Вторая — вопрос по функционалу, уровня «как сделать то-то» — то да, через лайв-чат или голосом.

              Средняя скорость ответа на емейл очень относительна <шутка про температуру в больнице>. Есть экстренные запросы, когда ничего не работает, на такие письма реакция через несколько минут, но чаще всего, в таких случаях звонят по телефону.
              Если запрос не срочный, то в течении часа отвечаем клиенту, что мы им занимаемся и нам требуется примерно столько-то времени.
                +1
                Бывают ситуации, типа «я тут самостоятельно продакшн переносил на другой сервер, все поломалось, 100 девелоперов не могут работать». Тогда для решения важна скорость, а для этого лучше чат + screen-sharing

                Да и по опыту, у лучшие ощущения у клиентов остаются именно после «живого» общения
                  +1
                  О, тогда конечно.
                  Хм, я всегда думал, что вы как saas продаете.
                    +1
                    у нас две модели — Saas ( On-Demand ) и локальная установка ( On-Site ).
            +1
            По доработке продукта вообще много вариантов, например, можно создать отдельную категорию для всяких юзкейсов, в которую будут попадать заявки после обработки сапортом, это упростит работу PO.
              +1
              Согласен, про доработку продукта — вообще отдельная тема. Сами много чего используем и влияем на продукт путем решения клиентских проблем. Но к клиентским «хотелкам» относимся как к «идеям» — т.е. благодарим, но ничего не обещаем.
                0
                Какой примерно у вас процент от таких обращений уходит в юзкейсы и передается разработке?
                  0
                  довольно небольшой. Т.е. большинство из них хорошие идеи, которые неплохо бы реализовать, но реализовать и закинуть в бэклог — это не совем одно и то же.

                  Был у нас период, когда делали в основном то, что просили кастомеры, но поняли, что лучший тул так не сделать. У нас своих идей больше, чес успеваем сделать.
          +1
          Вот есть у вашей компании небелорусская черта. Вы умеете рассказывать о себе интересно и понятно. :) Молодцы!
            +1
            Спасибо вам за инструмент. Уже все перетащили к вам, правда так и не решили проблему с клиентами — на каждого покупать аккаунт не круто, графики они смотреть хотят, а у нас заказная разработка по agile — то есть много новых клиентов в месяц, и они должны наблюдать за процессом.

            Много раз просил о бесплатном реад-онли доступу для клиентов — как появиться, будет очень круто. Ну а пока, будем думать, как через API вытягивать данные =)
              0
              Иво, спасибо вам за отзыв, нас очень многие просят создать бесплатный read-only access для случаев как ваш. Вы же знаете, кстати, про кривенький workarround. Создать одного юзера с read-only, но дать его login/password всем вашим клиентам :)
                0
                Так проблема в том, что клиенты не должны видеть другие проекты, кроме как свой =((
                0
                В ТП3 будет такая фича — рид онли доступ в строго ограниченную область. Для такого доступа не нужна будет лицензия. Но. Кастомизировать вид этого доступа можно будет только машапами. По дефолту там будет почти то же самое, что есть сейчас в хелп деске. Но будет несложно сделать машап с бурндауном, к примеру. Ограничение доступа будет сделано через привязку компании к проекту (как и сейчас в хелп деске). Но это будет не раньше ноября.
                0

                "Практика показала, что, так как люди из техподдержки больше всего общаются с клиентами, и писать документацию у нас это и получается лучше всего."
                Как-то не совсем по-русски. Я даже до конца не понял что имеется ввиду.
                ПС: Прошу прощения за некропостинг.

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

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