Михаил Елашкин - SAP Business One. Строим эффективный бизнес

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

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

Начальнику финансового отдела предварительная оценка предполагаемого дохода от той или иной сделки позволяет прогнозировать объем денежных поступлений, планировать финансовую деятельность и отслеживать план с фактом для дальнейшего анализа ( рис. 21 - Общий план поступления денежных средств по сотрудникам компании; и 22 — Детальная расшифровка финансовых аспектов работы менеджеров по продажам).

Вернемся к вопросу действий консультантов при обслуживании клиентов компании. За эту работу отвечает модуль «Сервис».

Рассказывает менеджер по технической поддержке «Эксперт Системс»:

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

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

Если он „пират“, то мы отказываем ему в поддержке. Впрочем, если он настроен лояльно, то его можно перевести в отдел продаж, для покупки лицензионной версии.

Для нас принципиально ответить клиенту сразу же, решить его проблему и закрыть сервисную заявку. Если же решение не найдено, то заявка остается открытой и висит на нас. Я вижу все заявки, которые не были закрыты, и связанную с ними активность. Если заявка висит долго, то на ней собирается большое количество активностей — попробовать это, запросить то... и так далее».

Таким образом, в основе идентификации пользователя консультантом лежит тот факт, что каждому проданному программному продукту присваивается регистрационный номер и автоматически создается карта учета объекта сервиса, в которой по регистрационному номеру можно узнать информацию о проданном продукте и о покупателе ( рис. 23 — Карта учета объектов сервиса).

Но того факта, что этот продукт куплен легально и пользователь зарегистрирован в базе данных, недостаточно для обслуживания клиента. При покупке сопровождения программного продукта в систему вносится сервисный договор, в котором определяются рамки действия договора по сопровождению ( рис. 24 — Сервисный договор).

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

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

При возможности вопрос решается сразу, если нет — консультант перезванивает клиенту или пишет письмо. В зависимости от этого сервисная заявка остается открытой до решения проблемы или сразу закрывается. Общая схема этих действий приведена на рис. 25.