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

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

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

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

Если открыть эту страницу в Wikipedia, то обнаружится более 100 программных решений для отслеживания ошибок/проблем – с открытым кодом, для настольных компьютеров или в качестве веб-приложений. О чем это говорит?

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

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

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

• Всеобщий охват: Все запросы в клиентскую поддержку: с сайта, из приложения, по электронной почте, по телефону и даже по обычной почте – должны поступать, быть доступны и анализироваться в одном интерфейсе.
• Легкость: Разработчики Fogbugz и Helpspot сумели избавиться от изрядного количества нажатий на кнопки, шагов, ненужных действий и барьеров, стоящих на пути достижения ваших целей, а что еще более важно – целей ваших клиентов.
• Уважение к клиенту: В наше время слишком много «справочных» систем служат внутренним политикам компании, навязчиво собирают данные о клиентах или вообще спроектированы так, что напоминают миграцию лосося – трудный путь вверх по течению с преодолением преград, чтобы умереть в конце своего пути. Нам нужно не это.
• Приятный внешний вид: Особенно если вы собираетесь использовать это приложение изо дня в день. Интерфейс должен быть привлекательным, профессиональным, легким в навигации и логичным – в общем, похожим на вашу начинающую компанию! Он должен быть стойким к постоянному использованию, не бояться перейти с привычной базы данных на новую и не быть рабом той палитры цветов, которая в моде на этой неделе.
• Отдавать приоритет болезненности: В частности, система должна помочь выяснить не только место, где не работает код, но также и как часто при каких конфигурациях и насколько болезненно для пользователя он не работает. Хотя большинство систем отслеживания ошибок расставляют приоритеты в зависимости от серьезности ошибки, по-моему, главное заключается в том, насколько серьезно страдает пользователь от конкретной ошибки. Другими словами, если вы сегодня можете посвятить исправлению ошибок только три часа и ни минуты больше, нужно исправить ту ошибку, от которой больше всего страдает большинство пользователей – даже если эта ошибка не такая серьезная, как та, от которой вылетает приложение или оперативная система у одного пользователя из тысячи. Это может звучать жестоко, но это бизнес. Нужно, чтобы система позволяла вам понять и оценить страдания клиентов.
• Минимум усилий пользователя: Кстати о клиентах. В реальности пользователи редко могут предоставить какую-либо информацию, которая на самом деле будет полезна при определении, что не так с кодом, и вы сильно разочаруетесь, если будете надеяться, что в вашем случае все будет по-другому. Причин этому может быть много, а решение заключается в том, чтобы как можно больше автоматизировать сбор данных, которые нужны по каждой ошибке, если, конечно, клиент согласится вам эту информацию отослать.
• Надежность: Я честно-честно обожаю ПО с открытым кодом и всемерно ценю тот вклад, который в него внесли многие программисты, лучшие, чем я (чем я и пользуюсь ежедневно). Тем не менее, я не доверю ему свой бизнес и не хочу тратить бесконечные часы, пытаясь исправить ошибки (ой, внося свой вклад) в «бесплатном» ПО. Мне нужно, чтобы где-то был кто-то, кому можно позвонить (Skype отлично для этого подходит) и прокричать: «Я неплохо заплатил за это дерьмо, чтобы все исправлено еще вчера!!!» (как и большинство докторов, чинящих программы, пациент из меня фиговый :)). Если серьезно, я доверяю людям, которые думают как я: Сделай отличный продукт. Заработай кучу денег на его продаже. Купи остров в тропиках.

2. Человек внутри. Не кантовать.

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

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

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

А поскольку просто пристрелить этих гадов, которые собираются хаять ваши программы только потому, что у них возникла проблема, о которой все остальные пользователи даже и не слышали, не получится, наилучшим вариантом в безжалостной бизнес-стратегии будет уважение и почтение по отношению к ним, достаточные для того, чтобы они не трепали языками – короче говоря, надо убить их добротой и пониманием! Может, любители мягкого подхода просто что-то затевают…

3. Чего делать не следует

