Чем путь заявки в строительстве отличается от обычного
В строительстве и ремонте между обращением и договором обычно стоят выезд на объект, расчёт и уточнения. Если у вас работа устроена так, обращение проходит через нескольких людей — например, менеджера, замерщика и сметчика, — и на каждой передаче может потеряться.
Поэтому главный вопрос к системе — не число функций, а то, видно ли в любой момент, на каком шаге находится каждое обращение и кто сейчас должен сделать следующий.
Где обычно теряются обращения
Разберите десять последних обращений, не дошедших до договора, и отметьте шаг, на котором оборвалась работа. Ниже примеры ситуаций, которые стоит проверить; это не статистика, у вас набор может быть другим.
- Заявка с сайта пришла на почту, а перезвонили через день, когда клиент уже договорился с другими.
- Замер проведён, но смета не отправлена: сметчик ждал уточнения, менеджер об этом не знал.
- Смета отправлена, клиент обещал подумать — и повторного контакта в согласованный срок не было.
- Менеджер ушёл в отпуск, а его переписка с клиентами осталась в личном мессенджере.
Что система должна уметь на вашем сценарии
Опишите свой путь заявки шагами — например: новое обращение, назначен замер, замер проведён, смета отправлена, решение клиента. Это пример, а не готовый регламент: у компании, которая строит дома, и у бригады по ремонту квартир шаги разные. Затем проверьте любой вариант системы по четырём вопросам.
- Видно ли по каждому обращению, на каком оно шаге и кто отвечает за следующий.
- Появляется ли напоминание, когда подошёл согласованный с клиентом срок повторного контакта.
- Сохраняются ли в одном месте адрес объекта, договорённости и отправленные документы.
- Может ли другой сотрудник продолжить работу, открыв карточку, без расспросов коллеги.
Учебный пример: одна заявка от звонка до договора
Пример условный: компании, людей и объекта не существует, сроки взяты для наглядности. Он показывает, какие записи должны остаться в системе после каждого шага, а не как обязана работать ваша компания.
В понедельник в 10:20 с сайта приходит заявка на ремонт двухкомнатной квартиры. Система создаёт карточку со статусом «Новое обращение» и назначает ответственным менеджера. Срок первого звонка по внутреннему правилу этой компании — два часа.
- Менеджер звонит в 11:05, записывает адрес и пожелания, ставит статус «Назначен замер» — среда, 18:00; ответственным за шаг становится замерщик.
- Замерщик в среду вносит площади и фотографии, ставит «Замер проведён»; сметчик получает задачу со сроком — пятница, 12:00.
- Сметчик прикрепляет смету, статус — «Смета отправлена»; менеджеру появляется задача повторного контакта на вторник, как договорились с клиентом.
- Во вторник система напоминает о звонке. Клиент просит убрать одну позицию — карточка возвращается сметчику с новым сроком, история сохраняется.
- После согласования статус — «Договор»; если клиент отказался — «Отказ» с записанной причиной, чтобы её можно было посчитать по всем обращениям.
Проверка простая: откройте карточку в любой день и, никого не спрашивая, ответьте на три вопроса — на каком шаге обращение, кто делает следующий шаг и к какому сроку. Если хотя бы на один ответа нет, сценарий в системе не настроен.
Разработка CRM: обсудить процесс и получить расчёт → · Обсудить задачу
Готовая программа или собственная разработка
На рынке есть отраслевые и универсальные программы. Попросите показать в них именно ваш сценарий целиком, а возможности, тарифы и ограничения сверяйте в документации поставщика. Если сценарий проходит настройкой и условия вас устраивают — разработка не нужна.
Если готовый продукт подходит, но не получает заявки с сайта или из калькулятора, сначала проверьте его документацию по подключениям: может хватить доработки сайта или отдельной интеграции без новой CRM. Собственную систему стоит оценивать, когда в готовый продукт не укладывается сам порядок работы — например, расчёт и этапы зависят от ваших собственных правил. У разработки есть свои расходы на размещение, обновления и сопровождение — сравнивайте стоимость владения за год.
Как связать CRM с сайтом
Если заявки приходят с сайта, договоритесь до начала работ, какие сведения передаются вместе с контактом: выбранная услуга, параметры из калькулятора, страница, с которой отправлена форма. Проверьте три случая: обычную отправку, повторную отправку той же формы и потерю соединения.
Пример передачи обращения с сайта есть в разборе проекта РОВНО: форма отправляет обращение вместе с выбранным пакетом и параметрами квартиры. Разбор описывает только этот путь — от сайта до полученного обращения; полной CRM в нём нет.
С чего начать
Начните с одного процесса — пути новой заявки до договора — и одной команды, которая будет работать в системе каждый день. Учёт объектов, снабжение и расчёты с бригадами не добавляйте в первую версию только потому, что они есть в чужой программе: сначала убедитесь, что основной сценарий перестал терять обращения.
Что обсудить с Lendmix
Lendmix разрабатывает сайты и собственные CRM под согласованный процесс. Здесь рассматриваем работу с обращениями; сметные расчёты, складской и бухгалтерский учёт в описанный состав не входят. Опишите путь одной заявки — откуда она приходит, кто с ней работает и на каком шаге чаще всего теряется, — и укажите, чем пользуетесь сейчас. По этому описанию скажем, решается ли задача настройкой имеющегося инструмента, доработкой сайта или отдельной разработкой.