Систему учёта заявок проще собрать под свой процесс, чем вести второй учёт рядом с Service Desk

Сообщение сохраняют, но отвечать за него никто не начинает. История переписки ещё не объясняет, у кого сейчас работа.

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

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

Сначала проверьте готовый Service Desk. В Okdesk добавляют свои статусы и переходы, в Zammad задают обязательность полей по условиям.

У Zammad есть пример обязательной категории при закрытии. Ради этого правила новую систему писать незачем: документы проверены 7 октября 2026.

Повод для разработки: после настройки решение всё ещё переносят руками. В учебном примере выезд и выполнение живут в Excel отдельно от заявки.

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

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

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

Приёмку пишут вместе с маршрутом. «Кнопка работает» ещё не проверяет, что повторная отправка не создаёт дубль.

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

Условия приёмки становятся частью задачи для агента. Здесь принимают проход обращения целиком.

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

Это вход в разговор о разработке. Наш тест не обслуживает парк оборудования и не ведёт выездные работы.

Кадр показывает вход, открытая кухня машины показывает работу над сайтом. Скриншот формы сам по себе не доказывает доставку заявки.

Форма может открываться, а запись или уведомление не состояться. Сторож должен проверять результат действия.

На нашей ленте материалы поступали, а публикаций не было. В истории ниже показано, какое правило выросло из отказа.

Проверяйте создание контрольной записи и её появление у ответственного. Тишина от клиентов не служит ошибкой: в этот день никто мог не написать.

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

На /services есть сценарий «Форма заявок не отвечает 11:12», затем «Починили… 11:40». Это иллюстрация услуги, не замер ремонта.

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

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

На /services «Один проект» стоит 250 000 ₽ в месяц: один поток, одна задача в работе. Это подписка на 7 октября 2026, не смета готовой системы.

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

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

2. Проверьте настройки и интеграции Service Desk. Свои названия статусов ещё не требуют собственного продукта.

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

4. Назначьте поддержку и контроль результата. Открывающаяся форма ещё не доказывает, что заявка дошла до исполнителя.