Техническая поддержка оборудования: учёт заявок на ремонт

Кратко

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

Актуально на 23 сентября 2026 года.

Обязательные поля заявки на ремонт

Этапы ремонта — статусы, а не один «в работе»

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

Отдельный статус на время ожидания детали важен: он не должен портить показатель скорости ремонта, потому что задержка из-за поставки — это отдельная причина простоя, а не медленная работа мастера.

Как посчитать реальную стоимость простоя

Стоимость простоя = время простоя в часах × стоимость часа простоя этой единицы оборудования.

Пример: конвейерная линия простаивает 6 часов, час простоя обходится в 45 000 ₸ по расчёту недополученной продукции → 270 000 ₸ прямых потерь за одну поломку, не считая стоимости самого ремонта. Такой расчёт по каждой заявке показывает, на какое оборудование в первую очередь закладывать резерв или профилактику — не только по частоте поломок, но и по цене каждого часа простоя.

Разовая поломка или повторяющаяся неисправность

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

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

Как проверить, что учёт заявок на ремонт ведётся правильно

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

Частые ошибки

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

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

Как вести журнал учёта заявок на ремонт оборудования, если оборудования много и оно одинаковое?

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

Чем система заявок на ремонт отличается от обычной системы заявок на обслуживание?

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

Как учитывать заявку, если оборудование забрали к стороннему сервису?

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

Нужен ли отдельный журнал заявок на ремонт оборудования, если в компании уже есть общий журнал заявок?

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

Как это устроено в TehProf.kz Support

Модель или инвентарный номер оборудования заводится как пользовательское поле заявки и попадает в фильтры наравне со стандартными полями (подробнее — Список заявок). Канбан-доска со статусами заявки — в том числе «Отложена», подходящим для ожидания детали до указанной даты, — показывает, на каком этапе застряла каждая заявка, без необходимости открывать их по одной (см. Канбан-доска). Повторные заявки по одному и тому же оборудованию можно объединить в одну, чтобы видеть полную историю поломок единицы в одной карточке, а не в разрозненных (Объединение заявок).

Что программа закрывает для сервисного центра и мастерской, а чего в ней нет (склада запчастей и кассы) — на странице Программа для сервисного центра.

Связанные статьи

• Техподдержка программного продукта: как организовать
• Колл-центр клиники: запись пациентов и обращения
• Клиентский сервис в банке: стандарты и сроки ответа
• Техподдержка интернет-провайдера: как устроить линии
• Система заявок: как выбрать программу для обращений