Страница 35 из 36
Однако вначале мы сосредоточимся на действиях отдела продаж. При желании приобрести продукт клиент вступает в контакт с менеджером по продажам Последний выясняет, что хочет приобрести клиент, при необходимости проводит презентации и объясняет преимущество того или иного продукта. Все контакты с клиентом заносятся в систему в виде активностей, таким образом, в любой момент можно узнать, как ведется работа (рис. 16 — Регистрация активностей при контакте с клиентом).
Важным достоинством этой модели продаж является возможность разделить продажу по отдельным логическим этапам, что позволяет четко определять границу работы и спрогнозировать будущий доход от той или иной сделки (рис. 17 — Логические этапы продаж).
В результате работы с клиентом на той или иной стадии клиент или решает купить продукт, или отказывается от него. В случае отказа в систему вносится пометка о причине отказа. При необходимости вносится напоминание для возобновления работы с бизнес-партнером через какой-то период времени. В случае успеха в систему вносится документ предложения, который инициирует процесс самой продажи.
Автоматизация рабочих мест сотрудников отдела продаж, конечно, важное дело. Теперь они в состоянии быстро восстановить всю историю отношений с заказчиком: легко найти контактные данные или по имени человека быстро вспомнить его должность и историю отношений именно с ним. Но не менее полезна информатизация этой деятельности для руководства. Трудно переоценить возможность практически мгновенно составлять отчеты по всем аспектам деятельности. Например, начальник отдела продаж может в режиме реального времени вести мониторинг активностей по тому или иному менеджеру, что позволяет постоянно быть в курсе дел и деятельности сотрудников. На рис. 18 выделена бизнес-часть блок-схемы продаж, включая анализ деятельности сотрудников и финансовое планирование.
Рис. 18. Оформление продаж и возможности руководителя в системе SAP Business One
Как это выглядит на практике? Анализ реализованных и упущенных возможностей позволяет оптимизировать процесс продажи и учесть ранее накопленный опыт (рис. 19 — Мониторинг активности деятельности менеджера по продажам).
Помимо этого, отчеты по деятельности отдельных менеджеров позволяют разработать справедливую систему оценки деятельности работников Причем можно понять, на каком этапе общения с потенциальным клиентом возникли основные проблемы у данного конкретного работника, и подкорректировать его работу (рис. 20 — Анализ деятельности менеджера по продажам).
В «Эксперт Системс» для каждого продавца существует план и KPI — Key Performance Indicator. Не останавливаясь на описании этого показателя, просто отметим, что это некоторые показатели, которые считаются важными для его работы. В простейшем случае это выполнение плана, но могут быть и более сложные показатели, например сделать клиентами компании 50 новых компаний в месяц или продавать более 20% сервиса.
Для создания отчетов о выполнении таких показателей администратор системы пишет довольно простые запросы, результаты которых доступны пользователям и позволяют более динамично и адресно управлять персоналом.
«Автоматически генерируемые отчеты избавляют меня от необходимости отвлекаться по мелочам и писать постоянные отчеты. Мой руководитель всегда знает, сколько звонков я сделал, сколько клиентов у меня на очереди, какие успехи в продажах, как это соотносится с планом».
Начальнику финансового отдела предварительная оценка предполагаемого дохода от той или иной сделки позволяет прогнозировать объем денежных поступлений, планировать финансовую деятельность и отслеживать план с фактом для дальнейшего анализа (рис. 21 - Общий план поступления денежных средств по сотрудникам компании; и 22 — Детальная расшифровка финансовых аспектов работы менеджеров по продажам).
Вернемся к вопросу действий консультантов при обслуживании клиентов компании. За эту работу отвечает модуль «Сервис».
Рассказывает менеджер по технической поддержке «Эксперт Системс»:
«У нас у каждого продукта есть серийный номер по которому однозначно идентифицируется клиент. Когда я получаю телефонный звонок с просьбой о технической поддержке, то я первым делом ввожу сообщенный мне серийный номер продукта. Смотрю информацию о клиенте. Ввожу сервисную заявку, название которой отражает суть проблемы.
Если у позвонившего нет серийного номера, то существует несколько вариантов. Допустим, что он является легальным пользователем, но потерял этот номер. Тогда возможен поиск по косвенным признакам — имени партнера, продавшего ему этот продукт, и тому подобное.
Если он „пират“, то мы отказываем ему в поддержке. Впрочем, если он настроен лояльно, то его можно перевести в отдел продаж, для покупки лицензионной версии.
Для нас принципиально ответить клиенту сразу же, решить его проблему и закрыть сервисную заявку. Если же решение не найдено, то заявка остается открытой и висит на нас. Я вижу все заявки, которые не были закрыты, и связанную с ними активность. Если заявка висит долго, то на ней собирается большое количество активностей — попробовать это, запросить то... и так далее».
Таким образом, в основе идентификации пользователя консультантом лежит тот факт, что каждому проданному программному продукту присваивается регистрационный номер и автоматически создается карта учета объекта сервиса, в которой по регистрационному номеру можно узнать информацию о проданном продукте и о покупателе (рис. 23 — Карта учета объектов сервиса).
Но того факта, что этот продукт куплен легально и пользователь зарегистрирован в базе данных, недостаточно для обслуживания клиента. При покупке сопровождения программного продукта в систему вносится сервисный договор, в котором определяются рамки действия договора по сопровождению (рис. 24 — Сервисный договор).
При обращении клиента с вопросом консультант прежде всего выясняет регистрационный номер программного продукта, по которому ищет в системе покупателя и проверяет, действителен ли договор технической поддержки. В случае если договор истек, и при желании клиента его продлить, звонящий перенаправляется в отдел продаж, и инициализируется продажа услуги.
Если у клиента действительный договор сопровождения, выясняется причина его обращения. В систему вносится сервисная заявка, в которой указывается причина обращения и возможное решение проблемы. При необходимости менеджер обращается в базу знаний, где ищет ответ на поставленный вопрос. Если подобной проблемы в базе не существует, вносится новая запись по решению.
При возможности вопрос решается сразу, если нет — консультант перезванивает клиенту или пишет письмо. В зависимости от этого сервисная заявка остается открытой до решения проблемы или сразу закрывается. Общая схема этих действий приведена на рис. 25.
Рис. 25. Решение проблемы клиента и закрытие сервисной заявки
Естественно, что руководство отдела по сопровождению имеет возможности получать отчеты по сервисным заявкам, сервисным договорам и объектам сервиса, подобно тому как их получает руководство отдела продаж. По этим отчетам можно судить о качестве сервиса, анализируя среднее время закрытия заявки, открытые заявки и договора.