Сервис ремонта техники: приём, диагностика и SMS о готовности в своей системе

MAATRIX

Клиент сдал смартфон на диагностику, приёмщик написал на бланке «не включается, разбит экран», мастер через два дня забыл, что говорил клиенту, а SMS о готовности либо не пришло, либо пришло позже, чем телефон реально починили. Знакомая картина для сервиса ремонта техники — от мастерской на два стола до сети приёмных пунктов. Бланк, память мастера и чужой SMS-сервис не складываются в один процесс, и каждый стык между ними — источник потерянной заявки или недовольного клиента. Ниже — как собрать приём, диагностику и уведомления в одной системе на своём сервере, без платы за облачный тикет-трекер и без зависимости от постороннего SMS-провайдера.

Почему бумажный бланк и общий чат — это не процесс

Типичная картина: приёмщик заполняет бланк, мастер общается с ним устно или в общем чате, а о готовности клиенту звонят или отправляют SMS вручную через панель стороннего провайдера. У каждого звена свой формат и своя память, посмотреть задним числом, что происходило, нечем.

Отсюда три конкретные проблемы:

• Заявка теряется физически. Бланк не в той стопке, потерялся при передаче смены, или два мастера взяли одно устройство с разных концов прилавка.
• Диагностика зафиксирована только в голове мастера. Если он заболел, а деталь не пришла за неделю, следующий начинает диагностику заново — клиент платит временем ожидания.
• Статус сообщается по случайности. Кто-то не написал SMS, потому что был занят; кто-то отправил не тот текст не тому номеру.

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

Что значит «единая система» на практике

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

1. Приём. Форма у приёмщика: клиент, телефон, устройство, неисправность, комплектность, повреждения — с фото. Заявке присваивается номер, который печатается на квитанции.
2. Диагностика. Мастер открывает заявку по номеру, добавляет заметки: что подтвердилось, деталь, стоимость, срок. Видно любому, кто откроет заявку позже.
3. Уведомление. Как только статус меняется на «готово» или «нужно согласовать стоимость», система сама шлёт клиенту SMS — без человека, который может забыть.

Технически это веб-приложение (готовая система для сервисных центров или самописное на PostgreSQL + бэкенд-фреймворк) плюс интеграция с SMS-шлюзом по API на одном сервере, доступное приёмщику и мастерам через браузер по локальной сети или VPN.

Приём заявки: что фиксировать сразу

Хорошая карточка приёма закрывает вопросы, из-за которых потом возникают споры: «экран был треснут ДО ремонта» или «я не просил менять батарею». Минимальный набор полей:

Заявка #: (генерируется автоматически)
Клиент: ФИО, телефон
Устройство: тип, марка, модель, серийный/IMEI
Заявленная неисправность: со слов клиента
Внешний осмотр: видимые повреждения (текст + фото)
Комплектность: что сдано вместе с устройством
Дата приёма, приёмщик
Ориентировочный срок диагностики

Фото на этапе приёма — не формальность: в спорах о царапинах, «появившихся уже в сервисе», фотография с таймстампом закрывает вопрос за секунды. А клиенту на квитанции или в SMS достаточно короткого номера заявки и контакта для проверки статуса, без ссылки на внутреннюю карточку с IMEI — это видят только сотрудники.

Диагностика: как не потерять контекст между мастерами

Правило простое: всё, что мастер узнал, попадает в карточку заявки, а не в его память или переписку с приёмщиком. На практике — лог записей внутри заявки:

2026-08-24 10:15 — Мастер Иван: вскрыл, разбит экран + отходит шлейф дисплея
2026-08-24 10:40 — Мастер Иван: батарея в норме, деталь на заказ, срок 2 дня
2026-08-26 14:20 — Мастер Пётр: экран пришёл, установлен, тест пройден
2026-08-26 14:25 — Система: статус изменён на "Готово", отправлено SMS клиенту

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

Отдельный статус — диагностика с озвучкой стоимости, не «готово»: клиенту уходит SMS с просьбой подтвердить, и мастер не трогает устройство без ответа. Это защищает и сервис, и клиента от сюрприза в чеке.

SMS о готовности: как это работает технически

Автоматическая отправка требует трёх вещей: аккаунта у SMS-провайдера с доступом по API, шаблонов сообщений и триггера на смену статуса. У большинства провайдеров похожая механика — HTTP-запрос с номером, текстом и API-ключом:

curl -X POST "https://api.sms-provider.example/send" \
  -H "Authorization: Bearer $SMS_API_KEY" \
  -d "phone=79161234567" \
  -d "text=Ваш заказ №4821 готов. Забрать по адресу... до 20:00."

В приложении это функция на смену статуса: берёт шаблон, подставляет номер заявки и адрес, отправляет SMS, логирует событие. Два нюанса заранее: сбой отправки (нет баланса, невалидный номер) система логирует и показывает приёмщику список заявок с неотправленным уведомлением — чтобы позвонить вручную, а не полагаться на «наверное, ушло». И не дублировать уведомления — SMS уходит только при реальном переходе в статус, не при каждом клике.

Если провайдер недоступен, тем же триггером можно слать уведомление в Telegram-бота — поднять простого бота на своём VPS — задача на пару часов. Похожая логика уже разбиралась на примере автосервиса: онлайн-запись и напоминания в мессенджер устроены тем же принципом.

Архитектура: что где хранится

Для одного пункта приёма достаточно связки: веб-приложение и база данных PostgreSQL на одном VPS. Если точек несколько — центральная база, к которой каждая подключается через VPN или HTTPS с авторизацией.

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

Сколько это стоит и когда окупается

Три статьи расходов заменяются одним сервером: SMS-подписка, тикет-система или CRM по подписке с ограничением по числу пользователей, и время на устные передачи и разбор споров — не деньги напрямую, но реальные часы.

Своя система на VPS убирает первые два пункта как подписки: вы платите за аренду сервера и, при необходимости, за SMS напрямую провайдеру, без наценки посреднической панели. Разовые затраты — время на настройку: с готовым open-source решением это дни, с нуля — дольше, но с точным соответствием специфике. Логику такого расчёта разбирали на примере облачной CRM автосервиса против своего сервера: механика та же, меняются только суммы.

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

Частые вопросы