Заказная разработка CRM для процессов, которые не влезают в воронку

У компании, которая ставит модульные бани, заказ проходит 11 этапов: замер, проект, согласование, предоплата, производство, доставка, монтаж, пусконаладка, акт, доплата, гарантия. Между замером и актом обычно 6–9 недель. В amoCRM у них была воронка на 11 колонок, и через полгода в колонке «Производство» висели 74 сделки. Какие из них уже стоят у клиентов, никто сказать не мог.

Воронка хорошо описывает продажу: одна сделка, один менеджер, этапы идут друг за другом. Когда процесс устроен иначе, его приходится проектировать отдельно. Ниже четыре типа процессов, с которыми к нам приходят чаще всего, и как мы строим под них CRM.

Многоэтапный заказ

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

Как проектируем:

• Заказ состоит из позиций, у каждой свой статус. Столешница готова, фасады ещё в покраске, и это видно в одном заказе.
• Этапы привязаны к ролям: технолог, мастер цеха, логист, монтажник. Каждый видит в своём списке только то, что сейчас ждёт его.
• У этапа есть плановая длительность. Если покраска идёт 5 дней вместо 3, заказ подсвечивается у начальника производства.
• Деньги идут по графику: предоплата 50%, после доставки 40%, после акта 10%. Система сверяет поступления из 1С с графиком.

Дело

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

Главным объектом здесь становится дело. Оно не движется по этапам слева направо: заседание переносят, приходит запрос из суда, клиент досылает документы. Поэтому вместо колонок мы строим ленту событий и календарь сроков:

• у каждого события есть тип, дата, документ и ответственный юрист;
• процессуальные сроки считаются от даты события, система напоминает за 5 и за 2 рабочих дня;
• к делу привязаны все документы: иск, определения, доверенности, акты оказанных услуг;
• оплата бывает абонентской, поэтапной или процентом от результата, это задаётся в договоре.

Руководителю нужен один экран: какие сроки истекают на этой неделе и у кого из юристов перегруз.

Рейс

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

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

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

Сервисный выезд

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

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

• Плановые выезды система создаёт сама по регламенту, например раз в квартал для каждого объекта.
• У аварийной заявки есть SLA: реакция 4 часа, устранение 24 часа. Диспетчер видит таймер.
• Мастер в приложении видит историю объекта, отмечает работы, списывает запчасти с остатка в машине, получает подпись клиента на экране.
• Акт формируется при закрытии выезда, а раз в месяц собираются сводный акт и счёт по договору.

Что общего в проектировании

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

1. Описываем главный объект и связанные с ним: клиент, договор, документы, деньги.
2. Рисуем статусы и события: кто их меняет и что при этом происходит автоматически.
3. Определяем роли и их рабочие экраны. У диспетчера, мастера и главбуха они разные.
4. Решаем, что берём из 1С и что отдаём туда. Обычно это контрагенты, номенклатура, оплаты и закрывающие документы.
5. Выбираем 3–4 отчёта, без которых руководитель не может работать.

Проектирование занимает 1–3 недели. На выходе получаются схема объектов, список статусов и ролей, макеты основных экранов. По этому документу разработку можно оценить с точностью до недели.

Отдельно договариваемся, где живут документы. Счета и акты для заказчика удобно печатать прямо из CRM по шаблону компании. УПД и счета-фактуры главбух чаще хочет формировать в 1С и отправлять через Диадок или СБИС, тогда CRM получает обратно только номер и статус подписания.

Когда хватит доработки amoCRM или Битрикс24

Если процесс короткий, в нём один-два исполнителя и нет параллельных этапов, своя система не нужна. Многоэтапный заказ из 4–5 шагов часто укладывается в смарт-процессы Битрикс24. Сервис с небольшим числом выездов можно вести в amoCRM с отдельной воронкой и виджетом для мастеров. Мы говорим об этом на первой встрече: заказная разработка CRM дороже настройки, и платить за неё стоит, когда настройка уже не помогает.

Если ваш процесс похож на один из четырёх, можно написать нам в Telegram @automationdev24: опишите процесс, и мы скажем, хватит ли доработки текущей системы или нужна своя.