Заказ наряд автосервис: система за 8 шагов в 2026

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

Обычно всё начинается с одного и того же вопроса клиента: машина уже готова?

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

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

Особенно неприятно становилось с дополнительными работами. Мастер находил неисправность, писал об этом в переписке, клиент отвечал там же. Но сам заказ-наряд не всегда показывал, что именно согласовано. Приходилось снова спрашивать: что нашли, что разрешили делать, что уже выполнено.

На странице шаблона Rukovoditel перечислены абонентская плата, ограничения тарифов и не самый понятный интерфейс. Ссылку оставляю ниже, чтобы ты сам сравнил.

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

Я решил начать не с большой CRM, а с одного понятного правила: дополнительную работу нельзя считать выполненной и включать в итог, пока клиент её не согласовал. Из этого правила и вырос весь журнал.

Что изменится в буднях, когда статус машины виден сразу?

В начале дня я открываю лист «Наряды» и вижу машины на ремонте. Не надо листать чат и искать последний звонок. У каждой строки есть этап: диагностика, ожидание согласования, в ремонте, контроль, готово к выдаче или выдано.

Рядом стоит отдельная отметка готовности. Она не означает, что машина просто перестала быть на подъёмнике. Это сигнал: необходимые работы завершены, согласованные позиции учтены, клиенту уже можно звонить.

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

Так не возникает привычной путаницы:

• найдено не значит согласовано;
• согласовано не значит выполнено;
• выполнено не значит готово к выдаче;
• отправлено клиенту не значит, что клиент ответил.

На странице AutoSTO приведён ориентир до 20 минут экономии на одном заказ-наряде. Для условного примера можно умножить 20 минут на 100 заказов: получится 2 000 минут, то есть около 33 часов. Это расчёт по указанному ориентиру, а не обещание для каждого сервиса: результат зависит от числа машин, дисциплины мастеров и прежнего объёма ручной работы. Расчёт AutoSTO. У тебя результат зависит от числа машин, дисциплины мастеров и того, сколько действий раньше делалось вручную.

Для меня ценнее не сама арифметика. Я перестал задавать мастерам один и тот же вопрос: «Что с машиной?» Вопрос стал конкретным: «Почему этот наряд всё ещё на согласовании?» Так разговор превращается из поиска информации в действие.

Почему свой журнал подходит для задачи «заказ наряд автосервис»?

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

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

Со своей сборкой я сам задаю порядок. Например:

1. Мастер добавляет дополнительную работу.
2. Позиция получает статус «На согласовании».
3. Клиент отвечает «Согласовано» или «Отклонено».
4. Только согласованная позиция попадает в сумму.
5. Наряд не переходит в готовность, если обязательная работа не завершена.

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

В готовых отраслевых системах такие возможности встречаются. Например, «АвтоДилер Онлайн» отдельно указывает операцию согласования новых товаров и работ. Но готовая система одновременно закрывает и другие контуры. Если нужна только видимость текущего этапа, собственный журнал может быть проще.

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

Из чего состоит журнал заказ-нарядов?

Если искать «заказ наряд на работы в автосервисе», часто попадаются бланки. Для ежедневной работы одного бланка мало. Мне нужен реестр, который показывает не только состав работ, но и движение машины по этапам.

Лист «Наряды»

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

Номер наряда | Дата приёмки | Клиент | Телефон | Автомобиль | Жалоба клиента | Результат диагностики | Текущий этап | Готово к выдаче | Итог согласованных работ | Итог согласованных запчастей | Итого | Ответственный

В строке не надо перечислять все детали ремонта. Она нужна для быстрого ответа на вопрос: где машина и что с ней сейчас.

Этапы можно начать с простого набора:

Запись
Принят
Диагностика
Ожидает согласования
В ремонте
Контроль
Готов к выдаче
Выдан
Отменён

Лист «Работы и запчасти»

Каждая работа или деталь получает отдельную строку на листе «Работы и запчасти». В ней хранятся номер наряда, тип позиции, наименование, количество, цена, сумма, почему добавили эту работу или запчасть, согласование, выполнение и комментарий. Так найденная дополнительная работа остаётся видимой, но не попадёт в итог, пока клиент её не согласовал.

Номер наряда | Тип | Наименование | Количество | Цена | Сумма | Причина появления позиции | Согласование | Выполнение | Комментарий

