В определенных сферах (автосервис, продажа сложного оборудования) задача компании не только продать товар или услугу, но и убедить клиента обратиться к ней за ремонтом (диагностикой) товара. Подобное постпродажное обслуживание — один из ключевых источников дохода. Однако выгоду компания получит, если контролирует весь процесс продаж и гарантийного обслуживания, а для этого надо знать:
- сроки гарантийного обслуживания и ремонта (начало и окончание дат) или фиксировать единицы измерения (часы, километры) гарантии в программе;
- причины обращения клиента: частота заявок, основные (постоянные) проблемы товара;
- клиента: контактную информация, историю взаимодействия;
- сопутствующие данные процесса: этапы и сроки обработки сделки, конкретные шаги специалистов.
Подручными инструментами вроде таблиц сложно управлять многоэтапным процессом. Здесь нужна единая система, которая поможет вовремя отследить гарантийные сроки, сохранить данные по сделке и качественно обслужить покупателя. В статье мы рассмотрим на примере кейса «СтарТек плюс», как корпоративный портал и CRM-система на базе Битрикс24 закрыли задачи компании и помогли перестать терять деньги в постпродажном периоде.
Клиент
К нам обратился дилер сельхозтехники в России «СтарТек плюс» (далее Стартек, клиент, заказчик). В компании два основных направления деятельности:
- Поставка тракторов и другого сельхозоборудования. Сюда входит прием заявок, согласование с заводом-изготовителем, доставка покупателю товара.
- Гарантийное и постгарантийное обслуживание и ремонт техники.
Важно, чтобы процессы, которые лежат в основе деятельности компании были упорядоченными и прозрачными. Ведь покупатели сельхозтехники обязаны проходить ТО и делать ремонт товара, поэтому обычно обращаются в Стартек. Однако гарантировать дальнейшее обращение клиента невозможно. Шансы на повторные продажи будут выше, если заказчик обеспечить лояльное отношение покупателя (особенно) за счет качественного обслуживания.
Проблема
У компании изначально не было единого инструмента для управления бизнесом. Стартек использовал 1С, а еще удобные (на тот момент) сервисы и программы. Однако, в процессе масштабирования бизнеса, стало не хватать их функциональности:
- Единой базы для хранения информации по товарам, клиентам, сделкам. Заказчику приходилось «поднимать» кипу бумаг, что бы узнать сведения о покупателе, завод-изготовитель, гарантийный срок, стоимость, технические характеристики машины, и (самое главное) причины и даты обращения покупателей по обслуживанию и ремонту.
- Четкого алгоритма воронки сервиса. Команда работала по устаревшей системе взаимодействия с покупателем, поэтому сотрудники не понимали, какой следующий шаг и, соответственно, увеличивался риск ошибок. К тому же, новые сотрудники долго адаптировались к БП компании.
- Автоматизации рутинных задач. Менеджерам и специалистам приходилось тратить много времени на обработку заявки и сделки.
Стартек понял, что нужная система, которая решит все задачи организации по БП. При этом нужно было интегрировать решение с 1С, чтобы отразить учет оплат на обеих платформах.
У Вас похожая задача по разработке бизнес-процесса?
Давайте обсудим
Наше решение
Мы провели аудит бизнес-процессов компании, по итогом которого составили техническое задание. За основу Стартек решил взять коробочную версию Битрикс24 (тариф Корпоративный портал). Сразу было понятно, что штатная функциональность платформы полностью не закроет задачи клиента. Поэтому мы предложили свое решение — с доработкой нужной функциональности и интеграцией с 1С.
В этой статье мы опишем, что как разработали опции по оперативной обработке заявки диспетчером, упорядочили действия по 4 сценариям послепродажного обслуживания, а также синхронизировали кастомизированную (индивидуальную) версию 1С с Б24.
1С-интеграция
Проект предстоял грандиозный: приходилось разрабатывать огромное количество опций, продумать логику БП, что в итоге привело к практически полностью переделанной под заказчика системе. Мы знали, что компания также изменила функциональность (кастомизировала) 1С под свои задачи. При этом обязательным пунктом договора стала интеграция систем между собой. Поэтому мы синхронизировали платформы по наиболее удобному для БП заказчика основанию — номеру заказа.
В случае клиента есть и другой вариант — сделать приложение 1С внутри Битрикс24, чтобы работать в одной программе и не переключаться между ними. Такая разработка выйдет клиенту дороже и дольше по срокам. Однако перед Стартек стояли другие задачи, а с учетом кастомизированной 1С, делать приложение внутри Б24 на тот момент было нецелесообразно. Поэтому данный вариант решили оставить на дальнейшие планы, когда основная часть проекта будет сделана.
Мнение команды Luckru
Сейчас процесс синхронизации платформ выглядит так: специалист присваивает номер заказа в 1С и копирует его в Сделку Б24 → происходит обмен информацией между платформами. Теперь оплаты, которые приходят по данному заказу и «оседают» в 1С, автоматически «подтягиваются» в корпортал Б24. В дальнейшем компания хотела усовершенствовать интеграцию платформ.
Диспетчер
Система заказчика изначально не предполагала автоматизации при обработке входящих вызовов. Представьте ситуацию: звонит человек и говорит, что у него сломался трактор. Диспетчер уточняет сведения: кто звонит, какой конкретно трактор сломался, местонахождение и так далее. После этого диспетчер прекращает разговор, чтобы уточнить у специалистов, обслуживают ли компания этого клиента, проходил ли он проверку (контрагента), что он покупал и так далее. Далее перезванивает клиенту и договаривается о диагностике или ремонте техники. Это наиболее простой случай.
Ситуация может осложниться, если клиент ранее не взаимодействовал с компанией. В этом случае процесс будет включать в себя проверку контрагента. Как следствие, процесс затягивается, а это не в интересах бизнеса. Поэтому сотрудники начинают спешить, что может привести к ошибкам из-за человеческого фактора.
Стартек понимал, что необходимо автоматизировать рутинные процессы там, где это возможно. Поэтому мы разработали интерфейс диспетчера с динамическими полями, который помогал «снять» часть обязательных функций с сотрудников.
Что из себя представляет разработка? Начнем с того, что у сотрудника, есть специальная метка диспетчера. Если звонок поступает по номеру телефона диспетчера, то открывается специальное окно, где он по ходу разговора заполняет данные:
- Если телефон определил контакт по номеру, то на экране диспетчера сразу появляется информация о звонящем и система «подтягивает» в форму остальную информацию: технику, обращения, адреса, телефоны. Кроме того запись разговора загружается автоматически в карточку заявки из связанного лида.
- Если телефон не определился, но клиент «знаком» Стартеку, то специалист может выбрать контакт из списка (динамические поля). В случае, если система не знает такого контакта, значит сотрудник должен создать карточку клиента, собрать все данные (+ прикрепить документы) и отправить потенциального клиента на согласование юристу.
После того, как диспетчер заполняет форму, он отправляет заявку на согласование ответственным за сделку специалистам.
Интерфейс диспетчер призван максимально облегчить труд сотрудника. Для этого ему важно упростить доступ к информации и как можно меньше, но эффективнее совершать действия. Например, справа от формы, есть список транспорта, который числится за клиентом. Можно выбрать трактор, по которому обращается клиент, либо внести новый. Каждая позиция «кликабельна»: при нажатии переходишь в карточку трактора, где видна история транспорта (покупатель, стоимость, завод-изготовитель, моточасы по гарантии, причины ремонта, даты обращения по ТО). Такое решение экономит время сотрудника, а значит и бережно относится к ресурсам компании.
Теперь диспетчеру не нужно тратить несколько часов, чтобы выяснить достоверность слов клиента. Специалист узнает всю актуальную информацию (в том числе сколько часов у клиента осталось по гарантии) из системы. При этом сотрудник может обработать пропущенный звонок через Лид. Все заявки на обслуживание и ремонт, которые формирует диспетчер, попадают в Реестр заказ-нарядов.
Каждая из заявок окрашивается в определенный цвет, в зависимости от статуса процесса (в работе у инженера, у механика, не в работе и т.д.). Цветовое обозначение помогает сотрудникам быстрее ориентироваться в заявках. Кроме того, сотрудник получает специальное уведомление в системе о выборе его ответственным и необходимости заполнить форму согласования. Такое решение позволяет диспетчеру автоматизировать рутинные процессы и быстрее обрабатывать заявки.
Гарантийные и постгарантийные послепродажные процессы
Сделки «собираются» в Реестре заказ-нарядов: здесь перемещать их вручную по этапам нельзя, это зависит от статуса сделки. К процессу подключается команда специалистов, каждый из которых заполняет свою часть формы: инженер отвечает за наличие расходников для техники, а начальник службы сервиса назначает ответственного за ремонт (или ТО).
Стартек разделил процессы на 4 сценария: гарантийные и постгарантийные ремонт и техническое обслуживание. Причем у каждого сценария есть свои особенности и логика.
Гарантийные ремонт и ТО
Обслуживание клиентов по гарантии — одно из основных направлений компании. Определяющим фактором, попадает ли техника под гарантию является количество моточасов, по истечении которых гарантия уже не предоставляется. После окончания гарантийного срока, компания также может обслуживать технику, но уже за счет клиента. Поэтому знать, сколько осталось до окончания срока — принципиально для Стартек.
Ранее контролировать точные сроки было крайне тяжело: не было единой базы, приходилось рыться в документах и файла, узнавать когда технику купили, сколько проездили, как часто обращались и так далее. Теперь появилась карточка техники, в которой указаны все данные по ней. Сотрудникам несложно зайти и увидеть полную картину по истории обслуживания и ремонта.
Остается только настроить воронку сервиса и разработать опции, которые помогут эффективно провести сделку по алгоритму. Но для начала объясним, что из себя представляет алгоритм «Гарантийного ТО» и «Гарантийного ремонта».
Отличительная черта гарантийных процессов в том, что Стартек проводит диагностический выезд, а также согласовывает каждое обращение с заводом-изготовителем. Завод должен подтвердить, что случай гарантийный. Для этого (до внедрения Б24) специалист составлял письмо, в котором описывал ситуацию и прилагал документы и фотографии техники. Приходилось искать контакты нужного завода и формулировать письмо-запрос, подставлять данные, указывать свои контакты и так далее. В итоге, бизнес-процесс растягивался и «забирал» ценное время сотрудников.
Поэтому мы разработали специальную форму с автоматической подстановкой контактных данных завода. Таким образом, специалисту не надо тратить время на поиск информации. В ответ завод присылает Акт рекламации — это документ, который подтверждает, что случай гарантийный. Далее клиента «ведут» по стандартной воронке сервиса: специальную форму заполняют специалисты, выезжают техники, подводят итоги. Все сведения заносят через удобный интерфейс, а дальше она оседает в базе Стартека.
Иногда требуется провести диагностический выезд, чтобы определить точную причину ремонта. В этом случае, владелец техники оплачивает выезд и ждет специалистов. Однако инженер и начальник сервиса могут заранее предположить, что сломалось в технике. Тогда они сразу предоставляют механику необходимые расходники. Если предположение специалистов оправдалось, то во время диагностического выезда механики сразу могут починить трактор. В таком случае все также требуется описать заводу ситуацию, но при этом статус сделки меняется на ожидание оплаты за расходники (а в случае, если гарантийный случай не подтвердиться, и за ремонт). Получается, что система позволяет идти по сокращенному алгоритму, не допуская ошибок со стороны сотрудников и экономя ресурсы компании. После перевода средств на счет Стартек, сделка завершается автоматически. После окончания сроков гарантии, процесс технического обслуживания техники немного отличается по алгоритму.
Постгарантийные ремонт и ТО
В Стартек могут обратиться как текущие, так и новые клиенты, у которых нет постгарантийного договора. Если в компанию обращается новый клиент, сотрудники создают карточку контрагента и проверяют достоверность данных. После проверки, клиента «ведут» по воронке сервиса (как в гарантийных случаях). При этом важно понимать,что ПОСТгарантийные случаи уже не нуждаются в одобрении завода-изготовителя, поэтому отправлять запрос-письмо не надо. Зато на данном этапе принципиальным является оплата услуг и запчастей (также в случае гарантийного ТО). Завершить Сделку в системе можно только после того, как клиент полностью всё оплатит. Вручную (и без оплаты) завершить сделку не получится, а значит уменьшается риск совершить ошибку.
Это основные моменты по разработке дополнительной функциональности в корпортале клиента. Кроме этого мы разработали другие опции, которые помогают специалистам в работе:
- начальник службы сервиса выбирает механика из списка (динамическое поле), в который попадают лишь те, кто не занят на других выездах;
- только начальник службы сервиса может перенести заявку на другой период, потому что появилась более приоритетная задача;
- инженер через систему указывает механику номер ячейки, в которую положили инструменты и расходники для ремонта, а также отмечает дату привоза запчастей;
- отрабатывается интеграция с 1С в части оплат.
Механики отправляют фотографии, акт выполненных работ и комментарии руководителя, а тот в свою очередь сохраняет все данные в Б24. На данный момент, мы разрабатываем мобильное приложение для механиков, в котором они смогут прислать всю информацию напрямую в систему.
У Вас похожая задача по разработке бизнес-процесса?
Давайте обсудим
Предпродажная подготовка и логика с оплатами
Механики в компании не только ремонтируют технику, но и делают предпродажную подготовку тракторов. Например, покупателю требуется установить на трактор дополнительное оборудование . В таком случае, специалист полностью собирает машину, а потом логист организует доставку до клиента. Такой процесс важно фиксировать в системе. Иначе компания «потеряется» в процессах.
Предпродажная подготовка аналогична воронке сервиса, только в ней нет таких этапов, как диагностический выезд или проверка оплаты. В остальном процессы похожи: специалисты заполняют свои блоки и назначают ответственного механика, указывают номер ячейки с инструментами, а также фиксируют результаты.
Мы создали фреймворк, включающий в себя стандартный набор инструментов вендора и универсальные наработки, которые решают задачи клиента. Таким образом команда Luckru может быстро развернуть проект на базе Битрикс24, а любую функцию адаптировать под запросы заказчика. Наш опыт показывает, что такой подход снижает издержки разработки и уменьшает сроки готовности проекта. Код получается максимально чистым и требует меньше доработок.Teamlead Алексей Мосиевский
Узнать итоги ✓
В результате проекта, получилась модифицированная под задачи клиента платформа с упрощенной интеграцией сложной 1С. На этом проект не заканчивается — в планах сделать мобильное приложения для механиков, работающее, в том числе и в офлайн-режиме. Через него специалисты будут получать распределенные на них заявки, узнавать номер ячейки по этой заявке, отчитываться по работе (отправлять акты выполненных работ, фотографии техники и описание ситуации).
Основным преимуществом этого грандиозного проекта стало возможность содержать огромный массив данных в одной системе, а также работать через «единое окно»:
- эффективно проводить сделки по алгоритмам (воронка продаж и сервиса), попутно фиксируя данные;
- оперативно получать сведения о различных товарах и сделках (карточки транспорта, сделки, клиента);
- автоматизировать рутинные задачи специалистов (убрали лишние шаги, которые «тормозили» рабочий процесс).
Результат разработки позволяет компании четко разграничивать каждый конкретный случай, даже если у покупателя десяток тракторов. Таким образом, новая система на базе Битрикс24 позволила Стартек не упускает выгоду даже в постпродажном периоде.
Если вам интересно решение схожих задач, оставьте заявку и наши специалисты вам перезвонят в течение 30 минут.
