Как обращаться в техподдержку, чтобы вашу проблему решили

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

Привет, на связи Антон Карцев, основатель AlarmCRM и автор телеграм канала про IT-решения для бизнеса и HR. Наша команда внедряет методологию и решения, которые повышают конверсию и улучшают взаимодействие с клиентами для отделов продаж и HR-департаментов.

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

В рамках статьи и разберу работу облачных Saas сервисов, хотя в коробочных решениях все аналогично. Для начала стоит понимать как работает техподдержка изнутри. Чаще всего отдел техподдержки крупных вендоров многоуровневый.

Обычно это 2-3 уровня:

1 уровень - решает типовые вопросы, гоняет клиента по стандартным вариантам решений, отвечает на вопросы из разряда как настроить стандартный функционал и может поделиться ссылкой на нужный раздел документации. Задача первого уровня закрыть 80% всех запросов.

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

3 уровень - решает приоритетные и критическе важные проблемы, которые влияют на работоспособность сервиса в целом. Обычно это инженеры, архитекторы, DevOps, старшие QA или TeamLead.

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

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

Бывает ситуации, когда система работает не так, как от неё ожидает пользователь, это может выражаться в неудобном интерфейсе или некорректном бизнес-процессе. Постарайтесь определить а действительно ли проблема, которая возникла является багом?

Лучше всего этот вопрос разобрать на примере из практики:

В компании реализован бизнес-процесс автоматического подтверждения записи клиентов на услугу через WhatsApp. Часть менеджеров предпочитают подтверждать запись по приоритетным клиентам вручную звонком.

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

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

С багом определились, далее проводим самодиагностику, задача которой получить ответы на вопросы:

Ответили? Сделайте перерыв подождите 10 минут и проверьте снова.

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

Ничего не помогло? Вот теперь можно писать запрос в техническую поддержку.

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

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

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

Еще частая проблема, запрос шлют не туда, когда используется несколько систем, интегрируемых между собой. Например есть CRM интегрируемая с телефонией, проблема звонки не попадают в CRM. Кому писать запрос? Поставщику телефонии или CRM? И однозначного ответа тут нет, точнее есть, но он не очевиден - запрос надо отправлять тому, чья интеграция.

С телефонией чаще всего - это сам поставщик телефонии отвечает за интеграцию. Поставщиков интеграции WhatsApp с CRM десятки, вы же не будете писать в Meta*, если у вас перестали приходить или отправляться сообщения?

Чат-бот помощники отличный инструмент, но для решения технических проблем они не подходят. В лучшем случае они способны отработать 50% запросов первого уровня, но если вы прошли этап самодиагностики, можете смело писать “Позови оператора”.

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

Итак выбрали куда и через какой канал будем слать запрос. Далее нужно составить сам запрос. Есть простой принцип: Составляйте запрос так, как будто вы объясняете проблему вашему другу, который вообще не понимает чем вы занимаетесь и впервые видит систему.

Вот вопросы, которые помогут верно составить запрос:

Добавьте скриншоты, видео демонстрации проблемы. Снимите видео экрана на телефон и прикрепите к запросу. Используете Saas решение через браузер? Сделайте скрины и видео с открытой консолью разработчика (клавиша F12 на клавиатуре).

Отправив тикет, будьте готовы выделить время и быть на связи, отвечая на запросы поддержки. Если вы отправите запрос и уйдете в отпуск на неделю, то вероятнее всего его закроют, из-за отсутствия активности.

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

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

Еще одна проблема, с которой уверен сталкивались все - сервис не доступен. Если вы понимаете, что проблема глобальная и не работает все и у всех, то слать запросы в поддержку бесполезно. Из недавнего пример со СДЭКом, который лежал фактически неделю. В диагностике таких проблем поможет Downradar или сообщество пользователей сервиса в соц.сетях.

Будьте уверены, когда вендор сталкивается с проблемами такого рода, то вся команда инженеров и разработчиков с максимальным приоритетом направляет все силы на решение проблемы. Из своего опыта 90% всех проблем решаются до 20 минут и сервис восстанавливается, лучшее что можно сделать - расслабиться, сделать перерыв, зарядку, выпить чашку чая или кофе. Тут главное не упустить момент, когда проблема единичная у вас.

Это одни из самых сложных проблем.

Например в CRM не загружается карточка сделки. При обновлении страницы все проходит.

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

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

SLA (Service Level Agreement — соглашение об уровне обслуживания) — внешний документ (существующий между заказчиком и исполнителем), описывающий параметры предоставляемой услуги.

Это отличный инструмент получить качественную услугу, но почему он не поможет. Зачастую в SLA прописываются обязательства по доступности сервисов и скорость реакции на обращения. То есть у вас будет прописано, гарантируем, что сервис будет доступен 99,98% времени и время реакции техподдержки на ваши запросы составит менее 20 минут в рабочее время и менее 1 часа в выходные и ночное время. Но это не гарантирует, что вашу проблему решат. Да тикет возьмут в работу, но если вы не предоставите достаточно количество данных для диагностики проблемы - можно часами зависать на первом уровне поддержки выполняя процедуры по диагностике.

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

Как раз для таких клиентов мы оказываем услугу сопровождения, где решение всех вопросов по IT-инфраструктуре работает по принципу одного окна. Достаточно написать в телеграм-чат запрос, а уже наш сотрудник поддержке проведет необходимое тестирование, соберет всю информацию и после подтверждения бага передаст вендору.

В заключении расскажу как я реализовал процесс техподдержки для наших клиентов.

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

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