Тип бывает «Работа» или «Запчасть». Поле «Причина появления позиции» показывает: это жалоба клиента, результат диагностики или дополнительная работа.

Статус согласования:

Не предложено
На согласовании
Согласовано
Отклонено

Статус выполнения:

Не начато
В работе
Выполнено

Дополнительная работа хранится отдельной строкой. Не прячь её в комментарии. Иначе она выпадет из расчёта, фильтра и проверки готовности.

Лист «Справочники»

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

• этапы наряда;
• статусы согласования;
• статусы выполнения;
• сотрудники;
• типовые работы;
• типовые запчасти;
• разрешённые переходы между этапами.

Google Таблицы умеют отклонять значение, которого нет в заданном списке:

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

Это защищает от случайных вариантов вроде «в ремонте», «ремонт» и «ремонтируем». Но выпадающий список не контролирует порядок этапов. Для этого нужен скрипт.

Что поставить перед сборкой и сколько это стоит?

После установки редактора сначала видишь тёмное окно с файлами. Писать код вручную для базовой сборки не обязательно: VS Code становится рабочей папкой, где можно увидеть результат помощника.

Claude Code это отдельный инструмент Anthropic для работы с кодом. Сначала проверь, как этот инструмент запускается у тебя и с чем он соединяется. Вместо технического задания вроде «создай функцию обработки события» можно написать: «не разрешай переводить наряд из диагностики сразу в готовность». Помощник разбирает техническую часть и объясняет, какие файлы изменил.

Установка инструментов может занять некоторое время. Это не сборка всей системы: журнал нужно проверить на тестовой машине, прогнать разные сценарии и настроить уведомления.

Подписка постоянная. Официальная цена Claude Pro - $20 в месяц. По статье РБК от 7 июля 2026 года, рассчитанной по курсу мая, ориентир составляет около 1 470-1 500 ₽ в месяц при прямой оплате зарубежной картой. Рублёвый итог через посредника зависит от его комиссии и отдельно не подтверждён. Ни одна из рублёвых сумм не является официальным тарифом Anthropic.

Не проси помощника сразу сделать всю CRM. Начни с журнала и одного правила. Чем меньше первый результат, тем проще понять, где ошибка.

Как собрать журнал заказ-нарядов по шагам?

1. Опиши процесс до сборки.

   Создай папку проекта, открой её в VS Code и попроси помощника сначала задать вопросы. Не начинай со слов «сделай CRM». Опиши, как машина проходит путь от приёмки до выдачи.

   Разобрать процесс автосервисаСкопировать промпт

   У меня небольшой автосервис. Я принимаю автомобиль, записываю жалобы клиента, передаю машину на диагностику, согласовываю дополнительные работы, жду запчасти, контролирую ремонт и выдаю автомобиль. Сейчас статусы находятся в бумажных нарядах, переписках и памяти. Хочу журнал заказ-нарядов, где по каждой машине видно этап, диагностику, согласованные работы, сумму и готовность к выдаче. Пока не пиши код. Разбери процесс, перечисли нужные данные и задай вопросы, если чего-то не хватает. Сохрани понятный план в файл plan.md. Не используй сложные технические термины.

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

2. Создай три листа.

   Попроси помощника собрать основу: «Наряды», «Работы и запчасти», «Справочники». На этом шаге не добавляй Telegram и сложные интеграции.

   Создать основу журналаСкопировать промпт

   Создай Google Таблицу для журнала заказ-нарядов с тремя листами: «Наряды», «Работы и запчасти», «Справочники». На листе «Наряды» сделай поля: номер наряда, дата приёмки, клиент, телефон, автомобиль, госномер, VIN, жалоба клиента, результат диагностики, текущий этап, готово к выдаче, итог согласованных работ, итог согласованных запчастей, итого, последнее изменение и ответственный. На листе «Работы и запчасти» сделай поля: номер наряда, тип, наименование, количество, цена, сумма, причина появления позиции, согласование, выполнение и комментарий. На листе «Справочники» создай списки этапов, статусов согласования, статусов выполнения и сотрудников. Пока не добавляй уведомления и интеграции. Покажи мне структуру полей и объясни связь между листами.

   Проверь схему и связь между листами: номер наряда должен быть на обоих рабочих листах. Это связь между машиной и её позициями.

