Почему заявки УК опасно синхронизировать в одну сторону
В PDP Mobile сделали двустороннюю синхронизацию заявок с CRM УК: 12 статусов, дерево услуг и mock-режим внешнего API. Рассказываем, где интеграция быстро перестаёт быть простой отправкой формы.
«Зачем нам двусторонняя синхронизация, если заявку можно один раз отправить в CRM?»
Нормальный вопрос. Особенно когда в мобильном приложении заявка выглядит как форма: услуга, адрес, комментарий, отправить. Кажется, что дальше всё живёт в CRM управляющей компании, а приложение может забыть про эту запись.
Наш спорный тезис после задачи в PDP Mobile: для сервисных заявок синхронизация в одну сторону часто хуже, чем отсутствие интеграции. Пользователь видит кнопку в приложении и считает, что приложение знает судьбу заявки. Если статус изменился в CRM, а мобильный клиент продолжает показывать «новая», доверие ломается быстрее, чем интеграция успевает принести пользу.
Заявка — это не сообщение в никуда
В PDP Mobile мы синхронизировали заявки на обслуживание с CRM управляющей компании в обе стороны. В жизненном цикле оказалось 12 статусов: от новой заявки до принятой, работы в процессе, выполненной, отложенной, закрытой и вариантов между ними.
Главная сложность здесь не в количестве статусов само по себе. Двенадцать значений можно положить в enum и разойтись. Проблема в том, что статус меняется не в одном месте.
Житель создаёт заявку в мобильном приложении. Дальше с ней работает УК в своей CRM. Там её принимают, переводят в работу, откладывают, закрывают. Мобильное приложение должно увидеть эти изменения и показать их пользователю. При этом в приложении тоже могут быть действия, которые нужно вернуть обратно в CRM.
На обсуждении быстро всплыл неприятный вопрос: кто владелец статуса? Если сказать «CRM всегда главная», приложение превращается в витрину и теряет часть сценариев. Если считать приложение равноправным источником, нужно аккуратно договориться, какие переходы статусов допустимы с каждой стороны.
И вот тут односторонняя отправка перестаёт выглядеть простой. Она экономит интеграцию на старте, но создаёт серую зону: запись вроде бы отправлена, а что с ней потом — неизвестно.
Дерево услуг нельзя заменить строкой
Вторая часть задачи — каталог услуг. Он иерархический: например, «Сантехника → Замена смесителя → Смеситель с установкой».
Можно было бы отправлять в CRM название выбранной услуги строкой. Это быстрее в реализации, но дальше начинаются вопросы:
- как CRM поймёт, что услуга относится к сантехнике;
- что делать, если название изменится;
- как отличить похожие услуги в разных ветках;
- как строить аналитику по категориям, если структура потерялась при передаче.
Поэтому для интеграции важна не только заявка как объект, но и контекст выбранной услуги. Дерево услуг влияет на маршрутизацию, обработку и отчёты внутри УК. Если мобильное приложение отдаёт только финальное название, оно срезает информацию, которая нужна CRM.
Живая деталь: на этой части было соблазнительно упростить модель до плоского списка. В интерфейсе пользователь всё равно видит конечную услугу. Но интеграция смотрит на данные иначе: ей нужно сохранить путь выбора, иначе часть смысла теряется на границе систем.
Mock-режим — не украшение для тестов
Внешняя CRM в проекте имела mock-режим для тестов. Для такой интеграции это оказалось важнее, чем кажется на первой встрече.
Когда есть 12 статусов и двусторонний обмен, разработка не должна останавливаться из-за недоступного внешнего API. Нужно проверять переходы, обработку ответов, поведение приложения и серверной части без ожидания живой CRM.
Mock-режим помогает прогонять сценарии: новая заявка ушла наружу, CRM вернула принятие, потом «в работе», потом «выполнена» или «отложена». Не надо каждый раз просить внешнюю систему создать нужное состояние руками. И не надо гадать, баг у нас или API сейчас отвечает не тем, что ожидали.
Здесь есть компромисс. Mock не доказывает, что интеграция полностью готова к реальной CRM. Он доказывает, что наша сторона умеет жить по согласованному контракту. Финальная проверка с внешним API всё равно нужна.
Где мы можем быть неправы
Двусторонняя синхронизация не всегда оправдана. Если CRM используется только как архив обращений, а пользователь не ждёт статусов в приложении, односторонней отправки может хватить. Если жизненный цикл состоит из двух состояний и не влияет на клиентский сценарий, полная синхронизация будет лишней нагрузкой.
Но в заявках на обслуживание это редко так. Пользователь отправляет обращение не ради факта отправки. Ему важно понять, приняли ли заявку, взяли ли её в работу, почему отложили, когда закрыли.
Поэтому в PDP Mobile мы пошли в двусторонний обмен: заявка живёт между мобильным приложением и CRM УК, статусы проходят полный цикл, каталог услуг передаётся с иерархией, а разработка не зависит от доступности внешнего API благодаря mock-режиму. Следующий слой такой интеграции — уже не «отправить заявку», а договориться о правилах переходов и источниках правды для каждого статуса.