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