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