3. Добавь выпадающие списки.

   Попроси помощника использовать значения со страницы «Справочники». Нельзя оставлять этапы и статусы свободным текстом.

   Добавить списки значенийСкопировать промпт

   Добавь в таблицу выпадающие списки. На листе «Наряды» поле «Текущий этап» должно брать значения из справочника этапов, а поле «Готово к выдаче» - только «Да» или «Нет». На листе «Работы и запчасти» поля «Тип», «Причина появления позиции», «Согласование» и «Выполнение» должны брать значения из соответствующих справочников. Если сотрудник вводит значение, которого нет в списке, таблица должна его отклонять или показывать ошибку. Не меняй названия листов и не удаляй существующие поля. После настройки дай мне список проверок, которые надо сделать глазами.

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

4. Свяжи этапы ремонта.

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

   Проверить последовательность этаповСкопировать промпт

   Добавь проверку переходов для листа «Наряды». Разрешённые переходы такие: «Запись» в «Принят», «Принят» в «Диагностика», «Диагностика» в «Ожидает согласования» или «В ремонте», «Ожидает согласования» в «В ремонте», «В ремонте» в «Контроль», «Контроль» в «Готов к выдаче», «Готов к выдаче» в «Выдан». Если новое значение нарушает последовательность, верни старое значение и покажи понятное предупреждение. Используй обработчик изменения таблицы. Записывай дату и время последнего изменения. Перед правкой покажи, какие файлы или скрипты изменишь. Объясни, как установить и проверить обработчик на тестовом наряде.

   В документации Google описан триггер onEdit(e): он срабатывает, когда пользователь меняет значение ячейки в таблице. Справка Google Apps Script

   Само правило автосервиса не встроено в Google Таблицы. Его создаёт скрипт, поэтому проверь переходы вручную: сначала разрешённый, затем запрещённый.

5. Посчитай только согласованное.

   Итог по наряду не должен складывать все найденные позиции. Несогласованная работа остаётся видимой, но не попадает в сумму.

   Посчитать согласованные работыСкопировать промпт

   Добавь расчёт на лист «Наряды». Поле «Итог согласованных работ» должно суммировать количество умножить на цену только по строкам листа «Работы и запчасти», где номер наряда совпадает и поле «Тип» равно «Работа», а поле «Согласование» равно «Согласовано». Поле «Итог согласованных запчастей» должно работать так же для типа «Запчасть». Поле «Итого» должно складывать два результата. Несогласованные и отклонённые позиции должны оставаться видимыми в списке, но не входить в сумму. Покажи тестовый пример с тремя позициями и объясни ожидаемый итог.

   Проверь пример глазами. Если одна позиция стоит 8 500 ₽ и имеет статус «На согласовании», сумма не должна увеличиться на 8 500 ₽.

6. Добавь признак готовности.

   Одного ручного флажка мало. Попроси связать его с этапом и незавершёнными согласованными работами.

   Сделать проверку готовностиСкопировать промпт

   Настрой поле «Готово к выдаче» на листе «Наряды». Значение «Да» должно появляться только тогда, когда текущий этап равен «Готов к выдаче» и среди строк этого наряда нет согласованных, но невыполненных работ или запчастей. Если условие не выполнено, показывай «Нет». Не учитывай отклонённые и ещё не согласованные позиции как выполненные работы. Добавь понятное пояснение в отдельную колонку или комментарий, если готовность не наступила. Не меняй данные тестовых нарядов без предупреждения.

   После ответа создай тестовый наряд с одной согласованной невыполненной работой. Перевод в «Готов к выдаче» должен быть заблокирован или дать «Нет».

7. Добавь уведомления после проверки.

   Уведомления нужны только после того, как сам журнал работает. Для действий, которым нужны сервисы с авторизацией, может потребоваться устанавливаемый триггер.

   Добавить внутренние уведомленияСкопировать промпт

   Добавь уведомления только для владельца автосервиса. Отправляй сообщение, когда новый наряд принят, когда появилась дополнительная работа со статусом «На согласовании» и когда машина перешла в «Готов к выдаче». В сообщении показывай номер наряда, автомобиль, текущий этап и следующий шаг. Не отправляй рекламные предложения клиентам. Храни в отдельном техническом листе дату события, тип события, номер наряда, статус отправки и текст ошибки. Используй устанавливаемый триггер для действий, которым требуется авторизация. Объясни, где выдать разрешения и как проверить повторную отправку после ошибки.

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

