Отслеживание откликов

[Likefire]

Интересная тема. Не поленился прочитать её с самого начала и поэкспериментировать. Отмечу, что всё ровно так и происходит, как описывает SLK. Но главное даже не в этом. Главное (для меня, как опытного внедренца) то, что сам процесс весьма и весьма сложен. Если в процессах (реальных бизнес-процессах) я не могу найти аналогов контракту от кампании, то мне приходится либо пробовать донести до менеджмента суть и необходимость такой сущности, что не всегда реально, либо адаптировать систему под реальные потребности и действия пользователей. Так вот, как раз по этому поводу вопрос к SLK: Вы просто тестировали всё вышеописанное, или у Вас практикуется сопряженный бизнес-процесс, с реальными аналогами контракта от кампании? И вообще мне интересно, как Вы внедряли существующий функционал (если конечно он внедрен) в "живой" компании?
Хотел бы отметить, что многие сущности стандартного функционала системы MS CRM 4.0, были встречены с непониманием со стороны представителей бизнеса и аналитиков. Например: мы не используем такую сущность как интерес - она явно избыточна и в аналогичных системах (да и методиках) того же Microsoft отсутствует напрочь. Исходно, вся клиентская база (Организации), поделена на представления, соответствующие основным сегментам, в которые сгружены все клиенты - как действующие, так и потенциальные. По мере работы разных специалистов база пополняется. На сегодняшний день система включает 14 сегментов, в каждом из которых не больше 200 записей о клиентах-организациях. Естественно, что каждый может подумать о том, что скорее всего база бесконтрольно разрастается. Реально - это не так. Вернее - по сути так оно и есть, но менеджеры не ощущают никакого дискомфорта в работе, потому что текущий список клиентов для каждого менеджера включает именно тех клиентов, текущее состояние которых обязывает менеджера к активной работе. Для понимания текущего состояния, в котором находится тот или иной клиент, каждый клиент наделяется статусом: 1. Потенциальный клиент; 2. Установлен контакт; 3. Проведена встреча; 4. Подписан договор; 5. Произведена оплата (Клиент); 6. Отказник (Клиентом не был); 7. Потерянный клиент. Переход между статусами происходит в результате фиксирования действий, поскольку, только в результате взаимодействия реально и происходит работа с клиентом (об отказе мы узнаем из встречи или телефонного звонка, договор подписываем в результате встречи, подтверждение оплаты приходит либо по факсу, либо по электронной почте). Единственный момент, который не предусматривает заведения действия для обретения статуса - это присвоение статуса 1. Это делает сам менеджер, когда отбирает из существующих сегментов потенциальный объект для обработки. Но даже эта процедура представляет собой наждатие двух кнопок. Весь процесс работы несложен. Из отчетов ясно видно, с кем из клиентов над чем нужно работать. Воронка продаж абсолютно понятна и прозрачна. Кроме того, с помощью колаутов мы запрограммировали планирование следующих действий. Это тоже логично, потому что каждый менеджер, установив с клиентом контакт, скажем по телефону, стремится договориться о встрече, или на крайняк о следующем звонке - то есть не терять с клиентом связь, либо же поскорее получить отказ, чтобы не тратить в дальнейшем своё время на пустые разговоры. Ну и конечно же, если звонок, либо запланированная встреча с клиентом были безрезультатны (неправильно набран номер, либо по указанному номеру дозвониться удалось, а оказывается, что искомой компании там нет) - система создаст менеджеру напоминание о том, что данный контакт нужно актуализировать, если опять же это необходимо (если это пустышка - запись о клиенте уничтожается). Но и даже в случае отказа, в нашей системе менеджеру создается напоминание с тем, чтобы через определенный промежуток времени, менеджер мог бы снова вспомнить о данной компании и возможно в этот раз уже возбудить интерес к нашим продуктам.
В завершении, хочу отметить, что на текущий момент мы разобрались со всеми нюансами и работаем достаточно уверенно в рамках описанной кастомизации. Естественен вопрос о развитии системы. В настоящий момент есть потребность фиксирования источника информации потенциального клиента о нашей компании, если клиент нам позвонил и сам проявил интерес к некому продукту. То есть грубо говоря, хочу приспособить поле "источник интереса" для этого. Но так как сам интерес в нашем случае ничто - достаточно просто связать данного клиента с кампанией, в результате которой он и получил информацию. Но тут встают два вопроса: 1. Может ли иметь место в моем случае наличие контракта от кампании и для каких целей его можно приспособить, без создания интереса; 2. Возможен случай, когда например кампания будет укрупнена, например: "Рекламная кампания в прессе", которая охватит не меньше 20 печатных изданий, как специализированных, так и общих, а менеджемент захочет проанализировать реальную отдачу каждого конкретного издания. А ведь компанией может быть и инет-поддержка, которая охватит почти полсотни интернет-сайтов, на которых появится наш баннер. Возможно эти сайты и издания и будут контракты от кампании? Я правильно сформировал понимание задачи?