Эффективный B2B Маркетинг. Выход на рынок. 5 шагов по запуску продукта.
книга: Эффективный B2B Маркетинг
( оглавление тут)
( предыдущая глава тут)
ЧАСТЬ ДЕВЯТАЯ. ВЫХОД НА РЫНОК
ГЛАВА 1. ПЯТЬ ШАГОВ К ЗАПУСКУ НОВОГО ПРОГРАММНОГО ПРОДУКТА
Когда мы показали некоторым людям, занимающим ключевые должности в IT-компаниях, майнд-мэпы и слайды с тренинга по софтверному маркетингу, то услышали от них вопрос: «А что же конкретно делать? У меня есть новый продукт… Что же надо предпринять, чтобы его запустить?» Мы решили уделить этому вопросу внимание и помочь вам с пошаговым алгоритмом вывода нового продукта на рынок.
ШАГ 1. ПОДГОТОВКА К ПРОДАЖАМ
Недостаточная подготовка гарантирует неудачный запуск продукта. По этой причине время и ресурсы на подготовку жалеть нельзя. Начнем с продукта. Во-первых, продукт должен работать. Бета- или даже альфа-версию лучше всего даже не выпускать. Не стоит делать мануал на 4-х страницах о том, как его инсталлировать. Процесс установки должен быть максимально прост: нажать - нажать - нажать - запустить. Во-вторых, продукт должен делать то, для чего он предназначен. Если случилось так, что вы уже всем объявили, что он выйдет в определенный день, но пока программа не работает, предусмотрите быстрый и несложный механизм, как сделать к нему «патчи» и минимальными усилиями помочь вашим клиентам решить этот вопрос.
Красивый или ожидаемый интерфейс. На сегодняшний день корпорации Microsoft и Apple - два гиганта, которые продвигают свои интерфейсы. Помните, когда вышел Windows 95, половина пользователей ненавидели этот «квадратный» дизайн, а другая половина - просто плясала от счастья. Потом уже все к нему привыкли. Дальше с Windows Vista случилось то же самое. При выходе Microsoft Office 2007 многие пользователи не стали переходить на него именно из-за непонятного ribbon-интерфейса. Потом опять все к нему привыкли и теперь уже ожидают дальнейшего развития событий. Также можно привести пример iTunes. Более бестолкового интерфейса с проигрывателем музыки мы просто не встречали, но миллионы людей приобрели его, и компания Apple заставила их привыкнуть к нему. По этой причине не придумывайте ничего нового. Соответствуйте ожиданиям ваших клиентов.
Сказав «красивый», мы не имели в виду «вычурный». Речь идет о легкости и удобстве использования, сочетании цветов и прочих дизайнерских элементов, расположенных на страницах или экранах вашего программного продукта. А если у вас не хватает финансов или мощностей для того, чтобы предложить принципиально новый пользовательский интерфейс или чтобы заставить людей его принять, просто используйте классический интерфейс пользователя. Это позволит вам сначала заработать денег на продукте, а уже потом вы сможете подумать, нужен ли вам другой вариант оформления. С этой точки зрения, рекомендуем вам сообщество специалистов по UI (user interface) и UX (user experience). В России их несколько. Обращайтесь.
Минимальная функциональность. К примеру, молоток должен забивать гвозди, отвертка - закручивать шурупы. Если отвертка не закручивает шуруп - это уже серьезная проблема… Помните - вы делаете коммерческий продукт, на котором зарабатываете деньги. Вам не нужно реализовать абсолютно всю возможную функциональность. Учтите индикатор time-to-market. Первую версию вы должны выпустить на рынок максимально быстро, чтобы, обогнав конкурентов, получить прибыль, выпустить уже следующий релиз и добиться стабильной работы компании. Если вы опоздаете, никому уже не понадобятся ни вторая, ни третья версия вашей программы. Поэтому, с точки зрения time-to-market, реализуйте в своем продукте главную функциональность. Затем уже вы уже сможете добавить дополнительные функции и удовлетворить пожелания пользователей.
Тестирование. Если программа «падает» при случайном вводе каких-то чисел, это очень плохо. Должно быть проведено, по крайней мере, первое тестирование продукта. Существует огромное количество видов тестирования:
• внутреннее, проведенное своими сотрудниками,
• тестирование независимыми специалистами,
• тестирование пользователями, которые готовы провести проверку бета-версии продукта,
• функциональное и нефункциональное,
• тестирование производительности и так далее.
- масса различных вариантов, в зависимости от требований, предъявляемых к продукту. Выбирайте правильные методы тестирования и добивайтесь необходимого, минимально достаточного качества и работоспособности программного решения.
Ликвидация ошибок, критических для большинства ваших потенциальных пользователей. Если продукт, работающий, например, на Windows, поставить на Vmware, который «бежит» под FreeBSD, а там в VPN что-то не подсоединяется, - это не страшно, это не критическая ошибка. Ее обнаружит лишь небольшое количество пользователей. Но в основной функциональности критических ошибок быть не должно. Выявляйте наиболее важные, наиболее типичные сценарии использования вашей системы и убедитесь, что она работает надежно. Процесс, критически важный с точки зрения бизнеса вашего клиента, не должен вдруг «упасть» на девятом шаге из десяти и привести к краху всей системы и потере данных.
Наличие помощи в режиме онлайн. Клавишей F1 обязательно должна вызываться справка, в которой пользователь найдет информацию, что означают конкретные экраны, что необходимо делать дальше для получения конкретного результата, а также обозначения терминов. «Help» не должен быть очень объемным, но должен соответствовать основным пожеланиям пользователей, отвечать на основные вопросы.
Инсталлятор и деинсталлятор. Казалось бы, тут все понятно, однако существуют некоторые продукты, инсталлятор которых пишется в самом начале. Потом продукт меняет функциональность, в него добавляются компоненты, а установщик не меняется. Он пропускает некоторые компоненты, и они не запускаются на отдельных компьютерах. Убедитесь в том, что инсталлятор и деинсталлятор работают правильно и не оставляют за собой лишних «следов».
Процесс поддержки - еще одна важная составляющая готовности продукта к старту продаж. С первого же дня, когда вы запустили продукт, ваши специалисты, осуществляющие поддержку, должны быть обучены поддерживать именно эту версию. Следует не просто предоставить им материалы, а провести по ним полноценные курсы. Более того, необходимо обучить техподдержку пользоваться самим инструментом, дать им поработать в этой программе, чтобы они почувствовали ее и, может быть, даже до автоматизма отработали некоторые наиболее критические аспекты функциональности. Это позволит максимально быстро и правильно отвечать на запросы клиентов. Лучше всего разбейтесь на группы, поделитесь на роли и отработайте типовые вопросы и ответы клиентов, чтобы у них был навык правильной реакции на звонки пользователей по типовым сценариям до запуска продукта. При этом вы должны подсказать, какие звонки ожидаются наиболее часто и какая функциональность наиболее критична с точки зрения поддержки, потому что, если они будут играть в эту ролевую игру в отношении неглавных функций, то результативность такого обучения будет минимальной.
FAQ. Список наиболее часто задаваемых вопросов также необходим. Откуда вы можете взять его, пока еще не выпустили продукт и им не начали пользоваться клиенты? Его позволит сформировать бета-тестирование вашего продукта, когда вы привлечете волонтеров из числа потенциальных клиентов и позволите им поработать с программой. На основе такого исследования вы сформируете рейтинг основных вопросов в FAQ. Разумеется, у вас должен быть и список правильных и проверенных ответов на эти вопросы. Обратите внимание, что после запуска продукта FAQ не должен оставаться в исходной версии. Его следует постоянно модифицировать, отталкиваясь от актуальных обращений пользователей.
Обучающее видео. Запишите видео, в котором рассказывается:
• как инсталлировать продукт,
• как с ним работать,
• как вводить новые данные,
• как делать и печатать отчеты,
• как передавать данные из одной системы в другую и так далее.
Основной функционал у вас должен быть «покрыт» видеороликами, уже готовыми к публикации на сайте в разделе технической поддержки. Это позволит снизить первоначальный поток звонков от клиентов.
Система регистрации заявок и проблем. Если в вашей компании эта система еще по какой-то причине не разработана, и вы работаете «по старинке», принимая бесконтрольные звонки или письма от пользователей вашего продукта и полагая, что у вас построена система поддержки, это не так. Уже сейчас, до запуска вашего продукта, подумайте, с помощью каких инструментов вы сможете реализовать эту систему, если ее нет. Существует масса недорогих и популярных систем. Некоторые компании для работы с заявками используют Backtracking, другие - Ticketing, в зависимости от их требований. Но запомните, что вы не должны начать пользоваться новой системой регистрации заявок одновременно с запуском нового продукта. Вам будет необходим опыт работы с этой системой: вся компания должна уметь с ней обращаться. Если у вас уже есть такая система, убедитесь, что вы сможете отделять заявки и проблемы, связанные с новой версией продукта, и сортировать, фильтровать и анализировать эти заявки.
Коммуникации между службой поддержки и разработчиками продукта. Их также стоит наладить с самого начала. Специалистам по поддержке будет необходим механизм быстрого предоставления разработчикам обратной информации о неполадках работы продукта и необходимости выпускать «фиксы» и «патчи».
Коммуникации между службой поддержки и тестировщиками. Если появились сигналы от клиентов о каких-либо неполадках, тестировщики должны поработать с этой проблемой и убедиться в том, что она выявлена и понятна, а также есть ли какие-нибудь дополнительные трудности, связанные с данным функционалом.
Связь между техподдержкой и техническими писателями. И те, и другие должны быть вовлечены в процесс пост-релизных модификаций системы, например, исправления ошибок или внесения изменений в базовой функциональности. Также в их компетенции - оперативные исправления в документации продукта.
Связь между поддержкой и отделом продаж. Это очень важно! Налаженная связь позволит продавцам понять, что происходит с вашим продуктом, каковы наиболее типичные или наиболее редкие проблемы, выявленные специалистами, а также поможет найти правильные ответы и механизмы смягчения конфликтов с пользователями.
Возможность эскалации техподдержки на менеджмент компании для решения наиболее острых и проблемных аспектов. Если служба поддержки имеет возможность повлиять на решение важных проблем, придавая ему необходимую силу и оперативность, это отлично.
НА ПОДСТУПАХ К ПРОДАЖАМ
Во-первых, ваша CRM-система должна быть готова поддерживать соответствующие запросы, обращения и отражать, с точки зрения ваших контактов и коммуникаций с клиентами, заявки, проблемы и тому подобное. Речь идет не столько о трудностях технического уровня, сколько о возникающих или возможных коммуникациях между account-менеджером с вашей стороны и представителями клиента. CRM должен быть определенным образом модифицирован. Может быть, необходимо добавить какие-то поля или договориться, какие из уже существующих вы используете для фиксирования коммуникаций и отношений с клиентом в контексте данного продукта или данной версии. Это крайне важно для того, чтобы в ближайшее время можно было проводить выборку и аналитику контактов. Желательно установить многоканальный телефон, ведь люди будут звонить не только в техподдержку, но и продавцам, чтобы те могли рассказать о проблемах, которые могут возникнуть при использовании продукта. Также неплохо иметь готовый механизм записи входящих звонков, чтобы контролировать эффективность поддержки и процесса продаж. Это делается не только для того, чтобы принять управленческие решения о вручении премий или наказаниях, но и затем, чтобы регулярно проигрывать с менеджерами и продавцами их разговоры, улучшать их и разбирать, а также менять скрипт для оптимизации заключения сделок. Если телефоны ваших продавцов заняты, возможно, имеет смысл организовать отдельную линию для обращений на тему только что выпущенного продукта. Несмотря на то, что продавцы будут говорить: «Нам не обязательно знать технические свойства продукта», - они должны понимать, как работает программа. С одной стороны, они должны понимать, что именно интересует и волнует клиента, но при запуске нового продукта или релиза клиент непременно будет задавать вашим продавцам вопросы, связанные с функциональностью программного решения. Если продавец не сможет квалифицированно ответить на эти вопросы, ваш рейтинг понизится и отношения с клиентами ухудшатся. Необходимо не только объяснить продавцам, что делать, но и заставить их включить клиента в диалог для выяснения необходимых дополнений, правок продукта и изменений скрипта с целью улучшения результатов.
ЧЕКЛИСТ ГОТОВНОСТИ ПРОДУКТА С ТОЧКИ ЗРЕНИЯ ЗАПУСКА ПРОЦЕССА МАРКЕТИНГА
Маркетинговые материалы. Приведем список материалов, минимально необходимых для запуска нового продукта. Разумеется, существуют и дополнительные материалы, но пока поговорим про простейший набор, который должен быть готов уже на старте.
1. Корпоративная брошюра. Она необходима потому, что при запуске нового продукта вы имеете возможность выйти на соответствующих лиц, принимающих решения, которым не столько важны тонкости вопроса о работе с программным решением, сколько взаимодействие с вашей компанией в целом. По этой причине корпоративная брошюра обязательна для «высоких начальников». Может сложиться ситуация, когда вашим продуктом пользуется один отдел какой-нибудь большой корпорации, а для всех остальных отделов и директоров брошюра будет иметь очень большое значение с точки зрения пиара.
2. Брошюра продукта. Так как вы выпускаете новый релиз или новый продукт, вы должны кратко и очень привлекательно описать его, указав, для решения каких проблем он предназначен, каковы его особенности, основная функциональность, технологические преимущества, включая красивые скриншоты работы. Также желательны не только описания различных ситуаций, но и отзывы клиентов, которые повествуют о том, что они сделали. Если вы не можете предоставить ни историй, ни отзывов, если это вообще новая тема для вашей компании, можете использовать отзывы о компании и техподдержке в целом.
3. Готовность к подготовке специальных предложений. В различных ситуациях, когда продажи нового продукта «не пошли» или, наоборот, для усиления продаж, когда вам нужно добиться лавины первых пользователей продукта, вы выпускаете специальные предложения. Тут вариантов очень много - например, предложение бесплатного апгрейда до второй версии тем, кто купил первую версию, бесплатная техподдержка в течение года, бесплатный выезд специалистов в компании, купившие 500 лицензий, и так далее. Такие предложения не должны быть сумбурными. Необходимо разработать, как минимум, три варианта, которые работали бы в различных направлениях. Используйте их в своих маркетинговых материалах. Лучше всего разработать datasheet по каждому предложению, в котором указать, что это и кому это нужно. Такие данные должны быть у вас под рукой, чтобы вы знали, как ими пользоваться.
Необходимо также помнить, что специальные предложения могут спасти ваш релиз или продукт, если продажи пошли не так, как вы надеялись. В таком случае специальное предложение может активизировать угасающий или нечеткий спрос и поднять его до нужного вам уровня.
Разумеется, маркетологи должны иметь доступ к CRM, чтобы четко отслеживать ситуации, происходящие в отношениях с клиентами в связи с запуском нового продукта.
4. Готовность компании с точки зрения процесса внедрения. Естественно, если ваш продукт не просто инсталлируется на компьютер самим клиентом или его IT-специалистами, если для его внедрения требуется ваше присутствие, у вас должен быть соответствующим образом обученный персонал. Его задача - принимать непосредственное участие в разработке и проектировании продукта. Это носители важной внутренней информации, которая поможет специалистам решать вопросы внедрения и проблемы тут же на месте - на территории клиента. Так как представители группы внедрения будут работать у заказчика, у них будет доступ к ресурсам, которые айтишники вашего клиента им дали с точки зрения безопасности. Однако, если у вас нет удаленного доступа к компьютеру или серверу клиента, вы сильно рискуете. Вам придется договариваться с заказчиком о том, что вам потребуется этот доступ для специалистов, которые находятся у вас и активно участвуют в процессе внедрения и решения проблем. Инструменты удаленного доступа крайне важны, их необходимо подготовить не только к запуску нового продукта, но и к работе с существующими клиентами, у которых возникли проблемы. Основной инструмент, которым пользуются многие компании, - это Teamviewer. Из коммерческих продуктов мы используем GoToAssist, GoToWebinar, а также хороший сервис есть у LogMeIn и Joel Spolsky, - это легенда софт-девелопмента и софт-маркетинга, он называется Copilot и является относительно недорогим. Его можно использовать, чтобы обходить все VPN, «шлюзы», прокси-серверы, файерволлы, чтобы среднестатистический пользователь (и бухгалтер, и секретарь) мог кликнуть на нужный линк и открыть вам доступ к их компьютеру без конфигураций со стороны администраторов. В простейшем варианте работает Skype. Radmin - также неплохие утилиты, но свои недостатки в них есть. Люди, которые только пробуют работать с вашими программами, не хотят давать вам постоянный доступ в свою сеть. Например, Teamviewer в бесплатном варианте для некоммерческого использования позволяет, запуская один и тот же файл на обеих сторонах, подключиться им друг к другу. По этим причинам всегда договаривайтесь с клиентом, какие инструменты они, собственно, могут разрешить вам применять. Тем не менее, наличие утилиты для удаленного доступа критически важно для решения вопросов внедрения и пост-релиз поддержки. Понятно, что конфигурация компьютера клиента может радикально отличаться от той, на которой вы тестировали свой продукт, и возможность разобраться в том, что происходит, - это очень важно.
5. План внедрения. Без него работа будет сильно осложнена. Почему-то многие компании думают, что, раз у них есть специалисты, они сейчас же во всем разберутся. Но, как профессионалы, вы должны не только иметь план внедрения, но и согласовать его с клиентом и его представителями (начиная с сотрудников отдела безопасности, отдела работы с клиентом и различных бизнес-структур, принимающих решения об использовании вашего продукта) таким образом, чтобы план внедрения не оказался чем-то необычным с точки зрения заказчика. Так же, как и вы, он должен быть готов к внедрению и обеспечить его процесс необходимыми ресурсами. Иногда придется поработать на выходных или в двух приложениях одновременно. Все эти вопросы вы должны заранее обсудить с клиентом и иметь четкий план внедрения.
6. Система эскалации, отчетности и контроля. Это крайне важные элементы системы внедрения, потому что многие вопросы выходят за рамки зоны ответственности пользователей, с которыми вы общаетесь или даже IT-специалистов. Поэтому вам необходима четкая система эскалации, чтобы вы знали, к кому необходимо обращаться для оперативного решения конкретных вопросов или конфликтных ситуаций. Вы должны знать, как проходит процесс внедрения, как действует ваша группа специалистов, насколько четко и оперативно она решает проблемы и взаимодействует с клиентом, чтобы, во-первых, все прошло гладко, а во-вторых, вы могли успешно использовать накопленный опыт в работе с другими клиентами при внедрении следующих версий продукта.
Процесс внедрения должен быть разработан заранее, то есть необходимы люди, которые будут внедрять этот продукт, и у них не должно быть вопросов после продажи. Уделите этому процессу максимально возможное внимание. При наличии правильных специалистов поток новых клиентов и контрактов будет только увеличиваться.
ШАГ 2. ПЛАН ЗАПУСКА ПРОДУКТА С ТОЧКИ ЗРЕНИЯ МАРКЕТИНГА
(продолжение следует)
Удачи!
( оглавление тут)
( предыдущая глава тут)
ЧАСТЬ ДЕВЯТАЯ. ВЫХОД НА РЫНОК
ГЛАВА 1. ПЯТЬ ШАГОВ К ЗАПУСКУ НОВОГО ПРОГРАММНОГО ПРОДУКТА
Когда мы показали некоторым людям, занимающим ключевые должности в IT-компаниях, майнд-мэпы и слайды с тренинга по софтверному маркетингу, то услышали от них вопрос: «А что же конкретно делать? У меня есть новый продукт… Что же надо предпринять, чтобы его запустить?» Мы решили уделить этому вопросу внимание и помочь вам с пошаговым алгоритмом вывода нового продукта на рынок.
ШАГ 1. ПОДГОТОВКА К ПРОДАЖАМ
Недостаточная подготовка гарантирует неудачный запуск продукта. По этой причине время и ресурсы на подготовку жалеть нельзя. Начнем с продукта. Во-первых, продукт должен работать. Бета- или даже альфа-версию лучше всего даже не выпускать. Не стоит делать мануал на 4-х страницах о том, как его инсталлировать. Процесс установки должен быть максимально прост: нажать - нажать - нажать - запустить. Во-вторых, продукт должен делать то, для чего он предназначен. Если случилось так, что вы уже всем объявили, что он выйдет в определенный день, но пока программа не работает, предусмотрите быстрый и несложный механизм, как сделать к нему «патчи» и минимальными усилиями помочь вашим клиентам решить этот вопрос.
Красивый или ожидаемый интерфейс. На сегодняшний день корпорации Microsoft и Apple - два гиганта, которые продвигают свои интерфейсы. Помните, когда вышел Windows 95, половина пользователей ненавидели этот «квадратный» дизайн, а другая половина - просто плясала от счастья. Потом уже все к нему привыкли. Дальше с Windows Vista случилось то же самое. При выходе Microsoft Office 2007 многие пользователи не стали переходить на него именно из-за непонятного ribbon-интерфейса. Потом опять все к нему привыкли и теперь уже ожидают дальнейшего развития событий. Также можно привести пример iTunes. Более бестолкового интерфейса с проигрывателем музыки мы просто не встречали, но миллионы людей приобрели его, и компания Apple заставила их привыкнуть к нему. По этой причине не придумывайте ничего нового. Соответствуйте ожиданиям ваших клиентов.
Сказав «красивый», мы не имели в виду «вычурный». Речь идет о легкости и удобстве использования, сочетании цветов и прочих дизайнерских элементов, расположенных на страницах или экранах вашего программного продукта. А если у вас не хватает финансов или мощностей для того, чтобы предложить принципиально новый пользовательский интерфейс или чтобы заставить людей его принять, просто используйте классический интерфейс пользователя. Это позволит вам сначала заработать денег на продукте, а уже потом вы сможете подумать, нужен ли вам другой вариант оформления. С этой точки зрения, рекомендуем вам сообщество специалистов по UI (user interface) и UX (user experience). В России их несколько. Обращайтесь.
Минимальная функциональность. К примеру, молоток должен забивать гвозди, отвертка - закручивать шурупы. Если отвертка не закручивает шуруп - это уже серьезная проблема… Помните - вы делаете коммерческий продукт, на котором зарабатываете деньги. Вам не нужно реализовать абсолютно всю возможную функциональность. Учтите индикатор time-to-market. Первую версию вы должны выпустить на рынок максимально быстро, чтобы, обогнав конкурентов, получить прибыль, выпустить уже следующий релиз и добиться стабильной работы компании. Если вы опоздаете, никому уже не понадобятся ни вторая, ни третья версия вашей программы. Поэтому, с точки зрения time-to-market, реализуйте в своем продукте главную функциональность. Затем уже вы уже сможете добавить дополнительные функции и удовлетворить пожелания пользователей.
Тестирование. Если программа «падает» при случайном вводе каких-то чисел, это очень плохо. Должно быть проведено, по крайней мере, первое тестирование продукта. Существует огромное количество видов тестирования:
• внутреннее, проведенное своими сотрудниками,
• тестирование независимыми специалистами,
• тестирование пользователями, которые готовы провести проверку бета-версии продукта,
• функциональное и нефункциональное,
• тестирование производительности и так далее.
- масса различных вариантов, в зависимости от требований, предъявляемых к продукту. Выбирайте правильные методы тестирования и добивайтесь необходимого, минимально достаточного качества и работоспособности программного решения.
Ликвидация ошибок, критических для большинства ваших потенциальных пользователей. Если продукт, работающий, например, на Windows, поставить на Vmware, который «бежит» под FreeBSD, а там в VPN что-то не подсоединяется, - это не страшно, это не критическая ошибка. Ее обнаружит лишь небольшое количество пользователей. Но в основной функциональности критических ошибок быть не должно. Выявляйте наиболее важные, наиболее типичные сценарии использования вашей системы и убедитесь, что она работает надежно. Процесс, критически важный с точки зрения бизнеса вашего клиента, не должен вдруг «упасть» на девятом шаге из десяти и привести к краху всей системы и потере данных.
Наличие помощи в режиме онлайн. Клавишей F1 обязательно должна вызываться справка, в которой пользователь найдет информацию, что означают конкретные экраны, что необходимо делать дальше для получения конкретного результата, а также обозначения терминов. «Help» не должен быть очень объемным, но должен соответствовать основным пожеланиям пользователей, отвечать на основные вопросы.
Инсталлятор и деинсталлятор. Казалось бы, тут все понятно, однако существуют некоторые продукты, инсталлятор которых пишется в самом начале. Потом продукт меняет функциональность, в него добавляются компоненты, а установщик не меняется. Он пропускает некоторые компоненты, и они не запускаются на отдельных компьютерах. Убедитесь в том, что инсталлятор и деинсталлятор работают правильно и не оставляют за собой лишних «следов».
Процесс поддержки - еще одна важная составляющая готовности продукта к старту продаж. С первого же дня, когда вы запустили продукт, ваши специалисты, осуществляющие поддержку, должны быть обучены поддерживать именно эту версию. Следует не просто предоставить им материалы, а провести по ним полноценные курсы. Более того, необходимо обучить техподдержку пользоваться самим инструментом, дать им поработать в этой программе, чтобы они почувствовали ее и, может быть, даже до автоматизма отработали некоторые наиболее критические аспекты функциональности. Это позволит максимально быстро и правильно отвечать на запросы клиентов. Лучше всего разбейтесь на группы, поделитесь на роли и отработайте типовые вопросы и ответы клиентов, чтобы у них был навык правильной реакции на звонки пользователей по типовым сценариям до запуска продукта. При этом вы должны подсказать, какие звонки ожидаются наиболее часто и какая функциональность наиболее критична с точки зрения поддержки, потому что, если они будут играть в эту ролевую игру в отношении неглавных функций, то результативность такого обучения будет минимальной.
FAQ. Список наиболее часто задаваемых вопросов также необходим. Откуда вы можете взять его, пока еще не выпустили продукт и им не начали пользоваться клиенты? Его позволит сформировать бета-тестирование вашего продукта, когда вы привлечете волонтеров из числа потенциальных клиентов и позволите им поработать с программой. На основе такого исследования вы сформируете рейтинг основных вопросов в FAQ. Разумеется, у вас должен быть и список правильных и проверенных ответов на эти вопросы. Обратите внимание, что после запуска продукта FAQ не должен оставаться в исходной версии. Его следует постоянно модифицировать, отталкиваясь от актуальных обращений пользователей.
Обучающее видео. Запишите видео, в котором рассказывается:
• как инсталлировать продукт,
• как с ним работать,
• как вводить новые данные,
• как делать и печатать отчеты,
• как передавать данные из одной системы в другую и так далее.
Основной функционал у вас должен быть «покрыт» видеороликами, уже готовыми к публикации на сайте в разделе технической поддержки. Это позволит снизить первоначальный поток звонков от клиентов.
Система регистрации заявок и проблем. Если в вашей компании эта система еще по какой-то причине не разработана, и вы работаете «по старинке», принимая бесконтрольные звонки или письма от пользователей вашего продукта и полагая, что у вас построена система поддержки, это не так. Уже сейчас, до запуска вашего продукта, подумайте, с помощью каких инструментов вы сможете реализовать эту систему, если ее нет. Существует масса недорогих и популярных систем. Некоторые компании для работы с заявками используют Backtracking, другие - Ticketing, в зависимости от их требований. Но запомните, что вы не должны начать пользоваться новой системой регистрации заявок одновременно с запуском нового продукта. Вам будет необходим опыт работы с этой системой: вся компания должна уметь с ней обращаться. Если у вас уже есть такая система, убедитесь, что вы сможете отделять заявки и проблемы, связанные с новой версией продукта, и сортировать, фильтровать и анализировать эти заявки.
Коммуникации между службой поддержки и разработчиками продукта. Их также стоит наладить с самого начала. Специалистам по поддержке будет необходим механизм быстрого предоставления разработчикам обратной информации о неполадках работы продукта и необходимости выпускать «фиксы» и «патчи».
Коммуникации между службой поддержки и тестировщиками. Если появились сигналы от клиентов о каких-либо неполадках, тестировщики должны поработать с этой проблемой и убедиться в том, что она выявлена и понятна, а также есть ли какие-нибудь дополнительные трудности, связанные с данным функционалом.
Связь между техподдержкой и техническими писателями. И те, и другие должны быть вовлечены в процесс пост-релизных модификаций системы, например, исправления ошибок или внесения изменений в базовой функциональности. Также в их компетенции - оперативные исправления в документации продукта.
Связь между поддержкой и отделом продаж. Это очень важно! Налаженная связь позволит продавцам понять, что происходит с вашим продуктом, каковы наиболее типичные или наиболее редкие проблемы, выявленные специалистами, а также поможет найти правильные ответы и механизмы смягчения конфликтов с пользователями.
Возможность эскалации техподдержки на менеджмент компании для решения наиболее острых и проблемных аспектов. Если служба поддержки имеет возможность повлиять на решение важных проблем, придавая ему необходимую силу и оперативность, это отлично.
НА ПОДСТУПАХ К ПРОДАЖАМ
Во-первых, ваша CRM-система должна быть готова поддерживать соответствующие запросы, обращения и отражать, с точки зрения ваших контактов и коммуникаций с клиентами, заявки, проблемы и тому подобное. Речь идет не столько о трудностях технического уровня, сколько о возникающих или возможных коммуникациях между account-менеджером с вашей стороны и представителями клиента. CRM должен быть определенным образом модифицирован. Может быть, необходимо добавить какие-то поля или договориться, какие из уже существующих вы используете для фиксирования коммуникаций и отношений с клиентом в контексте данного продукта или данной версии. Это крайне важно для того, чтобы в ближайшее время можно было проводить выборку и аналитику контактов. Желательно установить многоканальный телефон, ведь люди будут звонить не только в техподдержку, но и продавцам, чтобы те могли рассказать о проблемах, которые могут возникнуть при использовании продукта. Также неплохо иметь готовый механизм записи входящих звонков, чтобы контролировать эффективность поддержки и процесса продаж. Это делается не только для того, чтобы принять управленческие решения о вручении премий или наказаниях, но и затем, чтобы регулярно проигрывать с менеджерами и продавцами их разговоры, улучшать их и разбирать, а также менять скрипт для оптимизации заключения сделок. Если телефоны ваших продавцов заняты, возможно, имеет смысл организовать отдельную линию для обращений на тему только что выпущенного продукта. Несмотря на то, что продавцы будут говорить: «Нам не обязательно знать технические свойства продукта», - они должны понимать, как работает программа. С одной стороны, они должны понимать, что именно интересует и волнует клиента, но при запуске нового продукта или релиза клиент непременно будет задавать вашим продавцам вопросы, связанные с функциональностью программного решения. Если продавец не сможет квалифицированно ответить на эти вопросы, ваш рейтинг понизится и отношения с клиентами ухудшатся. Необходимо не только объяснить продавцам, что делать, но и заставить их включить клиента в диалог для выяснения необходимых дополнений, правок продукта и изменений скрипта с целью улучшения результатов.
ЧЕКЛИСТ ГОТОВНОСТИ ПРОДУКТА С ТОЧКИ ЗРЕНИЯ ЗАПУСКА ПРОЦЕССА МАРКЕТИНГА
Маркетинговые материалы. Приведем список материалов, минимально необходимых для запуска нового продукта. Разумеется, существуют и дополнительные материалы, но пока поговорим про простейший набор, который должен быть готов уже на старте.
1. Корпоративная брошюра. Она необходима потому, что при запуске нового продукта вы имеете возможность выйти на соответствующих лиц, принимающих решения, которым не столько важны тонкости вопроса о работе с программным решением, сколько взаимодействие с вашей компанией в целом. По этой причине корпоративная брошюра обязательна для «высоких начальников». Может сложиться ситуация, когда вашим продуктом пользуется один отдел какой-нибудь большой корпорации, а для всех остальных отделов и директоров брошюра будет иметь очень большое значение с точки зрения пиара.
2. Брошюра продукта. Так как вы выпускаете новый релиз или новый продукт, вы должны кратко и очень привлекательно описать его, указав, для решения каких проблем он предназначен, каковы его особенности, основная функциональность, технологические преимущества, включая красивые скриншоты работы. Также желательны не только описания различных ситуаций, но и отзывы клиентов, которые повествуют о том, что они сделали. Если вы не можете предоставить ни историй, ни отзывов, если это вообще новая тема для вашей компании, можете использовать отзывы о компании и техподдержке в целом.
3. Готовность к подготовке специальных предложений. В различных ситуациях, когда продажи нового продукта «не пошли» или, наоборот, для усиления продаж, когда вам нужно добиться лавины первых пользователей продукта, вы выпускаете специальные предложения. Тут вариантов очень много - например, предложение бесплатного апгрейда до второй версии тем, кто купил первую версию, бесплатная техподдержка в течение года, бесплатный выезд специалистов в компании, купившие 500 лицензий, и так далее. Такие предложения не должны быть сумбурными. Необходимо разработать, как минимум, три варианта, которые работали бы в различных направлениях. Используйте их в своих маркетинговых материалах. Лучше всего разработать datasheet по каждому предложению, в котором указать, что это и кому это нужно. Такие данные должны быть у вас под рукой, чтобы вы знали, как ими пользоваться.
Необходимо также помнить, что специальные предложения могут спасти ваш релиз или продукт, если продажи пошли не так, как вы надеялись. В таком случае специальное предложение может активизировать угасающий или нечеткий спрос и поднять его до нужного вам уровня.
Разумеется, маркетологи должны иметь доступ к CRM, чтобы четко отслеживать ситуации, происходящие в отношениях с клиентами в связи с запуском нового продукта.
4. Готовность компании с точки зрения процесса внедрения. Естественно, если ваш продукт не просто инсталлируется на компьютер самим клиентом или его IT-специалистами, если для его внедрения требуется ваше присутствие, у вас должен быть соответствующим образом обученный персонал. Его задача - принимать непосредственное участие в разработке и проектировании продукта. Это носители важной внутренней информации, которая поможет специалистам решать вопросы внедрения и проблемы тут же на месте - на территории клиента. Так как представители группы внедрения будут работать у заказчика, у них будет доступ к ресурсам, которые айтишники вашего клиента им дали с точки зрения безопасности. Однако, если у вас нет удаленного доступа к компьютеру или серверу клиента, вы сильно рискуете. Вам придется договариваться с заказчиком о том, что вам потребуется этот доступ для специалистов, которые находятся у вас и активно участвуют в процессе внедрения и решения проблем. Инструменты удаленного доступа крайне важны, их необходимо подготовить не только к запуску нового продукта, но и к работе с существующими клиентами, у которых возникли проблемы. Основной инструмент, которым пользуются многие компании, - это Teamviewer. Из коммерческих продуктов мы используем GoToAssist, GoToWebinar, а также хороший сервис есть у LogMeIn и Joel Spolsky, - это легенда софт-девелопмента и софт-маркетинга, он называется Copilot и является относительно недорогим. Его можно использовать, чтобы обходить все VPN, «шлюзы», прокси-серверы, файерволлы, чтобы среднестатистический пользователь (и бухгалтер, и секретарь) мог кликнуть на нужный линк и открыть вам доступ к их компьютеру без конфигураций со стороны администраторов. В простейшем варианте работает Skype. Radmin - также неплохие утилиты, но свои недостатки в них есть. Люди, которые только пробуют работать с вашими программами, не хотят давать вам постоянный доступ в свою сеть. Например, Teamviewer в бесплатном варианте для некоммерческого использования позволяет, запуская один и тот же файл на обеих сторонах, подключиться им друг к другу. По этим причинам всегда договаривайтесь с клиентом, какие инструменты они, собственно, могут разрешить вам применять. Тем не менее, наличие утилиты для удаленного доступа критически важно для решения вопросов внедрения и пост-релиз поддержки. Понятно, что конфигурация компьютера клиента может радикально отличаться от той, на которой вы тестировали свой продукт, и возможность разобраться в том, что происходит, - это очень важно.
5. План внедрения. Без него работа будет сильно осложнена. Почему-то многие компании думают, что, раз у них есть специалисты, они сейчас же во всем разберутся. Но, как профессионалы, вы должны не только иметь план внедрения, но и согласовать его с клиентом и его представителями (начиная с сотрудников отдела безопасности, отдела работы с клиентом и различных бизнес-структур, принимающих решения об использовании вашего продукта) таким образом, чтобы план внедрения не оказался чем-то необычным с точки зрения заказчика. Так же, как и вы, он должен быть готов к внедрению и обеспечить его процесс необходимыми ресурсами. Иногда придется поработать на выходных или в двух приложениях одновременно. Все эти вопросы вы должны заранее обсудить с клиентом и иметь четкий план внедрения.
6. Система эскалации, отчетности и контроля. Это крайне важные элементы системы внедрения, потому что многие вопросы выходят за рамки зоны ответственности пользователей, с которыми вы общаетесь или даже IT-специалистов. Поэтому вам необходима четкая система эскалации, чтобы вы знали, к кому необходимо обращаться для оперативного решения конкретных вопросов или конфликтных ситуаций. Вы должны знать, как проходит процесс внедрения, как действует ваша группа специалистов, насколько четко и оперативно она решает проблемы и взаимодействует с клиентом, чтобы, во-первых, все прошло гладко, а во-вторых, вы могли успешно использовать накопленный опыт в работе с другими клиентами при внедрении следующих версий продукта.
Процесс внедрения должен быть разработан заранее, то есть необходимы люди, которые будут внедрять этот продукт, и у них не должно быть вопросов после продажи. Уделите этому процессу максимально возможное внимание. При наличии правильных специалистов поток новых клиентов и контрактов будет только увеличиваться.
ШАГ 2. ПЛАН ЗАПУСКА ПРОДУКТА С ТОЧКИ ЗРЕНИЯ МАРКЕТИНГА
(продолжение следует)
Удачи!