8. Проверь тестовыми нарядами.

   На этом шаге не добавляй новые функции. Прогони реальные сценарии на выдуманных данных.

   Подготовить проверку журналаСкопировать промпт

   Составь тестовый план для журнала заказ-нарядов автосервиса. Проверь: создание наряда, переход от приёмки к диагностике, добавление найденной работы, отказ в переходе через этап, добавление несогласованной работы, согласование одной позиции, расчёт суммы только по согласованным позициям, перевод в «Готов к выдаче», отмену наряда, повторное открытие таблицы и появление уведомления. Для каждого теста напиши исходные данные, действие, ожидаемый результат и признак ошибки. Не меняй код и данные, пока я не подтвержу результат теста.

   После этого выполни таблицу проверок на тестовой машине; новые функции пока не добавляй. Перед переносом рабочих данных создай копию журнала.

   Я не писал код сам: описывал задачу помощнику и проверял каждый шаг. Такой подход часто называют вайб-кодингом.

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

Что появится в папке после сборки?

Обычно структура выглядит примерно так:

avtoservis-journal/
├── plan.md
├── README.md
├── appsscript/
│   ├── этапы
│   ├── расчёты
│   └── уведомления
├── справочники/
└── резервные_копии/

Названия файлов могут отличаться. Смотри на назначение файлов, а не на их названия:

• plan.md хранит описание процесса;
• скрипт этапов проверяет переходы;
• расчёты считают только согласованные позиции;
• уведомления запускают сообщения;
• справочники хранят допустимые значения;
• резервные копии позволяют вернуться к рабочему состоянию.

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

Не удаляй скрипт только потому, что он выглядит непонятно. Сначала попроси помощника объяснить конкретный файл простыми словами. И не редактируй его вручную без резервной копии.

Практикум по сборке и проверке системы

Если хочешь разобрать процесс руками, на практикуме можно описать задачу, проверить результат и исправить ошибки. Открыть практикум.

Что делать, если статус не меняется или сообщение не приходит?

1. После сбоя появился дубль. Повторное событие могло создать вторую строку или отправить сообщение дважды. Проверь уникальный идентификатор события и попроси помощника добавить защиту от повторной обработки.

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

2. Работают два экземпляра бота. Не запускай одновременное получение обновлений одним токеном в тестовой и рабочей копии: это может вызвать конфликт. Проверь процессы и отключи лишний экземпляр.

Сообщения приходят нестабильно, а в журнале появляются пропуски. Проверь, не используется ли один токен интеграции одновременно в двух экземплярах проекта. Найди настройки рабочей и тестовой среды, не показывая секретный токен в ответе. Добавь понятную проверку среды и запись имени экземпляра в технический журнал. Не меняй рабочий токен без моего подтверждения.

При использовании одного токена двумя экземплярами Telegram может вернуть ошибку конфликта при получении обновлений; точный текст зависит от библиотеки и способа интеграции. Это ограничение описано в FAQ Telegram о ботах. Тестовую копию держи на отдельном боте.

3. Появилась ошибка лимита API. Если конкретный API вернул код 429, проверь его документацию: это может быть ограничение частоты запросов. Не заставляй скрипт бесконечно повторять запись.

При добавлении согласования появляется ошибка 429, чтение таблицы иногда проходит, а запись не сохраняется. Найди все обращения к API и покажи, какие из них повторяются лишний раз. Добавь очередь записи, повтор с увеличивающейся паузой и понятный статус «ожидает отправки». Не удаляй событие при ошибке. После исправления подготовь тест на десяти последовательных записях.

У Google Apps Script есть ограничения по квотам. Если выполнение остановилось из-за лимита, журнал должен показывать не только экран, но и очередь неотправленных действий. Подробности смотри в документации о квотах Apps Script.

4. Истёк токен доступа. Если конкретный API возвращает 401 или 403, сверяйся с его документацией: причины могут быть связаны с авторизацией или правами доступа. Проверь токен, разрешения и процедуру повторной авторизации.

Уведомления перестали уходить, а в техническом журнале появились ошибки 401 или 403. Проверь, где хранится токен, есть ли срок его действия и что происходит после отказа авторизации. Не выводи секреты. Добавь понятную запись «нужна повторная авторизация», сохрани сообщение в очереди и не помечай его доставленным. Опиши ручные шаги восстановления для владельца автосервиса.

