"Ваша техподдержка ужасна" – 4 способа поднять уровень сервиса
Знаете, в чем заключается главное отличие компаний-разработчиков крупного ПО? Не только в рынке застройщиков, но и в целом?
Одни внедряют и занимаются техподдержкой своих продуктов самостоятельно, а другие перекладывают ответственность на подрядчиков.
Причины этому понятны:
- Необходимость содержания своего штата технических специалистов, проджектов, менеджеров.
- Контроль еще одного подразделения.
- Концентрация на производстве и продаже своего продукта.
Но что это значит для клиента?
1. Часто он получает не то, что хочет, а то, что ему способен дать подрядчик. Исполнитель не может погрузиться в проблему полностью – а это сложно сделать, если не знаешь абсолютно всех возможностей системы, которую поддерживаешь.
2. Обещания при покупке продукта часто не сходятся с результатом. Почему? Смотри п. 1.
3. Никакого индивидуального подхода. Только то, что входит в комплект поставки. Хочешь дополнительный отчет/ кнопку с определенными функциями? Сначала мы узнаем у других клиентов, актуально ли им это, и если большинство будет согласно, то тогда мы, спустя пару лет, что-то сделаем и обновим твою систему.
Занимательный факт – к компаниям, которые разделяют наше мнение, что
«Не должны разработка и поддержка находиться в разных уголках планеты – это неэффективно и для клиента, и для специалистов техподдержки»
предъявляется требование, которым ребята из второй категории не отвечают:
Вы должны работать идеально, иначе ваша техподдержка ужасна.
В глазах клиента это как? Первое, что приходит на ум – не косячить, соблюдать дедлайны и делать именно то, что просят.
Расскажем, почему это - утопия (даже если техподдержка будет стоить от 1млн Р/месяц).
Как же так? Вот так.
1. Посмотрим правде в глаза: все косячат. Все иногда срывают дедлайны или не успевают сдать часть работы. Мы тоже.
Вспомним уроки алгебры и кривую нормального распределения, она же кривая Гаусса.
Это график, который показывает количественное распределение. В нашем случае – распределение задач по качеству их выполнения. И нормальность распределения призвана показывать ту самую среднюю температуру. Это нормально, что есть задачи, сделанные отлично. И так же нормально, что есть задачи, которые сделаны ужасно – просрочены (к вопросу просрочек вернемся отдельно). Можно сказать, что этот график показывает наличие человеческого фактора. Нельзя всегда работать одинаково хорошо.
И до тех пор, пока большая часть задач находятся посередине (условно – сделано достаточно хорошо), подобные косяки – не более, чем случайность. Пытаться сделать так, чтобы ошибок не было вовсе, – утопия, которая требует космических затрат и ощутимого повышения ценника техподдержки.
2. Вопрос просроченных задач рассмотрим под лупой.
На этапе сдачи результата работ на тестирование, мы часто сталкиваемся с историями:
- А я не успел посмотреть, почему вы мне не напомнили? (А мы напоминали все 3 месяца просрока).
- А вот тут вот это надо исправить, держите правки! (А это не существующий интерфейс доработать надо, а свежесозданный функционал изменить. Не «правки», а совсем другое ТЗ).
- В ТЗ запрос на создание отчета из 5 столбцов! Но мы не можем проверить/ У нас не работает! Почему? Потому что нет 6 столбца! (Повторяем из раза в раз – мы что угодно разработаем, но четко по предоставленному ТЗ. Чего нет в ТЗ – то мы доработаем. Но уже по следующему ТЗ. Идеального ТЗ не существует – миримся с этой мыслью и живем дружно).
То есть, 60% задач со статусом «Просрочено» становятся такими из-за того, что клиент их проверяет с опозданием или начинает бодаться «Нет, это не разработка, а доработка!». Наш ведущий программист на подобное рекомендует отвечать «Мы разработчики, нам виднее», но руководитель техподдержки предпочитает мягкие переговоры жестким.
3. «Делайте, что мы просим, тогда мы будем убеждены, что вы умнички».
Но тут мы вспоминаем, что:
- Идеального ТЗ не существует. И мы со своей стороны максимально погружаемся в запрос клиента, задаем дополнительные вопросы (Зачем вам это? Почему нельзя оставить, как сейчас? Что вы уже пробовали?), и часто в процессе разговора выясняется, что клиент обозначает в ТЗ некий Х, а получить в результате хочет Ь. Плюс в процессе всегда появляются изменения. Они обычно вводятся со словами «А мы тут подумали…» и «Ой, этого не было в ТЗ?». И это – нормально.
- И даже после релиза нового функционала по отработанному ТЗ могут выйти какие-то недочеты. Просто потому, что идеал с нуля не создается, всегда нужно 2-3 итерации правок. И это нормально, это рабочий процесс.
Что действительно помогает работать хорошо?
Пишем только по своему опыту и без очевидного «берем только классных специалистов».
Требования разработки и бизнеса не противоречат, чтятся и соблюдаются.
CEO – разработчик. И разработчик не просто по образованию: он сам по сей день глубоко погружен в бизнес-процессы застройщиков и участвует в глобальной разработке продуктов.
Поэтому внутренние требования для разработчиков – это требования одновременно и бизнеса, и разработки. Для упорядочивания работы с заявками мы внедрили Jira Service Desk, с помощью которого мы:
- Определяем, по каким разделам CRM 4DEV идет наибольшее число запросов, и каких, и на основании этого своевременно обновляем функционал у всех наших клиентов.
- Распределяем нагрузку по консультантам, чтобы задачи выполнялись в срок.
- Контролируем выполнение задач – мы так же видим статусы задач коллег и приходим на помощь, если время реализации задачи уже всё, а консультант – еще нет :)
Оперативно оцениваем стоимость задач, которые выполняются по вашему ТЗ.
А с конкретными задачам мы работаем по SCRUM-методологии «из точки А в точку Б идем вот такими шагами (список шагов)». Ставим сроки и вперед. Реализовали – клиент оплатил. Готово.
2. Реально заботимся об удобстве контроля со стороны клиента.
С внедрением Jira Service Desk наши клиенты легко отслеживают прогресс работы с задачами:
- Они легко перемещаются и фильтруют все свои задачи, своего подразделения или всей компании, их темы и частотность,
- Отслеживают срок их реализации и смену статусов,
- Ставят задачу за 5-7 минут и получают уведомление, что мы ее получили и помчали в работу, на свою личную почту. Они не тратят время на разговоры с консультантом, просто пишут запрос и прикладывают скриншот,
- Быстро получают консультацию по работе в системе с уже настроенным функционалом.
3. Нет коммерческой структуры, которая мотивирована только на продажи без вхождения в контекст бизнес-процессов каждого клиента.
«Мы продали, а разбираться идите к вендору» – не наш путь. В целом, это директивная система, где бизнес сообщает «Мой продукт такой, какой есть. Подстраиваться под него будете вы. Вы, ваши бизнес-процессы, дополнительные сервисы». Мы же предлагаем сотрудничество и рост через внедрение уникального функционала, тех сервисов, которые будут развивать конкретно вашу компанию.
4. Наши консультанты техподдержки разбираются во всех конфигурациях наших продуктов и разрыва между консультацией и разработкой нет.
То есть, все говорят на привычном языке, но программист понимает запрос клиента, ведь консультант его уже «перевел».
Верить, что внедрение и работа с большими проектами может идти ровно, рядком и по плану, можно. Вопрос только в том, получается управлять происходящим или тебя затягивает в этот водоворот и ты несешься с криком "уиииииии!". Так что, на наш взгляд, каждый контакт с нашими клиентами-застройщиками, их уникальными бизнес-процессами и работа на их благо – наш стандартный in life проект. Если только слово «стандартный» вообще имеет право на жизнь в таком контексте.
Поэтому продолжаем развиваться, как разработчики, консультанты, "поддержатели продуктов", внедряем новый софт и предлагаем клиентам тот уровень сервиса, где фраза
"У меня ничего не работает и вы должны мне помочь!"
воспринимается исключительно с улыбкой и понятным каждой стороне регламентом работы.