Если ремонтная мастерская работает не по шаблону — принимает сложную электронику, ведет покомпонентный ремонт или согласовывает работы с клиентом поэтапно, — готовая CRM часто не подходит. Доработка обойдется в сумму от 300 000 российских рублей (для сравнения: запуск MVP SaaS-продукта стартует от этой же суммы при сроке от 8 недель) до полумиллиона, если процессы нестандартные и под них пишут отдельную админку. В этой статье я разложу, из чего складывается реальный бюджет и как не переплатить за ненужные функции на старте.
Почему готовая CRM не подходит для нестандартного ремонта?
Классические CRM создавались для компаний, где менеджер получает заявку, общается с клиентом, отрабатывает возражения и закрывает сделку. Это работает для продажи корпоративного оборудования или услуг. В сервисном центре всё иначе: ремонт может длиться неделю, за это время меняется цена запчастей, клиент согласовывает дополнительные работы, а мастер вносит данные о комплектующих и дефектах. Типовая CRM не умеет вести сложные жизненные циклы заказа.
Вот где стандартный функционал ломается: мастеру нужно видеть историю ремонтов устройства, а не просто карточку контакта; бухгалтеру — точно знать, какие детали списаны, а какие ещё в пути; клиенту — получать уведомления о статусе, когда деталь пришла или ремонт затягивается. Без доработок CRM превращается в дорогую записную книжку.
Из чего складывается бюджет на доработку CRM: модули и их стоимость
Бюджет на кастомную разработку не выражается одной цифрой. На практике стоимость считают не «от и до», а набором модулей: ядро сервиса, админка, платежи, интеграции, инфраструктура. Для сервисного центра ключевых модулей обычно пять.
| Модуль | Что входит | Примерный срок (недель) | Доля бюджета (ориентир) |
|---|---|---|---|
| Ядро (база данных, авторизация, роли) | Пользователи, права доступа, хранение заказов и клиентов | 1–2 | 20–25% |
| Управление заказами и ремонтами | Статусы, приёмка, согласование, привязка запчастей, история ремонтов по серийному номеру | 2–4 | 30–35% |
| Биллинг и платежи | Расчёт стоимости ремонта, выставление счёта, приём оплаты, возвраты | 1–3 | 15–20% |
| Интеграции (телефония, SMS, сайт) | Подключение облачной АТС, отправка уведомлений, синхронизация заказов с сайтом | 1–2 | 10–15% |
| Админка и отчёты | Настройка процессов, дашборды, выгрузка данных для бухгалтерии | 1–2 | 10–15% |
Срок внедрения готовой CRM с базовой настройкой — неделя-полторы. Если нужны интеграции с сайтом, оплатой и доставкой — три-шесть недель. Для нестандартных процессов, когда пишется отдельная админка, закладывайте от двух месяцев.
Какие доработки реально нужны в первую версию (MVP), а какие — подождут?
Простое правило: MVP закрывает один платный сценарий целиком, а не пять сценариев наполовину. Для сервисного центра это означает: сначала добейтесь, чтобы мастер мог принять устройство, назначить статус, привязать клиента и закрыть заказ с расчётом стоимости. Всё остальное — вторая очередь.
Вот типичная ошибка: владелец мастерской заказывает сразу интеграцию телефонии, синхронизацию с сайтом и мобильное приложение для клиента. На деле без работающего ядра эти интеграции висят мёртвым грузом. Интеграция телефонии с CRM действительно нужна, чтобы ни один звонок не потерялся — данные о звонках часто живут отдельно от CRM, а про пропущенный менеджер узнаёт слишком поздно. Но её можно подключить уже после того, как основной процесс ремонта отлажен.
Сколько стоит MVP для сервисного центра? Если отталкиваться от описанной выше модульной структуры, минимальная версия (ядро + управление заказами) займёт 3–4 недели работы команды и составит примерно 50–55% от полного бюджета. Остальное — интеграции, биллинг и админка — можно добавлять по мере роста выручки.
Три типичные ошибки при расчёте бюджета на доработку CRM
- Заказ всех интеграций сразу. Телефония, сайт, Telegram-бот, SMS-уведомления — каждая интеграция добавляет 1–2 недели разработки. На старте достаточно одной: например, только уведомления клиенту о смене статуса. Остальные подключайте, когда увидите, что без них теряете заказы.
- Игнорирование админки. Без панели для настройки процессов любое изменение (добавили новый тип ремонта, сменили поставщика запчастей) требует вызова разработчика. Админка может быть простой — 3–4 экрана — но без неё CRM быстро устареет.
- Экономия на проектировании. Проектирование веб-приложений начинается не с открытия редактора кода, а с ответов на вопросы: кто будет пользоваться сервисом, какие роли и сценарии, какие данные хранятся. Если пропустить этот этап, переделки в середине разработки обходятся в разы дороже правки макета в Figma.
Как не переплатить: 3 шага, которые можно сделать на этой неделе
Вот что стоит сделать до того, как брать смету у разработчика.
- Опишите один сквозной сценарий. Возьмите самый частый заказ — от звонка клиента до выдачи отремонтированного устройства. Распишите каждый шаг: кто и что делает, какие данные вводит, какие документы печатает. Это станет техническим заданием для MVP.
- Проверьте, можно ли закрыть сценарий настройками готовой CRM. Например, в некоторых системах можно добавить кастомные поля для серийного номера и даты следующего ремонта. Если хватает — доработки не нужны. Если нет — оцените, какой модуль придётся писать с нуля.
- Запросите оценку у 2–3 разработчиков. Дайте им описание сценария из пункта 1. Честный разработчик сразу скажет, что можно сделать стандартными средствами, а что — только кодом. Если все оценки сходятся с модульной структурой из таблицы выше, бюджет реалистичный.
