Почему сервисные компании перерастают таблицы и что приходит на их место

Один консультант ведёт всю практику в двух вкладках: таблица с заявками и папка с предложениями. Год это работает. Потом фирма нанимает троих, берёт в работу двадцать сделок - и таблица тихо превращается в узкое горло.

Форма проблемы

Сервисная компания не продаёт SKU. Она продаёт пакеты работ - и каждый пакет это маленький проект со своим сроком, своими результатами, своей ценой. Поэтому CRM, заточенный под SaaS, не подходит:

• Salesforce рассчитан на один продукт, одну цену, одно закрытие. У вас десять услуг в одной сделке, и каждая строка отдельно обсуждается.
• HubSpot отслеживает письма. А вам нужно отслеживать, кто пишет предложение, кто его проверяет, кто утвердил.
• Notion прекрасно подходит для самого предложения - пока кому-то не понадобится узнать, какие предложения сейчас в работе по всей фирме.

Что реально нужно отслеживать

Воронка сервисной компании - это четыре связанные сущности:

1. Заявка - тот, кто к вам обратился (почта, WhatsApp, рекомендация)
2. Сделка - конкретная возможность с конкретным пакетом работ и стадией
3. Проект - закрытая сделка, которая теперь в исполнении
4. Документ - предложение, контракт или допсоглашение со статусом (черновик, отправлен, подписан)

В таблице эти четыре сущности схлопываются в одну строку. Потом кто-то пытается отфильтровать «сделки с отправленным предложением, но без подписанного контракта» - и формулы рассыпаются.

Что сервисный CRM делает иначе

Он трактует эти четыре сущности как отдельные связанные таблицы со стадиями, владельцами и историей всех изменений. Что это даёт:

• Один вопрос - один фильтр. «Покажи все сделки от десяти тысяч, где предложение ушло больше четырнадцати дней назад и мы ни разу не написали повторно». Запрос в три клика, не час с VLOOKUP.
• ИИ берёт скучную писанину. Предложения собираются из библиотеки услуг. Повторные касания пишутся с человекоподобным интервалом. Команда одобряет, агент отправляет.
• Мульти-арендатор с первого дня. Большинство таблиц обслуживают одну практику. В тот момент, когда вы запускаете дочерний бренд или принимаете партнёрское агентство, модель данных должна клонироваться - и тут универсальные CRM начинают вас удерживать.

Горб миграции

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

• Импортируйте, что уже есть. Достаточно CSV с заявками и тегами, чтобы засеять воронку. Ждать «идеальную» модель данных не нужно.
• Замените сначала один процесс. Обычно это процесс предложения: сборка, проверка, отправка, подпись. Закрепите его - и принятие пойдёт само.
• Оставьте таблицу только для чтения на шестьдесят дней. Это страховочное одеяло. Через шестьдесят дней её никто не открывает.

День, когда команда перестаёт спрашивать «где последняя версия предложения», - это день, когда CRM окупился.