Люди обмениваются острыми словами,
- сказал Локи, - но эти слова ничего не весят.
У человека во рту их много.
«Empire V», В. Пелевин.
П ервая линия обороны на полях бизнес-сражений - служба техподдержки . Саппорт первым встречает адвертов, первым принимает на себя поток негодования при возникновении сбоев, отсеивает левых для бизнеса людей и, решая 90% проблем партнёров и клиентов, доводит до руководства лишь концентрат самого важного, требующего его непосредственного участия.
К то работает в службах поддержки? Каким должен быть саппорт? Как быть хорошим «саппортером»? Об этом вы узнаете в этой статье.
П ервая половина статьи предназначена для тех, кто хочет организовать службу поддержки для своего интернет-бизнеса. Вторая - для тех, кто желает найти работу в саппорте.
Э та статья не создаст за вас вашу службу технической поддержки. И не обеспечит работой в саппорте. Но информации к размышлению в ней более, чем достаточно.
П оэтому устраивайтесь поудобнее и приступим.
Н е важно, каким проектом вы руководите, будь то , дизайн-студия или - ваши пользователи (адверты, клиенты) чаще всего будут общаться со службой поддержки и, скорее всего, только с ней. Именно от саппорта зависит, какое первое впечатление произведёт ваш проект и как к нему будут относиться в дальнейшем. Поэтому данное звено вашего бизнеса должно быть не слабее, чем все остальные.
М ногие руководители проектов не утруждают себя созданием службы поддержки и не желают нанимать отдельного человека на эту работу. Возможно, они правы. Если проект не подразумевает большого количества участников и хорошо автоматизирован, то, вероятно, отдельная служба поддержки ему ни к чему.
Н о такое бывает крайне редко и, чаще всего, владельцу приходится самому выполнять функции саппорта. Достаточно ли у вас времени и терпения, чтобы выполнять эту работу? Окупится ли такой подход в перспективе?
В ероятнее всего, внимательное отношение к партнёрам, оперативность решения их проблем, грамотное общение с опытными адвертами, советы начинающим и экономия времени руководителя проекта с лихвой окупят скромную ставку саппортера. Не стоит недооценивать лицо вашего проекта, даже если это всего лишь слова в окошке ICQ-клиента.
Т еперь о том, какие качества нужны для того, чтобы получить работу сотрудника службы технической поддержки пользователей.
С табильная зарплата, работа в сильной команде с известными людьми - вот бонусы работы в службе поддержки. Правда, от вас тоже потребуется немало: внимательность, педантичность, хорошее знание профессиональной области, терпение и многое другое. Основные моменты я привожу ниже:
В опреки мнению многих, работа в службе поддержки - это не пустая болтовня в ICQ для тех, кто больше ничего не умеет. От качества работы этой службы зависит мнение компьюнити о проекте, что, в конечном итоге, влияет на то, останутся ли и будут ли продолжать работать с ним адверты. От техподдержки также сильно зависит количество клиентов и многое другое. Хорошая служба поддержки клиентов не решит всех проблем, которые возникают на тернистом бизнес-пути. Но способна сократить их количество во много раз!
К ачественная служба технической поддержки - это специалисты высокого класса, к которым предъявляют серьёзные требования. Их работа ответственна и совсем не проста. Спрос на эту специальность не падает, а зарплаты только растут. Становитесь хорошими профессионалами в своей области, и вас будут рады видеть в своих рядах многие известные команды.
Авг 14, 2014 oleg Организация качественной техподдержки. Теория и практика.
Будем честны — вряд-ли вы ждёте момент звонка в техподдержку вне зависимости от того, являетесь вы домашним или корпоративным пользователем. Бесконечная музыка в трубке, работники, стремящиеся переадресовать ваш звонок кому-то другому, а этот другой — кому-то ещё, некомпетентность, когда никто не понимает, как оно работает и как это починить — думаю, многие из вас сталкивались с подобными ужасами хотя бы один раз.
Как опытный руководитель, управлявший несколькими отделами технической поддержки, я прекрасно знаю об этих проблемах, более того, меня это раздражают больше, чем других просто потому, что я знаю, что нужно сделать чтобы организовать техническую поддержку с показателем удовлетворённости потребителей в 97,5%.
Исходя из своего опыта я могу выделить два ключевых фактора при построении отдела техподдержки — это люди и управление процессами.
Команда техподдержки должна комплектоваться людьми, интересующимися технологией, с которой они будут работать (в случае с нашей компанией — это технологии хранения и виртуализации) и которым нравится помогать людям. Определить таких людей нелегко, особенно если у вас есть всего 30 минут на собеседовании чтобы познакомиться поближе. Но и за это время можно кое-что узнать, например из ответов на вопросы не связанные с технической частью. Знание о том, каковы увлечения кандидата за пределами работы, может дать ответ о том, насколько он мотивирован. Если он занимается волонтёрской работой или иной деятельностью, направленной на помощь кому-либо — это хороший признак. Диплом же с высокими оценками может быть показателем того, что кандидат способен запомнить материал, но не даёт нам никаких намёков о том, насколько он мотивирован, каковы его реальные знания и способен ли он работать в команде.
Не удивляйтесь, если вам подкинули логическую задачку на собеседовании — её решение за ограниченный период времени может помочь узнать, насколько кандидат способен работать в условиях цейтнота — очень важное качество для сотрудника техподдержки. И не бойтесь — я заинтересован прежде всего в оценке подхода кандидата к её решению, а не в правильном ответе. Для меня важно не то, насколько человек умён в общем, а то, насколько умно он способен действовать при выполнении своих рабочих обязанностей.
Инженеры техподдержки должны уметь донести информацию кратко, чётко и в понятном для клиента виде. Наблюдая за нанятыми людьми, я понял, что наша система образования совершенно не учит общению в бизнес-стиле — навыкам переписки, презентации и общения с пользователями, а также логическому мышлению, а ведь это очень важно.
Для команды технической поддержки важно чтобы её участники разделяли общие ценности и хотели выполнить работу как можно лучше. Кроме того считаю, что для сплачивания важна не только командная работа, но и командные игры и иные развлечения. Картинг, пейнтбол, походы, совместное исполнение песен и многое другое — вот то, что я использую для построения командного духа во внерабочее время.
Можно сравнить эффективную командную работу со стайкой рыбок. Учёные считают, что многие виды рыбок держатся вместе чтобы уменьшить трение о воду и сохранить больше энергии при передвижении. В группе рыбке проще добывать еду, так-как помимо неё в поиске участвуют десятки глаз и носов. Как и стайке рыбок, команде с общими ценностями проще преодолевать различные проблемы, ведь совместная работа позволяет максимизировать ресурсы команды, находить новые пути решения задач.
Командная работа не ограничивается только отделом техподдержки, так-как для решения проблем зачастую необходимо взаимодействовать с инженерным отделом, отделом продаж и.т.д. Умение различных команд организовать совместную работу очень важно. Но, всё-же, важнее всего именно взаимодействие работников поддержки между собой, их способность действовать как единый организм, умение оказывать и принимать помощь.
Работа технической поддержки должна быть задокументирована чтобы всегда можно было вернуться к пройденному. Процессы должны быть простыми и предполагать возможность гибкого подхода на случай если стандартные решения неэффективны, и главным критерием тут является повышение удовлетворённости клиента.
Например, дав сервисным инженерам возможность тратить до 500$ (с отчётом, разумеется) для быстрого и эффективного решения проблемы, например отправки нового железа или программного продукта ускоренной, а не обычной доставкой, удалось весьма серьёзно улучшить уровень удовлетворённости нашими услугами. Грамотная разработка и документация процессов позволит организации отслеживать свои результаты чтобы узнать, достигли ли её клиенты уровня удовлетворённости в 97,5% или более.
Программа подготовки персонала для техподдержки должна включать как можно больше практического материала и симуляции жизненных ситуаций. Простое изучение методических материалов приводит к тому, что большая часть из них забывается, так что я предпочитаю именно практический подход.
В нашей компании мы создали команду руководствуясь этими факторами и мы продолжим работать в том же духе. Мы любим общаться с нашими клиентами и каждую заявку считаем возможностью показать нашу компанию с самой лучшей стороны.
У сотрудников техподдержки наверное самый высокий уровень текучки во всей ИТ-отрасли. Найти хорошего специалиста техподдержки сложно, а новичок, поработав несколько месяцев, стремиться перейти на менее беспокойные позиции. Техподдержка часто принимает на себя негативные эмоции пользователей. Выдерживать поток негатива день за днем тяжело, но необязательно. Многое в общении с пользователями зависит от поведения самого сотрудника. Что же должен делать сотрудник техподдержки, чтобы его работа не была такой тяжелой?
Для вас звонок пользователя - это новое обращение. Пользователь на свою проблему уже потратил достаточно времени - попытки самостоятельно разобраться, ожидание на телефонной линии, а возможно его уже пару раз отфутболили с обращениями по телефону в разные ИТ-службы. Стоит ли удивляться изначально негативному настрою? Выслушайте, наконец, в чем состоит его проблема, и только потом переходит к формальному заполнению заявки - выяснению личности пользователя, отдела/компании/ номера договора и т.п. Примечательно, что скрипты для техподдержки часто предлагают противоположное.
Можно потратить полчаса на попытку разобраться с проблемой, которой не существует. Для начала стоит убедиться, что ситуация, которую видит пользователь, не является частью более крупного инцидента, который он пока не заметил.
Например, пользователь звонит с обращением «У меня мышка залипает».
Один сценарий выяснять: оптическая или механическая, проводная или беспроводная, светиться ли диод и светился ли он раньше и т.п. Разговоров на 20 минут, а до проблемы вы можете так и не добраться.
Попробуем зайти с другого конца: «Итак, у вас не работает мышь, а все остальное на компьютере работает нормально? Например, попробуйте перейти в другую программу при помощи клавиш « Alt » + « Tab » или запустить программу из стартового меню при помощи « Ctrl »+« Esc » и стрелок» .
Если все работает, то можно попытаться выяснить, что случилось с мышкой. Если же нет, то мышь не причем и разбираться нужно уже с компьютером.
Типичный стереотип, которому подвержены сотрудники техподдержки - 80% проблем пользователей исправляются фразой «А вы пробовали выключить и включить?». Ну да, это часто срабатывает. В то же время, большинство пользователей достаточно хорошо знакомы с компьютером, чтобы проделать такие шаги самостоятельно.
Они отвечают «Да», даже не задумываясь над каждым вашим «Вы уже пробовали…»
Вы пробовали выключить и включить?
- Да
Вы держали нажатыми и , когда нажимали ?”
- Да
Вы держали компьютер над головой, когда выполняли ритуальный танец?
- Да
Вместо того, чтобы спрашивать, что пользователь уже делал, намного эффективнее дать пользователю задание, которое он должен проделать прямо сейчас и говорить с ним о том, что он видел. Эффективный метод - проделать по шагам весь путь пользователя к его ошибкам, например, запустив у себя те же программы. Если ошибка появится и на вашем компьютере, то это хорошая причина эскалировать инцидент другим специалистам.
Нельзя посадить техподдержку на Linux, если пользователи работают в Windows. Не стоит мигрировать ИТ-отдел на Windows 8, если в компании все еще активно используется Windows XP. Очень важно для сотрудника техподдержки иметь среду близкую к той, что у пользователя на компьютере. Так он может предсказать нормальное поведение компьютера и подсказать пользователю правильные шаги. Рабочая среда компьютера - лучшая подсказка в любых ситуациях, если вы хотя бы примерно знаете, что нужно делать.
Многие пользователи считают, что техподдержка должна знать абсолютно все о компьютерах и программном обеспечении. Мы с вами знаем, что среди тех кто работает на первой линии таких людей нет, но очень многие пытаются ими претворятся. Часто техподдержка пытается угадать правильное решение. В итоге пара неудачных догадок и вы полностью теряете доверие пользователей. Что же делать? Четность - лучшая политика. Если вы не знаете решения и не можете передать пользователя тому, кто знает, то попытайтесь разобраться в ситуации вместе с пользователем. Поищите в интернете, спросите не нашел ли пользователь там решение, попробуйте вместе с пользователем пройти это решение. Многие чувствуют себя глупо и неуверенно, общаясь с техподдержкой. Вовлечение пользователя в поиск решения может придать им уверенность в себе и повысить удовлетворенность от общения с техподдержкой.
Эмпатия - это очень нематериальное понятие. Тем не менее, например, совет улыбаться, отвечая на звонок действительно работает. Пользователи чувствуют ваше отношение. К сожалению, сочувствие к проблемам пользователей - это не то качество, которым отличаются большинство служб технической поддержки. Действительно, какое сочувствие может вызвать человек, который даже не может включить компьютер без посторонней помощи. С другой стороны, большинству пользователей достаточно один раз доступно объяснить правильный порядок действий, чтобы избежать их обращений в дальнейшем. Сотрудникам техподдержки и стоит чаще вспоминать о том, что они тоже многого не знают и не умеют, что вообще совершенно нормальная ситуация.
ИТ-специалисты в большинстве случаев не считают себя воспитателями детского сада для пользователей. Даже шутки при общении с пользователями чаще всего специфические и мало понятные «простым смертным». Есть такое хорошее, но постепенно выходящее из обращение слово Help Desk - служба помощи, впрочем вариант со службой поддержки тоже неплох. Задача техподдержки - помочь и поддержать пользователей. Если пользователи завершат разговор довольными, то и вы скорее всего будете чувствовать удовлетворение от хорошей работы, а значит и работать будет значительно легче.
Вообще техническая поддержка — это боль и слёзы рынка веб-разработки. Самые слёзные жалобы к нам поступают с просьбой забрать какой-то проект на доделки.
Спрос на техническую поддержку сейчас в разы больше предложения. В ближайшее время он будет только расти, т.к. многие компании будут резать косты и поддерживать свои проекты в более-менее живом состоянии, не запуская работы по новым направлениям.
Декларируют техподдержку многие. Делать системно и рентабельно умеют единицы. Этот текст скорее для студий (чтобы они могли улучшить свои процессы или сказать, как улучшить наши). Но будет полезен и тем, кому действительно интересно разобраться, есть ли жизнь после релиза. Мы потратили десятки часов на обсуждения и споры внутри студии, чтобы решить, что наш процесс должен выглядеть как-то так. И хотя мы довольно гибко можем настроить некоторые аспекты технической поддержки (например, вести работу в любимом таск-трекере заказчика), каркас, к которому мы пришли, мне кажется, довольно хорош.
Свои проекты мы делаем по гибкой методологии scrum. Это значит, что в процессе работы клиенту не обязательно придерживаться толстого и нудного ТЗ, а можно добавлять/удалять/изменять любые хотелки прямо по ходу работы. Плюсы: гибкость и прицел на постоянное развитие проекта сразу. Минусы — постоянно неактуальная документация.
Грозовая туча: старые и новые проекты.
Над каждым проектом работает КОМАНДА разработчиков. Это важно, потому что после запуска проекта как минимум два-три человека причастны к коду и могут его поддерживать. На практике это сильно лучше, чем если бы всю разработку делал бы один «незаменимый» гений.
С незаменимостью также помогают бороться две вещи: строгие стандарты кодирования и регулярные code review, которые мы проводим на своих проектах.
Временное подключение к поддержке дополнительных программистов, не участвовавших в реализации проекта, я не очень люблю: высок риск запустить прогрессирующее отравление проекта. Это явление есть проявление человеческого фактора и кажется, во многом обусловлено русским менталитетом. Желание творить крупными мазками, а не кропотливо доводить детали.
Нежелание нового разработчика лезть в чужой код и его понимание, что проектом он занимается временно — приводит к тому, что в код втыкаются костыли. После появления в коде критической массы костылей даже команда, которая изначально разработала проект, начинает считать код чужим и решает задачи с помощью новых костылей. Через некоторое время проектом заниматься никто не хочет и все ноют что он — говнокод. Купировать отравление можно, но довольно затратно: часто требуется провести глубокие кодревью и рефакторинг. Иногда два-три раза подряд. В общем, добавление новых людей на поддержку я считаю оправданным только в трех случаях:
В перерывах между спринтами (например, когда идет интенсивное тестирование и заниматься проектом нельзя), мы можем ставить больше техподдержки, если это целесообразно. В утренние часы разработчиков стараемся не дергать (без крайней необходимости). Это связано с тем, что важно, чтобы разработчики работали в потоке и как можно меньше отвлекались и переключались. Уменьшаем энтропию. Кроме того, это позволяет разработчику не зацикливаться только на саппорте старого (многие ее недолюбливают, но тут я суров: любой проект, который мало-мальски успешен обязательно будет просить развития), но и пробовать новое (новые технологии) на новых проектах.
Итак, мелкие и срочные задачи мы вклиниваем в эти два часа в день, с 16 до 18 (ну фактически, с учетом командной работы это может быть и 4 и 6 часов, в зависимости от того, параллелятся ли задания). Крупные задачи, которые можно делать в спокойном режиме, мы запускаем в работу спринтами (минимум по 40 часов), в основные часы. Работа спринтами стоит для клиента дешевле (в пересчете на стоимость часа), чем экстренные и срочные задачи, которые нужно сделать еще вчера.
За коммуникацию с клиентом на технической поддержке в большинстве случаев отвечает тот же менеджер, что и работал над проектом. К сожалению, это не всегда рационально с точки зрения использования дорогущщего времени менеджеров (дорогие — не только в смысле затрат, а в смысле ТОС: менеджеры очень часто становятся бутылочными горлышками системы, а час простоя в бутылочном горлышке равен часу простоя всей системы).
Если на менеджера за счёт технической поддержки чрезмерная нагрузка (мы называем это «рвет радугой») и потери на передачу проекта другому менеджеру принципиально окупятся — в этом случае я могу поменять менеджера. Во многом проекты на поддержке попадают подрастающему поколению для прокачки собственных сил и набора клиентской базы. Крайне редко менеджера меняем, если на проекте возник какой-то конфликт с клиентом и нужно начать отношения с чистого листа.
Опять же, в очень исключительно-редких случаях нехватки менеджерского времени, с формулировками клиента напрямую работает программист. Однако мы стараемся минимизировать такие коммуникации, т.к. нечеткость формулировок крайне нервирует программистов, а ответы программистов на вопросы клиентов без предварительной вычитки могут конфузить клиента наповал.
Так вот, про проактивность.
По проектам в активной фазе поддержки, проактивную позицию должен занимать менеджер проекта. Он замотивирован в получении % от проектов. По проектам, по которым нет никаких работ, мы системно проходимся несколько раз в год и стараемся их разбудить. Это хорошая практика, приносящая свои плоды. Будит спящих клиентов, как правило, аккаунт-менеджер. Не всегда спящего клиента нужно будить:)
Итого, мы оставляем за собой право уточнять и переформулировать постановки клиента в более чёткие. Уточнять и дописывать детали. И даже отговаривать клиента от каких-то задач (если на наш взгляд они сделают проект хуже). Однако за финальные формулировки несет ответственность клиент. Те формулировки, которые мы зафиксировали один в один будут направлены в разработку. И по ним же будет проверять наш тестировщик. И по ним же мы будем сдавать задачу.
Тем не менее, обсуждение задач, особенно крупных, неэффективно вести в трекере. Скайп, телефон с обязательной фиксацией результатов разговора в конкретные задачи. Обычно разговор резюмирует наш менеджер проекта. Задача клиента — проверить и утвердить правильность формулировок и дать добро в работу.
Понятно, что бывают ситуации, когда всё упало и нужно звонить и срочно решать вопрос. Например, у нас был случай, когда в интернет-магазине обуви в момент валютной паники, начало прилетать по 100 заказов в час, и клиенту потребовалось срочно остановить продажи, т.к. не справлялась логистика. Понятно, что в случаях форс-мажора мы все бросим и решим проблему по телефону. Даже в выходные дни и в нерабочее время. Но и устраивать вселенскую панику по каждой мелочи мы не можем себе позволить. Почти все клиенты это понимают, если им это объяснить.
Тем не менее, для некоторых проектов корпоративного сектора, где существует громоздкая процедура бюджетирования, такой подход не годится: все оценки и бюджеты нужно подписывать и утверждать заранее. В этом случае в наших оценках будет заложено максимальное число рисков, которые мы можем предусмотреть, по каждой из задач.
Замечу, что работа по time&material на практике для клиента быстрее и дешевле, однако возможна только если клиент доверяет и доволен. Нам это тоже выгодно, т.к. сокращает затраты на менеджмент и бюрократию (а менеджер, напомню, у нас бутылочное горлышко системы).
К вопросу о точных оценках: несмотря на то, что есть хорошие методы оценок , точных оценок не бывает. Эту мысль сложно донести до клиента и тут очень легко уйти в демагогию. Я предпочитаю не увлекаться с клиентом обсуждением этой темы, а просто обрисовать две схемы работы: с оценками, в которые заложены наши риски и оценками, где все риски несет на себе клиент, и дать выбор. В конце концов и мы должны понимать, что бюджеты клиента ограничены, а клиент — что нам нет смысла работать без прибыли.
Если вас всерьез интересует вопрос точных оценок — в конце статьи я там насколько ссылок.
При схеме time+material по сути все риски лежат на клиенте. Если ошибок много и их исправление выставляют клиенту — он будет недоволен и вам про это скажет. Как правило, экономически выгоднее не вступать в спор и поправить свои ошибки за свой счёт, не нагнетая обстановку, даже несмотря на то, что согласована схема работы по фактическим часам. Я придерживаюсь того, чтобы исправлять ошибки за наш счёт, если:
Если косяк откровенно наш — берем и исправляем, не компостируя мозги. Так в итоге дешевле.
Исключение: очень сложные системы с большим количеством зависимостей. Поменяешь запятую в карточке товара — сломается какой-нибудь хитрый импорт, который запускается раз в месяц. Здесь либо нужен code freeze + полный тест системы на каждое изменение (что очень дорого), либо полное покрытие кода тестами (что тоже очень-очень дорого), либо смирение, что такие ситуации возможны.
Замечу, что чтобы схема работала — нужно, чтобы спорные ситуации возникали как можно реже. Иначе клиент будет недоволен поддержкой или поддержка будет убыточной для студии.
Еще нюанс — мы не несем на себе ответственность за 3-х лиц (например, хостинг) или упущенную выгоду. Обычно это воспринимается адекватно.
В основном, реальная скорость работы зависит от того, как быстро задача попадет на разработку. Из чего она складывается:
0-8h на приемку и уточнение задачи. Менеджер получает уведомление о создании новой задачи. Банальный деловой этикет и принцип пустого ящика требует, чтобы в течении суток все такие обращения были обработаны. Далее, в зависимости от срочности — задача может быть либо отложена до формирования спринта, либо экстренно запущена в работу, либо запланирована в плане работы на программиста на следующий день. Либо, если формулировки неясны — начинаем работу над выяснением формулировок. Формально, здесь у менеджера есть лазейка включить дурочку и долго-долго чего-то не понимать и уточнять. Однако клиенты это чувствуют и становятся крайне недовольными в таких ситуациях и непременно скажут вам об этом. Останется только разобраться в причинах и применить управляющее воздействие.
8-16h обычно через сутки после того, как задача попала менеджеру проекта и все формулировки понятны, она попадает на разработку. Это связано с тем, что мы планируем, какими проектами будет заниматься каждый программист на утренних планерках (в 8:45) и затем уже стараемся не отклоняться от этого плана. Как правило, задача от клиента попадает в план на разработку на следующий день после постановки (но бывает, что и в тот же день).
16-24h в большинстве случаев мелкие задачи задачи выполняются и отгружаются клиенту за первые 8-16 часов. Еще 8 часов — резерв для выравнивания нашего потока работ или тестирования.
По большим и трудоемким задачам либо формируется спринт, либо — график выполнения, в зависимости от их срочности и приоритетов клиента. Абсолютно непродуктивно делать 30-40 часовые задачи урывками по 2 часа в день.
Понятно, что там, где форс-мажор, все сломалось и нужно все бросить и починить — бросаем и чиним. Если уровень форс-мажора выше 3-5% от всех задач — это повод искать огрехи в организации самого проекта или нашей над ним работы.
Замечу, что в долгосрочной перспективе бухтение клиента практически неизбежно (ну или я не знаю случаев, когда клиент был бы целиком доволен 2-3 летним итогом поддержки, не имел каких-либо нареканий и время от времени не смотрел бы на сторону). Итак.
Довольно правильно делать с клиентом пересмотр сделанного за 2-3 месяца. Формально анализировать список задач и смотреть причины возникновения ошибок. Это могут быть формулировки, и в этом случае вы совместно должны решить, как вам улучшить постановку задач. Это могут быть слишком частые ошибки программирования, и тут нужно искать причины на своей стороне. Наконец, клиент может быть недоволен тем, что его не отговорили от каких-то его идей и это привело только к лишней трате денег.
Вы должны системно проверять, доволен ли клиент работой с вами. Встречаться лично, разговаривать, обсуждать перспективы проекта, перспективы бизнеса клиента и его планы на ближайший год. Особенно осторожным следует быть при смене менеджера на стороне клиента. Важно рассказывать клиенту, где вы можете пойти ему навстречу и где нет, и почему. Это добавляет открытости и управляемости.
Без этого в долгосрочной перспективе вас сольют.
Нажмите на картинку для перехода к интерактивной карте
Организация служб технической поддержки – наш «конек», так как специалисты «Открытой Линии» имеют соответствующее профильное образование и большой опыт организации подобных служб.
Услуга представляет собой обслуживание поступающих от абонентов вызовов с вопросами технического характера.
На Ваш проект мы подберем операторов необходимой квалификации и с соответствующим образованием. Они будут приветствовать абонентов от лица Вашей компании и сделают все для решения возникшего вопроса.
Специалисты компании проходят подготовку и тестирование полученных знаний и навыков в области коммуникаций с разными типами абонентов, технологии разрешения конфликтных ситуаций, навыков стрессоустойчивости. Периодически тренеры call центра совместно со Службой качества будут проводить аттестацию сотрудников проекта и квалификационные экзамены.
В случае с «особо сложными» абонентами есть возможность перевода вызова на старшего смены или супервайзера, который отработает обращение качественно и профессионально.
Наш контакт центр предоставит Вам персонального менеджера проекта, который будет следить за соответствующим качеством обработки вызовов от клиентов и формировать ежемесячные отчеты о деятельности операторов.
Наше оборудование позволяет замерять пики и спады нагрузок – благодаря этим данным менеджер проекта подберет оптимальный график и количество работы операторов на Вашем проекте. Это будет способствовать увеличению доступности дозвона, сокращению времени ожидания на линии, повышению лояльности Ваших абонентов.
Проанализировав Ваши бизнес-процессы, менеджер проекта предложит Вам оптимальную схему распределения вызовов. В некоторых случаях эффективно разделить вызовы на 2 типа: вопросы общего характера, которые будут отработаны более дешевыми специалистами (первая линия), и вопросы узкопрофильного технического характера, которые будут в компетенции инженеров Службы технической поддержки. Это ведет к оптимизации издержек на обработку вызовов абонентов и улучшает ситуацию с дозвоном, так как разгружает линию высококвалифицированных специалистов от звонков с простыми вопросами (напр., «где расположен Ваш офис», «часы его работы» и другое).
Высокая квалификация наших специалистов будет способствовать снижению числа заявок на Ваших сервисных инженеров, так как мы сможем решать вопрос абонента дистанционно, без вызова специалиста на дом. Таким образом, Вам не нужно будет держать в штате дополнительное число инженеров, они будут работать с меньшим числом заявок и быстрее их отрабатывать. Подобная схема работы будет снижать Ваши издержки, повышать лояльность абонентов к Вам, удерживая клиентов качеством предоставляемого сервиса от соблазна перейти к конкурентам даже в период запускаемых спецпредложений и акций.
В периоды существенного повышения потока звонков мы готовы расширить число операторов на линии для повышения комфорта абонентов при дозвоне в компанию.
Формируемые нами подробные отчеты о деятельности Службы технической поддержки позволяют Заказчику повысить прозрачность этого процесса и владеть актуальными данными по проекту.
Все диалоги записываются и архивируются, и в случае возникновения спорной ситуации у Вас всегда будет возможность прослушать запись разговора для формирования своей объективной оценки.