5. Сообщение исчезло без ошибки. Событие могло быть получено, но не записано. Добавь отдельную запись сразу при приёме сообщения, ещё до дальнейшей обработки.

Клиент говорит, что отправил согласование, но в журнале нет ни сообщения, ни ошибки. Проверь путь события от получения до записи в таблицу. Добавь техническую запись сразу после приёма: event_id, дата, номер наряда если он найден, исходный текст, статус «получено». Затем отдельными статусами отмечай «обработано», «записано», «уведомление отправлено» и «ошибка». Не удаляй исходное событие при неудаче.

6. Таблица стала слишком большой. Если при каждом изменении загружается весь архив, журнал начнёт тормозить. Раздели активные и закрытые наряды.

Журнал стал медленно открываться и долго сохраняет одну новую строку. Проверь, не загружается ли вся история заказ-нарядов при каждом изменении. Предложи безопасное разделение активных и архивных нарядов, не удаляя данные. В активном листе оставь поля, нужные для текущей работы, а в архиве сохрани полную историю. Покажи план переноса и способ восстановления из копии.

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

У дополнительной работы стоит статус «Ожидает согласования», но клиент не получил сообщение. Проверь, начал ли клиент диалог с ботом, есть ли выбранный канал связи и записана ли попытка доставки. Если Telegram недоступен, не переводи наряд дальше автоматически. Покажи оператору резервный шаг: звонок или другое согласованное сообщение. Не отправляй рекламу.

8. Этап есть, но никто не действует. Статус сам по себе не устраняет просрочку. Для каждого этапа нужен ответственный и следующий шаг.

В журнале много нарядов на этапе «Ожидает согласования», но система не показывает, кто должен действовать. Добавь поля «Ответственный», «Следующий шаг» и «Срок». Сделай предупреждение о просрочке без рекламных сообщений. Не меняй этап автоматически. Покажи руководителю список нарядов без ответственного и нарядов, где срок прошёл.

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

Сколько стоит своё решение и когда лучше готовый сервис?

Если нужен только журнал с этапами, допработами и готовностью, подписка помощника даёт возможность собирать и менять собственную схему. Но подписка не заменяет поддержку, резервное копирование и ответственность за данные.

Для сравнения:

Цены сверяй на страницах Claude, «АвтоДилер Онлайн» и Birdyx.

Готовый сервис с тарифом от 599 ₽ может оказаться дешевле подписки. Он уже содержит заказ-наряды и другие функции. Собственная сборка оправдана, когда нужно сделать узкое правило под себя, даже если она не снижает расходы.

Такой журнал особенно полезен, если вместе с ним нужны:

• склад и автоматическое списание деталей;
• касса и чеки;
• зарплата мастеров;
• нормочасы;
• права доступа для ролей;
• несколько филиалов;
• бухгалтерские интеграции;
• печатные документы;
• история автомобиля;
• закупки и поставщики.

У «АвтоДилер Онлайн» в заказ-наряде заявлены товары со склада, платежи, печать документов и другие контуры. Это уже не просто журнал.

Не смешивай сервисное уведомление и рекламу. Сообщение «по заказ-наряду обнаружена дополнительная работа» относится к ремонту. Рекламная вставка может изменить правовую квалификацию сообщения, поэтому проверь требования к согласию по применимой юрисдикции и настрой отдельное согласие.

Что сделать сегодня, если не разбираешься в технологиях?

Безопасный порядок такой:

1. Возьми один типовой ремонт.
2. Выпиши поля приёмки и диагностики.
3. Отдельно перечисли работы и запчасти.
4. Отметь, что требует согласования.
5. Проверь, что несогласованная позиция не входит в сумму.
6. Проверь переходы этапов.
7. Сделай резервную копию.
8. Только после этого добавляй сообщения.

Service-Online может подойти для быстрого старта. На указанной странице описан онлайн-бланк со статусами работ: согласованные, рекомендованные и отклонённые. Это удобно, чтобы проверить саму идею раздельного учёта, а остальные функции нужно оценить отдельно.

По описанию Service-Online это онлайн-бланк; наличие полноценной истории этапов, ответственных и уведомлений нужно проверить отдельно. Поэтому используй его как временный вариант или проверку процесса.

Excel тоже остаётся рабочим выбором, если весь сервис уже работает на Windows и одном компьютере. Но чаты и Excel не сводятся сами к концу дня. Если информация живёт в двух местах, проблема статуса останется.

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

Вопросы и ответы