Legaltech-платформа для юридической компании: что автоматизировать, а что не стоит

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

Разберём по частям, опираясь на кабинет для партнёрской сети URITECH — платформу для ведения процедур банкротства физлиц, которую мы делали шесть месяцев командой из пяти человек.

Почему обычная CRM не подходит

Первый порыв любой юридической компании, выросшей из Excel, — купить amoCRM или Битрикс24 и настроить воронку. Это работает ровно до момента, когда выясняются три вещи.

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

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

Сроки внешние, а не ваши. Дедлайн ставит не руководитель отдела, а закон. Просроченный срок в продажах — упущенная сделка, просроченный срок в процедуре — испорченное дело клиента.

Дальше начинается настройка CRM под эти требования, и через год компания приходит к тому, что каждое изменение процесса упирается в ограничения коробки. Это стандартная развилка «коробка или заказная разработка» — мы разбирали её отдельно, и в legaltech она проходит раньше, чем в большинстве отраслей.

Статус-машина вместо канбана

Правильная модель юридического процесса — явная state machine: список состояний, разрешённые переходы между ними и условия каждого перехода. В URITECH таких состояний больше тридцати на одну процедуру.

Что это даёт на практике:

• Невозможные переходы просто не существуют. Не «валидация запретила», а в интерфейсе нет такой кнопки. Разница принципиальная: валидацию можно обойти через API, отсутствующий переход — нет.
• История переходов пишется автоматически. Кто перевёл дело на следующий этап и когда — это не отдельная фича логирования, а побочный эффект самой модели.
• Прогресс виден без отчётов. Если процедура — это позиция в известной последовательности, то ответ на вопрос «где мы» не требует ничьей ручной работы.

Главное возражение, которое приходится слышать: «а если процесс изменится?» Изменится — и это нормально. Поэтому переходы описываются данными, а не размазываются по коду обработчиков. Тогда добавление нового этапа — правка конфигурации, а не рефакторинг.

Документы: DOCX, а не PDF

Неочевидная вещь, о которой стоит знать до начала разработки: юристы правят документы после генерации. Всегда. Никакой шаблон не покроет всех формулировок, и юрист по определению человек, который меняет формулировки.

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

Что ещё оказывается важным в генерации:

• Шаблоны меняются через админку, без релизов. Формулировка в шаблоне меняется чаще, чем выходит новая версия платформы. Если для правки запятой нужен деплой, юристы вернутся в Word.
• Версионирование шаблонов. Документ, сгенерированный полгода назад, должен объясняться той версией шаблона, которая действовала тогда, — иначе разобрать спорную ситуацию невозможно.
• Подстановка данных проверяема. Юрист должен видеть, откуда взялось поле, а не доверять чёрному ящику.

Деньги — самое опасное место

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

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

Второе правило: никаких расчётов в интерфейсе. Если сумма считается на фронтенде, рано или поздно фронтенд и бэкенд разойдутся, и обнаружит это партнёр, а не разработчик.

Что автоматизировать не нужно

Раздел, который в коммерческих предложениях обычно отсутствует.

Юридическую оценку. Соблазн прикрутить модель, которая «сама определит перспективность дела», велик — но ответственность за оценку несёт юрист, и переложить её на систему не получится. Максимум, что имеет смысл, — подсветить формальные признаки: комплектность документов, попадание в сроки.

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

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

Что действительно окупается

По опыту URITECH, наибольший эффект дают три вещи, и ни одна из них не выглядит эффектно на демо.

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

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

Аудит-лог по чувствительным операциям. Юридическая сфера живёт под 152-ФЗ и 115-ФЗ, и вопрос «кто и когда это сделал» возникает не в теории. Отдельно стоит закладывать soft delete: в юридической системе ничего не должно исчезать бесследно — ни документ, ни запись, ни пользователь.

Сроки и бюджет

Ориентиры для платформы такого класса: discovery и карта процессов — 2–4 недели, MVP с одной ключевой ролью — 2–3 месяца, полный контур с документами, платежами и обучением — от полугода. URITECH занял шесть месяцев командой из пяти человек.

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

Итог

Legaltech отличается от обычной B2B-автоматизации тем, что процесс здесь не ваш: его задаёт закон, и подстраиваться приходится системе. Отсюда статус-машина вместо гибкой воронки, DOCX вместо PDF, полное покрытие тестами финансовых расчётов и аудит-лог как обязательный, а не опциональный элемент.

Если у вас юридическая практика, выросшая из Excel и мессенджеров, — посмотрите услугу разработки legaltech-платформ и кейс URITECH: там подробно разобрано, как устроен партнёрский кабинет и из каких модулей он собран.