Объекты обслуживания в Битрикс24: как мы вели базу флота на контактах и пользовательских полях

Когда мы начинали настраивать Битрикс24 для судовой сервисной компании, вопросом «где хранить объекты обслуживания» мы не задались. Вообще. Была задача запустить продажи и поддержку, а флот заказчиков как-то сам собой поселился там же, где контакты.

Сейчас, с девятью годами работы в Битриксе за спиной, я понимаю, что это было наполовину правильное решение. Расскажу, как база флота росла от простого списка до источника данных для анализа клиентской базы и сезонных закупок, где Битрикс справился, где уперся, и что я сделала бы иначе.

Случай судовой, но история универсальная: замените судно на станок, лифт, котельную или единицу спецтехники — и все совпадет.

Почему судно стало контактом

Решение выглядело логичным, и логика в нем действительно есть.

Судно принадлежит заказчику — значит, у него есть владелец, которого в CRM уже описывает компания. У судна есть своя почта и свой телефон: судовая связь существует отдельно от берегового офиса. У него есть имя, по которому его ищут. По набору свойств судно вело себя как контакт, и мы завели для него отдельный тип контакта — «Судно».

Первое время этого хватало с избытком. Мы вели историю закрытых заявок отдельным списком, по сделкам. Открываешь судно — видишь, что на нем делали и когда.

И здесь вылез первый изъян, который тянулся потом годами. Судно привязывалось к сделке через пользовательское поле типа «Привязка к CRM». Для человека это выглядит как связь. Для Битрикса — нет: штатную связь «сделка — контакт» он по такому полю не пробрасывает. А значит, в отчетах, фильтрах и роботах эта связь живет только там, где мы ее руками прописали.

Пока заявок десятки, это незаметно.Когда их тысячи — это становится стеной.

Пользовательские поля Битрикс24: когда их становится слишком много

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

Все это легло в карточку судна пользовательскими полями. Сначала несколько. Потом — очень много. В какой-то момент карточка судна перестала помещаться на экран, и прокрутка до нужного срока занимала больше времени, чем сам ответ на вопрос заказчика.

Пользовательские поля работают ровно до того момента, пока их не становится несколько десятков. Дальше начинаются типичные болезни: поля дублируются, половина не заполняется, никто не помнит, чем «Срок БТО» отличается от «БТО до», а любая массовая правка превращается в выгрузку, правку и загрузку обратно.

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

Главное, что это дало: отчет сам приходит в сделку

Вот тот момент, ради которого стоило все затевать.

Когда на судно создается очередная заявка, Битрикс достает свежий отчет по узлам и расходникам именно этого судна и кладет его первым комментарием в таймлайн сделки. Менеджер открывает заявку и сразу видит: вот это оборудование, вот у этого блока срок выходит через месяц, вот этот расходник пора менять.

Эффект оказался двойным, и оба эффекта денежные.

Индивидуальный подход перестал быть словами. Заказчик звонит по одной поломке, а менеджер говорит: раз мы все равно выходим на борт, у вас через три недели истекает срок вот по этому блоку. Это не впаривание, это нормальный сервис — и выглядит он как забота, потому что ею и является.

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

Что база объектов дала бизнесу через несколько лет

Данные копились годами, и в какой-то момент их стало достаточно, чтобы считать не по одному судну, а по всей клиентской базе.

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

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

Ни то ни другое не было целью, когда мы заводили тип контакта «Судно». Это побочный эффект того, что данные годами складывались в одно место и в структурированном виде.

Где Битрикс24 уперся

Сейчас у нас своя CRM — гибче Битрикса и дороже его. Причины разберу отдельной статьей, но та, что касается объектов обслуживания, относится к делу.

Все годы работы в Битриксе отчеты по заявкам мы вели комментариями к задачам. Задачи — это тот раздел Битрикса, куда обновления приходят не так быстро, как хотелось бы. И, что важнее, по API задачи отдают не всю информацию, которая нужна для доработок и кастомизации.

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

Мы сначала написали свой блок с отчетами по заявкам. Потом он оброс соседними задачами. Потом это превратилось в собственную CRM. Но это другая история.

Что бы я сделала иначе

Девять лет спустя — и с учетом того, что Битрикс с тех пор заметно изменился, — порядок шагов был бы другим.

• Завести отдельную сущность под объект обслуживания с самого начала. Сегодня для этого есть смарт-процессы: собственная сущность со своими полями, своей воронкой и нормальными связями с другими элементами CRM. Судно как контакт — решение времен, когда выбора особо не было. Сейчас выбор есть, и объект обслуживания — это не контакт, это объект;
• думать о связи со сделкой до того, как появится тысяча сделок. Главная цена нашего первого решения — не неудобная карточка, а то, что связь «судно — заявка» жила в пользовательском поле и не участвовала в штатной механике. Любой отчет по этой связи приходилось писать отдельно;
• не плодить поля под каждый срок. Сроки — это не свойства объекта, это записи с датами: что, когда и кем продлено. Десять полей «срок до» хуже одного списка из десяти записей хотя бы потому, что список можно отсортировать и по нему можно построить напоминание;
• решить про аналитику раньше, чем накопятся данные. Если по данным когда-нибудь понадобятся отчеты — а они понадобятся, — хранить их нужно в полях, а не в тексте комментариев. Это решение стоит принять в первый месяц, а не на пятый год.

Кому подойдет Битрикс24 для учета объектов обслуживания

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

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

Граница проходит там же, где прошла у нас: когда по накопленным данным нужна собственная аналитика, которую штатные отчеты не дают, а API отдает не все.

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

Если нужно разобрать вашу задачу по учету объектов обслуживания — что умеет Битрикс24 и как его настраивают под сервис, мы описали отдельно. Про систему заявок и плановых работ есть страница про ТОиР.