• Непрофессионально себя вести. Когда клиент начнет оскорблять ваш продукт, у вас и, возможно, у ваших предков, появится соблазн ответить тем же. Не надо. Да, легче вам станет, но не делайте этого. Будь то телефонный звонок, электронное сообщение, сообщение об ошибке или блог, в итоге вы пожалеете, что стали бороться огнем с огнем. В лучшем случае потеряете клиента. В худшем же случае навесите на себя такой интернет-ярлык, который Google будет находить при каждом запросе еще лет сто.
• Соглашаться исправить ошибку. Постойте, разве не надо исправлять любую и каждую ошибку в приложении? Надо, но в том время, в том месте и таким образом, который выберете вы. Согласие исправить «ошибку» вселяет в пользователя надежду, которую вы можете не оправдать по каким-то вполне разумным коммерческим причинам, а вот это уже станет проблемой, гораздо большей, чем изначальная ошибка.
• Соглашаться добавить функцию. Просьбы добавить функцию обычно приходят по тем же каналам, что и сообщения об ошибках, но они сильно отличаются от последних. Хотя, конечно, нужно поощрять и приветствовать просьбы о новых функциях, следует хорошенько задуматься, какие новые функции и когда будут реализованы, если вообще будут реализованы.
• Просто взять и исправить эту чертову ошибку! Исправление ошибки – это определенно хорошее начало, но это только первый шаг. Выделение времени на устранение источника ошибки очень полезно, это называется «залог на будущее», как будет видно из следующего раздела.
• Надеяться решить проблему каждого отдельного клиента. У меня плохие новости. Этого не произойдет. Ни в этой жизни, ни в следующей. Всегда будут ошибки, которые противоречат логике, законам гравитации и которые останутся, несмотря на все ваши усилия. Всегда найдутся клиенты, которые считают, что купили себе за свои 24,95 развлечение в виде гнева, выплескиваемого на вашу голову, и которые хотят не исправить ошибку, а страдать. Так уж устроен мир бизнеса – смиритесь с этим, переступите через гордость, верните им их деньги и выкиньте их из своей жизни как можно быстрее.

4. Делайте то, что делают большие банки. Инвестиции.

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

Будучи программистом, я не уверен, как это работает, но мне сказали, что надежный банк дает взаймы 10 долларов на каждый доллар имеющихся средств. Банки на Уолл-стрит и прочие институты, похожие на банки, например, страховые компании, вытянули этот финансовый рычаг за пределы 10:1 и стали плясать на горящем канате под музыку 30:1 и даже больше. Не делайте так. Вместо этого вкладывайте в каждую просьбу о поддержке от клиента (неважно, сгенерированы ли они автоматически вашим приложением или присланы клиентами по электронной почте как раз перед тем, как вы собираетесь закончить рабочий день), рассматривая каждый запрос как две задачи, а не одну.

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

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

5. А теперь инвестируйте в инвестиции.

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

• Автоматизированное тестирование программ: Начинающие компании и независимые производители не уделяют должного внимания ни функциональному, ни комплексному тестированию, не говоря уже о разработке через тестирование или разработке через функционирование. Я знаю, потому что сам не уделял. Но чем больше у вас тестов, тем меньше ошибок находят клиенты. Каждый раз, когда вы исправляете код, напишите пару тестов, чтобы навсегда похоронить ошибку. Называйте это разработкой по принципу «ненавижу тестирование, но еще больше ненавижу ошибки». Просто помните, что чем меньше ошибок, тем меньше разгневанных клиентов. По мере накопления тестов, когда вы станете привыкать к тому, что тесты дают коду зеленый свет вместо красного, вы обратитесь к уже готовому набору тестов при добавлении очередной небольшой функции и поймете, что тестирование – это лучший друг для начинающей компании: гораздо более надежный, чем виртуальное сообщество, дающий гораздо больше контроля и денег.
• Лучше один раз увидеть, чем сто раз прочитать: В случае отвлеченных дефектов или мест, где пользователи просто что-то не понимают, как думаете, что будет более эффективным: еще 5 страниц документации, которую никто не будет читать или 30 секунд видео, на котором видно, что нужно делать? Первый такой ролик вы сделаете за пять часов, второй – за два, а третий – уже за 45 минут. Понятные видеозаписи экрана (не нужно спецэффектов как в «Звездных войнах», достаточно ролика на YouTube) могут стать простым способом объяснить, как работает приложение. Чем больше таких роликов вы сделаете, тем проще они будут получаться, тем меньше времени это будет занимать, и тем больше вы сможете их применять в качестве маркетинговых инструментов.
• Превращайте негатив в позитив: Вот вам простой способ превратить жалобу клиента в преимущество вашей программы: подождите неделю после решения проблемы и отошлите клиенту сообщение или электронную открытку: Уважаемый мистер X, просто хотел поинтересоваться неделю спустя, как идут дела. Как все работает? Может быть, возникли какие-то вопросы или пожелания? Спасибо, Подпись. И все, ничего тяжеловесного, сложного или похожего на маркетинг. Мы же небольшие компании, которые могут и должны (!) вести себя как люди, а не как большие корпорации!

Этот пост был написан по специальному соглашению с Avangate. Но я готов повторить то же самое при любых обстоятельствах.

Эта запись была сделана в Tuesday, February 17th, 2009 at 6:33 pm и находится в категории Партнерский маркетинг.
Можно отслеживать ответы на эту запись, используя RSS 2.0.
Можно Оставьте комментарий, или разместить trackback на вашем собственном сайте.