Внедрение CRM для казахстанского дистрибьютора медицинского оборудования: две старые системы сведены в одну Zoho CRM, а сделки теперь сами уходят в партнёрский портал производителя. Проект вёл Евгений Росляков. Сайтами и бизнес-системами он занимается с 2016 года и работает самозанятым: заключает договор, юрлицам выдаёт закрывающие документы. С Алматы всё шло удалённо; сам он принимает заказы в Москве.
Компания продаёт оборудование клиникам, монтирует его и обслуживает. Отдел продаж сидел в давно не обновлявшемся SugarCRM. Сервисная служба вела заявки в vtiger. Третья система стояла у европейского производителя: он требует, чтобы дистрибьютор отчитывался по сделкам в партнёрском портале на Salesforce.com.
Результат был предсказуем. Одна клиника жила в двух базах с разными контактами. Сделку по тендеру менеджер вносил в SugarCRM, а сервисный инженер узнавал о ней случайно. Сроки поставки писали в таблицах, и часть подтверждений терялась. Руководитель отдела продаж не мог сказать, сколько тендеров сейчас в работе.
Нужна была одна CRM, в которой видят друг друга продавцы и сервис и которая не заставляет вручную дублировать данные для производителя.
Сначала сел с руководителями отделов и разобрал, кто какие данные вводит и зачем. Сравнили три варианта: остаться на SugarCRM и обновить его, объединить всё в vtiger или перейти на облачный сервис. Выбрали Zoho CRM. Он доступен в Казахстане, настраивается без программиста на стороне компании, а его API хватает для обмена с порталом производителя. Какие персональные данные можно держать в облаке, компания уточняла у своего юриста: в Казахстане на этот счёт свои правила.
В Zoho CRM настроил три воронки: «Продажа», «Тендер» и «Сервис». У тендера свои стадии и поля: номер закупки, дата подачи заявки, срок поставки. Карточка клиники связана с карточкой оборудования, где записаны серийный номер, дата монтажа и срок ближайшего ТО. За две недели до ТО менеджеру и инженеру приходит напоминание.
Данные из SugarCRM и vtiger выгрузил в файлы и разобрал скриптом. Клиники сравнивал по названию, городу и БИН, спорные пары отдавал менеджерам. Дубли склеил, историю звонков и заявок прикрепил к единой карточке.
Для портала на Salesforce.com написал обмен по API. Туда уходят только поля, которые требует производитель: клиент, модель, стадия, ожидаемая дата поставки. Остальное, например цены для клиники и внутренние заметки, наружу не попадает.
Права разделил по ролям: менеджер видит свои сделки, руководитель отдела — все, инженер — оборудование и заявки. Потом провёл два занятия для менеджеров и одно для сервисной службы, на реальных карточках.
У отдела продаж и сервисной службы теперь одна CRM. Менеджер открывает карточку клиники и сразу видит, какое оборудование там стоит, когда было последнее ТО и есть ли открытая заявка. Раньше за этим шли к инженеру или в чужую базу.
Тендеры не теряются: у каждого есть стадия, ответственный и дата, а руководитель видит их одним отчётом. Отчёты производителю в конце месяца вручную больше не собирают, сделки уходят в его портал сами, и расхождений между двумя системами стало заметно меньше.
SugarCRM и vtiger на время оставили только для чтения, чтобы можно было свериться со старой историей. Потом их отключили.
Есть ограничения. Дедупликация сработала не везде: клиники с разными юрлицами и одним адресом менеджеры до сих пор разбирают вручную. Обмен с Salesforce.com идёт в одну сторону и по правилам производителя, поэтому, если его портал сменит формат, обмен придётся подстраивать. Кое-кто из менеджеров сначала вёл записи по-старому, в таблицах, и ещё пару недель руководителю приходилось напоминать про CRM.
Обсуждали следующий шаг: подключить к Zoho CRM почту и телефонию, чтобы звонки клиник попадали в карточки автоматически. Решение за компанией, когда приживётся то, что уже запущено.
Если продажи и сервис у вас живут в разных базах, а старые данные жалко терять, пришлите мне через freelance.ru список систем и примерное число клиентов в каждой. По нему я скажу, получится ли внедрение CRM без остановки продаж.
