Улучшаем работу отдела продаж в CRM Битрикс24 для строительной компании

Главное в CRM — она должна быть удобной для всех

Наш клиент

«Девелопмент-Юг» — строительно-инвестиционная корпорация, которая более 30 лет работает в строительной сфере. Первые дома были построены в Краснодаре. Сейчас компания строит новые дома в Перми, Ростове-на-Дону, Батайске, Астрахани. Текущие результаты работы компании — построено 115 домов, сдано 2 000 000 м² жилья, 25 000 семей справили новоселье. Корпорация  активно внедряет новые технологии. Первой в регионе начала строить жилье по монолитно-каркасной технологии, массово использует строительство подземных паркингов, предлагает дома с услугами консьержей. Также компания внедряет современные ИТ-технологии, ищет новые решения для автоматизации бизнеса.

Почему ИНТЕРВОЛГА?

CRM во многих строительных компаниях уже внедрена, но часто не решает специфические задачи застройщика без доработок. При этом CRM строительной компании сильно отличается от CRM торговой компании. Отличия связаны с тем, что продаваемый товар — квартира. У каждой есть адрес, этаж, площадь, планировка и другие параметры. Поэтому универсальная CRM Битрикс24 для строительных компаний не подходит. Её необходимо доработать. Например, дополнительно делают “шахматки” или другие решения. В Девелопмент-Юг шахматка была уже создана. Но новые задачи требовали скорейшего решения:

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

Задачи сложные, требуют знаний, как “под капотом” устроена CRM, как безболезненно изменить функционал, при этом сохранить обновляемость Битрикс24. Для решения задач требовалась компания с опытом ведения крупных проектов, умением управлять разработками на основе современных методов и стандартов, знанием специфики строительной отрасли.

ИНТЕРВОЛГА работает с Битрикс24 с 2014 года. Умеет кастомизировать CRM, дорабатывать карточки клиентов, лидов, сделок. Разрабатывает собственные интеграции Битрикс24 с сайтами, интернет-магазинами, 1С, онлайн-сервисами проверки контрагентов, складскими системами и пр. Обсудив задачи, мы предложили технические решения, которые полностью устроили клиента.

Что важно — у нас много проектов для строительных компаний:

• Велесстрой;
• Главстрой;
• Баурекс;
• Евро Хоум Билдинг.

Мы знаем лучшие практики для отдела продаж. Наши дополнительные преимущества:

1. Умеем вести сложные доработки “коробочной” версии.
2. Входим в топ 10 команд по Битрикс24.
3. 70 человек в компании, больше половины — штатные программисты.
4. Битрикс рекомендует нас для крупных внедрений.
5. Умеем модернизировать “коробку” с сохранением обновляемости.
6. Наши сотрудники — авторы обучающих материалов для Битрикса.
7. Устоявшаяся, проверенная методология разработки.
8. Более 100 реализованных проектов на Битрикс24, выделенный отдел (13 человек), специализирующийся только на этой платформе.

Как доработали CRM Битрикс24 для строительной компании

Теплота клиента — визуализация сроков вывода клиента на заключение договора

Главное в CRM — она должна быть удобной для всех сотрудников. Первое наше решение — показать “теплоту” клиента. Руководителю отдела продаж, да и самому менеджеру важно наглядно видеть “теплоту” клиента. Можно создать пользовательское поле:

Но нет наглядности при работе с ним. Графическая маркировка, напротив, позволит легко фильтровать сделки, у которых критичны сроки. Для визуального отображения теплоты согласован следующий вариант градации:;

Показатель “теплота” — субъективная оценка менеджера, о возможном сроке вывода клиента на заключение договора. Чтобы убрать субъективность, теплоту рассчитываем, исходя из разницы текущей и даты вывода на сделку:

• Холодный: более 180 дней (голубой);
• Теплый: 90 - 180 дней (оранжевый);
• Горячий: 30 - 90 дней (оранжево-красный);
• Очень горячий: 0 - 30 дней  (выделение красным);
• Критический: если текущая дата превысила указанную (малиновый).

Результат:

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

Расширение фильтрации в сделках — что делать, если нужен сложный запрос для поиска

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

1. Квартира — поле, в которое передается информация из внешней БД:

2. Интерес: Регион, Проект, Дом — место встраивания приложения с иерархическим представлением Объектов недвижимости:

3. Жилой комплекс — список с множественным выбором:

4. Marketing_landing — поле заполняемое roistat, содержащее ссылку на лендинг. Определяет, какой Жилищный комплекс первоначально выбрал клиент при заполнении формы на сайте.

Совокупность 4-х полей позволяет понимать, какими Жилищными комплексами интересуется клиент, какие корпуса для него приоритетны. Но возникает проблема, как отобрать клиентов, которым интересен город Краснодар, Жилищный комплекс “Перспектива”, корпус - Литер 2.3. Использовать штатный фильтр невозможно, так как интегрированные поля в нем не отображаются. Решение — создать новое поле с особым типом, в котором будем задавать поисковый контент. Но сам поиск будет проходить по всем четырем полям. Хотя для менеджера это выглядит обычным полем:

Результат — отобраны сделки сразу по четырем полям:

Сделки с участием нескольких менеджеров

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

Первое улучшение, которое было сделано, — отбор сделок по наблюдателям в фильтре. К сожалению, по штатному полю "Наблюдатель" фильтровать сделки нельзя. Поэтому мы сделали функцию для поиска сделок по наблюдателям:

Результат работы поиска по наблюдателю:

