Введение|Общая схема|Постановка цели|Темы|Новости|Блог|Разное
Программное обеспечение для анализа продаж

Борьба с «двойниками» в клиентской базе

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

При этом «двойник» может быть записан по-другому и найти его бывает очень сложно. Например, в одном случае клиент записывается как ООО «Интерстрой», а во втором как «Интерстрой» ООО. Здесь даже если отсортировать записи по алфавиту, то эти два названия не попадутся рядом.

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

Но все-таки проблема «двойников» больше характерна именно для клиентских баз, т. е. для справочников контрагентов.

Борьба с такими «двойниками» ведется обычно по двум направлениям — техническому и организационному.

Технические средства борьбы с двойниками

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

При поиске вводится часть названия и система показывает те записи, в которых эти части названия присутствуют.

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

При сортировке названия выстраиваются по алфавиту и таким образом чисто визуально можно увидеть стоящие рядом похожие названия.

Тем не менее, как показывает практика, технические меры проблему не решают. Поэтому так или иначе они дополняются специальными организационными мероприятиями.

Организационные мероприятия

Здесь также можно выделить некоторые разновидности борьбы с дублями

Правила, управленческие регламенты

Один из первых и простых способов — разработка специальных правил, или по-другому их называют управленческими регламентами, которые определяют, как нужно вносить название клиента в базу.

Например, как правильно будет писать уже упоминавшееся выше название — ООО «Интерстрой» или «Интерстрой» ООО. Где должно быть ООО — в начале или в конце? Нужно ли использовать кавычки и т. д.?

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

Администратор базы

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

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

Кроме того, администратор базы должен регулярно — раз в месяц, а то и раз в неделю — контролировать состояние базы. Т.е. он должен специально просматривать список клиентов и контролировать, не возникло ли там каких-то ошибок, неправильных записей, в том числе и «двойников». И при обнаружении таких ошибок он будет заниматься и их исправлением или удалением.

Следует отметить, что работа эта весьма кропотливая и неблагодарная. Современные CRM-системы просто так не позволят удалить ту или иную запись. Дело в том, что для обеспечения целостности данных, когда записи ссылаются друг на друга, система блокирует попытки удаления до тех пор, пока у удаляемой записи есть связи с другими записями. Поэтому, прежде чем что-то удалить, приходится проходить по всей цепочке и переназначать имеющиеся ссылки на правильное название. И только после этого, когда не останется связей, можно будет удалить ошибочные записи.

Как видите, здесь также как и в медицине — легче предупредить ошибку, чем потом с нею бороться.

Ответственный за справочник контрагентов

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

Чаще всего делается так: право вносить новые названия предоставляется только одному человеку — тому же администратору базы. А если пользователей программы много, то кроме общего админа программы может быть еще и отдельный администратор именно базы клиентов.

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

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

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

Ошибки при работе с клиентской базой

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

Например, довольно часто руководство компаний пытается стимулировать своих сотрудников заполнять карточки клиентов. Иногда для этого отводятся специальные дни и устанавливаются определенные нормы, например, каждую неделю по 5 клиентов.

Практические всегда такие попытки проваливаются. И не потому, что менеджерам не хватает времени на такую работу, а потому, что она с их точки зрения бесмысленна.

Точно также многие менеджеры или программисты пытаются написать CRM-программу на базе Microsoft Outlook. Действительно, это очень удобный еженедельник и возникает сильный соблазн сделать из нее CRM-программу.

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

Но когда через месяц (обратите внимание на временной интервал?!) руководство решило проверить, как ведется клиентская база, то оказалось, что ее ведут только два человека — сам руководитель и его заместитель, который этот процесс инициировал. Все остальные менеджеры продинамили порученное задание под самыми различными и вполне благовидными предлогами.

В итоге, прогрессивная идея погибла на корню.

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

А ведь CRM-программа начинается только тогда, когда в ней есть как минимум два блока — справочник клиентов или собственно клиентская база, и вторая часть — информация о контактах с клиентами, т. е. записи о звонках, встречах, письмах и т. д.

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

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

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

Более подробно о скрытом сопротивлении при внедрении CRM-программ можно посмотреть в «Кратком справочнике руководителя отдела продаж по внедрению CRM»

Резюме

Для борьбы с «двойниками» в клиентской базе используются технические средства и организационные меры. Последние более эффективны.

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

31.01.2008
Введение
Общая схема
Постановка цели
Темы
Новости
Блог
Разное
Как далеко от директора сидит на совещаниях руководитель отдела продаж вашего предприятия?

1-е место от директора
2-е место от директора
3-е и более место от директора