Второе улучшение — уведомление наблюдателей о событиях в сделке. Когда в сделке происходят действия, то ответственному приходят сообщения. Удобно, чтобы и наблюдателям приходили оповещения. Для этого сделан дополнительный обработчик, который уведомляет наблюдателей о событиях. 

Чтобы избежать излишнего числа уведомлений (при большом потоке сообщений сотрудники часто перестают реагировать на “колокольчик”) сделана настройка, в которой выбираются поля, об изменении которых надо сообщать:

Отслеживаются следующие изменения в сделках:

• название сделки;
• сумма сделки;
• валюта сделки;
• комментарий к сделке;
• дата завершения сделки;
• компания;
• наблюдатели;
• стадия сделки;
• ответственный за сделку;
• добавление дела (задачи, звонка, письма) к сделке;
• изменение ответственного за дело;
• завершение дела.

Таблица в карточке сделки и слайдер для заполнения

Интерфейс Битрикс24 простой и удобный. Но для работы менеджера требуется фиксировать много информации в сделке. Для этого используются “пользовательские поля”. Два десятка пользовательских полей приводит к карточке сделки, которую приходиться долго прокручивать. Получается “простыня”, с которой трудно работать. Поля расположены вертикально, занимают много места, заполнять их неудобно. Не видно общей картины по клиенту:

Существующий интерфейс Битрикс24 — не приговор мучительно работать с “простыней”. Можно доработать и улучшить удобство карточек — объединить пользовательские поля в компактную таблицу:

Как редактировать таблицу? Разрабатывать новый функционал — сложно и долго. Более простое решение — использовать существующий “слайдер” в Битрикс24. Выводим в отдельный слайдер пользовательские поля и добавляем метод “Изменить”: 

Результат — используется штатный функционал Битрикс24, но получаем удобную карточку сделки для просмотра и редактирования информации:

Как работаем с большими задачами

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

Заказчик, который выбирает ИТ-компанию, опирается на следующие критерии:

• цена (часовая тарифная ставка на работы);
• культура разработки программного обеспечения (следование общепринятым стандартам и методологиям);
• число параллельных задач, которые может одновременно решать компания;
• команда проекта (удаленщики или программисты в офисе);
• менеджмент (выделенный менеджер или просто дежурный);
• поддержка обновляемости платформы;
• понимание со стороны разработчика внутренних процессов у клиента (знание отраслевой специфики);
• процесс передачи решения заказчику (тестирование и отладка);

Покажем, что ИНТЕРВОЛГА соответствует перечисленным критериям. 

Цена

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

Культура разработки

Стиль разработки программного обеспечения выбираем “под заказчика”. Мы не фанаты Agile методов, но и не всегда следуем водопадной (каскадной) модели. Кому-то удобно работать с нами по “водопаду”. Кому-то важнее быстро получить первую рабочую версию продукта и работать по методологии экстремального программирования. 

В проекте работы велись по водопаду: 

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

Поэтому работа велась поэтапно:

1. Заказчик описывает желательный функционал обычным “человеческим” языком: “Много полей, неудобно работать, нужно сделать компактнее. А редактировать желательно также, как сейчас. Что предложете?”.
2. Созваниваемся или проводим видеоконференцию. Обсуждаем функционал, интерфейс, удобство работы менеджеров, критичные функции и пр.
3. Формализуем задачу, переводим на технический язык в терминах Битрикс24, пишем Техническое задание.
4. Делаем оценку трудоемкости, получаем смету работ.
5. Согласовываем стоимость и сроки работ с заказчиком.
6. Берем предоплату и стартуем.
7. Выполняем разработку, по окончании которой программист делает отладку решения. 
8. Менеджер проекта проверяет полученное решение.
9. Переносим на рабочий Битрикс24 и проверяем “на бою”.
10. Сопровождаем процесс опытной эксплуатации. При возникновении проблем или проявления скрытых багов оперативно исправляем замечания. 

10 пунктов — это же долго? Отнюдь.

Обсудить и описать задачу — 2-3 дня.
Техническое задание и оценка — еще 2-3 дня. Итого рабочая неделя.
Разработка — тут зависит от объема работ, но мы укладывались в 1 месяц.
Тестирование и отладка — добавляем еще неделю.
Опытная эксплуатация — неделя контроля работы нового решения.
В результате через 1,5 - 2 месяца получаем готовый программный модуль.

При “водопаде” работаем быстро и качественно. И параллельно можем выполнять сразу несколько задач.

Команда

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

Менеджмент

На каждый проект выделяется постоянный менеджер. Это сотрудник, который погружен в проект, знает отраслевую специфику заказчика, понимает бизнес-процессы клиента.  Менеджер сопровождает проект с первых дней обращения клиента в ИНТЕРВОЛГУ и до тех пор, пока не завершится проект. Часто это многолетние проекты с постоянным потоком задач. 

Обновления

Боль, которая сопровождает доработки, — проблема с обновлениями. Разработчики создают новые модули с учетом существующего функционала платформы (Битрикс24). Но вендор всегда может без предупреждения изменить функционал Битрикс24 при новом обновлении. В результате — сбой в работе программного модуля.

Мы понимаем эту проблему и стараемся предупредить возникновение сбоев.

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

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

Тестирование

Простой этап на первый взгляд — проверить, работает или нет. Но, что значит “работает”?  Название кнопки съехало, текст не читается, но кнопка нажимается и ответная реакция правильная. Кнопка работает или нет? Чтобы не было такой неоднозначности, поступаем так. Разбиваем Техническое задание на отдельные функции, выделяем требования, вносим в таблицу тестирования: